draft-ietf-ipsecme-ikev2bis-07.txt   draft-ietf-ipsecme-ikev2bis-08.txt 
Network Working Group C. Kaufman Network Working Group C. Kaufman
Internet-Draft Microsoft Internet-Draft Microsoft
Obsoletes: 4306, 4718 P. Hoffman Obsoletes: 4306, 4718 P. Hoffman
(if approved) VPN Consortium (if approved) VPN Consortium
Intended status: Standards Track Y. Nir Intended status: Standards Track Y. Nir
Expires: July 24, 2010 Check Point Expires: August 30, 2010 Check Point
P. Eronen P. Eronen
Nokia Nokia
January 20, 2010 February 26, 2010
Internet Key Exchange Protocol: IKEv2 Internet Key Exchange Protocol: IKEv2
draft-ietf-ipsecme-ikev2bis-07 draft-ietf-ipsecme-ikev2bis-08
Abstract Abstract
This document describes version 2 of the Internet Key Exchange (IKE) This document describes version 2 of the Internet Key Exchange (IKE)
protocol. IKE is a component of IPsec used for performing mutual protocol. IKE is a component of IPsec used for performing mutual
authentication and establishing and maintaining security associations authentication and establishing and maintaining security associations
(SAs). This document replaces and updates RFC 4306, and includes all (SAs). This document replaces and updates RFC 4306, and includes all
of the clarifications from RFC 4718. of the clarifications from RFC 4718.
Status of this Memo Status of this Memo
skipping to change at page 1, line 45 skipping to change at line 44
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 24, 2010. This Internet-Draft will expire on August 30, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 7 skipping to change at line 75
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction
1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 6 1.1. Usage Scenarios
1.1.1. Security Gateway to Security Gateway Tunnel Mode . . 7 1.1.1. Security Gateway to Security Gateway Tunnel Mode
1.1.2. Endpoint-to-Endpoint Transport Mode . . . . . . . . . 7 1.1.2. Endpoint-to-Endpoint Transport Mode
1.1.3. Endpoint to Security Gateway Tunnel Mode . . . . . . 8 1.1.3. Endpoint to Security Gateway Tunnel Mode
1.1.4. Other Scenarios . . . . . . . . . . . . . . . . . . . 9 1.1.4. Other Scenarios
1.2. The Initial Exchanges . . . . . . . . . . . . . . . . . . 9 1.2. The Initial Exchanges
1.3. The CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 12 1.3. The CREATE_CHILD_SA Exchange
1.3.1. Creating New Child SAs with the CREATE_CHILD_SA 1.3.1. Creating New Child SAs with the CREATE_CHILD_SA
Exchange . . . . . . . . . . . . . . . . . . . . . . 13 Exchange
1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange . 15 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange
1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA
Exchange . . . . . . . . . . . . . . . . . . . . . . 15 Exchange
1.4. The INFORMATIONAL Exchange . . . . . . . . . . . . . . . 16 1.4. The INFORMATIONAL Exchange
1.4.1. Deleting an SA with INFORMATIONAL Exchanges . . . . . 17 1.4.1. Deleting an SA with INFORMATIONAL Exchanges
1.5. Informational Messages outside of an IKE SA . . . . . . . 18 1.5. Informational Messages outside of an IKE SA
1.6. Requirements Terminology . . . . . . . . . . . . . . . . 19 1.6. Requirements Terminology
1.7. Significant Differences Between RFC 4306 and This 1.7. Significant Differences Between RFC 4306 and This
Document . . . . . . . . . . . . . . . . . . . . . . . . 19 Document
2. IKE Protocol Details and Variations . . . . . . . . . . . . . 21 2. IKE Protocol Details and Variations
2.1. Use of Retransmission Timers . . . . . . . . . . . . . . 22 2.1. Use of Retransmission Timers
2.2. Use of Sequence Numbers for Message ID . . . . . . . . . 23 2.2. Use of Sequence Numbers for Message ID
2.3. Window Size for Overlapping Requests . . . . . . . . . . 24 2.3. Window Size for Overlapping Requests
2.4. State Synchronization and Connection Timeouts . . . . . . 25 2.4. State Synchronization and Connection Timeouts
2.5. Version Numbers and Forward Compatibility . . . . . . . . 27 2.5. Version Numbers and Forward Compatibility
2.6. IKE SA SPIs and Cookies . . . . . . . . . . . . . . . . . 29 2.6. IKE SA SPIs and Cookies
2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . 31 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD
2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 32 2.7. Cryptographic Algorithm Negotiation
2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 33 2.8. Rekeying
2.8.1. Simultaneous Child SA rekeying . . . . . . . . . . . 35 2.8.1. Simultaneous Child SA rekeying
2.8.2. Simultaneous IKE SA Rekeying . . . . . . . . . . . . 38 2.8.2. Simultaneous IKE SA Rekeying
2.8.3. Rekeying the IKE SA Versus Reauthentication . . . . . 38 2.8.3. Rekeying the IKE SA Versus Reauthentication
2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 39 2.9. Traffic Selector Negotiation
2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 42 2.9.1. Traffic Selectors Violating Own Policy
2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.10. Nonces
2.11. Address and Port Agility . . . . . . . . . . . . . . . . 43 2.11. Address and Port Agility
2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 43 2.12. Reuse of Diffie-Hellman Exponentials
2.13. Generating Keying Material . . . . . . . . . . . . . . . 44 2.13. Generating Keying Material
2.14. Generating Keying Material for the IKE SA . . . . . . . . 45 2.14. Generating Keying Material for the IKE SA
2.15. Authentication of the IKE SA . . . . . . . . . . . . . . 46 2.15. Authentication of the IKE SA
2.16. Extensible Authentication Protocol Methods . . . . . . . 48 2.16. Extensible Authentication Protocol Methods
2.17. Generating Keying Material for Child SAs . . . . . . . . 50 2.17. Generating Keying Material for Child SAs
2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange . . . . 51 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange
2.19. Requesting an Internal Address on a Remote Network . . . 52 2.19. Requesting an Internal Address on a Remote Network
2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 53 2.20. Requesting the Peer's Version
2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 54 2.21. Error Handling
2.21.1. Error Handling in IKE_SA_INIT . . . . . . . . . . . . 54 2.21.1. Error Handling in IKE_SA_INIT
2.21.2. Error Handling in IKE_AUTH . . . . . . . . . . . . . 55 2.21.2. Error Handling in IKE_AUTH
2.21.3. Error Handling after IKE SA is Authenticated . . . . 56 2.21.3. Error Handling after IKE SA is Authenticated
2.21.4. Error Handling Outside IKE SA . . . . . . . . . . . . 56 2.21.4. Error Handling Outside IKE SA
2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 57 2.22. IPComp
2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 58 2.23. NAT Traversal
2.23.1. Transport Mode NAT Traversal . . . . . . . . . . . . 62 2.23.1. Transport Mode NAT Traversal
2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 65 2.24. Explicit Congestion Notification (ECN)
2.25. Exchange Collisions . . . . . . . . . . . . . . . . . . . 65 2.25. Exchange Collisions
2.25.1. Collisions While Rekeying or Closing Child SAs . . . 66 2.25.1. Collisions While Rekeying or Closing Child SAs
2.25.2. Collisions While Rekeying or Closing IKE SAs . . . . 67 2.25.2. Collisions While Rekeying or Closing IKE SAs
3. Header and Payload Formats . . . . . . . . . . . . . . . . . 67 3. Header and Payload Formats
3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 67 3.1. The IKE Header
3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 70 3.2. Generic Payload Header
3.3. Security Association Payload . . . . . . . . . . . . . . 72 3.3. Security Association Payload
3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 74 3.3.1. Proposal Substructure
3.3.2. Transform Substructure . . . . . . . . . . . . . . . 76 3.3.2. Transform Substructure
3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 79 3.3.3. Valid Transform Types by Protocol
3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 79 3.3.4. Mandatory Transform IDs
3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 80 3.3.5. Transform Attributes
3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 82 3.3.6. Attribute Negotiation
3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 83 3.4. Key Exchange Payload
3.5. Identification Payloads . . . . . . . . . . . . . . . . . 84 3.5. Identification Payloads
3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 87 3.6. Certificate Payload
3.7. Certificate Request Payload . . . . . . . . . . . . . . . 89 3.7. Certificate Request Payload
3.8. Authentication Payload . . . . . . . . . . . . . . . . . 91 3.8. Authentication Payload
3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 93 3.9. Nonce Payload
3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 93 3.10. Notify Payload
3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 94 3.10.1. Notify Message Types
3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 97 3.11. Delete Payload
3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 99 3.12. Vendor ID Payload
3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 100 3.13. Traffic Selector Payload
3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 101 3.13.1. Traffic Selector
3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 103 3.14. Encrypted Payload
3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 105 3.15. Configuration Payload
3.15.1. Configuration Attributes . . . . . . . . . . . . . . 106 3.15.1. Configuration Attributes
3.15.2. Meaning of INTERNAL_IP4_SUBNET and 3.15.2. Meaning of INTERNAL_IP4_SUBNET and
INTERNAL_IP6_SUBNET . . . . . . . . . . . . . . . . . 109 INTERNAL_IP6_SUBNET
3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 111 3.15.3. Configuration payloads for IPv6
3.15.4. Address Assignment Failures . . . . . . . . . . . . . 112 3.15.4. Address Assignment Failures
3.16. Extensible Authentication Protocol (EAP) Payload . . . . 113 3.16. Extensible Authentication Protocol (EAP) Payload
4. Conformance Requirements . . . . . . . . . . . . . . . . . . 114 4. Conformance Requirements
5. Security Considerations . . . . . . . . . . . . . . . . . . . 116 5. Security Considerations
5.1. Traffic selector authorization . . . . . . . . . . . . . 119 5.1. Traffic selector authorization
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 120 6. IANA Considerations
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 121 7. Acknowledgements
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 122 8. References
8.1. Normative References . . . . . . . . . . . . . . . . . . 122 8.1. Normative References
8.2. Informative References . . . . . . . . . . . . . . . . . 123 8.2. Informative References
Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 127 Appendix A. Summary of changes from IKEv1
Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 128 Appendix B. Diffie-Hellman Groups
B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 128 B.1. Group 1 - 768 Bit MODP
B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 129 B.2. Group 2 - 1024 Bit MODP
Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 129 Appendix C. Exchanges and Payloads
C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 129 C.1. IKE_SA_INIT Exchange
C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 130 C.2. IKE_AUTH Exchange without EAP
C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 131 C.3. IKE_AUTH Exchange with EAP
C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying
Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 132 Child SAs
C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA . . . . 132 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA
C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 132 C.6. INFORMATIONAL Exchange
Appendix D. Changes Between Internet Draft Versions . . . . . . 132 Appendix D. Changes Between Internet Draft Versions
D.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 133 D.1. Changes from IKEv2 to draft -00
D.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 133 D.2. Changes from draft -00 to draft -01
D.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 135 D.3. Changes from draft -00 to draft -01
D.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 136 D.4. Changes from draft -01 to draft -02
D.5. Changes from draft -02 to draft -03 . . . . . . . . . . . 137 D.5. Changes from draft -02 to draft -03
D.6. Changes from draft -03 to D.6. Changes from draft -03 to
draft-ietf-ipsecme-ikev2bis-00 . . . . . . . . . . . . . 138 draft-ietf-ipsecme-ikev2bis-00
D.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to D.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to
draft-ietf-ipsecme-ikev2bis-01 . . . . . . . . . . . . . 139 draft-ietf-ipsecme-ikev2bis-01
D.8. Changes from draft-ietf-ipsecme-ikev2bis-01 to D.8. Changes from draft-ietf-ipsecme-ikev2bis-01 to
draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 143 draft-ietf-ipsecme-ikev2bis-02
D.9. Changes from draft-ietf-ipsecme-ikev2bis-01 to D.9. Changes from draft-ietf-ipsecme-ikev2bis-01 to
draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 145 draft-ietf-ipsecme-ikev2bis-02
D.10. Changes from draft-ietf-ipsecme-ikev2bis-02 to D.10. Changes from draft-ietf-ipsecme-ikev2bis-02 to
draft-ietf-ipsecme-ikev2bis-03 . . . . . . . . . . . . . 146 draft-ietf-ipsecme-ikev2bis-03
D.11. Changes from draft-ietf-ipsecme-ikev2bis-03 to D.11. Changes from draft-ietf-ipsecme-ikev2bis-03 to
draft-ietf-ipsecme-ikev2bis-04 . . . . . . . . . . . . . 146 draft-ietf-ipsecme-ikev2bis-04
D.12. Changes from draft-ietf-ipsecme-ikev2bis-04 to D.12. Changes from draft-ietf-ipsecme-ikev2bis-04 to
draft-ietf-ipsecme-ikev2bis-05 . . . . . . . . . . . . . 147 draft-ietf-ipsecme-ikev2bis-05
D.13. Changes from draft-ietf-ipsecme-ikev2bis-05 to D.13. Changes from draft-ietf-ipsecme-ikev2bis-05 to
draft-ietf-ipsecme-ikev2bis-06 . . . . . . . . . . . . . 149 draft-ietf-ipsecme-ikev2bis-06
D.14. Changes from draft-ietf-ipsecme-ikev2bis-06 to D.14. Changes from draft-ietf-ipsecme-ikev2bis-06 to
draft-ietf-ipsecme-ikev2bis-07 . . . . . . . . . . . . . 151 draft-ietf-ipsecme-ikev2bis-07
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 157 D.15. Changes from draft-ietf-ipsecme-ikev2bis-07 to
draft-ietf-ipsecme-ikev2bis-08
Authors' Addresses
1. Introduction 1. Introduction
IP Security (IPsec) provides confidentiality, data integrity, access IP Security (IPsec) provides confidentiality, data integrity, access
control, and data source authentication to IP datagrams. These control, and data source authentication to IP datagrams. These
services are provided by maintaining shared state between the source services are provided by maintaining shared state between the source
and the sink of an IP datagram. This state defines, among other and the sink of an IP datagram. This state defines, among other
things, the specific services provided to the datagram, which things, the specific services provided to the datagram, which
cryptographic algorithms will be used to provide the services, and cryptographic algorithms will be used to provide the services, and
the keys used as input to the cryptographic algorithms. the keys used as input to the cryptographic algorithms.
skipping to change at page 12, line 50 skipping to change at line 533
SAr2, TSi, TSr} SAr2, TSi, TSr}
The responder asserts its identity with the IDr payload, optionally The responder asserts its identity with the IDr payload, optionally
sends one or more certificates (again with the certificate containing sends one or more certificates (again with the certificate containing
the public key used to verify AUTH listed first), authenticates its the public key used to verify AUTH listed first), authenticates its
identity and protects the integrity of the second message with the identity and protects the integrity of the second message with the
AUTH payload, and completes negotiation of a Child SA with the AUTH payload, and completes negotiation of a Child SA with the
additional fields described below in the CREATE_CHILD_SA exchange. additional fields described below in the CREATE_CHILD_SA exchange.
The recipients of messages 3 and 4 MUST verify that all signatures The recipients of messages 3 and 4 MUST verify that all signatures
and MACs are computed correctly and that the names in the ID payloads and MACs are computed correctly. If either side uses a shared secret
correspond to the keys used to generate the AUTH payload. for authentication, the names in the ID payload MUST correspond to
the key used to generate the AUTH payload.
Because the initiator sends its Diffie-Hellman value in the
IKE_SA_INIT, it must guess the Diffie-Hellman group that the
responder will select from its list of supported groups. If the
initiator guesses wrong, the responder will respond with a Notify
payload of type INVALID_KE_PAYLOAD indicating the selected group. In
this case, the initiator MUST retry the IKE_SA_INIT with the
corrected Diffie-Hellman group. The initiator MUST again propose its
full set of acceptable cryptographic suites because the rejection
message was unauthenticated and otherwise an active attacker could
trick the endpoints into negotiating a weaker suite than a stronger
one that they both prefer.
If creating the Child SA during the IKE_AUTH exchange fails for some If creating the Child SA during the IKE_AUTH exchange fails for some
reason, the IKE SA is still created as usual. The list of responses reason, the IKE SA is still created as usual. The list of responses
in the IKE_AUTH exchange that do not prevent an IKE SA from being set in the IKE_AUTH exchange that do not prevent an IKE SA from being set
up include at least the following: NO_PROPOSAL_CHOSEN, up include at least the following: NO_PROPOSAL_CHOSEN,
TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, and TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, and
FAILED_CP_REQUIRED. FAILED_CP_REQUIRED.
If the failure is related to creating the IKE SA (for example, If the failure is related to creating the IKE SA (for example,
AUTHENTICATION_FAILED), the IKE SA is not created. Note that AUTHENTICATION_FAILED), the IKE SA is not created. Note that
skipping to change at page 14, line 35 skipping to change at line 628
reject the request and indicate its preferred Diffie-Hellman group in reject the request and indicate its preferred Diffie-Hellman group in
the INVALID_KE_PAYLOAD Notify payload. There are two octets of data the INVALID_KE_PAYLOAD Notify payload. There are two octets of data
associated with this notification: the accepted D-H Group number in associated with this notification: the accepted D-H Group number in
big endian order. In the case of such a rejection, the big endian order. In the case of such a rejection, the
CREATE_CHILD_SA exchange fails, and the initiator will probably retry CREATE_CHILD_SA exchange fails, and the initiator will probably retry
the exchange with a Diffie-Hellman proposal and KEi in the group that the exchange with a Diffie-Hellman proposal and KEi in the group that
the responder gave in the INVALID_KE_PAYLOAD. the responder gave in the INVALID_KE_PAYLOAD.
The responder sends a NO_ADDITIONAL_SAS notification to indicate that The responder sends a NO_ADDITIONAL_SAS notification to indicate that
a CREATE_CHILD_SA request is unacceptable because the responder is a CREATE_CHILD_SA request is unacceptable because the responder is
unwilling to accept any more Child SAs on this IKE SA. Some minimal unwilling to accept any more Child SAs on this IKE SA. This notify
can also be used to reject IKE SA rekey. Some minimal
implementations may only accept a single Child SA setup in the implementations may only accept a single Child SA setup in the
context of an initial IKE exchange and reject any subsequent attempts context of an initial IKE exchange and reject any subsequent attempts
to add more. to add more.
1.3.1. Creating New Child SAs with the CREATE_CHILD_SA Exchange 1.3.1. Creating New Child SAs with the CREATE_CHILD_SA Exchange
A Child SA may be created by sending a CREATE_CHILD_SA request. The A Child SA may be created by sending a CREATE_CHILD_SA request. The
CREATE_CHILD_SA request for creating a new Child SA is: CREATE_CHILD_SA request for creating a new Child SA is:
Initiator Responder Initiator Responder
skipping to change at page 16, line 40 skipping to change at line 730
A new responder SPI is supplied in the SPI field of the SA payload. A new responder SPI is supplied in the SPI field of the SA payload.
The new IKE SA has its message counters set to 0, regardless of what The new IKE SA has its message counters set to 0, regardless of what
they were in the earlier IKE SA. The first IKE requests from both they were in the earlier IKE SA. The first IKE requests from both
sides on the new IKE SA will have message ID 0. The old IKE SA sides on the new IKE SA will have message ID 0. The old IKE SA
retains its numbering, so any further requests (for example, to retains its numbering, so any further requests (for example, to
delete the IKE SA) will have consecutive numbering. The new IKE SA delete the IKE SA) will have consecutive numbering. The new IKE SA
also has its window size reset to 1, and the initiator in this rekey also has its window size reset to 1, and the initiator in this rekey
exchange is the new "original initiator" of the new IKE SA. exchange is the new "original initiator" of the new IKE SA.
Section 2.18 also covers IKE SA rekeying in detail.
1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA Exchange 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA Exchange
The CREATE_CHILD_SA request for rekeying a Child SA is: The CREATE_CHILD_SA request for rekeying a Child SA is:
Initiator Responder Initiator Responder
------------------------------------------------------------------- -------------------------------------------------------------------
HDR, SK {N(REKEY_SA), SA, Ni, [KEi], HDR, SK {N(REKEY_SA), SA, Ni, [KEi],
TSi, TSr} --> TSi, TSr} -->
The initiator sends SA offer(s) in the SA payload, a nonce in the Ni The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
payload, optionally a Diffie-Hellman value in the KEi payload, and payload, optionally a Diffie-Hellman value in the KEi payload, and
the proposed traffic selectors for the proposed Child SA in the TSi the proposed traffic selectors for the proposed Child SA in the TSi
and TSr payloads. and TSr payloads.
The notifications described in Section 1.3.1 may also be sent in a
rekeying exchange. Usually these will be the same notifications that
were used in the original exchange; for example, when rekeying a
transport mode SA, the USE_TRANSPORT_MODE notification will be used.
The REKEY_SA notification MUST be included in a CREATE_CHILD_SA The REKEY_SA notification MUST be included in a CREATE_CHILD_SA
exchange if the purpose of the exchange is to replace an existing ESP exchange if the purpose of the exchange is to replace an existing ESP
or AH SA. The SA being rekeyed is identified by the SPI field in the or AH SA. The SA being rekeyed is identified by the SPI field in the
Notify payload; this is the SPI the exchange initiator would expect Notify payload; this is the SPI the exchange initiator would expect
in inbound ESP or AH packets. There is no data associated with this in inbound ESP or AH packets. There is no data associated with this
Notify type. The Protocol ID field of the REKEY_SA notification is Notify type. The Protocol ID field of the REKEY_SA notification is
set to match the protocol of the SA we are rekeying, for example, 3 set to match the protocol of the SA we are rekeying, for example, 3
for ESP and 2 for AH. for ESP and 2 for AH.
The CREATE_CHILD_SA response for rekeying a Child SA is: The CREATE_CHILD_SA response for rekeying a Child SA is:
skipping to change at page 18, line 44 skipping to change at line 837
There is one exception. If by chance both ends of a set of SAs There is one exception. If by chance both ends of a set of SAs
independently decide to close them, each may send a delete payload independently decide to close them, each may send a delete payload
and the two requests may cross in the network. If a node receives a and the two requests may cross in the network. If a node receives a
delete request for SAs for which it has already issued a delete delete request for SAs for which it has already issued a delete
request, it MUST delete the outgoing SAs while processing the request request, it MUST delete the outgoing SAs while processing the request
and the incoming SAs while processing the response. In that case, and the incoming SAs while processing the response. In that case,
the responses MUST NOT include delete payloads for the deleted SAs, the responses MUST NOT include delete payloads for the deleted SAs,
since that would result in duplicate deletion and could in theory since that would result in duplicate deletion and could in theory
delete the wrong SA. delete the wrong SA.
Similar to ESP and AH SAs, IKE SAs are also deleted by sending an
Informational exchange. Deleting an IKE SA implicitly closes any
remaining Child SAs negotiated under it. The response to a request
that deletes the IKE SA is an empty INFORMATIONAL response.
Half-closed ESP or AH connections are anomalous, and a node with Half-closed ESP or AH connections are anomalous, and a node with
auditing capability should probably audit their existence if they auditing capability should probably audit their existence if they
persist. Note that this specification nowhere specifies time persist. Note that this specification nowhere specifies time
periods, so it is up to individual endpoints to decide how long to periods, so it is up to individual endpoints to decide how long to
wait. A node MAY refuse to accept incoming data on half-closed wait. A node MAY refuse to accept incoming data on half-closed
connections but MUST NOT unilaterally close them and reuse the SPIs. connections but MUST NOT unilaterally close them and reuse the SPIs.
If connection state becomes sufficiently messed up, a node MAY close If connection state becomes sufficiently messed up, a node MAY close
the IKE SA; doing so will implicitly close all SAs negotiated under the IKE SA, as described above. It can then rebuild the SAs it needs
it. It can then rebuild the SAs it needs on a clean base under a new on a clean base under a new IKE SA.
IKE SA. The response to a request that deletes the IKE SA is an
empty INFORMATIONAL response.
1.5. Informational Messages outside of an IKE SA 1.5. Informational Messages outside of an IKE SA
If an encrypted IKE request packet arrives on port 500 or 4500 with There are some cases in which a node receives a packet that it cannot
an unrecognized SPI, it could be because the receiving node has process, but it may want to notify the sender about this situation.
recently crashed and lost state or because of some other system
malfunction or attack. If the receiving node does not have an active
IKE SA to the IP address from whence the packet came, it MAY send a
notification of the wayward packet with a Notify payload without
cryptographic protection to the source IP address. Such a message is
not part of an INFORMATIONAL exchange, and the receiving node MUST
NOT respond to it. Doing so could cause a message loop.
The INVALID_SPI notification MAY be sent in an IKE INFORMATIONAL o If an ESP or AH packet arrives with an unrecognized SPI. This
exchange when a node receives an ESP or AH packet with an invalid might be due to the receiving node having recently crashed and
SPI. The Notification Data contains the SPI of the invalid packet. lost state, or because of some other system malfunction or attack.
This usually indicates a node has rebooted and forgotten an SA. If
this Notify payload is sent outside the context of an IKE SA, it
should only be used by the recipient as a "hint" that something might
be wrong (because it could easily be forged). The recipient of this
notification cannot tell whether the SPI is for AH or ESP, but this
is not important because the SPIs are supposed to be different for
the two.
There are two cases when a one-way message is sent: INVALID_IKE_SPI o If an encrypted IKE request packet arrives on port 500 or 4500
and INVALID_SPI. These messages are sent outside of an IKE SA. Note with an unrecognized IKE SPI. This might be due to the receiving
that such messages are explicitly not INFORMATIONAL exchanges; these node having recently crashed and lost state, or because of some
are one-way messages that must not be responded to. other system malfunction or attack.
(INVALID_MAJOR_VERSION is also a one-way message which is sent
outside of an IKE SA, although it is sent as a response to the
incoming IKE SA creation.)
In case of INVALID_IKE_SPI, the message sent is a response message, o If an IKE request packet arrives with a higher major version
and thus it is sent to the IP address and port from whence it came number than the implementation supports.
with the same IKE SPIs and the Message ID is copied. The Response
bit is set to 1, and the version flags are set in the normal fashion.
For a one-way INVALID_IKE_SPI notification for an unrecognized SPI,
the responder SHOULD copy the Exchange Type from the request.
In case of INVALID_SPI, however, there are no IKE SPI values that In the first case, if the receiving node has an active IKE SA to the
would be meaningful to the recipient of such a notification. Using IP address from whence the packet came, it MAY send an INVALID_SPI
zero values or random values are both acceptable. The Initiator flag notification of the wayward packet over that IKE SA in an
is set, the Response bit is set to 0, and the version flags are set INFORMATIONAL exchange. The Notification Data contains the SPI of
the invalid packet. The recipient of this notification cannot tell
whether the SPI is for AH or ESP, but this is not important because
the SPIs are supposed to be different for the two. If no suitable
IKE SA exists, the node MAY send an informational message without
cryptographic protection to the source IP address, using the source
UDP port as the destination port if the packet was UDP (UDP-
encapsulated ESP or AH). In this case, it should only be used by the
recipient as a hint that something might be wrong (because it could
easily be forged). This message is not part of an INFORMATIONAL
exchange, and the receiving node MUST NOT respond to it because doing
so could cause a message loop. The message is constructed as
follows: there are no IKE SPI values that would be meaningful to the
recipient of such a notification; using zero values or random values
are both acceptable, this being the exception to the rule in
Section 3.1 that prohibits zero IKE Initiator SPIs. The Initiator
flag is set, the Response bit is set to 0, and the version flags are
set in the normal fashion.
In the second and third cases, the message is always sent without
cryptographic protection (outside of an IKE SA), and includes either
an INVALID_IKE_SPI or an INVALID_MAJOR_VERSION notification (with no
notification data). The message is a response message, and thus it
is sent to the IP address and port from whence it came with the same
IKE SPIs and the Message ID and Exchange Type are copied from the
request. The Response bit is set to 1, and the version flags are set
in the normal fashion. in the normal fashion.
1.6. Requirements Terminology 1.6. Requirements Terminology
Definitions of the primitive terms in this document (such as Security Definitions of the primitive terms in this document (such as Security
Association or SA) can be found in [IPSECARCH]. It should be noted Association or SA) can be found in [IPSECARCH]. It should be noted
that parts of IKEv2 rely on some of the processing rules in that parts of IKEv2 rely on some of the processing rules in
[IPSECARCH], as described in various sections of this document. [IPSECARCH], as described in various sections of this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 21, line 35 skipping to change at line 979
been added since RFC 4306. been added since RFC 4306.
This document adds clarification on when notifications are and are This document adds clarification on when notifications are and are
not sent encrypted, depending on the state of the negotiation at the not sent encrypted, depending on the state of the negotiation at the
time. time.
This document discusses more about how to negotiate combined-mode This document discusses more about how to negotiate combined-mode
ciphers such as GCM and GMAC. ciphers such as GCM and GMAC.
In section 1.3.2, changed "The KEi payload SHOULD be included" to be In section 1.3.2, changed "The KEi payload SHOULD be included" to be
"The KEi payload MUST be included". This also lead to changes in "The KEi payload MUST be included". This also led to changes in
section 2.18. section 2.18.
In Section 2.3, there is new material covering how the initiator's In Section 2.1, there is new material covering how the initiator's
SPI and/or IP is used to differentiate if this is a "half-open" IKE SPI and/or IP is used to differentiate if this is a "half-open" IKE
SA or a new request. SA or a new request.
This document clarifies the use of the critical flag in Section 2.5. This document clarifies the use of the critical flag in Section 2.5.
In 2.8, changed "Note that, when rekeying, the new Child SA MAY have In 2.8, changed "Note that, when rekeying, the new Child SA MAY have
different traffic selectors and algorithms than the old one" to "Note different traffic selectors and algorithms than the old one" to "Note
that, when rekeying, the new Child SA SHOULD NOT have different that, when rekeying, the new Child SA SHOULD NOT have different
traffic selectors and algorithms than the old one". traffic selectors and algorithms than the old one".
skipping to change at page 22, line 19 skipping to change at line 1011
Section 2.18 requires doing a Diffie-Hellman exchange when rekeying Section 2.18 requires doing a Diffie-Hellman exchange when rekeying
the IKE_SA. In theory, RFC 4306 allowed a policy where the Diffie- the IKE_SA. In theory, RFC 4306 allowed a policy where the Diffie-
Hellman exchange was optional, but this was not useful (or Hellman exchange was optional, but this was not useful (or
appropriate) when rekeying the IKE_SA. appropriate) when rekeying the IKE_SA.
Section 2.21 has been greatly expanded to cover the different cases Section 2.21 has been greatly expanded to cover the different cases
where error responses are needed and the appropriate responses to where error responses are needed and the appropriate responses to
them. them.
Section 2.23 clarified that, in NAT traversal, now both UDP
encapsulated IPsec packets and non-UDP encapsulated IPsec packets
packets need to be understood when receiving.
Added Section 2.23.1 to describe NAT traversal when transport mode is Added Section 2.23.1 to describe NAT traversal when transport mode is
requested. requested.
All of Section 2.25 was added to explain how to act when there are All of Section 2.25 was added to explain how to act when there are
timing collisions when deleting and/or rekeying SAs, and two new timing collisions when deleting and/or rekeying SAs, and two new
error notifications (TEMPORARY_FAILURE and CHILD_SA_NOT_FOUND) were error notifications (TEMPORARY_FAILURE and CHILD_SA_NOT_FOUND) were
defined. defined.
In Section 3.6, added "Implementations MUST support the HTTP method In Section 3.6, added "Implementations MUST support the HTTP method
for hash-and-URL lookup. The behavior of other URL methods is not for hash-and-URL lookup. The behavior of other URL methods is not
skipping to change at page 23, line 45 skipping to change at line 1089
initiate requests at any time, and there can be many requests and initiate requests at any time, and there can be many requests and
responses "in flight" at any given moment. But each message is responses "in flight" at any given moment. But each message is
labeled as either a request or a response, and for each request/ labeled as either a request or a response, and for each request/
response pair one end of the security association is the initiator response pair one end of the security association is the initiator
and the other is the responder. and the other is the responder.
For every pair of IKE messages, the initiator is responsible for For every pair of IKE messages, the initiator is responsible for
retransmission in the event of a timeout. The responder MUST never retransmission in the event of a timeout. The responder MUST never
retransmit a response unless it receives a retransmission of the retransmit a response unless it receives a retransmission of the
request. In that event, the responder MUST ignore the retransmitted request. In that event, the responder MUST ignore the retransmitted
request except insofar as it triggers a retransmission of the request except insofar as it causes a retransmission of the response.
response. The initiator MUST remember each request until it receives The initiator MUST remember each request until it receives the
the corresponding response. The responder MUST remember each corresponding response. The responder MUST remember each response
response until it receives a request whose sequence number is larger until it receives a request whose sequence number is larger than or
than or equal to the sequence number in the response plus its window equal to the sequence number in the response plus its window size
size (see Section 2.3). In order to allow saving memory, responders (see Section 2.3). In order to allow saving memory, responders are
are allowed to forget the response after a timeout of several allowed to forget the response after a timeout of several minutes.
minutes. If the responder receives a retransmitted request for which If the responder receives a retransmitted request for which it has
it has already forgotten the response, it MUST ignore the request already forgotten the response, it MUST ignore the request (and not,
(and not, for example, attempt constructing a new response). for example, attempt constructing a new response).
IKE is a reliable protocol: the initiator MUST retransmit a request IKE is a reliable protocol: the initiator MUST retransmit a request
until either it receives a corresponding response, or until it deems until either it receives a corresponding response, or until it deems
the IKE SA to have failed. In the latter case, the initiator the IKE SA to have failed. In the latter case, the initiator
discards all state associated with the IKE SA and any Child SAs that discards all state associated with the IKE SA and any Child SAs that
were negotiated using that IKE SA. A retransmission from the were negotiated using that IKE SA. A retransmission from the
initiator MUST be bitwise identical to the original request. That initiator MUST be bitwise identical to the original request. That
is, everything starting from the IKE Header (the IKE SA initiator's is, everything starting from the IKE Header (the IKE SA initiator's
SPI onwards) must be bitwise identical; items before it (such as the SPI onwards) must be bitwise identical; items before it (such as the
IP and UDP headers) do not have to be identical. IP and UDP headers) do not have to be identical.
skipping to change at page 24, line 33 skipping to change at line 1125
creates a new IKE SA and sends a fresh response), or it belongs to an creates a new IKE SA and sends a fresh response), or it belongs to an
existing IKE SA where the IKE_AUTH request has been already received existing IKE SA where the IKE_AUTH request has been already received
(in which case the responder ignores it). (in which case the responder ignores it).
It is not sufficient to use the initiator's SPI and/or IP address to It is not sufficient to use the initiator's SPI and/or IP address to
differentiate between these three cases because two different peers differentiate between these three cases because two different peers
behind a single NAT could choose the same initiator SPI. Instead, a behind a single NAT could choose the same initiator SPI. Instead, a
robust responder will do the IKE SA lookup using the whole packet, robust responder will do the IKE SA lookup using the whole packet,
its hash, or the Ni payload. its hash, or the Ni payload.
The retransmission policy for one-way messages is somewhat different
from that for regular messages. Because no acknowledgement is ever
sent, there is no reason to gratuitously retransmit one-way messages.
Given that all these messages are errors, it makes sense to send them
only once per "offending" packet, and only retransmit if further
offending packets are received. Still, it also makes sense to limit
retransmissions of such error messages.
2.2. Use of Sequence Numbers for Message ID 2.2. Use of Sequence Numbers for Message ID
Every IKE message contains a Message ID as part of its fixed header. Every IKE message contains a Message ID as part of its fixed header.
This Message ID is used to match up requests and responses, and to This Message ID is used to match up requests and responses, and to
identify retransmissions of messages. identify retransmissions of messages.
The Message ID is a 32-bit quantity, which is zero for the The Message ID is a 32-bit quantity, which is zero for the
IKE_SA_INIT messages (including retries of the message due to IKE_SA_INIT messages (including retries of the message due to
responses such as COOKIE and INVALID_KE_PAYLOAD), and incremented for responses such as COOKIE and INVALID_KE_PAYLOAD), and incremented for
each subsequent exchange. Thus, the first pair of IKE_AUTH messages each subsequent exchange. Thus, the first pair of IKE_AUTH messages
skipping to change at page 30, line 25 skipping to change at line 1413
Although new payload types may be added in the future and may appear Although new payload types may be added in the future and may appear
interleaved with the fields defined in this specification, interleaved with the fields defined in this specification,
implementations SHOULD send the payloads defined in this implementations SHOULD send the payloads defined in this
specification in the order shown in the figures in Sections 1 and 2; specification in the order shown in the figures in Sections 1 and 2;
implementations MUST NOT reject as invalid a message with those implementations MUST NOT reject as invalid a message with those
payloads in any other order. payloads in any other order.
2.6. IKE SA SPIs and Cookies 2.6. IKE SA SPIs and Cookies
The term "cookies" originates with Karn and Simpson [PHOTURIS] in The initial two eight-octet fields in the header, called the "IKE
Photuris, an early proposal for key management with IPsec, and it has SPIs", are used as a connection identifier at the beginning of IKE
persisted. The Internet Security Association and Key Management packets. Each endpoint chooses one of the two SPIs and MUST choose
Protocol (ISAKMP) [ISAKMP] fixed message header includes two eight- them so as to be unique identifiers of an IKE SA. An SPI value of
octet fields titled "cookies", and that syntax is used by both IKEv1 zero is special: it indicates that the remote SPI value is not yet
and IKEv2, although in IKEv2 they are referred to as the "IKE SPI" known by the sender.
and there is a new separate field in a Notify payload holding the
cookie. The initial two eight-octet fields in the header are used as
a connection identifier at the beginning of IKE packets. Each
endpoint chooses one of the two SPIs and MUST choose them so as to be
unique identifiers of an IKE SA. An SPI value of zero is special and
indicates that the remote SPI value is not yet known by the sender.
Incoming IKE packets are mapped to an IKE SA only using the packet's Incoming IKE packets are mapped to an IKE SA only using the packet's
SPI, not using (for example) the source IP address of the packet. SPI, not using (for example) the source IP address of the packet.
Unlike ESP and AH where only the recipient's SPI appears in the Unlike ESP and AH where only the recipient's SPI appears in the
header of a message, in IKE the sender's SPI is also sent in every header of a message, in IKE the sender's SPI is also sent in every
message. Since the SPI chosen by the original initiator of the IKE message. Since the SPI chosen by the original initiator of the IKE
SA is always sent first, an endpoint with multiple IKE SAs open that SA is always sent first, an endpoint with multiple IKE SAs open that
wants to find the appropriate IKE SA using the SPI it assigned must wants to find the appropriate IKE SA using the SPI it assigned must
look at the I(nitiator) Flag bit in the header to determine whether look at the I(nitiator) Flag bit in the header to determine whether
skipping to change at page 32, line 19 skipping to change at line 1497
<VersionIDofSecret> should be changed whenever <secret> is <VersionIDofSecret> should be changed whenever <secret> is
regenerated. The cookie can be recomputed when the IKE_SA_INIT regenerated. The cookie can be recomputed when the IKE_SA_INIT
arrives the second time and compared to the cookie in the received arrives the second time and compared to the cookie in the received
message. If it matches, the responder knows that the cookie was message. If it matches, the responder knows that the cookie was
generated since the last change to <secret> and that IPi must be the generated since the last change to <secret> and that IPi must be the
same as the source address it saw the first time. Incorporating SPIi same as the source address it saw the first time. Incorporating SPIi
into the calculation ensures that if multiple IKE SAs are being set into the calculation ensures that if multiple IKE SAs are being set
up in parallel they will all get different cookies (assuming the up in parallel they will all get different cookies (assuming the
initiator chooses unique SPIi's). Incorporating Ni in the hash initiator chooses unique SPIi's). Incorporating Ni in the hash
ensures that an attacker who sees only message 2 can't successfully ensures that an attacker who sees only message 2 can't successfully
forge a message 3. Also, incorporating SPi in the hash prevents an forge a message 3. Also, incorporating SPIi in the hash prevents an
attacker from fetching one cookie from the other end, and then attacker from fetching one cookie from the other end, and then
initiating many IKE_SA_INIT exchanges all with different initiator initiating many IKE_SA_INIT exchanges all with different initiator
SPIs (and perhaps port numbers) so that the responder thinks that SPIs (and perhaps port numbers) so that the responder thinks that
there are lots of machines behind one NAT box who are all trying to there are lots of machines behind one NAT box who are all trying to
connect. connect.
If a new value for <secret> is chosen while there are connections in If a new value for <secret> is chosen while there are connections in
the process of being initialized, an IKE_SA_INIT might be returned the process of being initialized, an IKE_SA_INIT might be returned
with other than the current <VersionIDofSecret>. The responder in with other than the current <VersionIDofSecret>. The responder in
that case MAY reject the message by sending another response with a that case MAY reject the message by sending another response with a
skipping to change at page 32, line 44 skipping to change at line 1522
protection. The responder should change the value of <secret> protection. The responder should change the value of <secret>
frequently, especially if under attack. frequently, especially if under attack.
When one party receives an IKE_SA_INIT request containing a cookie When one party receives an IKE_SA_INIT request containing a cookie
whose contents do not match the value expected, that party MUST whose contents do not match the value expected, that party MUST
ignore the cookie and process the message as if no cookie had been ignore the cookie and process the message as if no cookie had been
included; usually this means sending a response containing a new included; usually this means sending a response containing a new
cookie. The initiator should limit the number of cookie exchanges it cookie. The initiator should limit the number of cookie exchanges it
tries before giving up. An attacker can forge multiple cookie tries before giving up. An attacker can forge multiple cookie
responses to the initiator's IKE_SA_INIT message, and each of those responses to the initiator's IKE_SA_INIT message, and each of those
forged cookie replies will trigger two packets: one packet from the forged cookie replies will cause two packets: one packet from the
initiator to the responder (which will reject those cookies), and one initiator to the responder (which will reject those cookies), and one
response from responder to initiator that includes the correct response from responder to initiator that includes the correct
cookie. cookie.
A note on terminology: the term "cookies" originates with Karn and
Simpson [PHOTURIS] in Photuris, an early proposal for key management
with IPsec, and it has persisted. The Internet Security Association
and Key Management Protocol (ISAKMP) [ISAKMP] fixed message header
includes two eight-octet fields called "cookies", and that syntax is
used by both IKEv1 and IKEv2, although in IKEv2 they are referred to
as the "IKE SPI" and there is a new separate field in a Notify
payload holding the cookie.
2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD
There are two common reasons why the initiator may have to retry the There are two common reasons why the initiator may have to retry the
IKE_SA_INIT exchange: the responder requests a cookie or wants a IKE_SA_INIT exchange: the responder requests a cookie or wants a
different Diffie-Hellman group than was included in the KEi payload. different Diffie-Hellman group than was included in the KEi payload.
If the initiator receives a cookie from the responder, the initiator If the initiator receives a cookie from the responder, the initiator
needs to decide whether or not to include the cookie in only the next needs to decide whether or not to include the cookie in only the next
retry of the IKE_SA_INIT request, or in all subsequent retries as retry of the IKE_SA_INIT request, or in all subsequent retries as
well. well.
If the initiator includes the cookie only in the next retry, one If the initiator includes the cookie only in the next retry, one
additional roundtrip may be needed in some cases. An additional additional roundtrip may be needed in some cases. An additional
roundtrip is needed also if the initiator includes the cookie in all roundtrip is needed also if the initiator includes the cookie in all
retries, but the responder does not support this. For instance, if retries, but the responder does not support this. For instance, if
the responder includes the SAi1 and KEi payloads in cookie the responder includes the KEi payloads in cookie calculation, it
calculation, it will reject the request by sending a new cookie. will reject the request by sending a new cookie.
If both peers support including the cookie in all retries, a slightly If both peers support including the cookie in all retries, a slightly
shorter exchange can happen. shorter exchange can happen.
Initiator Responder Initiator Responder
----------------------------------------------------------- -----------------------------------------------------------
HDR(A,0), SAi1, KEi, Ni --> HDR(A,0), SAi1, KEi, Ni -->
<-- HDR(A,0), N(COOKIE) <-- HDR(A,0), N(COOKIE)
HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> HDR(A,0), N(COOKIE), SAi1, KEi, Ni -->
<-- HDR(A,0), N(INVALID_KE_PAYLOAD) <-- HDR(A,0), N(INVALID_KE_PAYLOAD)
skipping to change at page 34, line 25 skipping to change at line 1609
combinations are acceptable. combinations are acceptable.
If an initiator proposes both normal ciphers with integrity If an initiator proposes both normal ciphers with integrity
protection as well as combined-mode ciphers, then two proposals are protection as well as combined-mode ciphers, then two proposals are
needed. One of the proposals includes the normal ciphers with the needed. One of the proposals includes the normal ciphers with the
integrity algoritms for them, and the other proposal includes all the integrity algoritms for them, and the other proposal includes all the
combined mode ciphers without the integrity algorithms (because combined mode ciphers without the integrity algorithms (because
combined mode ciphers are not allowed to have any integrity algorithm combined mode ciphers are not allowed to have any integrity algorithm
other than "none"). other than "none").
Since the initiator sends its Diffie-Hellman value in the
IKE_SA_INIT, it must guess the Diffie-Hellman group that the
responder will select from its list of supported groups. If the
initiator guesses wrong, the responder will respond with a Notify
payload of type INVALID_KE_PAYLOAD indicating the selected group. In
this case, the initiator MUST retry the IKE_SA_INIT with the
corrected Diffie-Hellman group. The initiator MUST again propose its
full set of acceptable cryptographic suites because the rejection
message was unauthenticated and otherwise an active attacker could
trick the endpoints into negotiating a weaker suite than a stronger
one that they both prefer.
When the IKE_SA_INIT exchange does not result in the creation of an When the IKE_SA_INIT exchange does not result in the creation of an
IKE SA due to INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN, or COOKIE (see IKE SA due to INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN, or COOKIE (see
Section 2.6), the responder's SPI will be zero. However, if the Section 2.6), the responder's SPI will be zero. However, if the
responder sends a non-zero responder SPI, the initiator should not responder sends a non-zero responder SPI, the initiator should not
reject the response for only that reason. reject the response for only that reason.
2.8. Rekeying 2.8. Rekeying
IKE, ESP, and AH security associations use secret keys that should be IKE, ESP, and AH security associations use secret keys that should be
used only for a limited amount of time and to protect a limited used only for a limited amount of time and to protect a limited
skipping to change at page 36, line 28 skipping to change at line 1695
the responder to know when it is OK to send on the newly created SA? the responder to know when it is OK to send on the newly created SA?
From a technical correctness and interoperability perspective, the From a technical correctness and interoperability perspective, the
responder MAY begin sending on an SA as soon as it sends its response responder MAY begin sending on an SA as soon as it sends its response
to the CREATE_CHILD_SA request. In some situations, however, this to the CREATE_CHILD_SA request. In some situations, however, this
could result in packets unnecessarily being dropped, so an could result in packets unnecessarily being dropped, so an
implementation MAY defer such sending. implementation MAY defer such sending.
The responder can be assured that the initiator is prepared to The responder can be assured that the initiator is prepared to
receive messages on an SA if either (1) it has received a receive messages on an SA if either (1) it has received a
cryptographically valid message on the new SA, or (2) the new SA cryptographically valid message on the other half of the SA pair, or
rekeys an existing SA and it receives an IKE request to close the (2) the new SA rekeys an existing SA and it receives an IKE request
replaced SA. When rekeying an SA, the responder continues to send to close the replaced SA. When rekeying an SA, the responder
traffic on the old SA until one of those events occurs. When continues to send traffic on the old SA until one of those events
establishing a new SA, the responder MAY defer sending messages on a occurs. When establishing a new SA, the responder MAY defer sending
new SA until either it receives one or a timeout has occurred. If an messages on a new SA until either it receives one or a timeout has
initiator receives a message on an SA for which it has not received a occurred. If an initiator receives a message on an SA for which it
response to its CREATE_CHILD_SA request, it interprets that as a has not received a response to its CREATE_CHILD_SA request, it
likely packet loss and retransmits the CREATE_CHILD_SA request. An interprets that as a likely packet loss and retransmits the
initiator MAY send a dummy message on a newly created SA if it has no CREATE_CHILD_SA request. An initiator MAY send a dummy ESP message
messages queued in order to assure the responder that the initiator on a newly created ESP SA if it has no messages queued in order to
is ready to receive messages. assure the responder that the initiator is ready to receive messages.
2.8.1. Simultaneous Child SA rekeying 2.8.1. Simultaneous Child SA rekeying
If the two ends have the same lifetime policies, it is possible that If the two ends have the same lifetime policies, it is possible that
both will initiate a rekeying at the same time (which will result in both will initiate a rekeying at the same time (which will result in
redundant SAs). To reduce the probability of this happening, the redundant SAs). To reduce the probability of this happening, the
timing of rekeying requests SHOULD be jittered (delayed by a random timing of rekeying requests SHOULD be jittered (delayed by a random
amount of time after the need for rekeying is noticed). amount of time after the need for rekeying is noticed).
This form of rekeying may temporarily result in multiple similar SAs This form of rekeying may temporarily result in multiple similar SAs
skipping to change at page 39, line 10 skipping to change at line 1818
recv resp1 <-- recv resp1 <--
When A receives this error, it already knows there was simultaneous When A receives this error, it already knows there was simultaneous
rekeying, so it can ignore the error message. rekeying, so it can ignore the error message.
2.8.2. Simultaneous IKE SA Rekeying 2.8.2. Simultaneous IKE SA Rekeying
Probably the most complex case occurs when both peers try to rekey Probably the most complex case occurs when both peers try to rekey
the IKE_SA at the same time. Basically, the text in Section 2.8 the IKE_SA at the same time. Basically, the text in Section 2.8
applies to this case as well; however, it is important to ensure that applies to this case as well; however, it is important to ensure that
the CHILD_SAs are inherited by the right IKE_SA. the Child SAs are inherited by the correct IKE_SA.
The case where both endpoints notice the simultaneous rekeying works The case where both endpoints notice the simultaneous rekeying works
the same way as with Child SAs. After the CREATE_CHILD_SA exchanges, the same way as with Child SAs. After the CREATE_CHILD_SA exchanges,
three IKE SAs exist between A and B: the old IKE SA and two new IKE three IKE SAs exist between A and B: the old IKE SA and two new IKE
SAs. The new IKE SA containing the lowest nonce inherits the Child SAs. The new IKE SA containing the lowest nonce SHOULD be deleted by
SAs. the node that created it, and the other suriving new IKE SA MUST
inherit all the Child SAs.
If only one peer detects a simultaneous rekey, redundant SAs are not In addition to normal simultaneous rekeying cases, there is a special
created. In this case, when the peer that did not notice the case where one peer finishes its rekey before it even notices that
simultaneous rekey gets the request to rekey the IKE SA that it has other peer is doing a rekey. If only one peer detects a simultaneous
already successfully rekeyed, it SHOULD return TEMPORARY_FAILURE rekey, redundant SAs are not created. In this case, when the peer
because it is an IKE SA that it is currently trying to close (whether that did not notice the simultaneous rekey gets the request to rekey
or not it has already sent the delete notification for the SA). If the IKE SA that it has already successfully rekeyed, it SHOULD return
the peer that did notice the simultaneous rekey gets the delete TEMPORARY_FAILURE because it is an IKE SA that it is currently trying
request from the other peer for the old IKE SA, it knows that the to close (whether or not it has already sent the delete notification
other peer did not detect the simultaneous rekey, and the first peer for the SA). If the peer that did notice the simultaneous rekey gets
can forget its own rekey attempt. the delete request from the other peer for the old IKE SA, it knows
that the other peer did not detect the simultaneous rekey, and the
first peer can forget its own rekey attempt.
Host A Host B Host A Host B
------------------------------------------------------------------- -------------------------------------------------------------------
send req1: send req1:
SA(..,SPIa1,..),Ni1,.. --> SA(..,SPIa1,..),Ni1,.. -->
<-- send req2: SA(..,SPIb1,..),Ni2,.. <-- send req2: SA(..,SPIb1,..),Ni2,..
--> recv req1 --> recv req1
<-- send resp1: SA(..,SPIb2,..),Nr2,.. <-- send resp1: SA(..,SPIb2,..),Nr2,..
recv resp1 <-- recv resp1 <--
send req3: D() --> send req3: D() -->
--> recv req3 --> recv req3
At this point, host B sees a request to close the IKE_SA. There's At this point, host B sees a request to close the IKE_SA. There's
not much more to do than to reply as usual. However, at this point not much more to do than to reply as usual. However, at this point
host B should stop retransmitting req2, since once host A receives host B should stop retransmitting req2, since once host A receives
resp3, it will delete all the state associated with the old IKE_SA resp3, it will delete all the state associated with the old IKE_SA
and will not be able to reply to it. and will not be able to reply to it.
<-- send resp3: () <-- send resp3: ()
Support of the TEMPORARY_FAILURE notification is not negotiated, so
older peers may receive these notifications. In that case, they will
treat it the same as any other unknown error notification, and will
stop the exchange. Because the other peer has already rekeyed the
exchange, doing so does not have any ill effects.
2.8.3. Rekeying the IKE SA Versus Reauthentication 2.8.3. Rekeying the IKE SA Versus Reauthentication
Rekeying the IKE SA and reauthentication are different concepts in Rekeying the IKE SA and reauthentication are different concepts in
IKEv2. Rekeying the IKE SA establishes new keys for the IKE SA and IKEv2. Rekeying the IKE SA establishes new keys for the IKE SA and
resets the Message ID counters, but it does not authenticate the resets the Message ID counters, but it does not authenticate the
parties again (no AUTH or EAP payloads are involved). parties again (no AUTH or EAP payloads are involved).
Although rekeying the IKE SA may be important in some environments, Although rekeying the IKE SA may be important in some environments,
reauthentication (the verification that the parties still have access reauthentication (the verification that the parties still have access
to the long-term credentials) is often more important. to the long-term credentials) is often more important.
skipping to change at page 41, line 34 skipping to change at line 1948
information. Since the two endpoints may be configured by different information. Since the two endpoints may be configured by different
people, the incompatibility may persist for an extended period even people, the incompatibility may persist for an extended period even
in the absence of errors. It also allows for intentionally different in the absence of errors. It also allows for intentionally different
configurations, as when one end is configured to tunnel all addresses configurations, as when one end is configured to tunnel all addresses
and depends on the other end to have the up-to-date list. and depends on the other end to have the up-to-date list.
When the responder chooses a subset of the traffic proposed by the When the responder chooses a subset of the traffic proposed by the
initiator, it narrows the traffic selectors to some subset of the initiator, it narrows the traffic selectors to some subset of the
initiator's proposal (provided the set does not become the null set). initiator's proposal (provided the set does not become the null set).
If the type of traffic selector proposed is unknown, the responder If the type of traffic selector proposed is unknown, the responder
ignores that traffic selector, so that the unknown type is not be ignores that traffic selector, so that the unknown type is not
returned in the narrowed set. returned in the narrowed set.
If the initiator requests an SA because it wants to send a data To enable the responder to choose the appropriate range in this case,
packet, including the specific addresses in the packet triggering the if the initiator has requested the SA due to a data packet, the
request in the first traffic selector in both TSi and TSr enables the initiator SHOULD include as the first traffic selector in each of TSi
responder to choose the appropriate range. In the example, the and TSr a very specific traffic selector including the addresses in
initiator would include in TSi two traffic selectors: the first the packet triggering the request. In the example, the initiator
containing the address range (198.51.100.43 - 198.51.100.43) and the would include in TSi two traffic selectors: the first containing the
source port and IP protocol from the packet and the second containing address range (198.51.100.43 - 198.51.100.43) and the source port and
(198.51.100.0 - 198.51.100.255) with all ports and IP protocols. The IP protocol from the packet and the second containing (198.51.100.0 -
initiator would similarly include two traffic selectors in TSr. If 198.51.100.255) with all ports and IP protocols. The initiator would
the initiator creates the Child SA pair not in response to an similarly include two traffic selectors in TSr. If the initiator
arriving packet, but rather, say, upon startup, then there may be no creates the Child SA pair not in response to an arriving packet, but
specific addresses the initiator prefers for the initial tunnel over rather, say, upon startup, then there may be no specific addresses
any other. In that case, the first values in TSi and TSr can be the initiator prefers for the initial tunnel over any other. In that
ranges rather than specific values. case, the first values in TSi and TSr can be ranges rather than
specific values.
The responder performs the narrowing as follows: The responder performs the narrowing as follows:
o If the responder's policy does not allow it to accept any part of o If the responder's policy does not allow it to accept any part of
the proposed traffic selectors, it responds with TS_UNACCEPTABLE. the proposed traffic selectors, it responds with TS_UNACCEPTABLE.
o If the responder's policy allows the entire set of traffic covered o If the responder's policy allows the entire set of traffic covered
by TSi and TSr, no narrowing is necessary, and the responder can by TSi and TSr, no narrowing is necessary, and the responder can
return the same TSi and TSr values. return the same TSi and TSr values.
skipping to change at page 47, line 8 skipping to change at line 2213
(indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er,
SK_pi, and SK_pr are taken in order from the generated bits of the SK_pi, and SK_pr are taken in order from the generated bits of the
prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman
exchange. g^ir is represented as a string of octets in big endian exchange. g^ir is represented as a string of octets in big endian
order padded with zeros if necessary to make it the length of the order padded with zeros if necessary to make it the length of the
modulus. Ni and Nr are the nonces, stripped of any headers. For modulus. Ni and Nr are the nonces, stripped of any headers. For
historical backwards-compatibility reasons, there are two PRFs that historical backwards-compatibility reasons, there are two PRFs that
are treated specially in this calculation. If the negotiated PRF is are treated specially in this calculation. If the negotiated PRF is
AES-XCBC-PRF-128 [AESXCBCPRF128] or AES-CMAC-PRF-128 [AESCMACPRF128], AES-XCBC-PRF-128 [AESXCBCPRF128] or AES-CMAC-PRF-128 [AESCMACPRF128],
only the first 64 bits of Ni and the first 64 bits of Nr are used in only the first 64 bits of Ni and the first 64 bits of Nr are used in
the calculation. calculating SKEYSEED, but all the bits are used for input to the prf+
function.
The two directions of traffic flow use different keys. The keys used The two directions of traffic flow use different keys. The keys used
to protect messages from the original initiator are SK_ai and SK_ei. to protect messages from the original initiator are SK_ai and SK_ei.
The keys used to protect messages in the other direction are SK_ar The keys used to protect messages in the other direction are SK_ar
and SK_er. and SK_er.
2.15. Authentication of the IKE SA 2.15. Authentication of the IKE SA
When not using extensible authentication (see Section 2.16), the When not using extensible authentication (see Section 2.16), the
peers are authenticated by having each sign (or MAC using a padded peers are authenticated by having each sign (or MAC using a padded
skipping to change at page 49, line 21 skipping to change at line 2321
protocols other than IKEv2. As noted above, deriving the shared protocols other than IKEv2. As noted above, deriving the shared
secret from a password is not secure. This construction is used secret from a password is not secure. This construction is used
because it is anticipated that people will do it anyway. The because it is anticipated that people will do it anyway. The
management interface by which the Shared Secret is provided MUST management interface by which the Shared Secret is provided MUST
accept ASCII strings of at least 64 octets and MUST NOT add a null accept ASCII strings of at least 64 octets and MUST NOT add a null
terminator before using them as shared secrets. It MUST also accept terminator before using them as shared secrets. It MUST also accept
a hex encoding of the Shared Secret. The management interface MAY a hex encoding of the Shared Secret. The management interface MAY
accept other encodings if the algorithm for translating the encoding accept other encodings if the algorithm for translating the encoding
to a binary string is specified. to a binary string is specified.
There are two types of EAP authentication (described in
Section 2.16), and each type uses different values in the AUTH
computations shown above. If the EAP method is key-generating,
substitute MSK for the Shared Secret in the computation. For non-
key-generating methods, substitute SK_pi and SK_pr, respectively, for
the Shared Secret in the two AUTH computations.
2.16. Extensible Authentication Protocol Methods 2.16. Extensible Authentication Protocol Methods
In addition to authentication using public key signatures and shared In addition to authentication using public key signatures and shared
secrets, IKE supports authentication using methods defined in RFC secrets, IKE supports authentication using methods defined in RFC
3748 [EAP]. Typically, these methods are asymmetric (designed for a 3748 [EAP]. Typically, these methods are asymmetric (designed for a
user authenticating to a server), and they may not be mutual. For user authenticating to a server), and they may not be mutual. For
this reason, these protocols are typically used to authenticate the this reason, these protocols are typically used to authenticate the
initiator to the responder and MUST be used in conjunction with a initiator to the responder and MUST be used in conjunction with a
public key signature based authentication of the responder to the public key signature based authentication of the responder to the
initiator. These methods are often associated with mechanisms initiator. These methods are often associated with mechanisms
skipping to change at page 51, line 13 skipping to change at line 2415
included in the two messages following the one containing the EAP included in the two messages following the one containing the EAP
Success message. Success message.
When the initiator authentication uses EAP, it is possible that the When the initiator authentication uses EAP, it is possible that the
contents of the IDi payload is used only for AAA routing purposes and contents of the IDi payload is used only for AAA routing purposes and
selecting which EAP method to use. This value may be different from selecting which EAP method to use. This value may be different from
the identity authenticated by the EAP method. It is important that the identity authenticated by the EAP method. It is important that
policy lookups and access control decisions use the actual policy lookups and access control decisions use the actual
authenticated identity. Often the EAP server is implemented in a authenticated identity. Often the EAP server is implemented in a
separate AAA server that communicates with the IKEv2 responder. In separate AAA server that communicates with the IKEv2 responder. In
this case, the authenticated identity has to be sent from the AAA this case, the authenticated identity, if different from that in the
server to the IKEv2 responder. IDi payload, has to be sent from the AAA server to the IKEv2
responder.
2.17. Generating Keying Material for Child SAs 2.17. Generating Keying Material for Child SAs
A single Child SA is created by the IKE_AUTH exchange, and additional A single Child SA is created by the IKE_AUTH exchange, and additional
Child SAs can optionally be created in CREATE_CHILD_SA exchanges. Child SAs can optionally be created in CREATE_CHILD_SA exchanges.
Keying material for them is generated as follows: Keying material for them is generated as follows:
KEYMAT = prf+(SK_d, Ni | Nr) KEYMAT = prf+(SK_d, Ni | Nr)
Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this
skipping to change at page 51, line 38 skipping to change at line 2441
For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman
exchange, the keying material is defined as: exchange, the keying material is defined as:
KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr ) KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr )
where g^ir (new) is the shared secret from the ephemeral Diffie- where g^ir (new) is the shared secret from the ephemeral Diffie-
Hellman exchange of this CREATE_CHILD_SA exchange (represented as an Hellman exchange of this CREATE_CHILD_SA exchange (represented as an
octet string in big endian order padded with zeros in the high-order octet string in big endian order padded with zeros in the high-order
bits if necessary to make it the length of the modulus). bits if necessary to make it the length of the modulus).
For ESP and AH, a single Child SA negotiation results in two security A single CHILD_SA negotiation may result in multiple security
associations (one in each direction). Keying material MUST be taken associations. ESP and AH SAs exist in pairs (one in each direction),
from the expanded KEYMAT in the following order: so two SAs are created in a single Child SA negotiation for them.
Furthermore, Child SA negotiation may include some future IPsec
o The encryption key (if any) for the SA carrying data from the protocol(s) in addition to, or instead of, ESP or AH (for example,
initiator to the responder. ROHC_INTEG). In any case, keying material for each child SA MUST be
taken from the expanded KEYMAT using the following rules:
o The authentication key (if any) for the SA carrying data from the o All keys for SAs carrying data from the initiator to the responder
initiator to the responder. are taken before SAs going from the responder to the initiator.
o The encryption key (if any) for the SA carrying data from the o If multiple IPsec protocols are negotiated, keying material for
responder to the initiator. each Child SA is taken in the order in which the protocol headers
will appear in the encapsulated packet.
o The authentication key (if any) for the SA carrying data from the o If an IPsec protocol requires multiple keys, the order in which
responder to the initiator. they are taken from the SA's keying material needs to be described
in protocol specification. For ESP and AH, [IPSECARCH] defines
the order, namely: the encryption key (if any) MUST be taken from
the first bits and the integrity key (if any) MUST be taken from
the remaining bits.
Each cryptographic algorithm takes a fixed number of bits of keying Each cryptographic algorithm takes a fixed number of bits of keying
material specified as part of the algorithm, or negotiated in SA material specified as part of the algorithm, or negotiated in SA
payloads (see Section 2.13 for description of key lengths, and payloads (see Section 2.13 for description of key lengths, and
Section 3.3.5 for the definition of the Key Length transform Section 3.3.5 for the definition of the Key Length transform
attribute). attribute).
2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange
The CREATE_CHILD_SA exchange can be used to rekey an existing IKE SA The CREATE_CHILD_SA exchange can be used to rekey an existing IKE SA
(see Section 2.8). New initiator and responder SPIs are supplied in (see and Section 1.3.2 and Section 2.8). New initiator and responder
the SPI fields in the Proposal structures inside the Security SPIs are supplied in the SPI fields in the Proposal structures inside
Association (SA) payloads (not the SPI fields in the IKE header). the Security Association (SA) payloads (not the SPI fields in the IKE
The TS payloads are omitted when rekeying an IKE SA. SKEYSEED for header). The TS payloads are omitted when rekeying an IKE SA.
the new IKE SA is computed using SK_d from the existing IKE SA as SKEYSEED for the new IKE SA is computed using SK_d from the existing
follows: IKE SA as follows:
SKEYSEED = prf(SK_d (old), g^ir (new) | Ni | Nr) SKEYSEED = prf(SK_d (old), g^ir (new) | Ni | Nr)
where g^ir (new) is the shared secret from the ephemeral Diffie- where g^ir (new) is the shared secret from the ephemeral Diffie-
Hellman exchange of this CREATE_CHILD_SA exchange (represented as an Hellman exchange of this CREATE_CHILD_SA exchange (represented as an
octet string in big endian order padded with zeros if necessary to octet string in big endian order padded with zeros if necessary to
make it the length of the modulus) and Ni and Nr are the two nonces make it the length of the modulus) and Ni and Nr are the two nonces
stripped of any headers. stripped of any headers.
The old and new IKE SA may have selected a different PRF. Because The old and new IKE SA may have selected a different PRF. Because
skipping to change at page 54, line 28 skipping to change at line 2578
The responder MUST NOT send a CFG_REPLY without having first received The responder MUST NOT send a CFG_REPLY without having first received
a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS
to perform an unnecessary configuration lookup if the IRAC cannot to perform an unnecessary configuration lookup if the IRAC cannot
process the REPLY. process the REPLY.
In the case where the IRAS's configuration requires that CP be used In the case where the IRAS's configuration requires that CP be used
for a given identity IDi, but IRAC has failed to send a for a given identity IDi, but IRAC has failed to send a
CP(CFG_REQUEST), IRAS MUST fail the request, and terminate the Child CP(CFG_REQUEST), IRAS MUST fail the request, and terminate the Child
SA creation with a FAILED_CP_REQUIRED error. The FAILED_CP_REQUIRED SA creation with a FAILED_CP_REQUIRED error. The FAILED_CP_REQUIRED
is not fatal to the IKE SA; it simply causes the Child SA creation is not fatal to the IKE SA; it simply causes the Child SA creation to
fail. The initiator can fix this by later starting a new fail. The initiator can fix this by later starting a new
configuration payload request. There is no associated data in the configuration payload request. There is no associated data in the
FAILED_CP_REQUIRED error. FAILED_CP_REQUIRED error.
2.20. Requesting the Peer's Version 2.20. Requesting the Peer's Version
An IKE peer wishing to inquire about the other peer's IKE software An IKE peer wishing to inquire about the other peer's IKE software
version information MAY use the method below. This is an example of version information MAY use the method below. This is an example of
a configuration request within an INFORMATIONAL exchange, after the a configuration request within an INFORMATIONAL exchange, after the
IKE SA and first Child SA have been created. IKE SA and first Child SA have been created.
skipping to change at page 55, line 32 skipping to change at line 2623
indicating the error. The decision whether or not to send such a indicating the error. The decision whether or not to send such a
response depends whether or not there is an authenticated IKE SA. response depends whether or not there is an authenticated IKE SA.
If there is an error parsing or processing a response packet, the If there is an error parsing or processing a response packet, the
general rule is to not send back any error message because responses general rule is to not send back any error message because responses
should not generate new requests (and a new request would be the only should not generate new requests (and a new request would be the only
way to send back an error message). Such errors in parsing or way to send back an error message). Such errors in parsing or
processing response packets should still cause the recipient to clean processing response packets should still cause the recipient to clean
up the IKE state (for example, by sending a DELETE for a bad SA). up the IKE state (for example, by sending a DELETE for a bad SA).
Only authentication failures (AUTHENTICATION_FAILED) and malformed Only authentication failures (AUTHENTICATION_FAILED and EAP failure)
messages (INVALID_SYNTAX) lead to a deletion of the IKE SA without and malformed messages (INVALID_SYNTAX) lead to a deletion of the IKE
requiring an explicit INFORMATIONAL exchange carrying a DELETE SA without requiring an explicit INFORMATIONAL exchange carrying a
payload. Other error conditions MAY require such an exchange if DELETE payload. Other error conditions MAY require such an exchange
policy dictates that this is needed. if policy dictates that this is needed. If the exchange is
terminated with EAP Failure, an AUTHENTICATION_FAILED notification is
not sent.
2.21.1. Error Handling in IKE_SA_INIT 2.21.1. Error Handling in IKE_SA_INIT
Errors that occur before a cryptographically protected IKE SA is Errors that occur before a cryptographically protected IKE SA is
established need to be handled very carefully. There is a trade-off established need to be handled very carefully. There is a trade-off
between wanting to help the peer to diagnose a problem and thus between wanting to help the peer to diagnose a problem and thus
responding to the error, and wanting to avoid being part of a denial responding to the error, and wanting to avoid being part of a denial
of service attack based on forged messages. of service attack based on forged messages.
In an IKE_SA_INIT exchange, any error notification causes the In an IKE_SA_INIT exchange, any error notification causes the
skipping to change at page 56, line 38 skipping to change at line 2680
and MUST only lead to an UNSUPPORTED_CRITICAL_PAYLOAD or and MUST only lead to an UNSUPPORTED_CRITICAL_PAYLOAD or
INVALID_SYNTAX Notification sent as a response. The receiver should INVALID_SYNTAX Notification sent as a response. The receiver should
not verify the payloads related to authentication in this case. not verify the payloads related to authentication in this case.
If authentication has succeeded in the IKE_AUTH exchange, the IKE SA If authentication has succeeded in the IKE_AUTH exchange, the IKE SA
is established; however, establishing the Child SA or requesting is established; however, establishing the Child SA or requesting
configuration information may still fail. This failure does not configuration information may still fail. This failure does not
automatically cause the IKE SA to be deleted. Specifically, a automatically cause the IKE SA to be deleted. Specifically, a
responder may include all the payloads associated with authentication responder may include all the payloads associated with authentication
(IDr, Cert and AUTH) while sending error notifications for the (IDr, Cert and AUTH) while sending error notifications for the
piggybacked exchanges (FAILED_CP_REQUIRED, INVALID_SELECTORS, piggybacked exchanges (FAILED_CP_REQUIRED, NO_PROPOSAL_CHOSEN, and so
NO_PROPOSAL_CHOSEN, and so on), and the initiator MUST NOT fail the on), and the initiator MUST NOT fail the authentication because of
authentication because of this. The initiator MAY, of course, for this. The initiator MAY, of course, for reasons of policy later
reasons of policy later delete such an IKE SA. delete such an IKE SA.
In an IKE_AUTH exchange, or in the INFORMATIONAL exchange immediately In an IKE_AUTH exchange, or in the INFORMATIONAL exchange immediately
following it (in case an error happened in when processing a response following it (in case an error happened when processing a response to
to IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and
AUTHENTICATION_FAILED notifications are the only ones to cause the AUTHENTICATION_FAILED notifications are the only ones to cause the
IKE SA to be deleted or not created, without a DELETE payload. IKE SA to be deleted or not created, without a DELETE payload.
Extension documents may define new error notifications with these Extension documents may define new error notifications with these
semantics, but MUST NOT use them unless the peer has been shown to semantics, but MUST NOT use them unless the peer has been shown to
understand them. understand them.
2.21.3. Error Handling after IKE SA is Authenticated 2.21.3. Error Handling after IKE SA is Authenticated
After the IKE SA is authenticated all requests having errors MUST After the IKE SA is authenticated all requests having errors MUST
result in response notifying about the error. result in a response notifying about the error.
In normal situations, there should not be cases where valid response In normal situations, there should not be cases where a valid
from one peer results in an error situation in the other peer, so response from one peer results in an error situation in the other
there should not be any reason for a peer to send error messages to peer, so there should not be any reason for a peer to send error
the other end except as a response. Because sending such error messages to the other end except as a response. Because sending such
messages as INFORMATIONAL exchange might lead to further errors that error messages as an INFORMATIONAL exchange might lead to further
could cause loops, such errors SHOULD NOT be sent. If errors are errors that could cause loops, such errors SHOULD NOT be sent. If
seen that indicate that the peers do not have same state, it might be errors are seen that indicate that the peers do not have the same
good to delete the IKE SA to clean up state and start over. state, it might be good to delete the IKE SA to clean up state and
start over.
If a peer parsing a request notices that it is badly formatted (after If a peer parsing a request notices that it is badly formatted (after
it has passed the message authentication code checks and window it has passed the message authentication code checks and window
checks) and it returns an INVALID_SYNTAX notification, then this checks) and it returns an INVALID_SYNTAX notification, then this
error notification is considered fatal in both peers, meaning that error notification is considered fatal in both peers, meaning that
the IKE SA is deleted without needing an explicit DELETE payload. the IKE SA is deleted without needing an explicit DELETE payload.
2.21.4. Error Handling Outside IKE SA 2.21.4. Error Handling Outside IKE SA
A node needs to limit the rate at which it will send messages in A node needs to limit the rate at which it will send messages in
skipping to change at page 60, line 23 skipping to change at line 2856
Opening an IPsec connection through a NAT introduces special Opening an IPsec connection through a NAT introduces special
problems. If the connection runs in transport mode, changing the IP problems. If the connection runs in transport mode, changing the IP
addresses on packets will cause the checksums to fail and the NAT addresses on packets will cause the checksums to fail and the NAT
cannot correct the checksums because they are cryptographically cannot correct the checksums because they are cryptographically
protected. Even in tunnel mode, there are routing problems because protected. Even in tunnel mode, there are routing problems because
transparently translating the addresses of AH and ESP packets transparently translating the addresses of AH and ESP packets
requires special logic in the NAT and that logic is heuristic and requires special logic in the NAT and that logic is heuristic and
unreliable in nature. For that reason, IKEv2 will use UDP unreliable in nature. For that reason, IKEv2 will use UDP
encapsulation of IKE and ESP packets. This encoding is slightly less encapsulation of IKE and ESP packets. This encoding is slightly less
efficient but is easier for NATs to process. In addition, firewalls efficient but is easier for NATs to process. In addition, firewalls
may be configured to pass IPsec traffic over UDP but not ESP/AH or may be configured to pass UDP-encapsulated IPsec traffic but not
vice versa. plain, unencapsulated ESP/AH or vice versa.
It is a common practice of NATs to translate TCP and UDP port numbers It is a common practice of NATs to translate TCP and UDP port numbers
as well as addresses and use the port numbers of inbound packets to as well as addresses and use the port numbers of inbound packets to
decide which internal node should get a given packet. For this decide which internal node should get a given packet. For this
reason, even though IKE packets MUST be sent from and to UDP port 500 reason, even though IKE packets MUST be sent from and to UDP port 500
or 4500, they MUST be accepted coming from any port and responses or 4500, they MUST be accepted coming from any port and responses
MUST be sent to the port from whence they came. This is because the MUST be sent to the port from whence they came. This is because the
ports may be modified as the packets pass through NATs. Similarly, ports may be modified as the packets pass through NATs. Similarly,
IP addresses of the IKE endpoints are generally not included in the IP addresses of the IKE endpoints are generally not included in the
IKE payloads because the payloads are cryptographically protected and IKE payloads because the payloads are cryptographically protected and
could not be transparently modified by NATs. could not be transparently modified by NATs.
Port 4500 is reserved for UDP-encapsulated ESP and IKE. An IPsec Port 4500 is reserved for UDP-encapsulated ESP and IKE. An IPsec
endpoint that discovers a NAT between it and its correspondent MUST endpoint that discovers a NAT between it and its correspondent MUST
send all subsequent traffic from port 4500, which NATs should not send all subsequent traffic from port 4500, which NATs should not
treat specially (as they might with port 500). treat specially (as they might with port 500).
An initiator can use port 4500, regardless whether or not there is An initiator can use port 4500 for both IKE and ESP, regardless of
NAT, even at the beginning of IKE. When either side is using port whether or not there is a NAT, even at the beginning of IKE. When
4500, sending with UDP encapsulation is not required, but either side is using port 4500, sending with UDP encapsulation is not
understanding received packets with UDP encapsulation is required. required, but understanding received IKE and ESP packets with UDP
UDP encapsulation MUST NOT be done on port 500. If NAT-T is encapsulation is required. UDP encapsulation MUST NOT be done on
supported (that is, if NAT_DETECTION_*_IP payloads were exchanged port 500. If NAT-T is supported (that is, if NAT_DETECTION_*_IP
during IKE_SA_INIT), all devices MUST be able to receive and process payloads were exchanged during IKE_SA_INIT), all devices MUST be able
both UDP encapsulated and non-UDP encapsulated packets at any time. to receive and process both UDP encapsulated and non-UDP encapsulated
Either side can decide whether or not to use UDP encapsulation packets at any time. Either side can decide whether or not to use
irrespective of the choice made by the other side. However, if a NAT UDP encapsulation irrespective of the choice made by the other side.
is detected, both devices MUST send UDP encapsulated packets. However, if a NAT is detected, both devices MUST send UDP
encapsulated packets.
The specific requirements for supporting NAT traversal [NATREQ] are The specific requirements for supporting NAT traversal [NATREQ] are
listed below. Support for NAT traversal is optional. In this listed below. Support for NAT traversal is optional. In this
section only, requirements listed as MUST apply only to section only, requirements listed as MUST apply only to
implementations supporting NAT traversal. implementations supporting NAT traversal.
o IKE MUST listen on port 4500 as well as port 500. IKE MUST o IKE MUST listen on port 4500 as well as port 500. IKE MUST
respond to the IP address and port from which packets arrived. respond to the IP address and port from which packets arrived.
o Both IKE initiator and responder MUST include in their IKE_SA_INIT o Both IKE initiator and responder MUST include in their IKE_SA_INIT
skipping to change at page 61, line 36 skipping to change at line 2918
message if the sender does not know which of several network message if the sender does not know which of several network
attachments will be used to send the packet. attachments will be used to send the packet.
o The data associated with the NAT_DETECTION_DESTINATION_IP o The data associated with the NAT_DETECTION_DESTINATION_IP
notification is a SHA-1 digest of the SPIs (in the order they notification is a SHA-1 digest of the SPIs (in the order they
appear in the header), IP address, and port to which this packet appear in the header), IP address, and port to which this packet
was sent. was sent.
o The recipient of either the NAT_DETECTION_SOURCE_IP or o The recipient of either the NAT_DETECTION_SOURCE_IP or
NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied
value to a SHA-1 hash of the SPIs, source IP address, and port, value to a SHA-1 hash of the SPIs, source or recipient IP address
and if they don't match it SHOULD enable NAT traversal. In the (respectively), address, and port, and if they don't match it
case there is a mismatch of the NAT_DETECTION_SOURCE_IP hash with SHOULD enable NAT traversal. In the case there is a mismatch of
all of the NAT_DETECTION_SOURCE_IP payloads received, the the NAT_DETECTION_SOURCE_IP hash with all of the
recipient MAY reject the connection attempt if NAT traversal is NAT_DETECTION_SOURCE_IP payloads received, the recipient MAY
not supported. In the case of a mismatching reject the connection attempt if NAT traversal is not supported.
NAT_DETECTION_DESTINATION_IP hash, it means that the system In the case of a mismatching NAT_DETECTION_DESTINATION_IP hash, it
receiving the NAT_DETECTION_DESTINATION_IP payload is behind a NAT means that the system receiving the NAT_DETECTION_DESTINATION_IP
and that system SHOULD start sending keepalive packets as defined payload is behind a NAT and that system SHOULD start sending
in [UDPENCAPS]; alternately, it MAY reject the connection attempt keepalive packets as defined in [UDPENCAPS]; alternately, it MAY
if NAT traversal is not supported. reject the connection attempt if NAT traversal is not supported.
o If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches o If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches
the expected value of the source IP and port found from the IP the expected value of the source IP and port found from the IP
header of the packet containing the payload, it means that the header of the packet containing the payload, it means that the
system sending those payloads is behind NAT (i.e., someone along system sending those payloads is behind NAT (i.e., someone along
the route changed the source address of the original packet to the route changed the source address of the original packet to
match the address of the NAT box). In this case, the system match the address of the NAT box). In this case, the system
receiving the payloads should allow dynamic update of the other receiving the payloads should allow dynamic update of the other
systems' IP address, as described later. systems' IP address, as described later.
skipping to change at page 62, line 28 skipping to change at line 2958
octets of the ESP header contain the SPI, and the SPI cannot octets of the ESP header contain the SPI, and the SPI cannot
validly be zero, it is always possible to distinguish ESP and IKE validly be zero, it is always possible to distinguish ESP and IKE
messages. messages.
o Implementations MUST process received UDP-encapsulated ESP packets o Implementations MUST process received UDP-encapsulated ESP packets
even when no NAT was detected. even when no NAT was detected.
o The original source and destination IP address required for the o The original source and destination IP address required for the
transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS])
are obtained from the Traffic Selectors associated with the are obtained from the Traffic Selectors associated with the
exchange. In the case of NAT traversal, the Traffic Selectors exchange. In the case of transport mode NAT traversal, the
MUST contain exactly one IP address, which is then used as the Traffic Selectors MUST contain exactly one IP address, which is
original IP address. then used as the original IP address. This is covered in greater
detail in Section 2.23.1.
o There are cases where a NAT box decides to remove mappings that o There are cases where a NAT box decides to remove mappings that
are still alive (for example, the keepalive interval is too long, are still alive (for example, the keepalive interval is too long,
or the NAT box is rebooted). To recover in these cases, hosts or the NAT box is rebooted). This will be apparent to a host if
that do not support other methods of recovery such as MOBIKE it receives a packet whose integrity protection validates, but has
[MOBIKE], and that are not behind a NAT, SHOULD send all packets a different port, address, or both from the one that was
(including retransmission packets) to the IP address and port from associated with the SA in the validated packet. When such a
the last valid authenticated packet from the other end (that is, validated packet is found, a host that does not support other
they should dynamically update the address). A host behind a NAT methods of recovery such as MOBIKE [MOBIKE], and that is not
SHOULD NOT do this because it opens a possible denial of service behind a NAT, SHOULD send all packets (including retransmission
attack. Any authenticated IKE packet or any authenticated UDP- packets) to the IP address and port in the validated packet, and
encapsulated ESP packet can be used to detect that the IP address SHOULD store this as the new address and port combination for the
or the port has changed. When IKEv2 is used with MOBIKE, SA (that is, they SHOULD dynamically update the address). A host
dynamically updating the addresses described above interferes with behind a NAT SHOULD NOT do this type of dynamic address update if
MOBIKE's way of recovering from the same situation. See Section a validated packet has different port and/or address values
3.8 of [MOBIKE] for more information. because it opens a possible denial of service attack (such as
allowing an attacker to break the connection with a single
packet). Also, dynamic address update should only be done in
response to a new packet; otherwise, an attacker can revert the
addresses with old replayed packets. Because of this, dynamic
update can only be done safely if replay protection is enabled.
When IKEv2 is used with MOBIKE, dynamically updating the addresses
described above interferes with MOBIKE's way of recovering from
the same situation. See Section 3.8 of [MOBIKE] for more
information.
2.23.1. Transport Mode NAT Traversal 2.23.1. Transport Mode NAT Traversal
Transport mode used with NAT Traversal requires special handling of Transport mode used with NAT Traversal requires special handling of
the traffic selectors used in the IKEv2. The complete scenario looks the traffic selectors used in the IKEv2. The complete scenario looks
like: like:
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
|Client| IP1 | NAT | IPN1 IPN2 | NAT | IP2 |Server| |Client| IP1 | NAT | IPN1 IPN2 | NAT | IP2 |Server|
|node |<------>| A |<---------->| B |<------->| | |node |<------>| A |<---------->| B |<------->| |
skipping to change at page 63, line 37 skipping to change at line 3020
the outer address of the NAT B, that is, the IPN2 address. If NAT B the outer address of the NAT B, that is, the IPN2 address. If NAT B
is a static NAT, then its address can be configured to the client's is a static NAT, then its address can be configured to the client's
configuration. Other options would be find it using some other configuration. Other options would be find it using some other
protocol (like DNS), but those are outside of scope of IKEv2. protocol (like DNS), but those are outside of scope of IKEv2.
In this scenario, both client and server are configured to use In this scenario, both client and server are configured to use
transport mode for the traffic originating from the client node and transport mode for the traffic originating from the client node and
destined to the server. destined to the server.
When the client starts creating the IKEv2 SA and Child SA for sending When the client starts creating the IKEv2 SA and Child SA for sending
traffic to the server, it has a triggering packet with source IP traffic to the server, it may hve a triggering packet with source IP
address of IP1, and a destination IP address of IPN2. Its PAD and address of IP1, and a destination IP address of IPN2. Its PAD and
SPD needs to have configuration matching those addresses (or wildcard SPD needs to have configuration matching those addresses (or wildcard
entries covering them). Because this is transport mode, it uses entries covering them). Because this is transport mode, it uses
exactly same addresses as the traffic selectors and outer IP address exactly same addresses as the traffic selectors and outer IP address
of the IKE packets. For transport mode, it MUST use exactly one IP of the IKE packets. For transport mode, it MUST use exactly one IP
address in the TSi and TSr payloads. It can have multiple traffic address in the TSi and TSr payloads. It can have multiple traffic
selectors if it has, for example, multiple port ranges that it wants selectors if it has, for example, multiple port ranges that it wants
to negotiate, but all TSi entries must use IP1-IP1 range as the IP to negotiate, but all TSi entries must use IP1-IP1 range as the IP
addresses, and all TSr entries must have the IPN2-IPN2 range as IP addresses, and all TSr entries must have the IPN2-IPN2 range as IP
addresses. The first traffic selector of TSi and TSr SHOULD have addresses. The first traffic selector of TSi and TSr SHOULD have
very specific traffic selectors including protocol and port numbers very specific traffic selectors including protocol and port numbers,
from the packet triggering the request. such as from the packet triggering the request.
NAT A will then replace the source address of the IKE packet from IP1 NAT A will then replace the source address of the IKE packet from IP1
to IPN1, and NAT B will replace the destination address of the IKE to IPN1, and NAT B will replace the destination address of the IKE
packet from IPN2 to IP2, so when the packet arrives to the server it packet from IPN2 to IP2, so when the packet arrives to the server it
will still have the exactly same traffic selectors which were sent by will still have the exactly same traffic selectors which were sent by
the client, but the IP address of the IKE packet has been replaced to the client, but the IP address of the IKE packet has been replaced to
IPN1 and IP2. IPN1 and IP2.
When the server receives this packet, it normally looks the PAD based When the server receives this packet, it normally looks the PAD based
on the ID and then searches the SPD based on the traffic selectors. on the ID and then searches the SPD based on the traffic selectors.
Because IP1 does not really mean anything to the server (it is the Because IP1 does not really mean anything to the server (it is the
address client has behind the NAT), it is useless to do lookup based address client has behind the NAT), it is useless to do a lookup
on that if transport mode is used. On the other hand, the server based on that if transport mode is used. On the other hand, the
cannot know whether transport mode is allowed by its policy before it server cannot know whether transport mode is allowed by its policy
finds the matching SPD entry. before it finds the matching SPD entry.
In this case, the server should first check that as initiator In this case, the server should first check that the initiator
requested transport mode and do address substitution on the traffic requested transport mode, and then do address substitution on the
selectors. It needs to first store the old traffic selector IP traffic selectors. It needs to first store the old traffic selector
addresses to be used later for the incremental checksum fixup (the IP IP addresses to be used later for the incremental checksum fixup (the
address in the TSi can be stored as the original source address and IP address in the TSi can be stored as the original source address
the IP address in the TSr can be stored as the original destination and the IP address in the TSr can be stored as the original
address). After that, if the other end was detected as being behind destination address). After that, if the other end was detected as
a NAT, the server replaces the IP address in TSi payloads with the IP being behind a NAT, the server replaces the IP address in TSi
address obtained from the source address of the IKE packet received payloads with the IP address obtained from the source address of the
(that is, it replaces IP1 in TSi with IPN1). If the server's end was IKE packet received (that is, it replaces IP1 in TSi with IPN1). If
detected to be behind NAT, it replaces the IP address in the TSr the server's end was detected to be behind NAT, it replaces the IP
payloads with the IP address obtained from the destination address of address in the TSr payloads with the IP address obtained from the
the IKE packet received (that is, it replaces IPN2 in TSr with IP2). destination address of the IKE packet received (that is, it replaces
IPN2 in TSr with IP2).
After this address substitution, both the traffic selectors and the After this address substitution, both the traffic selectors and the
IKE UDP source/destination addresses look the same, and the server IKE UDP source/destination addresses look the same, and the server
does SPD lookup based on those new traffic selectors. If an entry is does SPD lookup based on those new traffic selectors. If an entry is
found and it allows transport mode, then that entry is used. If an found and it allows transport mode, then that entry is used. If an
entry is found but it does not allow transport mode, then the server entry is found but it does not allow transport mode, then the server
MAY undo the address substitution and redo the SPD lookup using the MAY undo the address substitution and redo the SPD lookup using the
original traffic selectors. If the second lookup succeeds, the original traffic selectors. If the second lookup succeeds, the
server will create an SA in tunnel mode using real traffic selectors server will create an SA in tunnel mode using real traffic selectors
sent by the other end. sent by the other end.
skipping to change at page 65, line 31 skipping to change at line 3112
For the client proposing transport mode: For the client proposing transport mode:
- The TSi entries MUST have exactly one IP address, and that MUST - The TSi entries MUST have exactly one IP address, and that MUST
match the source address of the IKE SA. match the source address of the IKE SA.
- The TSr entries MUST have exactly one IP address, and that MUST - The TSr entries MUST have exactly one IP address, and that MUST
match the destination address of the IKE SA. match the destination address of the IKE SA.
- The first TSi and TSr traffic selectors SHOULD have very specific - The first TSi and TSr traffic selectors SHOULD have very specific
traffic selectors including protocol and port numbers from the traffic selectors including protocol and port numbers, such as
packet triggering the request. from the packet triggering the request.
- There MAY be multiple TSi and TSr entries. - There MAY be multiple TSi and TSr entries.
- If transport mode for the SA was selected (that is, if the server - If transport mode for the SA was selected (that is, if the server
included USE_TRANSPORT_MODE notification in its response): included USE_TRANSPORT_MODE notification in its response):
- Store the original traffic selectors as the received source and - Store the original traffic selectors as the received source and
destination address. destination address.
- If the server is behind a NAT, substitute the IP address in the - If the server is behind a NAT, substitute the IP address in the
skipping to change at page 67, line 22 skipping to change at line 3199
size of 1, and recommends solutions. size of 1, and recommends solutions.
A TEMPORARY_FAILURE notification SHOULD be sent when a peer receives A TEMPORARY_FAILURE notification SHOULD be sent when a peer receives
a request that cannot be completed due to a temporary condition such a request that cannot be completed due to a temporary condition such
as a rekeying operation. When a peer receives a TEMPORARY_FAILURE as a rekeying operation. When a peer receives a TEMPORARY_FAILURE
notification, it MUST NOT immediately retry the operation; it MUST notification, it MUST NOT immediately retry the operation; it MUST
wait so that the sender may complete whatever operation caused the wait so that the sender may complete whatever operation caused the
temporary condition. The recipient MAY retry the request one or more temporary condition. The recipient MAY retry the request one or more
times over a period of several minutes. If a peer continues to times over a period of several minutes. If a peer continues to
receive TEMPORARY_FAILURE on the same IKE SA after several minutes, receive TEMPORARY_FAILURE on the same IKE SA after several minutes,
it SHOULD conclude that state information is out-of-sync and close it SHOULD conclude that the state information is out-of-sync and
the IKE SA. close the IKE SA.
A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives
a request to rekey a Child SA that does not exist. The SA that the a request to rekey a Child SA that does not exist. The SA that the
initiator attempted to rekey is indicated by the SPI field in the initiator attempted to rekey is indicated by the SPI field in the
Notify Payload, which is copied from the SPI field in the REYEY_SA Notify Payload, which is copied from the SPI field in the REYEY_SA
notification. A peer that receives a CHILD_SA_NOT_FOUND notification notification. A peer that receives a CHILD_SA_NOT_FOUND notification
SHOULD silently delete the Child SA (if it still exists) and send a SHOULD silently delete the Child SA (if it still exists) and send a
request to create a new Child SA from scratch (if the Child SA does request to create a new Child SA from scratch (if the Child SA does
not yet exist). not yet exist).
skipping to change at page 67, line 47 skipping to change at line 3224
trying to close, it SHOULD reply with TEMPORARY_FAILURE. If a peer trying to close, it SHOULD reply with TEMPORARY_FAILURE. If a peer
receives a request to rekey a Child SA that it is currently rekeying, receives a request to rekey a Child SA that it is currently rekeying,
it SHOULD reply as usual, and SHOULD prepare to close redundant SAs it SHOULD reply as usual, and SHOULD prepare to close redundant SAs
later based on the nonces (see Section 2.8.1). If a peer receives a later based on the nonces (see Section 2.8.1). If a peer receives a
request to rekey a Child SA that does not exist, it SHOULD reply with request to rekey a Child SA that does not exist, it SHOULD reply with
CHILD_SA_NOT_FOUND. CHILD_SA_NOT_FOUND.
If a peer receives a request to close a Child SA that it is currently If a peer receives a request to close a Child SA that it is currently
trying to close, it SHOULD reply without Delete payloads (see trying to close, it SHOULD reply without Delete payloads (see
Section 1.4.1). If a peer receives a request to close a Child SA Section 1.4.1). If a peer receives a request to close a Child SA
that it is currently rekeying, it SHOULD reply as usual, with Delete that it is currently rekeying, it SHOULD reply as usual, with a
payload. If a peer receives a request to close a Child SA that does Delete payload. If a peer receives a request to close a Child SA
not exist, it SHOULD reply without Delete payloads. that does not exist, it SHOULD reply without Delete payloads.
If a peer receives a request to rekey the IKE SA, and it is currently If a peer receives a request to rekey the IKE SA, and it is currently
creating, rekeying, or closing a Child SA of that IKE SA, it SHOULD creating, rekeying, or closing a Child SA of that IKE SA, it SHOULD
reply with TEMPORARY_FAILURE. reply with TEMPORARY_FAILURE.
2.25.2. Collisions While Rekeying or Closing IKE SAs 2.25.2. Collisions While Rekeying or Closing IKE SAs
If a peer receives a request to rekey an IKE SA that it is currently If a peer receives a request to rekey an IKE SA that it is currently
rekeying, it SHOULD reply as usual, and SHOULD prepare to close rekeying, it SHOULD reply as usual, and SHOULD prepare to close
redundant SAs and move inherited Child SAs later based on the nonces redundant SAs and move inherited Child SAs later based on the nonces
skipping to change at page 68, line 50 skipping to change at line 3276
UDP datagram. Information from the beginning of the packet through UDP datagram. Information from the beginning of the packet through
the UDP header is largely ignored except that the IP addresses and the UDP header is largely ignored except that the IP addresses and
UDP ports from the headers are reversed and used for return packets. UDP ports from the headers are reversed and used for return packets.
When sent on UDP port 500, IKE messages begin immediately following When sent on UDP port 500, IKE messages begin immediately following
the UDP header. When sent on UDP port 4500, IKE messages have the UDP header. When sent on UDP port 4500, IKE messages have
prepended four octets of zero. These four octets of zero are not prepended four octets of zero. These four octets of zero are not
part of the IKE message and are not included in any of the length part of the IKE message and are not included in any of the length
fields or checksums defined by IKE. Each IKE message begins with the fields or checksums defined by IKE. Each IKE message begins with the
IKE header, denoted HDR in this document. Following the header are IKE header, denoted HDR in this document. Following the header are
one or more IKE payloads each identified by a "Next Payload" field in one or more IKE payloads each identified by a "Next Payload" field in
the preceding payload. Payloads are processed in the order in which the preceding payload. Payloads are identified in the order in which
they appear in an IKE message by invoking the appropriate processing they appear in an IKE message by looking in the "Next Payload" field
routine according to the "Next Payload" field in the IKE header and in the IKE header, and subsequently according to the "Next Payload"
subsequently according to the "Next Payload" field in the IKE payload field in the IKE payload itself until a "Next Payload" field of zero
itself until a "Next Payload" field of zero indicates that no indicates that no payloads follow. If a payload of type "Encrypted"
payloads follow. If a payload of type "Encrypted" is found, that is found, that payload is decrypted and its contents parsed as
payload is decrypted and its contents parsed as additional payloads. additional payloads. An Encrypted payload MUST be the last payload
An Encrypted payload MUST be the last payload in a packet and an in a packet and an Encrypted payload MUST NOT contain another
Encrypted payload MUST NOT contain another Encrypted payload. Encrypted payload.
The Recipient SPI in the header identifies an instance of an IKE The responder's SPI in the header identifies an instance of an IKE
security association. It is therefore possible for a single instance security association. It is therefore possible for a single instance
of IKE to multiplex distinct sessions with multiple peers. of IKE to multiplex distinct sessions with multiple peers, including
multiple sessions per peer.
All multi-octet fields representing integers are laid out in big All multi-octet fields representing integers are laid out in big
endian order (also known as "most significant byte first", or endian order (also known as "most significant byte first", or
"network byte order"). "network byte order").
The format of the IKE header is shown in Figure 4. The format of the IKE header is shown in Figure 4.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 70, line 47 skipping to change at line 3369
in the flags field being set. The bits are as follows: in the flags field being set. The bits are as follows:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|X|X|R|V|I|X|X|X| |X|X|R|V|I|X|X|X|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
In the description below, a bit being 'set' means its value is In the description below, a bit being 'set' means its value is
'1', while 'cleared' means its value is '0'. "X" bits MUST be '1', while 'cleared' means its value is '0'. "X" bits MUST be
cleared when sending and MUST be ignored on receipt. cleared when sending and MUST be ignored on receipt.
* I(nitiator) - This bit MUST be set in messages sent by the * R(esponse) - This bit indicates that this message is a response
original initiator of the IKE SA and MUST be cleared in to a message containing the same message ID. This bit MUST be
messages sent by the original responder. It is used by the cleared in all request messages and MUST be set in all
recipient to determine which eight octets of the SPI were responses. An IKE endpoint MUST NOT generate a response to a
generated by the recipient. This bit changes to reflect who message that is marked as being a response.
initiated the last rekey of the IKE SA.
* V(ersion) - This bit indicates that the transmitter is capable * V(ersion) - This bit indicates that the transmitter is capable
of speaking a higher major version number of the protocol than of speaking a higher major version number of the protocol than
the one indicated in the major version number field. the one indicated in the major version number field.
Implementations of IKEv2 MUST clear this bit when sending and Implementations of IKEv2 MUST clear this bit when sending and
MUST ignore it in incoming messages. MUST ignore it in incoming messages.
* R(esponse) - This bit indicates that this message is a response * I(nitiator) - This bit MUST be set in messages sent by the
to a message containing the same message ID. This bit MUST be original initiator of the IKE SA and MUST be cleared in
cleared in all request messages and MUST be set in all messages sent by the original responder. It is used by the
responses. An IKE endpoint MUST NOT generate a response to a recipient to determine which eight octets of the SPI were
message that is marked as being a response. generated by the recipient. This bit changes to reflect who
initiated the last rekey of the IKE SA.
o Message ID (4 octets) - Message identifier used to control o Message ID (4 octets) - Message identifier used to control
retransmission of lost packets and matching of requests and retransmission of lost packets and matching of requests and
responses. It is essential to the security of the protocol responses. It is essential to the security of the protocol
because it is used to prevent message replay attacks. See because it is used to prevent message replay attacks. See
Section 2.1 and Section 2.2. Section 2.1 and Section 2.2.
o Length (4 octets) - Length of total message (header + payloads) in o Length (4 octets) - Length of total message (header + payloads) in
octets. octets.
skipping to change at page 71, line 48 skipping to change at line 3418
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Generic Payload Header Figure 5: Generic Payload Header
The Generic Payload Header fields are defined as follows: The Generic Payload Header fields are defined as follows:
o Next Payload (1 octet) - Identifier for the payload type of the o Next Payload (1 octet) - Identifier for the payload type of the
next payload in the message. If the current payload is the last next payload in the message. If the current payload is the last
in the message, then this field will be 0. This field provides a in the message, then this field will be 0. This field provides a
"chaining" capability whereby additional payloads can be added to "chaining" capability whereby additional payloads can be added to
a message by appending it to the end of the message and setting a message by appending each one to the end of the message and
the "Next Payload" field of the preceding payload to indicate the setting the "Next Payload" field of the preceding payload to
new payload's type. An Encrypted payload, which must always be indicate the new payload's type. An Encrypted payload, which must
the last payload of a message, is an exception. It contains data always be the last payload of a message, is an exception. It
structures in the format of additional payloads. In the header of contains data structures in the format of additional payloads. In
an Encrypted payload, the Next Payload field is set to the payload the header of an Encrypted payload, the Next Payload field is set
type of the first contained payload (instead of 0). The payload to the payload type of the first contained payload (instead of 0);
type values are listed here. The values in the following table conversely, the Next Payload field of the last contained payload
are only current as of the publication date of RFC 4306. Other is set to zero). The payload type values are listed here. The
values may have been added since then or will be added after the values in the following table are only current as of the
publication of this document. Readers should refer to [IKEV2IANA] publication date of RFC 4306. Other values may have been added
for the latest values. since then or will be added after the publication of this
document. Readers should refer to [IKEV2IANA] for the latest
values.
Next Payload Type Notation Value Next Payload Type Notation Value
-------------------------------------------------- --------------------------------------------------
No Next Payload 0 No Next Payload 0
Security Association SA 33 Security Association SA 33
Key Exchange KE 34 Key Exchange KE 34
Identification - Initiator IDi 35 Identification - Initiator IDi 35
Identification - Responder IDr 36 Identification - Responder IDr 36
Certificate CERT 37 Certificate CERT 37
Certificate Request CERTREQ 38 Certificate Request CERTREQ 38
skipping to change at page 74, line 13 skipping to change at line 3529
initiator's SA payload MUST have a Proposal # of one (1). One reason initiator's SA payload MUST have a Proposal # of one (1). One reason
to use multiple proposals is to propose both standard crypto ciphers to use multiple proposals is to propose both standard crypto ciphers
and combined-mode ciphers. Combined-mode ciphers include both and combined-mode ciphers. Combined-mode ciphers include both
integrity and encryption in a single encryption algorithm, and MUST integrity and encryption in a single encryption algorithm, and MUST
either offer no integrity algorithm or a single integrity algorithm either offer no integrity algorithm or a single integrity algorithm
of "none", with no integrity algorithm being the RECOMMENDED method. of "none", with no integrity algorithm being the RECOMMENDED method.
If an initiator wants to propose both combined-mode ciphers and If an initiator wants to propose both combined-mode ciphers and
normal ciphers, it must include two proposals: one will have all the normal ciphers, it must include two proposals: one will have all the
combined-mode ciphers, and the other will have all the normal ciphers combined-mode ciphers, and the other will have all the normal ciphers
with the integrity algorithms. For example, one such proposal would with the integrity algorithms. For example, one such proposal would
have two proposal structures: ESP with ENCR_AES-CCM_8, ENCR_AES- have two proposal structures. Proposal 1 is ESP with AES-128, AES-
CCM_12, and ENCR_AES-CCM_16 as Proposal #1, and ESP with 192, and AES-256 bits in CBC mode, with either HMAC-SHA1-96 or
ENCR_AES_CBC, ENCR_3DES, AUTH_AES_XCBC_96, and AUTH_HMAC_SHA1_96 as XCBC-96 as the integrity algorithm; Proposal 2 is AES-128 or AES-256
Proposal #2. in GCM mode with an 8-octet ICV. Both proposals allow but do not
require the use of ESN. This can be illustrated as:
SA Payload
|
+--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4,
| | 7 transforms, SPI = 0x052357bb )
| |
| +-- Transform ENCR ( Name = ENCR_AES_CBC )
| | +-- Attribute ( Key Length = 128 )
| |
| +-- Transform ENCR ( Name = ENCR_AES_CBC )
| | +-- Attribute ( Key Length = 192 )
| |
| +-- Transform ENCR ( Name = ENCR_AES_CBC )
| | +-- Attribute ( Key Length = 256 )
| |
| +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 )
| +-- Transform INTEG ( Name = AUTH_AES_XCBC_96 )
| +-- Transform ESN ( Name = ESNs )
| +-- Transform ESN ( Name = No ESNs )
|
+--- Proposal #2 ( Proto ID = ESP(3), SPI size = 4,
| 4 transforms, SPI = 0x35a1d6f2 )
|
+-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
| +-- Attribute ( Key Length = 128 )
|
+-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
| +-- Attribute ( Key Length = 256 )
|
+-- Transform ESN ( Name = ESNs )
+-- Transform ESN ( Name = No ESNs )
Each Proposal/Protocol structure is followed by one or more transform Each Proposal/Protocol structure is followed by one or more transform
structures. The number of different transforms is generally structures. The number of different transforms is generally
determined by the Protocol. AH generally has two transforms: determined by the Protocol. AH generally has two transforms:
Extended Sequence Numbers (ESN) and an integrity check algorithm. Extended Sequence Numbers (ESN) and an integrity check algorithm.
ESP generally has three: ESN, an encryption algorithm and an ESP generally has three: ESN, an encryption algorithm and an
integrity check algorithm. IKE generally has four transforms: a integrity check algorithm. IKE generally has four transforms: a
Diffie-Hellman group, an integrity check algorithm, a PRF algorithm, Diffie-Hellman group, an integrity check algorithm, a PRF algorithm,
and an encryption algorithm. For each Protocol, the set of and an encryption algorithm. For each Protocol, the set of
permissible transforms is assigned transform ID numbers, which appear permissible transforms is assigned transform ID numbers, which appear
skipping to change at page 78, line 51 skipping to change at line 3785
For Transform Type 2 (Pseudo-random Function), the Transform IDs are For Transform Type 2 (Pseudo-random Function), the Transform IDs are
listed below. The values in the following table are only current as listed below. The values in the following table are only current as
of the publication date of RFC 4306. Other values may have been of the publication date of RFC 4306. Other values may have been
added since then or will be added after the publication of this added since then or will be added after the publication of this
document. Readers should refer to [IKEV2IANA] for the latest values. document. Readers should refer to [IKEV2IANA] for the latest values.
Name Number Defined In Name Number Defined In
------------------------------------------------------ ------------------------------------------------------
PRF_HMAC_MD5 1 (RFC2104), [MD5] PRF_HMAC_MD5 1 (RFC2104), [MD5]
PRF_HMAC_SHA1 2 (RFC2104), [SHA] PRF_HMAC_SHA1 2 (RFC2104), [SHA]
PRF_HMAC_TIGER 3 (RFC2104) PRF_HMAC_TIGER 3 (UNSPECIFIED)
For Transform Type 3 (Integrity Algorithm), defined Transform IDs are For Transform Type 3 (Integrity Algorithm), defined Transform IDs are
listed below. The values in the following table are only current as listed below. The values in the following table are only current as
of the publication date of RFC 4306. Other values may have been of the publication date of RFC 4306. Other values may have been
added since then or will be added after the publication of this added since then or will be added after the publication of this
document. Readers should refer to [IKEV2IANA] for the latest values. document. Readers should refer to [IKEV2IANA] for the latest values.
Name Number Defined In Name Number Defined In
---------------------------------------- ----------------------------------------
NONE 0 NONE 0
AUTH_HMAC_MD5_96 1 (RFC2403) AUTH_HMAC_MD5_96 1 (RFC2403)
skipping to change at page 82, line 6 skipping to change at line 3930
|A| Attribute Type | AF=0 Attribute Length | |A| Attribute Type | AF=0 Attribute Length |
|F| | AF=1 Attribute Value | |F| | AF=1 Attribute Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AF=0 Attribute Value | | AF=0 Attribute Value |
| AF=1 Not Transmitted | | AF=1 Not Transmitted |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Data Attributes Figure 9: Data Attributes
o Attribute Format (AF) (1 bit) - Indicates whether the data o Attribute Format (AF) (1 bit) - Indicates whether the data
attribute follow the Type/Length/Value (TLV) format or a shortened attribute follows the Type/Length/Value (TLV) format or a
Type/Value (TV) format. If the AF bit is zero (0), then the shortened Type/Value (TV) format. If the AF bit is zero (0), then
attribute uses TLV format; if the AF bit is one (1), the TV format the attribute uses TLV format; if the AF bit is one (1), the TV
(with two-byte value) is used. format (with two-byte value) is used.
o Attribute Type (15 bits) - Unique identifier for each type of o Attribute Type (15 bits) - Unique identifier for each type of
attribute (see below). attribute (see below).
o Attribute Value (variable length) - Value of the Attribute o Attribute Value (variable length) - Value of the Attribute
associated with the Attribute Type. If the AF bit is a zero (0), associated with the Attribute Type. If the AF bit is a zero (0),
this field has a variable length defined by the Attribute Length this field has a variable length defined by the Attribute Length
field. If the AF bit is a one (1), the Attribute Value has a field. If the AF bit is a one (1), the Attribute Value has a
length of 2 octets. length of 2 octets.
The only currently defined attribute type (Key Length) is fixed The only currently defined attribute type (Key Length) is fixed
length; the variable-length encoding specification is included only length; the variable-length encoding specification is included only
for future extensions. Attributes described as fixed length MUST NOT for future extensions. Attributes described as fixed length MUST NOT
be encoded using the variable-length encoding. Variable-length be encoded using the variable-length encoding unless that length
attributes MUST NOT be encoded as fixed-length even if their value exceeds two bytes. Variable-length attributes MUST NOT be encoded as
can fit into two octets. NOTE: This is a change from IKEv1, where fixed-length even if their value can fit into two octets. NOTE: This
increased flexibility may have simplified the composer of messages is a change from IKEv1, where increased flexibility may have
but certainly complicated the parser. simplified the composer of messages but certainly complicated the
parser.
The values in the following table are only current as of the The values in the following table are only current as of the
publication date of RFC 4306. Other values may have been added since publication date of RFC 4306. Other values may have been added since
then or will be added after the publication of this document. then or will be added after the publication of this document.
Readers should refer to [IKEV2IANA] for the latest values. Readers should refer to [IKEV2IANA] for the latest values.
Attribute Type Value Attribute Format Attribute Type Value Attribute Format
------------------------------------------------------------ ------------------------------------------------------------
Key Length (in bits) 14 TV Key Length (in bits) 14 TV
skipping to change at page 83, line 37 skipping to change at line 4011
During security association negotiation initiators present offers to During security association negotiation initiators present offers to
responders. Responders MUST select a single complete set of responders. Responders MUST select a single complete set of
parameters from the offers (or reject all offers if none are parameters from the offers (or reject all offers if none are
acceptable). If there are multiple proposals, the responder MUST acceptable). If there are multiple proposals, the responder MUST
choose a single proposal. If the selected proposal has multiple choose a single proposal. If the selected proposal has multiple
Transforms with the same type, the responder MUST choose a single Transforms with the same type, the responder MUST choose a single
one. Any attributes of a selected transform MUST be returned one. Any attributes of a selected transform MUST be returned
unmodified. The initiator of an exchange MUST check that the unmodified. The initiator of an exchange MUST check that the
accepted offer is consistent with one of its proposals, and if not accepted offer is consistent with one of its proposals, and if not
that response MUST be rejected. MUST terminate the exchange.
If the responder receives a proposal that contains a Transform Type If the responder receives a proposal that contains a Transform Type
it does not understand, or a proposal that is missing a mandatory it does not understand, or a proposal that is missing a mandatory
Transform Type, it MUST consider this proposal unacceptable; however, Transform Type, it MUST consider this proposal unacceptable; however,
other proposals in the same SA payload are processed as usual. other proposals in the same SA payload are processed as usual.
Similarly, if the responder receives a transform that contains a Similarly, if the responder receives a transform that it does not
Transform Attribute it does not understand, it MUST consider this understand, or one that contains a Transform Attribute it does not
transform unacceptable; other transforms with the same Transform Type understand, it MUST consider this transform unacceptable; other
are processed as usual. This allows new Transform Types and transforms with the same Transform Type are processed as usual. This
Transform Attributes to be defined in the future. allows new Transform Types and Transform Attributes to be defined in
the future.
Negotiating Diffie-Hellman groups presents some special challenges. Negotiating Diffie-Hellman groups presents some special challenges.
SA offers include proposed attributes and a Diffie-Hellman public SA offers include proposed attributes and a Diffie-Hellman public
number (KE) in the same message. If in the initial exchange the number (KE) in the same message. If in the initial exchange the
initiator offers to use one of several Diffie-Hellman groups, it initiator offers to use one of several Diffie-Hellman groups, it
SHOULD pick the one the responder is most likely to accept and SHOULD pick the one the responder is most likely to accept and
include a KE corresponding to that group. If the responder selects a include a KE corresponding to that group. If the responder selects a
proposal using a different Diffie-Hellman group (other than NONE), proposal using a different Diffie-Hellman group (other than NONE),
the responder will indicate the correct group in the response and the the responder will indicate the correct group in the response and the
initiator SHOULD pick an element of that group for its KE value when initiator SHOULD pick an element of that group for its KE value when
skipping to change at page 84, line 39 skipping to change at line 4062
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Key Exchange Data ~ ~ Key Exchange Data ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Key Exchange Payload Format Figure 10: Key Exchange Payload Format
A key exchange payload is constructed by copying one's Diffie-Hellman A key exchange payload is constructed by copying one's Diffie-Hellman
public value into the "Key Exchange Data" portion of the payload. public value into the "Key Exchange Data" portion of the payload.
The length of the Diffie-Hellman public value MUST be equal to the The length of the Diffie-Hellman public value for MODP groups MUST be
length of the prime modulus over which the exponentiation was equal to the length of the prime modulus over which the
performed, prepending zero bits to the value if necessary. exponentiation was performed, prepending zero bits to the value if
necessary.
The DH Group # identifies the Diffie-Hellman group in which the Key The DH Group # identifies the Diffie-Hellman group in which the Key
Exchange Data was computed (see Section 3.3.2). This Group # MUST Exchange Data was computed (see Section 3.3.2). This Group # MUST
match a DH Group specified in a proposal in the SA payload that is match a DH Group specified in a proposal in the SA payload that is
sent in the same message, and SHOULD match the DH group in the first sent in the same message, and SHOULD match the DH group in the first
group in the first proposal, if such exists. If none of the group in the first proposal, if such exists. If none of the
proposals in that SA payload specifies a DH Group, the KE payload proposals in that SA payload specifies a DH Group, the KE payload
MUST NOT be present. If the selected proposal uses a different MUST NOT be present. If the selected proposal uses a different
Diffie-Hellman group (other than NONE), the message MUST be rejected Diffie-Hellman group (other than NONE), the message MUST be rejected
with a Notify payload of type INVALID_KE_PAYLOAD. See also with a Notify payload of type INVALID_KE_PAYLOAD. See also
skipping to change at page 87, line 47 skipping to change at line 4183
types of identification. types of identification.
Two implementations will interoperate only if each can generate a Two implementations will interoperate only if each can generate a
type of ID acceptable to the other. To assure maximum type of ID acceptable to the other. To assure maximum
interoperability, implementations MUST be configurable to send at interoperability, implementations MUST be configurable to send at
least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and
MUST be configurable to accept all of these types. Implementations MUST be configurable to accept all of these types. Implementations
SHOULD be capable of generating and accepting all of these types. SHOULD be capable of generating and accepting all of these types.
IPv6-capable implementations MUST additionally be configurable to IPv6-capable implementations MUST additionally be configurable to
accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable
to send only ID_IPV6_ADDR. to send only ID_IPV6_ADDR instead of ID_IPV6_ADDR for IP addresses.
EAP [EAP] does not mandate the use of any particular type of EAP [EAP] does not mandate the use of any particular type of
identifier, but often EAP is used with Network Access Identifiers identifier, but often EAP is used with Network Access Identifiers
(NAIs) defined in [NAI]. Although NAIs look a bit like email (NAIs) defined in [NAI]. Although NAIs look a bit like email
addresses (e.g., "joe@example.com"), the syntax is not exactly the addresses (e.g., "joe@example.com"), the syntax is not exactly the
same as the syntax of email address in [MAILFORMAT]. For those NAIs same as the syntax of email address in [MAILFORMAT]. For those NAIs
that include the realm component, the ID_RFC822_ADDR identification that include the realm component, the ID_RFC822_ADDR identification
type SHOULD be used. Responder implementations should not attempt to type SHOULD be used. Responder implementations should not attempt to
verify that the contents actually conform to the exact syntax given verify that the contents actually conform to the exact syntax given
in [MAILFORMAT], but instead should accept any reasonable-looking in [MAILFORMAT], but instead should accept any reasonable-looking
skipping to change at page 88, line 20 skipping to change at line 4205
identification type SHOULD be used. identification type SHOULD be used.
3.6. Certificate Payload 3.6. Certificate Payload
The Certificate Payload, denoted CERT in this document, provides a The Certificate Payload, denoted CERT in this document, provides a
means to transport certificates or other authentication-related means to transport certificates or other authentication-related
information via IKE. Certificate payloads SHOULD be included in an information via IKE. Certificate payloads SHOULD be included in an
exchange if certificates are available to the sender. The Hash and exchange if certificates are available to the sender. The Hash and
URL formats of the Certificate payloads should be used in case the URL formats of the Certificate payloads should be used in case the
peer has indicated an ability to retrieve this information from peer has indicated an ability to retrieve this information from
elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note
Certificate payloads SHOULD be included in an exchange if that the term "Certificate Payload" is somewhat misleading, because
certificates are available to the sender unless the peer has not all authentication mechanisms use certificates and data other
indicated an ability to retrieve this information from elsewhere than certificates may be passed in this payload.
using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note that the
term "Certificate Payload" is somewhat misleading, because not all
authentication mechanisms use certificates and data other than
certificates may be passed in this payload.
The Certificate Payload is defined as follows: The Certificate Payload is defined as follows:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert Encoding | | | Cert Encoding | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
skipping to change at page 89, line 52 skipping to change at line 4280
o Hash and URL encodings allow IKE messages to remain short by o Hash and URL encodings allow IKE messages to remain short by
replacing long data structures with a 20 octet SHA-1 hash (see replacing long data structures with a 20 octet SHA-1 hash (see
[SHA]) of the replaced value followed by a variable-length URL [SHA]) of the replaced value followed by a variable-length URL
that resolves to the DER encoded data structure itself. This that resolves to the DER encoded data structure itself. This
improves efficiency when the endpoints have certificate data improves efficiency when the endpoints have certificate data
cached and makes IKE less subject to denial of service attacks cached and makes IKE less subject to denial of service attacks
that become easier to mount when IKE messages are large enough to that become easier to mount when IKE messages are large enough to
require IP fragmentation [DOSUDPPROT]. require IP fragmentation [DOSUDPPROT].
Use the following ASN.1 definition for an X.509 bundle: The "Hash and URL of a bundle" type uses the following ASN.1
definition for the X.509 bundle:
CertBundle CertBundle
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-cert-bundle(34) } id-mod-cert-bundle(34) }
DEFINITIONS EXPLICIT TAGS ::= DEFINITIONS EXPLICIT TAGS ::=
BEGIN BEGIN
IMPORTS IMPORTS
skipping to change at page 90, line 48 skipping to change at line 4326
The behavior of other URL methods is not currently specified, and The behavior of other URL methods is not currently specified, and
such methods SHOULD NOT be used in the absence of a document such methods SHOULD NOT be used in the absence of a document
specifying them. specifying them.
3.7. Certificate Request Payload 3.7. Certificate Request Payload
The Certificate Request Payload, denoted CERTREQ in this document, The Certificate Request Payload, denoted CERTREQ in this document,
provides a means to request preferred certificates via IKE and can provides a means to request preferred certificates via IKE and can
appear in the IKE_INIT_SA response and/or the IKE_AUTH request. appear in the IKE_INIT_SA response and/or the IKE_AUTH request.
Certificate Request payloads MAY be included in an exchange when the Certificate Request payloads MAY be included in an exchange when the
sender needs to get the certificate of the receiver. If multiple CAs sender needs to get the certificate of the receiver.
are trusted and the certificate encoding does not allow a list, then
multiple Certificate Request payloads would need to be transmitted.
The Certificate Request Payload is defined as follows: The Certificate Request Payload is defined as follows:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert Encoding | | | Cert Encoding | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
skipping to change at page 94, line 35 skipping to change at line 4505
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Nonce Payload Format Figure 15: Nonce Payload Format
o Nonce Data (variable length) - Contains the random data generated o Nonce Data (variable length) - Contains the random data generated
by the transmitting entity. by the transmitting entity.
The payload type for the Nonce Payload is forty (40). The payload type for the Nonce Payload is forty (40).
The size of a Nonce MUST be between 16 and 256 octets inclusive. The size the Nonce Data MUST be between 16 and 256 octets inclusive.
Nonce values MUST NOT be reused. Nonce values MUST NOT be reused.
3.10. Notify Payload 3.10. Notify Payload
The Notify Payload, denoted N in this document, is used to transmit The Notify Payload, denoted N in this document, is used to transmit
informational data, such as error conditions and state transitions, informational data, such as error conditions and state transitions,
to an IKE peer. A Notify Payload may appear in a response message to an IKE peer. A Notify Payload may appear in a response message
(usually specifying why a request was rejected), in an INFORMATIONAL (usually specifying why a request was rejected), in an INFORMATIONAL
Exchange (to report an error not in an IKE request), or in any other Exchange (to report an error not in an IKE request), or in any other
message to indicate sender capabilities or to modify the meaning of message to indicate sender capabilities or to modify the meaning of
skipping to change at page 97, line 13 skipping to change at line 4624
written to a console or log. written to a console or log.
INVALID_MESSAGE_ID 9 INVALID_MESSAGE_ID 9
See Section 2.3. See Section 2.3.
INVALID_SPI 11 INVALID_SPI 11
See Section 1.5. See Section 1.5.
NO_PROPOSAL_CHOSEN 14 NO_PROPOSAL_CHOSEN 14
None of the proposed crypto suites was acceptable. This can be None of the proposed crypto suites was acceptable. This can be
sent in any case where the offered proposal (including but not sent in any case where the offered proposals (including but not
limited to SA payload values, USE_TRANSPORT_MODE notify, limited to SA payload values, USE_TRANSPORT_MODE notify,
IPCOMP_SUPPORTED notify) are not acceptable for the responder. IPCOMP_SUPPORTED notify) are not acceptable for the responder.
This can also be used as "generic" Child SA error when Child SA This can also be used as "generic" Child SA error when Child SA
cannot be created for some other reason. See also Section 2.7. cannot be created for some other reason. See also Section 2.7.
INVALID_KE_PAYLOAD 17 INVALID_KE_PAYLOAD 17
See Section 1.3 and 2.7. See Section 1.2 and 1.3.
AUTHENTICATION_FAILED 24 AUTHENTICATION_FAILED 24
Sent in the response to an IKE_AUTH message when for some reason Sent in the response to an IKE_AUTH message when for some reason
the authentication failed. There is no associated data. See also the authentication failed. There is no associated data. See also
Section 2.21.2. Section 2.21.2.
SINGLE_PAIR_REQUIRED 34 SINGLE_PAIR_REQUIRED 34
See Section 2.9. See Section 2.9.
NO_ADDITIONAL_SAS 35 NO_ADDITIONAL_SAS 35
skipping to change at page 100, line 18 skipping to change at line 4768
defined constant. The constant is used by vendors to identify and defined constant. The constant is used by vendors to identify and
recognize remote instances of their implementations. This mechanism recognize remote instances of their implementations. This mechanism
allows a vendor to experiment with new features while maintaining allows a vendor to experiment with new features while maintaining
backward compatibility. backward compatibility.
A Vendor ID payload MAY announce that the sender is capable of A Vendor ID payload MAY announce that the sender is capable of
accepting certain extensions to the protocol, or it MAY simply accepting certain extensions to the protocol, or it MAY simply
identify the implementation as an aid in debugging. A Vendor ID identify the implementation as an aid in debugging. A Vendor ID
payload MUST NOT change the interpretation of any information defined payload MUST NOT change the interpretation of any information defined
in this specification (i.e., the critical bit MUST be set to 0). in this specification (i.e., the critical bit MUST be set to 0).
Multiple Vendor ID payloads MAY be sent. An implementation is NOT Multiple Vendor ID payloads MAY be sent. An implementation is not
REQUIRED to send any Vendor ID payload at all. required to send any Vendor ID payload at all.
A Vendor ID payload may be sent as part of any message. Reception of A Vendor ID payload may be sent as part of any message. Reception of
a familiar Vendor ID payload allows an implementation to make use of a familiar Vendor ID payload allows an implementation to make use of
private use numbers described throughout this document, such as private use numbers described throughout this document, such as
private payloads, private exchanges, private notifications, etc. private payloads, private exchanges, private notifications, etc.
Unfamiliar Vendor IDs MUST be ignored. Unfamiliar Vendor IDs MUST be ignored.
Writers of Internet-Drafts who wish to extend this protocol MUST Writers of Internet-Drafts who wish to extend this protocol MUST
define a Vendor ID payload to announce the ability to implement the define a Vendor ID payload to announce the ability to implement the
extension in the Internet-Draft. It is expected that Internet-Drafts extension in the Internet-Draft. It is expected that Internet-Drafts
skipping to change at page 104, line 32 skipping to change at line 4975
TS_IPV6_ADDR_RANGE 8 TS_IPV6_ADDR_RANGE 8
A range of IPv6 addresses, represented by two sixteen-octet A range of IPv6 addresses, represented by two sixteen-octet
values. The first value is the beginning IPv6 address values. The first value is the beginning IPv6 address
(inclusive) and the second value is the ending IPv6 address (inclusive) and the second value is the ending IPv6 address
(inclusive). All addresses falling between the two specified (inclusive). All addresses falling between the two specified
addresses are considered to be within the list. addresses are considered to be within the list.
3.14. Encrypted Payload 3.14. Encrypted Payload
The Encrypted Payload, denoted SK{...} or E in this document, The Encrypted Payload, denoted SK{...} in this document, contains
contains other payloads in encrypted form. The Encrypted Payload, if other payloads in encrypted form. The Encrypted Payload, if present
present in a message, MUST be the last payload in the message. in a message, MUST be the last payload in the message. Often, it is
Often, it is the only payload in the message. the only payload in the message. This payload is also called the
"Encrypted and Authenticated" payload.
The algorithms for encryption and integrity protection are negotiated The algorithms for encryption and integrity protection are negotiated
during IKE SA setup, and the keys are computed as specified in during IKE SA setup, and the keys are computed as specified in
Section 2.14 and Section 2.18. Section 2.14 and Section 2.18.
This document specifies the cryptographic processing of Encrypted This document specifies the cryptographic processing of Encrypted
payloads using a block cipher in CBC mode and an integrity check payloads using a block cipher in CBC mode and an integrity check
algorithm that computes a fixed-length checksum over a variable size algorithm that computes a fixed-length checksum over a variable size
message. The design is modeled after the ESP algorithms described in message. The design is modeled after the ESP algorithms described in
RFCs 2104 [HMAC], 4303 [ESP], and 2451 [ESPCBC]. This document RFCs 2104 [HMAC], 4303 [ESP], and 2451 [ESPCBC]. This document
skipping to change at page 107, line 23 skipping to change at line 5111
-------------------------- --------------------------
CFG_REQUEST 1 CFG_REQUEST 1
CFG_REPLY 2 CFG_REPLY 2
CFG_SET 3 CFG_SET 3
CFG_ACK 4 CFG_ACK 4
o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on
receipt. receipt.
o Configuration Attributes (variable length) - These are type length o Configuration Attributes (variable length) - These are type length
values specific to the Configuration Payload and are defined value (TLV) structures specific to the Configuration Payload and
below. There may be zero or more Configuration Attributes in this are defined below. There may be zero or more Configuration
payload. Attributes in this payload.
3.15.1. Configuration Attributes 3.15.1. Configuration Attributes
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Attribute Type | Length | |R| Attribute Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Value ~ ~ Value ~
skipping to change at page 107, line 51 skipping to change at line 5139
o Reserved (1 bit) - This bit MUST be set to zero and MUST be o Reserved (1 bit) - This bit MUST be set to zero and MUST be
ignored on receipt. ignored on receipt.
o Attribute Type (15 bits) - A unique identifier for each of the o Attribute Type (15 bits) - A unique identifier for each of the
Configuration Attribute Types. Configuration Attribute Types.
o Length (2 octets) - Length in octets of Value. o Length (2 octets) - Length in octets of Value.
o Value (0 or more octets) - The variable-length value of this o Value (0 or more octets) - The variable-length value of this
Configuration Attribute. The following lists the attribute types. Configuration Attribute. The following lists the attribute types.
The values in the following table are only current as of the
publication date of RFC 4306 (except INTERNAL_ADDRESS_EXPIRY and The values in the following table are only current as of the
INTERNAL_IP6_NBNS which were removed by this document). Other publication date of RFC 4306 (except INTERNAL_ADDRESS_EXPIRY and
values may have been added since then or will be added after the INTERNAL_IP6_NBNS which were removed by this document). Other values
publication of this document. Readers should refer to [IKEV2IANA] may have been added since then or will be added after the publication
for the latest values. of this document. Readers should refer to [IKEV2IANA] for the latest
values.
Attribute Type Value Multi-Valued Length Attribute Type Value Multi-Valued Length
------------------------------------------------------------ ------------------------------------------------------------
INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets
INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets
INTERNAL_IP4_DNS 3 YES 0 or 4 octets INTERNAL_IP4_DNS 3 YES 0 or 4 octets
INTERNAL_IP4_NBNS 4 YES 0 or 4 octets INTERNAL_IP4_NBNS 4 YES 0 or 4 octets
INTERNAL_IP4_DHCP 6 YES 0 or 4 octets INTERNAL_IP4_DHCP 6 YES 0 or 4 octets
APPLICATION_VERSION 7 NO 0 or more APPLICATION_VERSION 7 NO 0 or more
INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets
skipping to change at page 112, line 19 skipping to change at line 5347
then the gateway's response might be: then the gateway's response might be:
CP(CFG_REPLY) = CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(198.51.100.234) INTERNAL_IP4_ADDRESS(198.51.100.234)
INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192) INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 198.51.100.234-198.51.100.234) TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
TSr = (0, 0-65535, 192.0.2.155-192.0.2.155) TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)
Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET is in Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET in
CFG_REQUESTs is unclear, they cannot be used reliably in CFG_REQUESTs is unclear, they cannot be used reliably in
CFG_REQUESTs. CFG_REQUESTs.
3.15.3. Configuration payloads for IPv6 3.15.3. Configuration payloads for IPv6
The configuration payloads for IPv6 are based on the corresponding The configuration payloads for IPv6 are based on the corresponding
IPv4 payloads, and do not fully follow the "normal IPv6 way of doing IPv4 payloads, and do not fully follow the "normal IPv6 way of doing
things". In particular, IPv6 stateless autoconfiguration or router things". In particular, IPv6 stateless autoconfiguration or router
advertisement messages are not used; neither is neighbor discovery. advertisement messages are not used; neither is neighbor discovery.
Note that there is an additional document that discusses IPv6 Note that there is an additional document that discusses IPv6
skipping to change at page 115, line 6 skipping to change at line 5479
Figure 25: EAP Message Format Figure 25: EAP Message Format
o Code (1 octet) indicates whether this message is a Request (1), o Code (1 octet) indicates whether this message is a Request (1),
Response (2), Success (3), or Failure (4). Response (2), Success (3), or Failure (4).
o Identifier (1 octet) is used in PPP to distinguish replayed o Identifier (1 octet) is used in PPP to distinguish replayed
messages from repeated ones. Since in IKE, EAP runs over a messages from repeated ones. Since in IKE, EAP runs over a
reliable protocol, it serves no function here. In a response reliable protocol, it serves no function here. In a response
message, this octet MUST be set to match the identifier in the message, this octet MUST be set to match the identifier in the
corresponding request. In other messages, this field MAY be set corresponding request.
to any value.
o Length (2 octets) is the length of the EAP message and MUST be o Length (2 octets) is the length of the EAP message and MUST be
four less than the Payload Length of the encapsulating payload. four less than the Payload Length of the encapsulating payload.
o Type (1 octet) is present only if the Code field is Request (1) or o Type (1 octet) is present only if the Code field is Request (1) or
Response (2). For other codes, the EAP message length MUST be Response (2). For other codes, the EAP message length MUST be
four octets and the Type and Type_Data fields MUST NOT be present. four octets and the Type and Type_Data fields MUST NOT be present.
In a Request (1) message, Type indicates the data being requested. In a Request (1) message, Type indicates the data being requested.
In a Response (2) message, Type MUST either be Nak or match the In a Response (2) message, Type MUST either be Nak or match the
type of the data requested. The following types are defined in type of the data requested. Note that since IKE passes an
[EAP]: indication of initiator identity in message 3 of the protocol, the
responder SHOULD NOT send EAP Identity requests (type 1). The
1 Identity initiator MAY, however, respond to such requests if it receives
2 Notification them.
3 Nak (Response Only)
4 MD5-Challenge
5 One-Time Password (OTP)
6 Generic Token Card
o Type_Data (Variable Length) varies with the Type of Request and o Type_Data (Variable Length) varies with the Type of Request and
the associated Response. For the documentation of the EAP the associated Response. For the documentation of the EAP
methods, see [EAP]. methods, see [EAP].
Note that since IKE passes an indication of initiator identity in Note that since IKE passes an indication of initiator identity in
message 3 of the protocol, the responder should not send EAP Identity message 3 of the protocol, the responder should not send EAP Identity
requests. The initiator may, however, respond to such requests if it requests. The initiator may, however, respond to such requests if it
receives them. receives them.
skipping to change at page 116, line 12 skipping to change at line 5527
of optional features that can easily be ignored by a particular of optional features that can easily be ignored by a particular
implementation if it does not support that feature. Those features implementation if it does not support that feature. Those features
include: include:
o Ability to negotiate SAs through a NAT and tunnel the resulting o Ability to negotiate SAs through a NAT and tunnel the resulting
ESP SA over UDP. ESP SA over UDP.
o Ability to request (and respond to a request for) a temporary IP o Ability to request (and respond to a request for) a temporary IP
address on the remote end of a tunnel. address on the remote end of a tunnel.
o Ability to support various types of legacy authentication. o Ability to support EAP-based authentication.
o Ability to support window sizes greater than one. o Ability to support window sizes greater than one.
o Ability to establish multiple ESP or AH SAs within a single IKE o Ability to establish multiple ESP or AH SAs within a single IKE
SA. SA.
o Ability to rekey SAs. o Ability to rekey SAs.
To assure interoperability, all implementations MUST be capable of To assure interoperability, all implementations MUST be capable of
parsing all payload types (if only to skip over them) and to ignore parsing all payload types (if only to skip over them) and to ignore
skipping to change at page 117, line 14 skipping to change at line 5577
IP addresses, it MUST include a CP payload in message 3 containing at IP addresses, it MUST include a CP payload in message 3 containing at
least a field of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. least a field of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS.
All other fields are optional. If an implementation supports All other fields are optional. If an implementation supports
responding to such requests, it MUST parse the CP payload of type responding to such requests, it MUST parse the CP payload of type
CFG_REQUEST in message 3 and recognize a field of type CFG_REQUEST in message 3 and recognize a field of type
INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports leasing INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports leasing
an address of the appropriate type, it MUST return a CP payload of an address of the appropriate type, it MUST return a CP payload of
type CFG_REPLY containing an address of the requested type. The type CFG_REPLY containing an address of the requested type. The
responder may include any other related attributes. responder may include any other related attributes.
A minimal IPv4 responder implementation will ignore the contents of
the CP payload except to determine that it includes an
INTERNAL_IP4_ADDRESS attribute and will respond with the address and
other related attributes regardless of whether the initiator
requested them.
A minimal IPv4 initiator will generate a CP payload containing only
an INTERNAL_IP4_ADDRESS attribute and will parse the response
ignoring attributes it does not know how to use.
For an implementation to be called conforming to this specification, For an implementation to be called conforming to this specification,
it MUST be possible to configure it to accept the following: it MUST be possible to configure it to accept the following:
o PKIX Certificates containing and signed by RSA keys of size 1024 o PKIX Certificates containing and signed by RSA keys of size 1024
or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN,
ID_RFC822_ADDR, or ID_DER_ASN1_DN. ID_RFC822_ADDR, or ID_DER_ASN1_DN.
o Shared key authentication where the ID passed is any of ID_KEY_ID, o Shared key authentication where the ID passed is any of ID_KEY_ID,
ID_FQDN, or ID_RFC822_ADDR. ID_FQDN, or ID_RFC822_ADDR.
skipping to change at page 118, line 13 skipping to change at line 5613
initiator is willing to use. initiator is willing to use.
Use of EAP authentication changes the probing possibilities somewhat. Use of EAP authentication changes the probing possibilities somewhat.
When EAP authentication is used, the responder proves its identity When EAP authentication is used, the responder proves its identity
before the initiator does, so an initiator that knew the name of a before the initiator does, so an initiator that knew the name of a
valid initiator could probe the responder for both its name and valid initiator could probe the responder for both its name and
certificates. certificates.
Repeated rekeying using CREATE_CHILD_SA without additional Diffie- Repeated rekeying using CREATE_CHILD_SA without additional Diffie-
Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a
single key or overrun of either endpoint. Implementers should take single key. Implementers should take note of this fact and set a
note of this fact and set a limit on CREATE_CHILD_SA exchanges limit on CREATE_CHILD_SA exchanges between exponentiations. This
between exponentiations. This document does not prescribe such a document does not prescribe such a limit.
limit.
The strength of a key derived from a Diffie-Hellman exchange using The strength of a key derived from a Diffie-Hellman exchange using
any of the groups defined here depends on the inherent strength of any of the groups defined here depends on the inherent strength of
the group, the size of the exponent used, and the entropy provided by the group, the size of the exponent used, and the entropy provided by
the random number generator used. Due to these inputs, it is the random number generator used. Due to these inputs, it is
difficult to determine the strength of a key for any of the defined difficult to determine the strength of a key for any of the defined
groups. Diffie-Hellman group number two, when used with a strong groups. Diffie-Hellman group number two, when used with a strong
random number generator and an exponent no less than 200 bits, is random number generator and an exponent no less than 200 bits, is
common for use with 3DES. Group five provides greater security than common for use with 3DES. Group five provides greater security than
group two. Group one is for historic purposes only and does not group two. Group one is for historic purposes only and does not
skipping to change at page 122, line 4 skipping to change at line 5795
IKEv2 packets. In environments where IP spoofing is possible (i.e., IKEv2 packets. In environments where IP spoofing is possible (i.e.,
almost everywhere) this essentially allows any peer to create Child almost everywhere) this essentially allows any peer to create Child
SAs with any traffic selectors. This is not an appropriate or secure SAs with any traffic selectors. This is not an appropriate or secure
configuration in most circumstances. See [H2HIPSEC] for an extensive configuration in most circumstances. See [H2HIPSEC] for an extensive
discussion about this issue, and the limitations of host-to-host discussion about this issue, and the limitations of host-to-host
IPsec in general. IPsec in general.
6. IANA Considerations 6. IANA Considerations
[IKEV2] defined many field types and values. IANA has already [IKEV2] defined many field types and values. IANA has already
registered those types and values in [IKEV2IANA], so the are not registered those types and values in [IKEV2IANA], so they are not
listed here again. listed here again.
Two items are removed from the IKEv2 Configuration Payload Attribute Two items are removed from the IKEv2 Configuration Payload Attribute
Types table: INTERNAL_IP6_NBNS and INTERNAL_ADDRESS_EXPIRY. Types table: INTERNAL_IP6_NBNS and INTERNAL_ADDRESS_EXPIRY.
Two new additions to the IKEv2 parameters "NOTIFY MESSAGES - ERROR Two new additions to the IKEv2 parameters "NOTIFY MESSAGES - ERROR
TYPES" registry are defined here that were not defined in [IKEV2]: TYPES" registry are defined here that were not defined in [IKEV2]:
{TBA1} TEMPORARY_FAILURE {TBA1} TEMPORARY_FAILURE
{TBA2} CHILD_SA_NOT_FOUND {TBA2} CHILD_SA_NOT_FOUND
IANA should change the exiting IKEv2 Payload Types table from:
46 Encrypted E [RFC4306]
to
46 Encrypted and Authenticated SK [This document]
IANA should update all references to RFC 4306 to point to this IANA should update all references to RFC 4306 to point to this
document. document.
7. Acknowledgements 7. Acknowledgements
Many individuals in the IPsecME Working Group were very helpful in Many individuals in the IPsecME Working Group were very helpful in
contributing ideas and text for this document, as well as in contributing ideas and text for this document, as well as in
reviewing the clarifications suggested by others. reviewing the clarifications suggested by others.
The acknowledgements from the IKEv2 document were: The acknowledgements from the IKEv2 document were:
skipping to change at page 126, line 23 skipping to change at line 6013
[IP-COMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP [IP-COMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP
Payload Compression Protocol (IPComp)", RFC 3173, Payload Compression Protocol (IPComp)", RFC 3173,
September 2001. September 2001.
[IPSECARCH-OLD] [IPSECARCH-OLD]
Kent, S. and R. Atkinson, "Security Architecture for the Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[IPV6CONFIG] [IPV6CONFIG]
Eronen, et. al., P., "IPv6 Configuration in IKEv2", Eronen, et. al., P., "IPv6 Configuration in IKEv2",
draft-ietf-ipsecme-ikev2-ipv6-config (work in progress), RFC 5739, February 2010.
August 2009.
[ISAKMP] Maughan, D., Schneider, M., and M. Schertler, "Internet [ISAKMP] Maughan, D., Schneider, M., and M. Schertler, "Internet
Security Association and Key Management Protocol Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998. (ISAKMP)", RFC 2408, November 1998.
[MAILFORMAT] [MAILFORMAT]
Resnick, P., "Internet Message Format", RFC 5322, Resnick, P., "Internet Message Format", RFC 5322,
October 2008. October 2008.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
skipping to change at page 144, line 22 skipping to change at line 6844
draft-ietf-ipsecme-ikev2bis-02 draft-ietf-ipsecme-ikev2bis-02
In section 1.3.1, added "Failure of an attempt to create a CHILD SA In section 1.3.1, added "Failure of an attempt to create a CHILD SA
SHOULD NOT tear down the IKE SA: there is no reason to lose the work SHOULD NOT tear down the IKE SA: there is no reason to lose the work
done to set up the IKE SA. When an IKE SA is not created, the error done to set up the IKE SA. When an IKE SA is not created, the error
message return SHOULD NOT be encrypted because the other party will message return SHOULD NOT be encrypted because the other party will
not be able to authenticate that message." This may be changed again not be able to authenticate that message." This may be changed again
in the future. [Issue #9] in the future. [Issue #9]
In section 1.3.2, changed "The KEi payload SHOULD be included" to be In section 1.3.2, changed "The KEi payload SHOULD be included" to be
"The KEi payload MUST be included". This also lead to changes in "The KEi payload MUST be included". This also led to changes in
section 2.18. The square brackets around "g^ir (new)" in the section 2.18. The square brackets around "g^ir (new)" in the
SKEYSEED calculation are eliminated, and the requirement language in SKEYSEED calculation are eliminated, and the requirement language in
the paragraph starting "The main rekeying" is changed from SHOULD to the paragraph starting "The main rekeying" is changed from SHOULD to
MUST. [Issue #50] MUST. [Issue #50]
In section 1.3.2, changed "The window size starts at 1 for any new In section 1.3.2, changed "The window size starts at 1 for any new
IKE SA." to "The first IKE requests from both sides on the new IKE SA IKE SA." to "The first IKE requests from both sides on the new IKE SA
will have message ID 0. The old IKE SA retains its numbering, so any will have message ID 0. The old IKE SA retains its numbering, so any
further requests (for example, to delete the IKE SA) will have further requests (for example, to delete the IKE SA) will have
consecutive numbering. The new IKE SA also has its window size reset consecutive numbering. The new IKE SA also has its window size reset
skipping to change at page 158, line 19 skipping to change at line 7517
[V+][N+] [V+][N+]
to to
request --> SA, Ni, KEi request --> SA, Ni, KEi
[V+][N+] [V+][N+]
response <-- SA, Nr, KEr response <-- SA, Nr, KEr
[V+][N+] [V+][N+]
D.15. Changes from draft-ietf-ipsecme-ikev2bis-07 to
draft-ietf-ipsecme-ikev2bis-08
Lots more small editorial issues fixed.
These changes were made after WG Last Call, mostly to close out open
issues.
In 1.2, changed "The recipients of messages 3 and 4 MUST verify that
all signatures and MACs are computed correctly and that the names in
the ID payloads correspond to the keys used to generate the AUTH
payload." to "The recipients of messages 3 and 4 MUST verify that all
signatures and MACs are computed correctly. If either side uses a
shared secret for authentication, the names in the ID payload MUST
correspond to the key used to generate the AUTH payload."
In 1.3, added "This notify can also be used to reject IKE SA rekey"
to the discussion of sending the NO_ADDITIONAL_SAS notification.
[Issue #132]
In 1.3.2, added a pointer to 2.18; vice versa.
Added to 1.3.3: "The notifications described in Section 1.3.1 may
also be sent in a rekeying exchange. Usually these will be the same
notifications that were used in the original exchange; for example,
when rekeying a transport mode SA, the USE_TRANSPORT_MODE
notification will be used." [Issue #133]
In 1.4.1, replaced the last paragraph ("Half-closed ESP or AH
connections...") with two paragraphs that clarify deleting IKE SAs as
compared to half-closed ESP or AH connections.
In 1.5, changed "If the receiving node does not have an active IKE SA
to the IP address from whence the packet came, it" to "The receiving
node".
In 1.5, replaced the last three paragraphs ("There are two cases...",
"In case of INVALID_IKE_SPI...", and "In case of INVALID_SPI...")
with a more detailed description. [Issue #143]
In 1.7, added "Section 2.23 clarified that, in NAT traversal, now
both UDP encapsulated IPsec packets and non-UDP encapsulated IPsec
packets packets need to be understood when receiving."
Added a new paragraph at the end of 2.1 ("The retransmission policy
for one-way messages is somewhat different..."). [Issue #147]
Replaced the first paragraph in 2.6 with a shorter one, and moved the
historical material to the end of the section. [Issue #148]
In 2.6.1, removed "SAi1 and" from "For instance, if the responder
includes the SAi1 and KEi payloads in cookie calculation..." [Issue
#134]
In 2.7, moved the paragraph that begins "Because the initiator sends
its Diffie-Hellman value in the IKE_SA_INIT" to 1.2. [Issue #144]
In 2.8, replaced "MAY send a dummy message on a newly created SA"
with "MAY send a dummy ESP message on a newly created ESP SA".
[Issue #154]
In 2.8, changed "...it has received a cryptographically valid message
on the new SA..." to "...it has received a cryptographically valid
message on the other half of the SA pair...". [Issue #149]
In 2.8.2, changed "The new IKE SA containing the lowest nonce
inherits the Child SAs" to "The new IKE SA containing the lowest
nonce SHOULD be deleted by the node that created it, and the other
suriving new IKE SA MUST inherit all the Child SAs". [Issue #135]
In 2.8.2, added "In addition to normal simultaneous rekeying cases,
there is a special case where one peer finishes its rekey before it
even notices that other peer is doing a rekey." [Issue #171]
In 2.8.2, added "Support of the TEMPORARY_FAILURE notification is not
negotiated, so older peers may receive these notifications. In that
case, they will treat it the same as any other unknown error
notification, and will stop the exchange. Because the other peer has
already rekeyed the exchange, doing so does not have any ill
effects." [Issue #150]
In 2.9, reverted to using a SHOULD for trigger packets. Replaced "If
the initiator requests an SA because it wants to send a data packet,
including the specific addresses in the packet triggering the request
in the first traffic selector in both TSi and TSr enables the
responder to choose the appropriate range" with "To enable the
responder to choose the appropriate range in this case, if the
initiator has requested the SA due to a data packet, the initiator
SHOULD include as the first traffic selector in each of TSi and TSr a
very specific traffic selector including the addresses in the packet
triggering the request." [Issue #155]
In 2.14, changed "only the first 64 bits of Ni and the first 64 bits
of Nr are used in the calculation" to "only the first 64 bits of Ni
and the first 64 bits of Nr are used in calculating SKEYSEED, but all
the bits are used for input to the prf+ function". [Issue #138]
Added to the end of 2.15: "There are two types of EAP authentication
(described in Section 2.16), and each type uses different values in
the AUTH computations shown above. If the EAP method is key-
generating, substitute MSK for the Shared Secret in the computation.
For non-key-generating methods, substitute SK_pi and SK_pr,
respectively, for the Shared Secret in the two AUTH computations."
[Issue #151]
In 2.16, changed "the authenticated identity has to be sent" to "the
authenticated identity, if different from that in the IDi payload,
has to be sent". [Issue #174]
In 2.17, significantly changed the discussion of the order in which
keying material is taken from KEYMAT. The result is the same, but
the description is quite different, and now also refers to ROHC.
[Issue #139]
In 2.21, changed "Only authentication failures
(AUTHENTICATION_FAILED)..." to "Only authentication failures
(AUTHENTICATION_FAILED and EAP failure)...". Also added "If the
exchange is terminated with EAP Failure, an AUTHENTICATION_FAILED
notification is not sent." [Issue #152 and #160]
In 2.21.2, removed INVALID_SELECTORS from the list of things that are
returned from the piggybacked exchanges. [Issue #166]
In 2.23, changed "In the case of NAT traversal, the Traffic Selectors
MUST contain exactly one IP address, which is then used as the
original IP address" to "In the case of transport mode NAT traversal,
the Traffic Selectors MUST contain exactly one IP address, which is
then used as the original IP address". [Issue #136]
In 2.23, completely replaced the paragraph that begins "An initiator
can use port 4500". [Issue #146]
In 2.23, changed "In addition, firewalls may be configured to pass
IPsec traffic over UDP but not ESP/AH or vice versa." to "In
addition, firewalls may be configured to pass UDP-encapsulated IPsec
traffic but not plain, unencapsulated ESP/AH or vice versa".
In 2.23, changed "SPIs, source IP address, and port" to "SPIs, source
or recipient IP address respectively, and port". [Issue #162].
In 2.23, completely replaced the last paragraph ("There are cases
where a NAT box..."). [Issue #175]
In 2.23.1, changed "When the client starts creating the IKEv2 SA and
Child SA for sending traffic to the server, it has a triggering
packet with source IP address of IP1, and a destination IP address of
IPN2" to "...it may have a triggering packet...". Changed "The first
traffic selector of TSi and TSr SHOULD have very specific traffic
selectors including protocol and port numbers from the packet
triggering the request" to "...SHOULD have very specific traffic
selectors including protocol and port numbers, such as from the
packet...". The same change is made in the third bullet of the
client list near the end of the section. [Issue #173]
At the beginning of the second paragraph of 3.1, changed "The
Recipient SPI" to the "The responder's SPI".
In 3.1, changed "Payloads are processed in the order in which they
appear in an IKE message by invoking the appropriate processing
routine according to the "Next Payload" field in the IKE header and
subsequently according to the "Next Payload" field in the IKE payload
itself until a "Next Payload" field of zero indicates that no
payloads follow" to "Payloads are identified in the order in which
they appear in an IKE message by looking in the "Next Payload" field
in the IKE header, and subsequently according to the "Next Payload"
field in the IKE payload itself until a "Next Payload" field of zero
indicates that no payloads follow". [Issue #159]
In 3.1, added "including multiple sessions per peer" to the end of
the second paragraph.
In 3.2, changed "In the header of an Encrypted payload, the Next
Payload field is set to the payload type of the first contained
payload (instead of 0)" to "In the header of an Encrypted payload,
the Next Payload field is set to the payload type of the first
contained payload (instead of 0); conversely, the Next Payload field
of the last contained payload is set to zero." [Issue #164]
In 3.3, changed the example of the two proposals and added a worked-
out figure for them. [Issue #157]
In 3.3.2, changed PRF_HMAC_TIGER to UNSPECIFIED.
In 3.3.5, added "unless that length exceeds two bytes" to the end of
"Attributes described as fixed length MUST NOT be encoded using the
variable-length encoding". [Issue #167]
In 3.3.6, changed "The initiator of an exchange MUST check that the
accepted offer is consistent with one of its proposals, and if not
that response MUST be rejected" to "The initiator of an exchange MUST
check that the accepted offer is consistent with one of its
proposals, and if not MUST terminate the exchange".
In 3.3.6, changed "Similarly, if the responder receives a transform
that contains a Transform Attribute it does not understand..." to
"Similarly, if the responder receives a transform that it does not
understand, or one that contains a Transform Attribute it does not
understand...".
In 3.4, changed "The length of the Diffie-Hellman public value MUST
be equal to the length of the prime modulus over which the
exponentiation was performed, prepending zero bits to the value if
necessary" to "The length of the the Diffie-Hellman public value for
MODP groups..." (because it is not true for elliptic curve groups).
In 3.5, changed "IPv6-only implementations MAY be configurable to
send only ID_IPV6_ADDR" to "IPv6-only implementations MAY be
configurable to send ID_IPV6_ADDR instead of ID_IPV6_ADDR for IP
addresses."
In 3.6, replaced "Use the following ASN.1 definition for an X.509
bundle" by "The "Hash and URL of a bundle" type uses the following
ASN.1 definition for the X.509 bundle".
In 3.7, removed "If multiple CAs are trusted and the certificate
encoding does not allow a list, then multiple Certificate Request
payloads would need to be transmitted".
In 3.14, added "This payload is also called the "Encrypted and
Authenticated" payload."
In 3.16, removed the table of EAP types and replaced it with "Note
that since IKE passes an indication of initiator identity in message
3 of the protocol, the responder SHOULD NOT send EAP Identity
requests (type 1). The initiator MAY, however, respond to such
requests if it receives them." [Issue #153]
In 3.16, removed "In other messages, this field MAY be set to any
value" from the bullet defining Identifier. [Issue #168]
In 4, changed "Ability to support various types of legacy
authentication" to "Ability to support EAP-based authentication".
In section 4, removed two sentences ("A minimal IPv4 responder
implementation..." and "A minimal IPv4 initiator...") because they
were redundant with the preceding text but also used new terms that
were not defined. [Issue #172]
In 5, removed "or overrun of either endpoint". [Issue #169]
In 6, added that IANA should change "46 Encrypted E" to "46 Encrypted
SK".
In 8.2, updated the pointer for IPV6CONFIG to RFC 5739.
Authors' Addresses Authors' Addresses
Charlie Kaufman Charlie Kaufman
Microsoft Microsoft
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
US US
Phone: 1-425-707-3335 Phone: 1-425-707-3335
Email: charliek@microsoft.com Email: charliek@microsoft.com
 End of changes. 109 change blocks. 
473 lines changed or deleted 818 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/