--- 1/draft-ietf-ipsecme-ikev2bis-06.txt 2010-01-21 00:11:10.000000000 +0100 +++ 2/draft-ietf-ipsecme-ikev2bis-07.txt 2010-01-21 00:11:10.000000000 +0100 @@ -1,31 +1,31 @@ Network Working Group C. Kaufman Internet-Draft Microsoft Obsoletes: 4306, 4718 P. Hoffman (if approved) VPN Consortium Intended status: Standards Track Y. Nir -Expires: June 12, 2010 Check Point +Expires: July 24, 2010 Check Point P. Eronen Nokia - December 9, 2009 + January 20, 2010 Internet Key Exchange Protocol: IKEv2 - draft-ietf-ipsecme-ikev2bis-06 + draft-ietf-ipsecme-ikev2bis-07 Abstract This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations - (SAs). It replaces and updates RFC 4306, and includes all of the - clarifications from RFC 4718. + (SAs). This document replaces and updates RFC 4306, and includes all + of the clarifications from RFC 4718. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -34,25 +34,25 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on June 12, 2010. + This Internet-Draft will expire on July 24, 2010. Copyright Notice - Copyright (c) 2009 IETF Trust and the persons identified as the + Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -82,55 +82,56 @@ 1.3. The CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 12 1.3.1. Creating New Child SAs with the CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . . . . . . . . . 13 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange . 15 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . . . . . . . . . 15 1.4. The INFORMATIONAL Exchange . . . . . . . . . . . . . . . 16 1.4.1. Deleting an SA with INFORMATIONAL Exchanges . . . . . 17 1.5. Informational Messages outside of an IKE SA . . . . . . . 18 1.6. Requirements Terminology . . . . . . . . . . . . . . . . 19 - 1.7. Differences Between RFC 4306 and This Document . . . . . 19 - 2. IKE Protocol Details and Variations . . . . . . . . . . . . . 20 - 2.1. Use of Retransmission Timers . . . . . . . . . . . . . . 21 - 2.2. Use of Sequence Numbers for Message ID . . . . . . . . . 22 - 2.3. Window Size for Overlapping Requests . . . . . . . . . . 23 - 2.4. State Synchronization and Connection Timeouts . . . . . . 24 - 2.5. Version Numbers and Forward Compatibility . . . . . . . . 26 - 2.6. IKE SA SPIs and Cookies . . . . . . . . . . . . . . . . . 28 - 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . 30 - 2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 31 - 2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 32 - 2.8.1. Simultaneous Child SA rekeying . . . . . . . . . . . 34 - 2.8.2. Simultaneous IKE SA Rekeying . . . . . . . . . . . . 36 - 2.8.3. Rekeying the IKE SA Versus Reauthentication . . . . . 37 - 2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 38 - 2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 41 - 2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 41 - 2.11. Address and Port Agility . . . . . . . . . . . . . . . . 42 - 2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 42 - 2.13. Generating Keying Material . . . . . . . . . . . . . . . 43 - 2.14. Generating Keying Material for the IKE SA . . . . . . . . 44 - 2.15. Authentication of the IKE SA . . . . . . . . . . . . . . 45 - 2.16. Extensible Authentication Protocol Methods . . . . . . . 47 - 2.17. Generating Keying Material for Child SAs . . . . . . . . 49 - 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange . . . . 50 - 2.19. Requesting an Internal Address on a Remote Network . . . 51 - 2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 52 - 2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 53 - 2.21.1. Error Handling in IKE_SA_INIT . . . . . . . . . . . . 53 - 2.21.2. Error Handling in IKE_AUTH . . . . . . . . . . . . . 54 - 2.21.3. Error Handling after IKE SA is Authenticated . . . . 55 - 2.21.4. Error Handling Outside IKE SA . . . . . . . . . . . . 55 - 2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 56 - 2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 57 - 2.23.1. Transport Mode NAT Traversal . . . . . . . . . . . . 61 + 1.7. Significant Differences Between RFC 4306 and This + Document . . . . . . . . . . . . . . . . . . . . . . . . 19 + 2. IKE Protocol Details and Variations . . . . . . . . . . . . . 21 + 2.1. Use of Retransmission Timers . . . . . . . . . . . . . . 22 + 2.2. Use of Sequence Numbers for Message ID . . . . . . . . . 23 + 2.3. Window Size for Overlapping Requests . . . . . . . . . . 24 + 2.4. State Synchronization and Connection Timeouts . . . . . . 25 + 2.5. Version Numbers and Forward Compatibility . . . . . . . . 27 + 2.6. IKE SA SPIs and Cookies . . . . . . . . . . . . . . . . . 29 + 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . 31 + 2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 32 + 2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 33 + 2.8.1. Simultaneous Child SA rekeying . . . . . . . . . . . 35 + 2.8.2. Simultaneous IKE SA Rekeying . . . . . . . . . . . . 38 + 2.8.3. Rekeying the IKE SA Versus Reauthentication . . . . . 38 + 2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 39 + 2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 42 + 2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 42 + 2.11. Address and Port Agility . . . . . . . . . . . . . . . . 43 + 2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 43 + 2.13. Generating Keying Material . . . . . . . . . . . . . . . 44 + 2.14. Generating Keying Material for the IKE SA . . . . . . . . 45 + 2.15. Authentication of the IKE SA . . . . . . . . . . . . . . 46 + 2.16. Extensible Authentication Protocol Methods . . . . . . . 48 + 2.17. Generating Keying Material for Child SAs . . . . . . . . 50 + 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange . . . . 51 + 2.19. Requesting an Internal Address on a Remote Network . . . 52 + 2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 53 + 2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 54 + 2.21.1. Error Handling in IKE_SA_INIT . . . . . . . . . . . . 54 + 2.21.2. Error Handling in IKE_AUTH . . . . . . . . . . . . . 55 + 2.21.3. Error Handling after IKE SA is Authenticated . . . . 56 + 2.21.4. Error Handling Outside IKE SA . . . . . . . . . . . . 56 + 2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 57 + 2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 58 + 2.23.1. Transport Mode NAT Traversal . . . . . . . . . . . . 62 2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 65 2.25. Exchange Collisions . . . . . . . . . . . . . . . . . . . 65 2.25.1. Collisions While Rekeying or Closing Child SAs . . . 66 2.25.2. Collisions While Rekeying or Closing IKE SAs . . . . 67 3. Header and Payload Formats . . . . . . . . . . . . . . . . . 67 3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 67 3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 70 3.3. Security Association Payload . . . . . . . . . . . . . . 72 3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 74 3.3.2. Transform Substructure . . . . . . . . . . . . . . . 76 @@ -140,100 +141,99 @@ 3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 82 3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 83 3.5. Identification Payloads . . . . . . . . . . . . . . . . . 84 3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 87 3.7. Certificate Request Payload . . . . . . . . . . . . . . . 89 3.8. Authentication Payload . . . . . . . . . . . . . . . . . 91 3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 93 3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 93 3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 94 3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 97 - 3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 98 + 3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 99 3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 100 3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 101 3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 103 3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 105 3.15.1. Configuration Attributes . . . . . . . . . . . . . . 106 - 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 109 + 3.15.2. Meaning of INTERNAL_IP4_SUBNET and + INTERNAL_IP6_SUBNET . . . . . . . . . . . . . . . . . 109 3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 111 3.15.4. Address Assignment Failures . . . . . . . . . . . . . 112 - 3.16. Extensible Authentication Protocol (EAP) Payload . . . . 112 + 3.16. Extensible Authentication Protocol (EAP) Payload . . . . 113 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 114 5. Security Considerations . . . . . . . . . . . . . . . . . . . 116 5.1. Traffic selector authorization . . . . . . . . . . . . . 119 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 120 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 121 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 121 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 121 - 8.2. Informative References . . . . . . . . . . . . . . . . . 122 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 122 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 122 + 8.2. Informative References . . . . . . . . . . . . . . . . . 123 Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 127 Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 128 B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 128 - B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 128 + B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 129 Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 129 C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 129 C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 130 C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 131 C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 132 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA . . . . 132 C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 132 - Appendix D. Significant Changes from RFC 4306 . . . . . . . . . 132 - Appendix E. Changes Between Internet Draft Versions . . . . . . 133 - E.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 133 - E.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 133 - E.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 135 - E.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 136 - E.5. Changes from draft -02 to draft -03 . . . . . . . . . . . 137 - E.6. Changes from draft -03 to + Appendix D. Changes Between Internet Draft Versions . . . . . . 132 + D.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 133 + D.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 133 + D.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 135 + D.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 136 + D.5. Changes from draft -02 to draft -03 . . . . . . . . . . . 137 + D.6. Changes from draft -03 to draft-ietf-ipsecme-ikev2bis-00 . . . . . . . . . . . . . 138 - E.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 - E.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 - E.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 - E.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 - E.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 - E.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 - E.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 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 151 + D.14. Changes from draft-ietf-ipsecme-ikev2bis-06 to + draft-ietf-ipsecme-ikev2bis-07 . . . . . . . . . . . . . 151 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 157 1. Introduction - [[ An introduction to the differences between RFC 4306 [IKEV2] and - this document is given at the end of Section 1. It is put there - (instead of here) to preserve the section numbering of RFC 4306. ]] - IP Security (IPsec) provides confidentiality, data integrity, access control, and data source authentication to IP datagrams. These services are provided by maintaining shared state between the source and the sink of an IP datagram. This state defines, among other things, the specific services provided to the datagram, which cryptographic algorithms will be used to provide the services, and the keys used as input to the cryptographic algorithms. Establishing this shared state in a manual fashion does not scale well. Therefore, a protocol to establish this state dynamically is - needed. This memo describes such a protocol -- the Internet Key + needed. This document describes such a protocol -- the Internet Key Exchange (IKE). Version 1 of IKE was defined in RFCs 2407 [DOI], 2408 [ISAKMP], and 2409 [IKEV1]. IKEv2 replaced all of those RFCs. IKEv2 was defined in [IKEV2] (RFC 4306) and was clarified in [Clarif] (RFC 4718). This document replaces and updates RFC 4306 and RFC 4718. IKEv2 was a change to the IKE protocol that was not backward compatible. In contrast, the current document not only provides a clarification of IKEv2, but makes minimum changes to the IKE - protocol. + protocol. A list of the significant differences between RFC 4306 and + this document is given in Section 1.7. IKE performs mutual authentication between two parties and establishes an IKE security association (SA) that includes shared secret information that can be used to efficiently establish SAs for Encapsulating Security Payload (ESP) [ESP] or Authentication Header (AH) [AH] and a set of cryptographic algorithms to be used by the SAs to protect the traffic that they carry. In this document, the term "suite" or "cryptographic suite" refers to a complete set of algorithms used to protect an SA. An initiator proposes one or more suites by listing supported algorithms that can be combined into @@ -252,34 +252,35 @@ there may be more than one of each of these exchanges. In all cases, all IKE_SA_INIT exchanges MUST complete before any other exchange type, then all IKE_AUTH exchanges MUST complete, and following that any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur in any order. In some scenarios, only a single Child SA is needed between the IPsec endpoints, and therefore there would be no additional exchanges. Subsequent exchanges MAY be used to establish additional Child SAs between the same authenticated pair of endpoints and to perform housekeeping functions. - IKE message flow always consists of a request followed by a response. - It is the responsibility of the requester to ensure reliability. If - the response is not received within a timeout interval, the requester - needs to retransmit the request (or abandon the connection). + An IKE message flow always consists of a request followed by a + response. It is the responsibility of the requester to ensure + reliability. If the response is not received within a timeout + interval, the requester needs to retransmit the request (or abandon + the connection). The first request/response of an IKE session (IKE_SA_INIT) negotiates security parameters for the IKE SA, sends nonces, and sends Diffie- Hellman values. The second request/response (IKE_AUTH) transmits identities, proves knowledge of the secrets corresponding to the two identities, and sets up an SA for the first (and often only) AH or ESP Child SA (unless there is failure setting up the AH or ESP Child SA, in which - case the IKE SA is still established without the IPsec SA). + case the IKE SA is still established without the Child SA). The types of subsequent exchanges are CREATE_CHILD_SA (which creates a Child SA) and INFORMATIONAL (which deletes an SA, reports error conditions, or does other housekeeping). Every request requires a response. An INFORMATIONAL request with no payloads (other than the empty Encrypted payload required by the syntax) is commonly used as a check for liveness. These subsequent exchanges cannot be used until the initial exchanges have completed. In the description that follows, we assume that no errors occur. @@ -407,61 +408,63 @@ response pairs. We'll describe the base exchange first, followed by variations. The first pair of messages (IKE_SA_INIT) negotiate cryptographic algorithms, exchange nonces, and do a Diffie-Hellman exchange [DH]. The second pair of messages (IKE_AUTH) authenticate the previous messages, exchange identities and certificates, and establish the first Child SA. Parts of these messages are encrypted and integrity protected with keys established through the IKE_SA_INIT exchange, so the identities are hidden from eavesdroppers and all fields in all - the messages are authenticated. (See Section 2.14 for information on - how the encryption keys are generated.) + the messages are authenticated. See Section 2.14 for information on + how the encryption keys are generated. (A man-in-the-middle who + cannot complete the IKE_AUTH exchange can nonetheless see the + identity of the initiator.) All messages following the initial exchange are cryptographically protected using the cryptographic algorithms and keys negotiated in the IKE_SA_INIT exchange. These subsequent messages use the syntax of the Encrypted Payload described in Section 3.14, encrypted with keys that are derived as described in Section 2.14. All subsequent messages include an Encrypted Payload, even if they are referred to in the text as "empty". For the CREATE_CHILD_SA, IKE_AUTH, or - IKE_INFORMATIONAL exchanges, the message following the header is + INFORMATIONAL exchanges, the message following the header is encrypted and the message including the header is integrity protected using the cryptographic algorithms negotiated for the IKE SA. In the following descriptions, the payloads contained in the message are indicated by names as listed below. Notation Payload ----------------------------------------- AUTH Authentication CERT Certificate CERTREQ Certificate Request CP Configuration D Delete - E Encrypted EAP Extensible Authentication - HDR IKE Header + HDR IKE Header (not a payload) IDi Identification - Initiator IDr Identification - Responder KE Key Exchange Ni, Nr Nonce N Notify SA Security Association + SK Encrypted and Authenticated TSi Traffic Selector - Initiator TSr Traffic Selector - Responder V Vendor ID The details of the contents of each payload are described in section 3. Payloads that may optionally appear will be shown in brackets, - such as [CERTREQ], indicate that optionally a certificate request - payload can be included. + such as [CERTREQ]; this indicates that a certificate request payload + can optionally be included. The initial exchanges are as follows: Initiator Responder ------------------------------------------------------------------- HDR, SAi1, KEi, Ni --> HDR contains the Security Parameter Indexes (SPIs), version numbers, and flags of various sorts. The SAi1 payload states the cryptographic algorithms the initiator supports for the IKE SA. The @@ -591,23 +594,23 @@ exchange, and the Diffie-Hellman value (if KE payloads are included in the CREATE_CHILD_SA exchange). If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of the SA offers MUST include the Diffie-Hellman group of the KEi. The Diffie-Hellman group of the KEi MUST be an element of the group the initiator expects the responder to accept (additional Diffie-Hellman groups can be proposed). If the responder selects a proposal using a different Diffie-Hellman group (other than NONE), the responder MUST reject the request and indicate its preferred Diffie-Hellman group in - the INVALID_KE_PAYLOAD Notification payload. There are two octets of - data associated with this notification: the accepted D-H Group number - in big endian order. In the case of such a rejection, the + the INVALID_KE_PAYLOAD Notify payload. There are two octets of data + associated with this notification: the accepted D-H Group number in + big endian order. In the case of such a rejection, the 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 responder gave in the INVALID_KE_PAYLOAD. The responder sends a NO_ADDITIONAL_SAS notification to indicate that a CREATE_CHILD_SA request is unacceptable because the responder is unwilling to accept any more Child SAs on this IKE SA. Some minimal implementations may only accept a single Child SA setup in the context of an initial IKE exchange and reject any subsequent attempts to add more. @@ -661,66 +664,67 @@ The NON_FIRST_FRAGMENTS_ALSO notification is used for fragmentation control. See [IPSECARCH] for a fuller explanation. Both parties need to agree to sending non-first fragments before either party does so. It is enabled only if NON_FIRST_FRAGMENTS_ALSO notification is included in both the request proposing an SA and the response accepting it. If the responder does not want to send or receive non- first fragments, it only omits NON_FIRST_FRAGMENTS_ALSO notification from its response, but does not reject the whole Child SA creation. + An IPCOMP_SUPPORTED notification, covered in Section 2.22, can also + be included in the request/response pair. + Failure of an attempt to create a Child SA 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 message return SHOULD - NOT be encrypted because the other party will not be able to - authenticate that message. See Section 2.21 for a list of error - messages that might occur if creating a Child SA fails. + SA. See Section 2.21 for a list of error messages that might occur + if creating a Child SA fails. 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange The CREATE_CHILD_SA request for rekeying an IKE SA is: Initiator Responder ------------------------------------------------------------------- HDR, SK {SA, Ni, KEi} --> The initiator sends SA offer(s) in the SA payload, a nonce in the Ni payload, and a Diffie-Hellman value in the KEi payload. The KEi - payload MUST be included. New initiator and responder SPIs are - supplied in the SPI fields of the SA payload. Once a peer receives a - request to rekey an IKE SA or sends a request to rekey an IKE SA, it - SHOULD NOT start any new CREATE_CHILD_SA exchanges on the IKE SA that - is being rekeyed. + payload MUST be included. A new initiator SPI is supplied in the SPI + field of the SA payload. Once a peer receives a request to rekey an + IKE SA or sends a request to rekey an IKE SA, it SHOULD NOT start any + new CREATE_CHILD_SA exchanges on the IKE SA that is being rekeyed. The CREATE_CHILD_SA response for rekeying an IKE SA is: <-- HDR, SK {SA, Nr, KEr} The responder replies (using the same Message ID to respond) with the accepted offer in an SA payload, and a Diffie-Hellman value in the KEr payload if the selected cryptographic suite includes that group. + 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 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 retains its numbering, so any further requests (for example, to 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 exchange is the new "original initiator" of the new IKE SA. 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA Exchange The CREATE_CHILD_SA request for rekeying a Child SA is: Initiator Responder ------------------------------------------------------------------- - HDR, SK {N, SA, Ni, [KEi], + HDR, SK {N(REKEY_SA), SA, Ni, [KEi], TSi, TSr} --> 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 the proposed traffic selectors for the proposed Child SA in the TSi and TSr payloads. 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 or AH SA. The SA being rekeyed is identified by the SPI field in the @@ -744,36 +748,37 @@ in the TS payloads in the response, which may be a subset of what the initiator of the Child SA proposed. 1.4. The INFORMATIONAL Exchange At various points during the operation of an IKE SA, peers may desire to convey control messages to each other regarding errors or notifications of certain events. To accomplish this, IKE defines an INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur after the initial exchanges and are cryptographically protected with - the negotiated keys. Section 2.21 also covers error messages in - great detail. + the negotiated keys. Note that some informational messages, not + exchanges, can be sent outside the context of an IKE SA. Section + 2.21 also covers error messages in great detail. Control messages that pertain to an IKE SA MUST be sent under that IKE SA. Control messages that pertain to Child SAs MUST be sent under the protection of the IKE SA which generated them (or its successor if the IKE SA was rekeyed). Messages in an INFORMATIONAL exchange contain zero or more - Notification, Delete, and Configuration payloads. The Recipient of - an INFORMATIONAL exchange request MUST send some response (else the - Sender will assume the message was lost in the network and will - retransmit it). That response MAY be a message with no payloads. - The request message in an INFORMATIONAL exchange MAY also contain no - payloads. This is the expected way an endpoint can ask the other - endpoint to verify that it is alive. + Notification, Delete, and Configuration payloads. The recipient of + an INFORMATIONAL exchange request MUST send some response; otherwise, + the sender will assume the message was lost in the network and will + retransmit it. That response MAY be an empty message. The request + message in an INFORMATIONAL exchange MAY also contain no payloads. + This is the expected way an endpoint can ask the other endpoint to + verify that it is alive. The INFORMATIONAL exchange is defined as: Initiator Responder ------------------------------------------------------------------- HDR, SK {[N,] [D,] [CP,] ...} --> <-- HDR, SK {[N,] [D,] [CP], ...} @@ -785,74 +790,72 @@ ESP and AH SAs always exist in pairs, with one SA in each direction. When an SA is closed, both members of the pair MUST be closed (that is, deleted). Each endpoint MUST close its incoming SAs and allow the other endpoint to close the other SA in each pair. To delete an SA, an INFORMATIONAL exchange with one or more delete payloads is sent listing the SPIs (as they would be expected in the headers of inbound packets) of the SAs to be deleted. The recipient MUST close the designated SAs. Note that one never sends delete payloads for the two sides of an SA in a single message. If there are many SAs to delete at the same time, one includes delete payloads for the inbound - half of each SA pair in your Informational exchange. + half of each SA pair in the INFORMATIONAL exchange. - Normally, the reply in the INFORMATIONAL exchange will contain delete - payloads for the paired SAs going in the other direction. 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 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 request, it - MUST delete the outgoing SAs while processing the request and the - incoming SAs while processing the response. In that case, the - responses MUST NOT include delete payloads for the deleted SAs, since - that would result in duplicate deletion and could in theory delete - the wrong SA. + Normally, the response in the INFORMATIONAL exchange will contain + delete payloads for the paired SAs going in the other direction. + 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 + 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 + request, it MUST delete the outgoing SAs while processing the request + and the incoming SAs while processing the response. In that case, + the responses MUST NOT include delete payloads for the deleted SAs, + since that would result in duplicate deletion and could in theory + delete the wrong SA. Half-closed ESP or AH connections are anomalous, and a node with auditing capability should probably audit their existence if they persist. Note that this specification nowhere specifies time 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 connections but MUST NOT unilaterally close them and reuse the SPIs. If connection state becomes sufficiently messed up, a node MAY close the IKE SA; doing so will implicitly close all SAs negotiated under it. It can then rebuild the SAs it needs on a clean base under a new IKE SA. The response to a request that deletes the IKE SA is an - empty Informational response. + empty INFORMATIONAL response. 1.5. Informational Messages outside of an IKE SA If an encrypted IKE request packet arrives on port 500 or 4500 with an unrecognized SPI, it could be because the receiving node has recently crashed and lost state or because of some other system - malfunction or attack. If the receiving node has an active IKE SA to - the IP address from whence the packet came, it MAY send a - notification of the wayward packet over that IKE SA in an - INFORMATIONAL exchange. If it does not have such an IKE SA, it MAY - send an Informational message 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. + 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 exchange when a node receives an ESP or AH packet with an invalid SPI. The Notification Data contains the SPI of the invalid packet. This usually indicates a node has rebooted and forgotten an SA. If - this Informational Message 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. + 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 and INVALID_SPI. These messages are sent outside of an IKE SA. Note - that such messages are explicitly not Informational exchanges; these + that such messages are explicitly not INFORMATIONAL exchanges; these are one-way messages that must not be responded to. (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, and thus it is sent to the IP address and port from whence it came 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, @@ -864,81 +867,141 @@ is set, the Response bit is set to 0, and the version flags are set in the normal fashion. 1.6. Requirements Terminology Definitions of the primitive terms in this document (such as Security Association or SA) can be found in [IPSECARCH]. It should be noted that parts of IKEv2 rely on some of the processing rules in [IPSECARCH], as described in various sections of this document. - Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and - "MAY" that appear in this document are to be interpreted as described - in [MUSTSHOULD]. + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [MUSTSHOULD]. -1.7. Differences Between RFC 4306 and This Document +1.7. Significant Differences Between RFC 4306 and This Document This document contains clarifications and amplifications to IKEv2 [IKEV2]. The clarifications are mostly based on [Clarif]. The changes listed in that document were discussed in the IPsec Working Group and, after the Working Group was disbanded, on the IPsec mailing list. That document contains detailed explanations of areas that were unclear in IKEv2, and is thus useful to implementers of IKEv2. The protocol described in this document retains the same major version number (2) and minor version number (0) as was used in RFC 4306. That is, the version number is *not* changed from RFC 4306. This document makes the figures and references a bit more regular than in [IKEV2]. - IKEv2 developers have noted that the SHOULD-level requirements are - often unclear in that they don't say when it is OK to not obey the - requirements. They also have noted that there are MUST-level - requirements that are not related to interoperability. This document - has more explanation of some of these requirements. All non- - capitalized uses of the words SHOULD and MUST now mean their normal - English sense, not the interoperability sense of [MUSTSHOULD]. + IKEv2 developers have noted that the SHOULD-level requirements in RFC + 4306 are often unclear in that they don't say when it is OK to not + obey the requirements. They also have noted that there are MUST- + level requirements that are not related to interoperability. This + document has more explanation of some of these requirements. All + non-capitalized uses of the words SHOULD and MUST now mean their + normal English sense, not the interoperability sense of [MUSTSHOULD]. IKEv2 (and IKEv1) developers have noted that there is a great deal of - material in the tables of codes in Section 3.10.1. This leads to - implementers not having all the needed information in the main body - of the document. Much of the material from those tables has been - moved into the associated parts of the main body of the document. + material in the tables of codes in Section 3.10.1 in RFC 4306. This + leads to implementers not having all the needed information in the + main body of the document. Much of the material from those tables + has been moved into the associated parts of the main body of the + document. This document removes discussion of nesting AH and ESP. This was a mistake in RFC 4306 caused by the lag between finishing RFC 4306 and RFC 4301. Basically, IKEv2 is based on RFC 4301, which does not include "SA bundles" that were part of RFC 2401. While a single packet can go through IPsec processing multiple times, each of these passes uses a separate SA, and the passes are coordinated by the forwarding tables. In IKEv2, each of these SAs has to be created using a separate CREATE_CHILD_SA exchange. This document removes discussion of the INTERNAL_ADDRESS_EXPIRY configuration attribute because its implementation was very problematic. Implementations that conform to this document MUST ignore proposals that have configuration attribute type 5, the old - value for INTERNAL_ADDRESS_EXPIRY. + value for INTERNAL_ADDRESS_EXPIRY. This document also removed + INTERNAL_IP6_NBNS as a configuration attribute. - This document adds the restriction in Section 2.13 that all PRFs used - with IKEv2 MUST take variable-sized keys. This should not affect any - implementations because there were no standardized PRFs that have - fixed-size keys. + This document removes the allowance for rejecting messages where the + payloads were not in the "right" order; now implementations MUST NOT + reject them. This is due to the lack of clarity where the orders for + the payloads are described. + + The lists of items from RFC 4306 that ended up in the IANA registry + were trimmed to only include items that were actually defined in RFC + 4306. Also, many of those lists are now preceded with the very + important instruction to developers that they really should look at + the IANA registry at the time of development because new items have + been added since RFC 4306. + + This document adds clarification on when notifications are and are + not sent encrypted, depending on the state of the negotiation at the + time. + + This document discusses more about how to negotiate combined-mode + ciphers such as GCM and GMAC. + + 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 + section 2.18. + + In Section 2.3, there is new material covering how the initiator's + SPI and/or IP is used to differentiate if this is a "half-open" IKE + SA or a new request. + + 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 + different traffic selectors and algorithms than the old one" to "Note + that, when rekeying, the new Child SA SHOULD NOT have different + traffic selectors and algorithms than the old one". + + The new Section 2.8.2 covers simultaneous IKE SA rekeying. + + The new Section 2.9.2 covers traffic selectors in rekeying. + + This document adds the restriction in Section 2.13 that all pseudo- + random functions (PRFs) used with IKEv2 MUST take variable-sized + keys. This should not affect any implementations because there were + no standardized PRFs that have fixed-size keys. + + Section 2.18 requires doing a Diffie-Hellman exchange when rekeying + the IKE_SA. In theory, RFC 4306 allowed a policy where the Diffie- + Hellman exchange was optional, but this was not useful (or + appropriate) when rekeying the IKE_SA. Section 2.21 has been greatly expanded to cover the different cases where error responses are needed and the appropriate responses to them. + Added Section 2.23.1 to describe NAT traversal when transport mode is + requested. + All of Section 2.25 was added to explain how to act when there are - timing collisions when deleting and/or rekeying SAs. + timing collisions when deleting and/or rekeying SAs, and two new + error notifications (TEMPORARY_FAILURE and CHILD_SA_NOT_FOUND) were + defined. + + In Section 3.6, added "Implementations MUST support the HTTP method + for hash-and-URL lookup. The behavior of other URL methods is not + currently specified, and such methods SHOULD NOT be used in the + absence of a document specifying them." + + In Section 3.15.3, added a pointer to a new document that is related + to configuration of IPv6 addresses. + + Appendix C was expanded and clarified. 2. IKE Protocol Details and Variations IKE normally listens and sends on UDP port 500, though IKE messages may also be received on UDP port 4500 with a slightly different format (see Section 2.23). Since UDP is a datagram (unreliable) protocol, IKE includes in its definition recovery from transmission errors, including packet loss, packet replay, and packet forgery. IKE is designed to function so long as (1) at least one of a series of retransmitted packets reaches its destination before timing out; @@ -946,35 +1009,35 @@ as to exhaust the network or CPU capacities of either endpoint. Even in the absence of those minimum performance requirements, IKE is designed to fail cleanly (as though the network were broken). Although IKEv2 messages are intended to be short, they contain structures with no hard upper bound on size (in particular, X.509 certificates), and IKEv2 itself does not have a mechanism for fragmenting large messages. IP defines a mechanism for fragmentation of oversize UDP messages, but implementations vary in the maximum message size supported. Furthermore, use of IP fragmentation opens - an implementation to denial of service attacks [DOSUDPPROT]. + an implementation to denial of service (DoS) attacks [DOSUDPPROT]. Finally, some NAT and/or firewall implementations may block IP fragments. All IKEv2 implementations MUST be able to send, receive, and process IKE messages that are up to 1280 octets long, and they SHOULD be able to send, receive, and process messages that are up to 3000 octets long. IKEv2 implementations need to be aware of the maximum UDP message size supported and MAY shorten messages by leaving out some certificates or cryptographic suite proposals if that will keep messages below the maximum. Use of the "Hash and URL" formats rather than including certificates in exchanges where possible can avoid most problems. Implementations and configuration need to keep in mind, however, that if the URL lookups are possible only after the - IPsec SA is established, recursion issues could prevent this + Child SA is established, recursion issues could prevent this technique from working. The UDP payload of all packets containing IKE messages sent on port 4500 MUST begin with the prefix of four zeros; otherwise, the receiver won't know how to handle them. 2.1. Use of Retransmission Timers All messages in IKE exist in pairs: a request and a response. The setup of an IKE SA normally consists of two request/response pairs. @@ -988,35 +1051,34 @@ For every pair of IKE messages, the initiator is responsible for retransmission in the event of a timeout. The responder MUST never retransmit a response unless it receives a retransmission of the request. In that event, the responder MUST ignore the retransmitted request except insofar as it triggers a retransmission of the response. The initiator MUST remember each request until it receives the corresponding response. The responder MUST remember each response until it receives a request whose sequence number is larger than or equal to the sequence number in the response plus its window size (see Section 2.3). In order to allow saving memory, responders - are allowed to forget response after a timeout of several minutes. - If the responder receives a retransmitted request for which it has - already forgotten the response, it MUST ignore the request (and not, - for example, attempt constructing a new response). + are allowed to forget the response after a timeout of several + minutes. If the responder receives a retransmitted request for which + it has already forgotten the response, it MUST ignore the request + (and not, for example, attempt constructing a new response). - IKE is a reliable protocol, in the sense that the initiator MUST - retransmit a request until either it receives a corresponding reply - OR it deems the IKE security association to have failed and it - discards all state associated with the IKE SA and any Child SAs - negotiated using that IKE SA. A retransmission from the initiator - MUST be bitwise identical to the original request. That is, - everything starting from the IKE Header (the IKE SA Initiator's SPI - onwards) must be bitwise identical; items before it (such as the IP - and UDP headers, and the zero non-ESP marker) do not have to be - identical. + IKE is a reliable protocol: the initiator MUST retransmit a request + until either it receives a corresponding response, or until it deems + 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 + were negotiated using that IKE SA. A retransmission from the + initiator MUST be bitwise identical to the original request. That + is, everything starting from the IKE Header (the IKE SA initiator's + SPI onwards) must be bitwise identical; items before it (such as the + IP and UDP headers) do not have to be identical. Retransmissions of the IKE_SA_INIT request require some special handling. When a responder receives an IKE_SA_INIT request, it has to determine whether the packet is a retransmission belonging to an existing "half-open" IKE SA (in which case the responder retransmits the same response), or a new request (in which case the responder 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 (in which case the responder ignores it). @@ -1028,47 +1090,46 @@ 2.2. Use of Sequence Numbers for Message ID 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 identify retransmissions of messages. The Message ID is a 32-bit quantity, which is zero for the IKE_SA_INIT messages (including retries of the message due to responses such as COOKIE and INVALID_KE_PAYLOAD), and incremented for - each subsequent exchange. The Message ID is reset to zero in the new - IKE SA after the IKE SA is rekeyed. Rekeying an IKE SA resets the - sequence numbers. Thus, the first pair of IKE_AUTH messages will - have ID of 1, the second (when EAP is used) will be 2, and so on. + each subsequent exchange. Thus, the first pair of IKE_AUTH messages + will have ID of 1, the second (when EAP is used) will be 2, and so + on. The Message ID is reset to zero in the new IKE SA after the IKE + SA is rekeyed. Each endpoint in the IKE Security Association maintains two "current" Message IDs: the next one to be used for a request it initiates and the next one it expects to see in a request from the other end. These counters increment as requests are generated and received. Responses always contain the same message ID as the corresponding request. That means that after the initial exchange, each integer n may appear as the message ID in four distinct messages: the nth request from the original IKE initiator, the corresponding response, the nth request from the original IKE responder, and the corresponding response. If the two ends make very different numbers of requests, the Message IDs in the two directions can be very different. There is no ambiguity in the messages, however, because the (I)nitiator and (R)esponse bits in the message header specify which of the four messages a particular one is. Throughout this document, "initiator" refers to the party who - initiated the exchange being described, and "original initiator" - refers to the party who initiated the whole IKE SA. The "original - initiator" always refers to the party who initiated the exchange - which resulted in the current IKE SA. In other words, if the - "original responder" starts rekeying the IKE SA, that party becomes - the "original initiator" of the new IKE SA. + initiated the exchange being described. The "original initiator" + always refers to the party who initiated the exchange which resulted + in the current IKE SA. In other words, if the "original responder" + starts rekeying the IKE SA, that party becomes the "original + initiator" of the new IKE SA. Note that Message IDs are cryptographically protected and provide protection against message replays. In the unlikely event that Message IDs grow too large to fit in 32 bits, the IKE SA MUST be closed or rekeyed. 2.3. Window Size for Overlapping Requests The SET_WINDOW_SIZE notification asserts that the sending endpoint is capable of keeping state for multiple outstanding exchanges, @@ -1135,29 +1196,30 @@ and restart. It is important when an endpoint either fails or reinitializes its state that the other endpoint detect those conditions and not continue to waste network bandwidth by sending packets over discarded SAs and having them fall into a black hole. The INITIAL_CONTACT notification asserts that this IKE SA is the only IKE SA currently active between the authenticated identities. It MAY be sent when an IKE SA is established after a crash, and the recipient MAY use this information to delete any other IKE SAs it has to the same authenticated identity without waiting for a timeout. + This notification MUST NOT be sent by an entity that may be replicated (e.g., a roaming user's credentials where the user is allowed to connect to the corporate firewall from two remote systems at the same time). The INITIAL_CONTACT notification, if sent, MUST be in the first IKE_AUTH request or response, not as a separate - exchange afterwards; however, receiving parties MAY ignore it in - other messages. + exchange afterwards; receiving parties MAY ignore it in other + messages. - Since IKE is designed to operate in spite of Denial of Service (DoS) + Since IKE is designed to operate in spite of denial of service attacks from the network, an endpoint MUST NOT conclude that the other endpoint has failed based on any routing information (e.g., ICMP messages) or IKE messages that arrive without cryptographic protection (e.g., Notify messages complaining about unknown SPIs). An endpoint MUST conclude that the other endpoint has failed only when repeated attempts to contact it have gone unanswered for a timeout period or when a cryptographically protected INITIAL_CONTACT notification is received on a different IKE SA to the same authenticated identity. An endpoint should suspect that the other endpoint has failed based on routing information and initiate a @@ -1170,40 +1232,40 @@ retransmitted) message has been received from the other side recently, unprotected notifications MAY be ignored. Implementations MUST limit the rate at which they take actions based on unprotected messages. Numbers of retries and lengths of timeouts are not covered in this specification because they do not affect interoperability. It is suggested that messages be retransmitted at least a dozen times over a period of at least several minutes before giving up on an SA, but different environments may require different rules. To be a good - network citizen, retranmission times MUST increase exponentially to + network citizen, retransmission times MUST increase exponentially to avoid flooding the network and making an existing congestion situation worse. If there has only been outgoing traffic on all of the SAs associated with an IKE SA, it is essential to confirm liveness of the other endpoint to avoid black holes. If no cryptographically protected messages have been received on an IKE SA or any of its Child SAs recently, the system needs to perform a liveness check in order to prevent sending messages to a dead peer. (This is sometimes called "dead peer detection" or "DPD", although it is really detecting live peers, not dead ones.) Receipt of a fresh cryptographically protected message on an IKE SA or any of its Child SAs ensures liveness of the IKE SA and all of its Child SAs. Note that this places requirements on the failure modes of an IKE endpoint. An implementation MUST NOT continue sending on any SA if some failure prevents it from receiving on all of the associated SAs. If Child SAs can fail independently from one another without the associated IKE SA being able to send a delete message, then they MUST be negotiated by separate IKE SAs. - There is a Denial of Service attack on the initiator of an IKE SA + There is a denial of service attack on the initiator of an IKE SA that can be avoided if the initiator takes the proper care. Since the first two messages of an SA setup are not cryptographically protected, an attacker could respond to the initiator's message before the genuine responder and poison the connection setup attempt. To prevent this, the initiator MAY be willing to accept multiple responses to its first message, treat each as potentially legitimate, respond to it, and then discard all the invalid half-open connections when it receives a valid cryptographically protected response to any one of its requests. Once a cryptographically valid response is received, all subsequent responses should be ignored whether or not @@ -1294,21 +1356,21 @@ payload MUST be ignored. Payloads sent in IKE response messages MUST NOT have the critical flag set. Note that the critical flag applies only to the payload type, not the contents. If the payload type is recognized, but the payload contains something which is not (such as an unknown transform inside an SA payload, or an unknown Notify Message Type inside a Notify payload), the critical flag is ignored. Although new payload types may be added in the future and may appear interleaved with the fields defined in this specification, implementations SHOULD send the payloads defined in this - specification in the order shown in the figures in Section 2; + specification in the order shown in the figures in Sections 1 and 2; implementations MUST NOT reject as invalid a message with those payloads in any other order. 2.6. IKE SA SPIs and Cookies 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 titled "cookies", and that syntax is used by both IKEv1 @@ -1369,76 +1431,70 @@ The first two messages do not affect any initiator or responder state except for communicating the cookie. In particular, the message sequence numbers in the first four messages will all be zero and the message sequence numbers in the last two messages will be one. 'A' is the SPI assigned by the initiator, while 'B' is the SPI assigned by the responder. An IKE implementation can implement its responder cookie generation in such a way as to not require any saved state to recognize its valid cookie when the second IKE_SA_INIT message arrives. The exact - algorithms and syntax they use to generate cookies do not affect + algorithms and syntax used to generate cookies do not affect interoperability and hence are not specified here. The following is an example of how an endpoint could use cookies to implement limited DOS protection. A good way to do this is to set the responder cookie to be: Cookie = | Hash(Ni | IPi | SPIi | ) where is a randomly generated secret known only to the responder and periodically changed and | indicates concatenation. should be changed whenever is regenerated. The cookie can be recomputed when the IKE_SA_INIT arrives the second time and compared to the cookie in the received message. If it matches, the responder knows that the cookie was generated since the last change to and that IPi must be the same as the source address it saw the first time. Incorporating SPIi into the calculation ensures that if multiple IKE SAs are being set up in parallel they will all get different cookies (assuming the initiator chooses unique SPIi's). Incorporating Ni in the hash ensures that an attacker who sees only message 2 can't successfully - forge a message 3. Also, incorporating Ni in the hash prevents an + forge a message 3. Also, incorporating SPi in the hash prevents an attacker from fetching one cookie from the other end, and then initiating many IKE_SA_INIT exchanges all with different initiator 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 connect. If a new value for is chosen while there are connections in the process of being initialized, an IKE_SA_INIT might be returned with other than the current . The responder in that case MAY reject the message by sending another response with a new cookie or it MAY keep the old value of around for a short time and accept cookies computed from either one. The responder should not accept cookies indefinitely after is changed, since that would defeat part of the denial of service protection. The responder should change the value of frequently, especially if under attack. - In addition to cookies, there are several cases where the IKE_SA_INIT - exchange does not result in the creation of an IKE SA (such as - INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). In such a case, sending a - zero value for the Responder's SPI is correct. If the responder - sends a non-zero responder SPI, the initiator should not reject the - response for only that reason. - When one party receives an IKE_SA_INIT request containing a cookie whose contents do not match the value expected, that party MUST ignore the cookie and process the message as if no cookie had been included; usually this means sending a response containing a new cookie. The initiator should limit the number of cookie exchanges it tries before giving up. An attacker can forge multiple cookie responses to the initiator's IKE_SA_INIT message, and each of those forged cookie replies will trigger two packets: one packet from the initiator to the responder (which will reject those cookies), and one - reply from responder to initiator that includes the correct cookie. + response from responder to initiator that includes the correct + cookie. 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD 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 different Diffie-Hellman group than was included in the KEi payload. 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 retry of the IKE_SA_INIT request, or in all subsequent retries as well. @@ -1540,62 +1596,60 @@ MAY refuse all CREATE_CHILD_SA requests within an IKE SA. If an SA has expired or is about to expire and rekeying attempts using the mechanisms described here fail, an implementation MUST close the IKE SA and any associated Child SAs and then MAY start new ones. Implementations may wish to support in-place rekeying of SAs, since doing so offers better performance and is likely to reduce the number of packets lost during the transition. To rekey a Child SA within an existing IKE SA, create a new, equivalent SA (see Section 2.17 below), and when the new one is - established, delete the old one. + established, delete the old one. Note that, when rekeying, the new + Child SA SHOULD NOT have different traffic selectors and algorithms + than the old one. To rekey an IKE SA, establish a new equivalent IKE SA (see Section 2.18 below) with the peer to whom the old IKE SA is shared using a CREATE_CHILD_SA within the existing IKE SA. An IKE SA so created inherits all of the original IKE SA's Child SAs, and the new IKE SA is used for all control messages needed to maintain those Child SAs. After the new equivalent IKE SA is created, the initiator deletes the old IKE SA, and the Delete payload to delete itself MUST - be the last request sent over the old IKE SA. Note that, when - rekeying, the new Child SA SHOULD NOT have different traffic - selectors and algorithms than the old one. + be the last request sent over the old IKE SA. SAs should be rekeyed proactively, i.e., the new SA should be established before the old one expires and becomes unusable. Enough time should elapse between the time the new SA is established and the old one becomes unusable so that traffic can be switched over to the new SA. A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes were negotiated. In IKEv2, each end of the SA is responsible for enforcing its own lifetime policy on the SA and rekeying the SA when necessary. If the two ends have different lifetime policies, the end with the shorter lifetime will end up always being the one to request the rekeying. If an SA has been inactive for a long time and if an endpoint would not initiate the SA in the absence of traffic, the endpoint MAY choose to close the SA instead of rekeying it when its - lifetime expires. It should do so if there has been no traffic since - the last time the SA was rekeyed. + lifetime expires. It can also do so if there has been no traffic + since the last time the SA was rekeyed. Note that IKEv2 deliberately allows parallel SAs with the same traffic selectors between common endpoints. One of the purposes of this is to support traffic quality of service (QoS) differences among the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and section 4.1 of + [DIFFTUNNEL]). Hence unlike IKEv1, the combination of the endpoints and the traffic selectors may not uniquely identify an SA between those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on the basis of duplicate traffic selectors SHOULD NOT be used. - The node that initiated the surviving rekeyed SA should delete the - replaced SA after the new one is established. - There are timing windows -- particularly in the presence of lost packets -- where endpoints may not agree on the state of an SA. The responder to a CREATE_CHILD_SA MUST be prepared to accept messages on an SA before sending its response to the creation request, so there is no ambiguity for the initiator. The initiator MAY begin sending on an SA as soon as it processes the response. The initiator, however, cannot receive on a newly created SA until it receives and processes the response to its CREATE_CHILD_SA request. How, then, is the responder to know when it is OK to send on the newly created SA? @@ -1631,24 +1685,25 @@ This form of rekeying may temporarily result in multiple similar SAs between the same pairs of nodes. When there are two SAs eligible to receive packets, a node MUST accept incoming packets through either SA. If redundant SAs are created though such a collision, the SA created with the lowest of the four nonces used in the two exchanges SHOULD be closed by the endpoint that created it. "Lowest" means an octet-by-octet, lexicographical comparison (instead of, for instance, comparing the nonces as large integers). In other words, start by comparing the first octet; if they're equal, move to the next octet, and so on. If you reach the end of one nonce, that nonce is the - lower one. + lower one. The node that initiated the surviving rekeyed SA should + delete the replaced SA after the new one is established. The following is an explanation on the impact this has on - implementations. Assume that hosts A and B have an existing IPsec SA + implementations. Assume that hosts A and B have an existing Child SA pair with SPIs (SPIa1,SPIb1), and both start rekeying it at the same time: Host A Host B ------------------------------------------------------------------- send req1: N(REKEY_SA,SPIa1), SA(..,SPIa2,..),Ni1,.. --> <-- send req2: N(REKEY_SA,SPIb1), SA(..,SPIb2,..),Ni2 recv req2 <-- @@ -1708,53 +1764,52 @@ From B's point of view, the rekeying is now completed, and since it has not yet received A's req1, it does not even know that there was simultaneous rekeying. However, A will continue retransmitting the message, and eventually it will reach B. resend req1 --> --> recv req1 To B, it looks like A is trying to rekey an SA that no longer exists; thus, B responds to the request with something non-fatal such as - NO_PROPOSAL_CHOSEN. + CHILD_SA_NOT_FOUND. - <-- send resp1: N(NO_PROPOSAL_CHOSEN) + <-- send resp1: N(CHILD_SA_NOT_FOUND) recv resp1 <-- When A receives this error, it already knows there was simultaneous rekeying, so it can ignore the error message. 2.8.2. Simultaneous IKE SA Rekeying 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 applies to this case as well; however, it is important to ensure that the CHILD_SAs are inherited by the right IKE_SA. The case where both endpoints notice the simultaneous rekeying works 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 SAs. The new IKE SA containing the lowest nonce inherits the Child - SAs. If only one peer detects a simultaneous rekey, redundant SAs - are not created. In this case, when the peer that did not notice the + SAs. + + If only one peer detects a simultaneous rekey, redundant SAs are not + created. In this case, when the peer that did not notice the simultaneous rekey gets the request to rekey the IKE SA that it has - already successfully rekeyed, it MUST return TEMPORARY_FAILURE + already successfully rekeyed, it SHOULD return TEMPORARY_FAILURE because it is an IKE SA that it is currently trying to close (whether or not it has already sent the delete notification for the SA). If the peer that did notice the simultaneous rekey gets 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. - However, there is a twist to the other case where one rekeying - finishes first: - Host A Host B ------------------------------------------------------------------- send req1: SA(..,SPIa1,..),Ni1,.. --> <-- send req2: SA(..,SPIb1,..),Ni2,.. --> recv req1 <-- send resp1: SA(..,SPIb2,..),Nr2,.. recv resp1 <-- send req3: D() --> --> recv req3 @@ -1822,108 +1877,104 @@ range (IPv4 or IPv6), a port range, and an IP protocol ID. The first of the two TS payloads is known as TSi (Traffic Selector- initiator). The second is known as TSr (Traffic Selector-responder). TSi specifies the source address of traffic forwarded from (or the destination address of traffic forwarded to) the initiator of the Child SA pair. TSr specifies the destination address of the traffic forwarded to (or the source address of the traffic forwarded from) the responder of the Child SA pair. For example, if the original initiator requests the creation of a Child SA pair, and wishes to - tunnel all traffic from subnet 192.0.1.* on the initiator's side to - subnet 192.0.2.* on the responder's side, the initiator would include - a single traffic selector in each TS payload. TSi would specify the - address range (192.0.1.0 - 192.0.1.255) and TSr would specify the - address range (192.0.2.0 - 192.0.2.255). Assuming that proposal was - acceptable to the responder, it would send identical TS payloads - back. (Note: The IP address range 192.0.2.* has been reserved for - use in examples in RFCs and similar documents. This document needed - two such ranges, and so also used 192.0.1.*. This should not be - confused with any actual address.) + tunnel all traffic from subnet 198.51.100.* on the initiator's side + to subnet 192.0.2.* on the responder's side, the initiator would + include a single traffic selector in each TS payload. TSi would + specify the address range (198.51.100.0 - 198.51.100.255) and TSr + would specify the address range (192.0.2.0 - 192.0.2.255). Assuming + that proposal was acceptable to the responder, it would send + identical TS payloads back. IKEv2 allows the responder to choose a subset of the traffic proposed by the initiator. This could happen when the configurations of the two endpoints are being updated but only one end has received the new information. Since the two endpoints may be configured by different people, the incompatibility may persist for an extended period even in the absence of errors. It also allows for intentionally different configurations, as when one end is configured to tunnel all addresses 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 initiator, it narrows the traffic selectors to some subset of the initiator's proposal (provided the set does not become the null set). If the type of traffic selector proposed is unknown, the responder ignores that traffic selector, so that the unknown type is not be returned in the narrowed set. - 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. In the example, the initiator - would include in TSi two traffic selectors: the first containing the - address range (192.0.1.43 - 192.0.1.43) and the source port and IP - protocol from the packet and the second containing (192.0.1.0 - - 192.0.1.255) with all ports and IP protocols. The initiator would - similarly include two traffic selectors in TSr. If the initiator - creates the Child SA pair not in response to an arriving packet, but - rather, say, upon startup, then there may be no specific addresses - the initiator prefers for the initial tunnel over any other. In that - case, the first values in TSi and TSr can be ranges rather than - specific values. + 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. In the example, the + initiator would include in TSi two traffic selectors: the first + containing the address range (198.51.100.43 - 198.51.100.43) and the + source port and IP protocol from the packet and the second containing + (198.51.100.0 - 198.51.100.255) with all ports and IP protocols. The + initiator would similarly include two traffic selectors in TSr. If + the initiator creates the Child SA pair not in response to an + arriving packet, but rather, say, upon startup, then there may be no + specific addresses the initiator prefers for the initial tunnel over + any other. In that case, the first values in TSi and TSr can be + ranges rather than specific values. The responder performs the narrowing as follows: o If the responder's policy does not allow it to accept any part of the proposed traffic selectors, it responds with TS_UNACCEPTABLE. 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 return the same TSi and TSr values. o If the responder's policy allows it to accept the first selector of TSi and TSr, then the responder MUST narrow the traffic selectors to a subset that includes the initiator's first choices. In this example above, the responder might respond with TSi being - (192.0.1.43 - 192.0.1.43) with all ports and IP protocols. + (198.51.100.43 - 198.51.100.43) with all ports and IP protocols. o If the responder's policy does not allow it to accept the first selector of TSi and TSr, the responder narrows to an acceptable subset of TSi and TSr. When narrowing is done, there may be several subsets that are acceptable but their union is not. In this case, the responder arbitrarily chooses one of them, and MAY include an ADDITIONAL_TS_POSSIBLE notification in the response. The ADDITIONAL_TS_POSSIBLE notification asserts that the responder narrowed the proposed traffic selectors but that other traffic selectors would also have been acceptable, though only in a separate SA. There is no data associated with this Notify type. This case will occur only when the initiator and responder are configured differently from one another. If the initiator and responder agree on the granularity of tunnels, the initiator will never request a - tunnel wider than the responder will accept. Such misconfigurations - should be recorded in error logs. + tunnel wider than the responder will accept. It is possible for the responder's policy to contain multiple smaller ranges, all encompassed by the initiator's traffic selector, and with the responder's policy being that each of those ranges should be sent over a different SA. Continuing the example above, the responder might have a policy of being willing to tunnel those addresses to and from the initiator, but might require that each address pair be on a - separately negotiated Child SA. If the initiator generated its - request in response to an incoming packet from 192.0.1.43 to - 192.0.2.123, there would be no way for the responder to determine - which pair of addresses should be included in this tunnel, and it - would have to make a guess or reject the request with a status of - SINGLE_PAIR_REQUIRED. + separately negotiated Child SA. If the initiator didn't generate its + request based on the packet, but (for example) upon startup, there + would not be the very specific first traffic selectors helping the + responder to select the correct range. There would be no way for the + responder to determine which pair of addresses should be included in + this tunnel, and it would have to make a guess or reject the request + with a status of SINGLE_PAIR_REQUIRED. The SINGLE_PAIR_REQUIRED error indicates that a CREATE_CHILD_SA request is unacceptable because its sender is only willing to accept traffic selectors specifying a single pair of addresses. The requestor is expected to respond by requesting an SA for only the specific traffic it is trying to forward. Few implementations will have policies that require separate SAs for each address pair. Because of this, if only some parts of the TSi and TSr proposed by the initiator are acceptable to the responder, @@ -1932,59 +1983,58 @@ 2.9.1. Traffic Selectors Violating Own Policy When creating a new SA, the initiator needs to avoid proposing traffic selectors that violate its own policy. If this rule is not followed, valid traffic may be dropped. If you use decorrelated policies from [IPSECARCH], this kind of policy violations cannot happen. This is best illustrated by an example. Suppose that host A has a - policy whose effect is that traffic to 192.0.1.66 is sent via host B - encrypted using AES, and traffic to all other hosts in 192.0.1.0/24 - is also sent via B, but must use 3DES. Suppose also that host B - accepts any combination of AES and 3DES. + policy whose effect is that traffic to 198.51.100.66 is sent via host + B encrypted using AES, and traffic to all other hosts in + 198.51.100.0/24 is also sent via B, but must use 3DES. Suppose also + that host B accepts any combination of AES and 3DES. If host A now proposes an SA that uses 3DES, and includes TSr - containing (192.0.1.0-192.0.1.255), this will be accepted by host B. - Now, host B can also use this SA to send traffic from 192.0.1.66, but - those packets will be dropped by A since it requires the use of AES - for those traffic. Even if host A creates a new SA only for - 192.0.1.66 that uses AES, host B may freely continue to use the first - SA for the traffic. In this situation, when proposing the SA, host A - should have followed its own policy, and included a TSr containing - ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead. + containing (198.51.100.0-198.51.100.255), this will be accepted by + host B. Now, host B can also use this SA to send traffic from + 198.51.100.66, but those packets will be dropped by A since it + requires the use of AES for this traffic. Even if host A creates a + new SA only for 198.51.100.66 that uses AES, host B may freely + continue to use the first SA for the traffic. In this situation, + when proposing the SA, host A should have followed its own policy, + and included a TSr containing ((198.51.100.0- + 198.51.100.65),(198.51.100.67-198.51.100.255)) instead. In general, if (1) the initiator makes a proposal "for traffic X (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator does not actually accept traffic X' with SA, and (3) the initiator would be willing to accept traffic X' with some SA' (!=SA), valid traffic can be unnecessarily dropped since the responder can apply either SA or SA' to traffic X'. 2.10. Nonces The IKE_SA_INIT messages each contain a nonce. These nonces are used as inputs to cryptographic functions. The CREATE_CHILD_SA request and the CREATE_CHILD_SA response also contain nonces. These nonces are used to add freshness to the key derivation technique used to obtain keys for Child SA, and to ensure creation of strong pseudo- random bits from the Diffie-Hellman key. Nonces used in IKEv2 MUST be randomly chosen, MUST be at least 128 bits in size, and MUST be at - least half the key size of the negotiated prf. ("prf" refers to - "pseudo-random function", one of the cryptographic algorithms - negotiated in the IKE exchange.) However, the initiator chooses the - nonce before the outcome of the negotiation is known. Because of - that, the nonce has to be long enough for all the PRFs being - proposed. If the same random number source is used for both keys and - nonces, care must be taken to ensure that the latter use does not - compromise the former. + least half the key size of the negotiated pseudo-random function + (PRF). However, the initiator chooses the nonce before the outcome + of the negotiation is known. Because of that, the nonce has to be + long enough for all the PRFs being proposed. If the same random + number source is used for both keys and nonces, care must be taken to + ensure that the latter use does not compromise the former. 2.11. Address and Port Agility IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and AH associations for the same IP addresses it runs over. The IP addresses and ports in the outer header are, however, not themselves cryptographically protected, and IKE is designed to work even through Network Address Translation (NAT) boxes. An implementation MUST accept incoming requests even if the source port is not 500 or 4500, and MUST respond to the address and port from which the request was @@ -2014,82 +2064,86 @@ reasonable strategies for doing this. An endpoint could choose a new exponential only periodically though this could result in less-than- perfect forward secrecy if some connection lasts for less than the lifetime of the exponential. Or it could keep track of which exponential was used for each connection and delete the information associated with the exponential only when some corresponding connection was closed. This would allow the exponential to be reused without losing perfect forward secrecy at the cost of maintaining more state. - Decisions as to whether and when to reuse Diffie-Hellman exponentials - is a private decision in the sense that it will not affect - interoperability. An implementation that reuses exponentials MAY - choose to remember the exponential used by the other endpoint on past - exchanges and if one is reused to avoid the second half of the - calculation. See [REUSE] for a security analysis of this practice - and for additional security considerations when reusing ephemeral DH - keys. + Whether and when to reuse Diffie-Hellman exponentials are private + decisions in the sense that they will not affect interoperability. + An implementation that reuses exponentials MAY choose to remember the + exponential used by the other endpoint on past exchanges and if one + is reused to avoid the second half of the calculation. See [REUSE] + for a security analysis of this practice and for additional security + considerations when reusing ephemeral DH keys. 2.13. Generating Keying Material In the context of the IKE SA, four cryptographic algorithms are negotiated: an encryption algorithm, an integrity protection algorithm, a Diffie-Hellman group, and a pseudo-random function - (prf). The pseudo-random function is used for the construction of - keying material for all of the cryptographic algorithms used in both - the IKE SA and the Child SAs. + (PRF). The PRF is used for the construction of keying material for + all of the cryptographic algorithms used in both the IKE SA and the + Child SAs. We assume that each encryption algorithm and integrity protection algorithm uses a fixed-size key and that any randomly chosen value of that fixed size can serve as an appropriate key. For algorithms that accept a variable length key, a fixed key size MUST be specified as part of the cryptographic transform negotiated (see Section 3.3.5 for - the defintion of the Key Length transform attribute). For algorithms - for which not all values are valid keys (such as DES or 3DES with key - parity), the algorithm by which keys are derived from arbitrary - values MUST be specified by the cryptographic transform. For - integrity protection functions based on Hashed Message Authentication - Code (HMAC), the fixed key size is the size of the output of the - underlying hash function. + the definition of the Key Length transform attribute). For + algorithms for which not all values are valid keys (such as DES or + 3DES with key parity), the algorithm by which keys are derived from + arbitrary values MUST be specified by the cryptographic transform. + For integrity protection functions based on Hashed Message + Authentication Code (HMAC), the fixed key size is the size of the + output of the underlying hash function. - It is assumed that pseudo-random functions (PRFs) accept keys of any - length, but have a preferred key size. The preferred key size is - used as the length of SK_d, SK_pi, and SK_pr (see Section 2.14). For - PRFs based on the HMAC construction, the preferred key size is equal - to the length of the output of the underlying hash function. Other - types of PRFs MUST specify their preferred key size. + It is assumed that PRFs accept keys of any length, but have a + preferred key size. The preferred key size is used as the length of + SK_d, SK_pi, and SK_pr (see Section 2.14). For PRFs based on the + HMAC construction, the preferred key size is equal to the length of + the output of the underlying hash function. Other types of PRFs MUST + specify their preferred key size. Keying material will always be derived as the output of the - negotiated prf algorithm. Since the amount of keying material needed - may be greater than the size of the output of the prf algorithm, we - will use the prf iteratively. We will use the terminology prf+ to - describe the function that outputs a pseudo-random stream based on - the inputs to a prf as follows: (where | indicates concatenation) + negotiated PRF algorithm. Since the amount of keying material needed + may be greater than the size of the output of the PRF, the PRF is + used iteratively. The term "prf+" describes a function that outputs + a pseudo-random stream based on the inputs to a pseudo-random + function called "prf". + + In the following, | indicates concatenation. prf+ is defined as: + prf+ (K,S) = T1 | T2 | T3 | T4 | ... where: T1 = prf (K, S | 0x01) T2 = prf (K, T1 | S | 0x02) T3 = prf (K, T2 | S | 0x03) T4 = prf (K, T3 | S | 0x04) + ... - continuing as needed to compute all required keys. The keys are - taken from the output string without regard to boundaries (e.g., if - the required keys are a 256-bit Advanced Encryption Standard (AES) - key and a 160-bit HMAC key, and the prf function generates 160 bits, - the AES key will come from T1 and the beginning of T2, while the HMAC - key will come from the rest of T2 and the beginning of T3). + This continues until all the material needed to compute all required + keys has been output from prf+. The keys are taken from the output + string without regard to boundaries (e.g., if the required keys are a + 256-bit Advanced Encryption Standard (AES) key and a 160-bit HMAC + key, and the prf function generates 160 bits, the AES key will come + from T1 and the beginning of T2, while the HMAC key will come from + the rest of T2 and the beginning of T3). - The constant concatenated to the end of each string feeding the prf - is a single octet. prf+ in this document is not defined beyond 255 - times the size of the prf output. + The constant concatenated to the end of each prf function is a single + octet. The prf+ function is not defined beyond 255 times the size of + the prf function output. 2.14. Generating Keying Material for the IKE SA The shared keys are computed as follows. A quantity called SKEYSEED is calculated from the nonces exchanged during the IKE_SA_INIT exchange and the Diffie-Hellman shared secret established during that exchange. SKEYSEED is used to calculate seven other secrets: SK_d used for deriving new keys for the Child SAs established with this IKE SA; SK_ai and SK_ar used as a key to the integrity protection algorithm for authenticating the component messages of subsequent @@ -2227,27 +2281,27 @@ In addition to authentication using public key signatures and shared secrets, IKE supports authentication using methods defined in RFC 3748 [EAP]. Typically, these methods are asymmetric (designed for a user authenticating to a server), and they may not be mutual. For this reason, these protocols are typically used to authenticate the initiator to the responder and MUST be used in conjunction with a public key signature based authentication of the responder to the initiator. These methods are often associated with mechanisms referred to as "Legacy Authentication" mechanisms. - While this memo references [EAP] with the intent that new methods can - be added in the future without updating this specification, some - simpler variations are documented here and in Section 3.16. [EAP] - defines an authentication protocol requiring a variable number of - messages. Extensible Authentication is implemented in IKE as - additional IKE_AUTH exchanges that MUST be completed in order to - initialize the IKE SA. + While this document references [EAP] with the intent that new methods + can be added in the future without updating this specification, some + simpler variations are documented here. [EAP] defines an + authentication protocol requiring a variable number of messages. + Extensible Authentication is implemented in IKE as additional + IKE_AUTH exchanges that MUST be completed in order to initialize the + IKE SA. An initiator indicates a desire to use extensible authentication by leaving out the AUTH payload from message 3. By including an IDi payload but not an AUTH payload, the initiator has declared an identity but has not proven it. If the responder is willing to use an extensible authentication method, it will place an Extensible Authentication Protocol (EAP) payload in message 4 and defer sending SAr2, TSi, and TSr until initiator authentication is complete in a subsequent IKE_AUTH exchange. In the case of a minimal extensible authentication, the initial SA establishment will appear as follows: @@ -2369,36 +2423,36 @@ SKEYSEED = prf(SK_d (old), g^ir (new) | Ni | Nr) where g^ir (new) is the shared secret from the ephemeral Diffie- Hellman exchange of this CREATE_CHILD_SA exchange (represented as an 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 stripped of any headers. The old and new IKE SA may have selected a different PRF. Because the rekeying exchange belongs to the old IKE SA, it is the old IKE - SA's PRF that is used. + SA's PRF that is used to generate SKEYSEED. The main reason for rekeying the IKE SA is to ensure that the compromise of old keying material does not provide information about the current keys, or vice versa. Therefore, implementations MUST perform a new Diffie-Hellman exchange when rekeying the IKE SA. In other words, an initiator MUST NOT propose the value "NONE" for the D-H transform, and a responder MUST NOT accept such a proposal. This - means that a succesful exchange rekeying the IKE SA always includes + means that a successful exchange rekeying the IKE SA always includes the KEi/KEr payloads. The new IKE SA MUST reset its message counters to 0. SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as specified in Section 2.14, using SPIi, SPIr, Ni, and Nr from the new - exchange. + exchange, and using the new IKE SA's PRF. 2.19. Requesting an Internal Address on a Remote Network Most commonly occurring in the endpoint-to-security-gateway scenario, an endpoint may need an IP address in the network protected by the security gateway and may need to have that address dynamically assigned. A request for such a temporary address can be included in any request to create a Child SA (including the implicit request in message 3) by including a CP payload. Note, however, it is usual to only assign one IP address during the IKE_AUTH exchange. That @@ -2449,35 +2503,33 @@ INTERNAL_NETMASK(255.255.255.0) INTERNAL_SUBNET(192.0.2.0/255.255.255.0) TSi = (0, 0-65535,192.0.2.202-192.0.2.202) TSr = (0, 0-65535,192.0.2.0-192.0.2.255) All returned values will be implementation dependent. As can be seen in the above example, the IRAS MAY also send other attributes that were not included in CP(CFG_REQUEST) and MAY ignore the non- mandatory attributes that it does not support. - The FAILED_CP_REQUIRED notification is sent by responder in the case - where CP(CFG_REQUEST) was expected but not received, and so is a - conflict with locally configured policy. There is no associated - data. - 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 to perform an unnecessary configuration lookup if the IRAC cannot - process the REPLY. 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 CP(CFG_REQUEST), IRAS MUST fail the request, and - terminate the IKE exchange with a FAILED_CP_REQUIRED error. The - FAILED_CP_REQUIRED is not fatal to the IKE SA; it simply causes the - Child SA creation fail. The initiator can fix this by later starting - a new configuration payload request. + process the REPLY. + + 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 + CP(CFG_REQUEST), IRAS MUST fail the request, and terminate the Child + 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 + fail. The initiator can fix this by later starting a new + configuration payload request. There is no associated data in the + FAILED_CP_REQUIRED error. 2.20. Requesting the Peer's Version 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 a configuration request within an INFORMATIONAL exchange, after the IKE SA and first Child SA have been created. An IKE implementation MAY decline to give out version information prior to authentication or even after authentication to prevent @@ -2574,26 +2626,20 @@ In an IKE_AUTH exchange, or in the INFORMATIONAL exchange immediately following it (in case an error happened in when processing a response to IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and AUTHENTICATION_FAILED notifications are the only ones to cause the IKE SA to be deleted or not created, without a DELETE payload. Extension documents may define new error notifications with these semantics, but MUST NOT use them unless the peer has been shown to understand them. - NOTE FOR WG DISCUSSION: Having other payloads in the message is - allowed but there are none suggested. One WG member mentioned the - possibility of adding a DELETE payload when the error is sent in a - separate INFORMATIONAL exchange. Do we want to allow such additional - payloads that have operational semantics? - 2.21.3. Error Handling after IKE SA is Authenticated After the IKE SA is authenticated all requests having errors MUST result in response notifying about the error. In normal situations, there should not be cases where valid response from one peer results in an error situation in the other peer, so there should not be any reason for a peer to send error messages to the other end except as a response. Because sending such error messages as INFORMATIONAL exchange might lead to further errors that @@ -2760,22 +2806,22 @@ ports may be modified as the packets pass through NATs. Similarly, IP addresses of the IKE endpoints are generally not included in the IKE payloads because the payloads are cryptographically protected and could not be transparently modified by NATs. Port 4500 is reserved for UDP-encapsulated ESP and IKE. An IPsec endpoint that discovers a NAT between it and its correspondent MUST send all subsequent traffic from port 4500, which NATs should not treat specially (as they might with port 500). - An initiator can float to port 4500, regardless whether or not there - is NAT, even at the beginning of IKE. When either side is using port + An initiator can use port 4500, regardless whether or not there is + NAT, even at the beginning of IKE. When either side is using port 4500, sending with UDP encapsulation is not required, but understanding received packets with UDP encapsulation is required. UDP encapsulation MUST NOT be done on port 500. If NAT-T is supported (that is, if NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT), all devices MUST be able to receive and process both UDP encapsulated and non-UDP encapsulated packets at any time. Either side can decide whether or not to use UDP encapsulation irrespective of the choice made by the other side. However, if a NAT is detected, both devices MUST send UDP encapsulated packets. @@ -2790,59 +2836,53 @@ o Both IKE initiator and responder MUST include in their IKE_SA_INIT packets Notify payloads of type NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP. Those payloads can be used to detect if there is NAT between the hosts, and which end is behind the NAT. The location of the payloads in the IKE_SA_INIT packets is just after the Ni and Nr payloads (before the optional CERTREQ payload). o The data associated with the NAT_DETECTION_SOURCE_IP notification is a SHA-1 digest of the SPIs (in the order they appear in the - header), IP address, and port on which this packet was sent. + header), IP address, and port from which this packet was sent. There MAY be multiple NAT_DETECTION_SOURCE_IP payloads in a message if the sender does not know which of several network attachments will be used to send the packet. o The data associated with the NAT_DETECTION_DESTINATION_IP 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 was sent. o The recipient of either the NAT_DETECTION_SOURCE_IP or NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied value to a SHA-1 hash of the SPIs, source IP address, and port, and if they don't match it SHOULD enable NAT traversal. In the - case of a mismatching NAT_DETECTION_SOURCE_IP hash, the recipient - MAY reject the connection attempt if NAT traversal is not - supported. In the case of a mismatching + case there is a mismatch of the NAT_DETECTION_SOURCE_IP hash with + all of the NAT_DETECTION_SOURCE_IP payloads received, the + recipient MAY reject the connection attempt if NAT traversal is + not supported. In the case of a mismatching NAT_DETECTION_DESTINATION_IP hash, it means that the system receiving the NAT_DETECTION_DESTINATION_IP payload is behind a NAT and that system SHOULD start sending keepalive packets as defined in [UDPENCAPS]; alternately, it MAY reject the connection attempt if NAT traversal is not supported. 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 header of the packet containing the payload, it means that the system sending those payloads is behind NAT (i.e., someone along the route changed the source address of the original packet to match the address of the NAT box). In this case, the system receiving the payloads should allow dynamic update of the other systems' IP address, as described later. - o If the NAT_DETECTION_DESTINATION_IP payload received does not - match the hash of the destination IP and port found from the IP - header of the packet containing the payload, it means that the - system receiving the NAT_DETECTION_DESTINATION_IP payload is - behind a NAT. In this case, that system SHOULD start sending - keepalive packets as explained in [UDPENCAPS]. - o The IKE initiator MUST check these payloads if present and if they do not match the addresses in the outer packet MUST tunnel all future IKE and ESP packets associated with this IKE SA over UDP port 4500. o To tunnel IKE packets over UDP port 4500, the IKE header has four octets of zero prepended and the result immediately follows the UDP header. To tunnel ESP packets over UDP port 4500, the ESP header immediately follows the UDP header. Since the first four octets of the ESP header contain the SPI, and the SPI cannot @@ -2860,48 +2900,47 @@ original IP address. o There are cases where a NAT box decides to remove mappings that are still alive (for example, the keepalive interval is too long, or the NAT box is rebooted). To recover in these cases, hosts that do not support other methods of recovery such as MOBIKE [MOBIKE], and that are not behind a NAT, SHOULD send all packets (including retransmission packets) to the IP address and port from the last valid authenticated packet from the other end (that is, they should dynamically update the address). A host behind a NAT - SHOULD NOT do this because it opens a possible denial-of-service + SHOULD NOT do this because it opens a possible denial of service attack. Any authenticated IKE packet or any authenticated UDP- encapsulated ESP packet can be used to detect that the IP address or the port has changed. When IKEv2 is used with MOBIKE, dynamically updating the addresses described above interferes with - MOBIKE's way of recovering from the same situation, so this method - MUST NOT be used when MOBIKE is used. See Section 3.8 of [MOBIKE] - for more information. + 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 Transport mode used with NAT Traversal requires special handling of the traffic selectors used in the IKEv2. The complete scenario looks like: +------+ +------+ +------+ +------+ |Client| IP1 | NAT | IPN1 IPN2 | NAT | IP2 |Server| |node |<------>| A |<---------->| B |<------->| | +------+ +------+ +------+ +------+ - (Other scenarios are simplications of this complex case, so this + (Other scenarios are simplifications of this complex case, so this discussion uses the complete scenario.) In this scenario, there are two address translating NATs: NAT A and NAT B. NAT A is dynamic NAT that maps the clients source address IP1 to IPN1. NAT B is static NAT configured so that connections coming - to IPN2 address are mapped to the gateways adddress IP2, that is, - IPN2 destination address is mapped to IP2. This allows the client to + to IPN2 address are mapped to the gateways address IP2, that is, IPN2 + destination address is mapped to IP2. This allows the client to connect to a server by connecting to the IPN2. NAT B does not necessarily need to be a static NAT, but the client needs to know how to connect to the server, and it can only do that if it somehow knows 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 configuration. Other options would be find it using some other protocol (like DNS), but those are outside of scope of IKEv2. In this scenario, both client and server are configured to use transport mode for the traffic originating from the client node and @@ -2911,21 +2950,21 @@ traffic to the server, it has a triggering packet with source IP address of IP1, and a destination IP address of IPN2. Its PAD and SPD needs to have configuration matching those addresses (or wildcard entries covering them). Because this is transport mode, it uses exactly same addresses as the traffic selectors and outer IP address 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 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 addresses, and all TSr entries must have the IPN2-IPN2 range as IP - the 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 from the packet triggering the request. 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 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 the client, but the IP address of the IKE packet has been replaced to IPN1 and IP2. @@ -2934,29 +2973,29 @@ 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 on that if transport mode is used. On the other hand, the server cannot know whether transport mode is allowed by its policy before it finds the matching SPD entry. In this case, the server should first check that as initiator requested transport mode and do address substitution on the traffic selectors. It needs to first store the old traffic selector IP addresses to be used later for the incremental checksum fixup (the IP - address in the TSi can be stored as the real source address and the - IP address in the TSr can be stored as the real destination address). - After that, if the other end was detected as being behind a NAT, the - server replaces the IP address in TSi payloads with the IP address - obtained from the source address of the IKE packet received (that is, - it replaces IP1 in TSi with IPN1). If the server's end was detected - to be behind NAT, it replaces the IP address in the TSr payloads with - the IP address obtained from the destination address of the IKE - packet received (thta is, it replaces IPN2 in TSr with IP2). + address in the TSi can be stored as the original source address and + the IP address in the TSr can be stored as the original destination + address). After that, if the other end was detected as being behind + a NAT, the server replaces the IP address in TSi payloads with the IP + address obtained from the source address of the IKE packet received + (that is, it replaces IP1 in TSi with IPN1). If the server's end was + detected to be behind NAT, it replaces the IP address in the TSr + payloads with the IP address obtained from the 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 IKE UDP source/destination addresses look the same, and the server 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 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 original traffic selectors. If the second lookup succeeds, the server will create an SA in tunnel mode using real traffic selectors sent by the other end. @@ -2972,67 +3011,68 @@ SPD entries, for example, for different known NATs outer addresses. After the SPD lookup, the server will do traffic selector narrowing based on the SPD entry it found. It will again use the already- substituted traffic selectors, and it will thus send back traffic selectors having IPN1 and IP2 as their IP addresses; it can still narrow down the protocol number or port ranges used by the traffic selectors. The SAD entry created for the Child SA will have the addresses as seen by the server, namely IPN1 and IP2. - When the client receives the server's reply to the Child SA, it will - do similar processing. If the transport mode SA was created, the - client can store the original returned traffic selectors as real - source and destination addresses. It will replace the IP addresses - in the traffic selectors with the ones from the IP header of the IKE - packet: it will replace IPN1 with IP1 and IP2 with IPN2. Then it - will use those traffic selectors when verifying the SA against sent - traffic selectors, and when installing the SAD entry. + When the client receives the server's response to the Child SA, it + will do similar processing. If the transport mode SA was created, + the client can store the original returned traffic selectors as + original source and destination addresses. It will replace the IP + addresses in the traffic selectors with the ones from the IP header + of the IKE packet: it will replace IPN1 with IP1 and IP2 with IPN2. + Then it will use those traffic selectors when verifying the SA + against sent traffic selectors, and when installing the SAD entry. A summary of the rules for NAT-traversal in transport mode is: For the client proposing transport mode: - The TSi entries MUST have exactly one IP address, and that MUST match the source address of the IKE SA. - The TSr entries MUST have exactly one IP address, and that MUST match the destination address of the IKE SA. - The first TSi and TSr traffic selectors SHOULD have very specific traffic selectors including protocol and port numbers from the packet triggering the request. - There MAY be multiple TSi and TSr entries. - If transport mode for the SA was selected (that is, if the server - included USE_TRANSPORT_MODE notification in its reply): + included USE_TRANSPORT_MODE notification in its response): - - Store the original traffic selectors as the real source and + - Store the original traffic selectors as the received source and destination address. - If the server is behind a NAT, substitute the IP address in the TSr entries with the remote address of the IKE SA. - If the client is behind a NAT, substitute the IP address in the TSi entries with the local address of the IKE SA. - Do address substitution before using those traffic selectors for anything else other than storing original content of them. This includes verification that traffic selectors were narrowed correctly by other end, creation of the SAD entry, and so on. For the responder, when transport mode is proposed by client: - - Store the original traffic selector IP addresses as real source - and destination address in case we need to undo address - substitution. + - Store the original traffic selector IP addresses as received source + and destination address, both in case we need to undo address + substitution, and to use as the "real source and destination + address" specified by [UDPENCAPS], and for TCP/UDP checksum fixup. - If the client is behind a NAT, substitute the IP address in the TSi entries with the remote address of the IKE SA. - If the server is behind a NAT substitute the IP address in the TSr entries with the local address of the IKE SA. - Do PAD and SPD lookup using the ID and substituted traffic selectors. @@ -3049,21 +3089,21 @@ the client. 2.24. Explicit Congestion Notification (ECN) When IPsec tunnels behave as originally specified in [IPSECARCH-OLD], ECN usage is not appropriate for the outer IP headers because tunnel decapsulation processing discards ECN congestion indications to the detriment of the network. ECN support for IPsec tunnels for IKEv1- based IPsec requires multiple operating modes and negotiation (see [ECN]). IKEv2 simplifies this situation by requiring that ECN be - usable in the outer IP headers of all tunnel-mode IPsec SAs created + usable in the outer IP headers of all tunnel-mode Child SAs created by IKEv2. Specifically, tunnel encapsulators and decapsulators for all tunnel-mode SAs created by IKEv2 MUST support the ECN full- functionality option for tunnels specified in [ECN] and MUST implement the tunnel encapsulation and decapsulation processing specified in [IPSECARCH] to prevent discarding of ECN congestion indications. 2.25. Exchange Collisions Because IKEv2 exchanges can be initiated by either peer, it is @@ -3082,90 +3123,95 @@ as a rekeying operation. When a peer receives a TEMPORARY_FAILURE notification, it MUST NOT immediately retry the operation; it MUST wait so that the sender may complete whatever operation caused the temporary condition. The recipient MAY retry the request one or more times over a period of several minutes. If a peer continues to receive TEMPORARY_FAILURE on the same IKE SA after several minutes, it SHOULD conclude that state information is out-of-sync and close the IKE SA. A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives - a request to rekey a Child SA that does not exist. A peer that - receives a CHILD_SA_NOT_FOUND notification SHOULD silently delete the - Child SA and send a request to create a new Child SA from scratch. + 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 + Notify Payload, which is copied from the SPI field in the REYEY_SA + notification. A peer that receives a CHILD_SA_NOT_FOUND notification + 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 + not yet exist). 2.25.1. Collisions While Rekeying or Closing Child SAs If a peer receives a request to rekey a Child SA that it is currently 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, it SHOULD reply as usual, and SHOULD prepare to close redundant SAs - later based on the nonces. If a peer receives a request to rekey a - Child SA that does not exist, it SHOULD reply with + 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 CHILD_SA_NOT_FOUND. If a peer receives a request to close a Child SA that it is currently - trying to close, it SHOULD reply without Delete payloads. If a peer - receives a request to close a Child SA that it is currently rekeying, - it SHOULD reply as usual, with Delete payload. If a peer receives a - request to close a Child SA that does not exist, it SHOULD reply - without Delete payloads. + 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 + that it is currently rekeying, it SHOULD reply as usual, with Delete + payload. If a peer receives a request to close a Child SA 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 creating, rekeying, or closing a Child SA of that IKE SA, it SHOULD reply with TEMPORARY_FAILURE. 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 rekeying, it SHOULD reply as usual, and SHOULD prepare to close - redundant SAs and move inherited Child SAs later based on the nonces. - If a peer receives a request to rekey an IKE SA that it is currently - trying to close, it SHOULD reply with TEMPORARY_FAILURE. + redundant SAs and move inherited Child SAs later based on the nonces + (see Section 2.8.2). If a peer receives a request to rekey an IKE SA + that it is currently trying to close, it SHOULD reply with + TEMPORARY_FAILURE. If a peer receives a request to close an IKE SA that it is currently rekeying, it SHOULD reply as usual, and forget about its own rekeying request. If a peer receives a request to close an IKE SA that it is currently trying to close, it SHOULD reply as usual, and forget about its own close request. If a peer receives a request to create or rekey a Child SA when it is currently rekeying the IKE SA, it SHOULD reply with TEMPORARY_FAILURE. If a peer receives a request to delete a Child SA when it is currently rekeying the IKE SA, it SHOULD reply as usual, with a Delete payload. 3. Header and Payload Formats In the tables in this section, some cryptographic primitives and - configuation attributes are marked as "UNSPECIFIED". These are items - for which there are no known specifications and therefore + configuration attributes are marked as "UNSPECIFIED". These are + items for which there are no known specifications and therefore interoperability is currently impossible. A future specification may describe their use, but until such specification is made, implementations SHOULD NOT attempt to use items marked as "UNSPECIFIED" in implementations that are meant to be interoperable. 3.1. The IKE Header IKE messages use UDP ports 500 and/or 4500, with one IKE message per UDP datagram. Information from the beginning of the packet through the UDP header is largely ignored except that the IP addresses and UDP ports from the headers are reversed and used for return packets. When sent on UDP port 500, IKE messages begin immediately following the UDP header. When sent on UDP port 4500, IKE messages have 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 fields or checksums defined by IKE. Each IKE message begins with the - IKE header, denoted HDR in this memo. Following the header are one - or more IKE payloads each identified by a "Next Payload" field in the - preceding payload. Payloads are processed in the order in which they - appear in an IKE message by invoking the appropriate processing + IKE header, denoted HDR in this document. Following the header are + one or more IKE payloads each identified by a "Next Payload" field in + the preceding payload. 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. If a payload of type "Encrypted" is found, that payload is decrypted and its contents parsed as additional payloads. An Encrypted payload MUST be the last payload in a packet and an Encrypted payload MUST NOT contain another Encrypted payload. The Recipient SPI in the header identifies an instance of an IKE security association. It is therefore possible for a single instance @@ -3232,49 +3278,48 @@ Exchange Type Value ---------------------------------- IKE_SA_INIT 34 IKE_AUTH 35 CREATE_CHILD_SA 36 INFORMATIONAL 37 o Flags (1 octet) - Indicates specific options that are set for the message. Presence of options is indicated by the appropriate bit - in the flags field being set. The bits are defined LSB first, so - bit 0 would be the least significant bit of the Flags octet. In - the description below, a bit being 'set' means its value is '1', - while 'cleared' means its value is '0'. + in the flags field being set. The bits are as follows: - * X(reserved) (bits 0-2) - These bits MUST be cleared when - sending and MUST be ignored on receipt. + +-+-+-+-+-+-+-+-+ + |X|X|R|V|I|X|X|X| + +-+-+-+-+-+-+-+-+ - * I(nitiator) (bit 3 of Flags) - This bit MUST be set in messages - sent by the original initiator of the IKE SA and MUST be - cleared in messages sent by the original responder. It is used - by the recipient to determine which eight octets of the SPI - were generated by the recipient. This bit changes to reflect - who initiated the last rekey of the IKE SA. + In the description below, a bit being 'set' means its value is + '1', while 'cleared' means its value is '0'. "X" bits MUST be + cleared when sending and MUST be ignored on receipt. - * V(ersion) (bit 4 of Flags) - This bit indicates that the - transmitter is capable of speaking a higher major version - number of the protocol than the one indicated in the major - version number field. Implementations of IKEv2 MUST clear this - bit when sending and MUST ignore it in incoming messages. + * I(nitiator) - This bit MUST be set in messages sent by the + original initiator of the IKE SA and MUST be cleared in + messages sent by the original responder. It is used by the + recipient to determine which eight octets of the SPI were + generated by the recipient. This bit changes to reflect who + initiated the last rekey of the IKE SA. - * R(esponse) (bit 5 of Flags) - This bit indicates that this - message is a response to a message containing the same message - ID. This bit MUST be cleared in all request messages and MUST - be set in all responses. An IKE endpoint MUST NOT generate a - response to a message that is marked as being a response. + * V(ersion) - This bit indicates that the transmitter is capable + of speaking a higher major version number of the protocol than + the one indicated in the major version number field. + Implementations of IKEv2 MUST clear this bit when sending and + MUST ignore it in incoming messages. - * X(reserved) (bits 6-7 of Flags) - These bits MUST be cleared - when sending and MUST be ignored on receipt. + * R(esponse) - This bit indicates that this message is a response + to a message containing the same message ID. This bit MUST be + cleared in all request messages and MUST be set in all + responses. An IKE endpoint MUST NOT generate a response to a + message that is marked as being a response. o Message ID (4 octets) - Message identifier used to control retransmission of lost packets and matching of requests and responses. It is essential to the security of the protocol because it is used to prevent message replay attacks. See Section 2.1 and Section 2.2. o Length (4 octets) - Length of total message (header + payloads) in octets. @@ -3298,45 +3343,44 @@ o Next Payload (1 octet) - Identifier for the payload type of the 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 "chaining" capability whereby additional payloads can be added to a message by appending it to the end of the message and setting the "Next Payload" field of the preceding payload to indicate the new payload's type. An Encrypted payload, which must always be the last payload of a message, is an exception. It contains data structures in the format of additional payloads. 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). - - o The payload type values are listed here. The values in the - following table are only current as of the publication date of RFC - 4306. Other values may have been added since then or will be - added after the publication of this document. Readers should - refer to [IKEV2IANA] for the latest values. + type of the first contained payload (instead of 0). The payload + type values are listed here. The values in the following table + are only current as of the publication date of RFC 4306. Other + values may have been added 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 -------------------------------------------------- No Next Payload 0 Security Association SA 33 Key Exchange KE 34 Identification - Initiator IDi 35 Identification - Responder IDr 36 Certificate CERT 37 Certificate Request CERTREQ 38 Authentication AUTH 39 Nonce Ni, Nr 40 Notify N 41 Delete D 42 Vendor ID V 43 Traffic Selector - Initiator TSi 44 Traffic Selector - Responder TSr 45 - Encrypted E 46 + Encrypted and Authenticated SK 46 Configuration CP 47 Extensible Authentication EAP 48 (Payload type values 1-32 should not be assigned in the future so that there is no overlap with the code assignments for IKEv1.) o Critical (1 bit) - MUST be set to zero if the sender wants the recipient to skip this payload if it does not understand the payload type code in the Next Payload field of the previous @@ -3344,41 +3388,42 @@ reject this entire message if it does not understand the payload type. MUST be ignored by the recipient if the recipient understands the payload type code. MUST be set to zero for payload types defined in this document. Note that the critical bit applies to the current payload rather than the "next" payload whose type code appears in the first octet. The reasoning behind not setting the critical bit for payloads defined in this document is that all implementations MUST understand all payload types defined in this document and therefore must ignore the Critical bit's value. Skipped payloads are expected to have valid Next - Payload and Payload Length fields. + Payload and Payload Length fields. See Section 2.5 for more + information on this bit. o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on receipt. o Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. Many payloads contain fields marked as "RESERVED". Some payloads in IKEv2 (and historically in IKEv1) are not aligned to 4-octet boundaries. 3.3. Security Association Payload - The Security Association Payload, denoted SA in this memo, is used to - negotiate attributes of a security association. Assembly of Security - Association Payloads requires great peace of mind. An SA payload MAY - contain multiple proposals. If there is more than one, they MUST be - ordered from most preferred to least preferred. Each proposal - contains a single IPsec protocol (where a protocol is IKE, ESP, or - AH), each protocol MAY contain multiple transforms, and each + The Security Association Payload, denoted SA in this document, is + used to negotiate attributes of a security association. Assembly of + Security Association Payloads requires great peace of mind. An SA + payload MAY contain multiple proposals. If there is more than one, + they MUST be ordered from most preferred to least preferred. Each + proposal contains a single IPsec protocol (where a protocol is IKE, + ESP, or AH), each protocol MAY contain multiple transforms, and each transform MAY contain multiple attributes. When parsing an SA, an implementation MUST check that the total Payload Length is consistent with the payload's internal lengths and counts. Proposals, Transforms, and Attributes each have their own variable length encodings. They are nested such that the Payload Length of an SA includes the combined contents of the SA, Proposal, Transform, and Attribute information. The length of a Proposal includes the lengths of all Transforms and Attributes it contains. The length of a Transform includes the lengths of all Attributes it contains. @@ -3394,44 +3439,42 @@ One of the reasons the semantics of the SA payload has changed from ISAKMP and IKEv1 is to make the encodings more compact in common cases. The Proposal structure contains within it a Proposal # and an IPsec protocol ID. Each structure MUST have a proposal number one (1) greater than the previous structure. The first Proposal in the initiator's SA payload MUST have a Proposal # of one (1). One reason to use multiple proposals is to propose both standard crypto ciphers and combined-mode ciphers. Combined-mode ciphers include both - integrity and encryption in a single encryption algorithm, and are - not allowed to be offered with a separate integrity algorithm other - than "none". If an initiator wants to propose both combined-mode - ciphers and normal ciphers, it must include two proposals: one will - have all the combined-mode ciphers, and the other will have all the - normal ciphers with the integrity algorithms. For example, one such - proposal would have two proposal structures: ESP with ENCR_AES-CCM_8, - ENCR_AES-CCM_12, and ENCR_AES-CCM_16 as Proposal #1, and ESP with + integrity and encryption in a single encryption algorithm, and MUST + either offer no integrity algorithm or a single integrity algorithm + of "none", with no integrity algorithm being the RECOMMENDED method. + If an initiator wants to propose both combined-mode ciphers and + normal ciphers, it must include two proposals: one will have all the + combined-mode ciphers, and the other will have all the normal ciphers + with the integrity algorithms. For example, one such proposal would + have two proposal structures: ESP with ENCR_AES-CCM_8, ENCR_AES- + CCM_12, and ENCR_AES-CCM_16 as Proposal #1, and ESP with ENCR_AES_CBC, ENCR_3DES, AUTH_AES_XCBC_96, and AUTH_HMAC_SHA1_96 as Proposal #2. Each Proposal/Protocol structure is followed by one or more transform structures. The number of different transforms is generally determined by the Protocol. AH generally has two transforms: Extended Sequence Numbers (ESN) and an integrity check algorithm. ESP generally has three: ESN, an encryption algorithm and an integrity check algorithm. IKE generally has four transforms: a - Diffie-Hellman group, an integrity check algorithm, a prf algorithm, - and an encryption algorithm. If an algorithm that combines - encryption and integrity protection is proposed, it MUST be proposed - as an encryption algorithm and an integrity protection algorithm MUST - NOT be proposed. For each Protocol, the set of permissible - transforms is assigned transform ID numbers, which appear in the - header of each transform. + Diffie-Hellman group, an integrity check algorithm, a PRF algorithm, + and an encryption algorithm. For each Protocol, the set of + permissible transforms is assigned transform ID numbers, which appear + in the header of each transform. If there are multiple transforms with the same Transform Type, the proposal is an OR of those transforms. If there are multiple Transforms with different Transform Types, the proposal is an AND of the different groups. For example, to propose ESP with (3DES or AES- CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two Transform Type 1 candidates (one for 3DES and one for AEC-CBC) and two Transform Type 3 candidates (one for HMAC_MD5 and one for HMAC_SHA). This effectively proposes four combinations of algorithms. If the initiator wanted to propose only a subset of @@ -3861,41 +3904,40 @@ that response MUST be rejected. If the responder receives a proposal that contains a Transform Type it does not understand, or a proposal that is missing a mandatory Transform Type, it MUST consider this proposal unacceptable; however, other proposals in the same SA payload are processed as usual. Similarly, if the responder receives a transform that contains a Transform Attribute it does not understand, it MUST consider this transform unacceptable; other transforms with the same Transform Type are processed as usual. This allows new Transform Types and - Transform Attributes to be defined in the future. An exception is - the case where one of the proposals offered is for the Diffie-Hellman - group of NONE. In this case, the responder MUST ignore the - initiator's KE payload and omit the KE payload from the response. + Transform Attributes to be defined in the future. Negotiating Diffie-Hellman groups presents some special challenges. SA offers include proposed attributes and a Diffie-Hellman public number (KE) in the same message. If in the initial exchange the initiator offers to use one of several Diffie-Hellman groups, it SHOULD pick the one the responder is most likely to accept and include a KE corresponding to that group. If the responder selects a proposal using a different Diffie-Hellman group (other than NONE), 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 retrying the first message. It SHOULD, however, continue to propose its full supported set of groups in order to prevent a man-in-the- - middle downgrade attack. + middle downgrade attack. If one of the proposals offered is for the + Diffie-Hellman group of NONE, the responder MUST ignore the + initiator's KE payload and omit the KE payload from the response. 3.4. Key Exchange Payload - The Key Exchange Payload, denoted KE in this memo, is used to + The Key Exchange Payload, denoted KE in this document, is used to exchange Diffie-Hellman public numbers as part of a Diffie-Hellman key exchange. The Key Exchange Payload consists of the IKE generic payload header followed by the Diffie-Hellman public value itself. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DH Group # | RESERVED | @@ -3914,29 +3956,30 @@ performed, prepending zero bits to the value if necessary. The DH Group # identifies the Diffie-Hellman group in which the Key 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 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 proposals in that SA payload specifies a DH Group, the KE payload MUST NOT be present. If the selected proposal uses a different Diffie-Hellman group (other than NONE), the message MUST be rejected - with a Notify payload of type INVALID_KE_PAYLOAD. + with a Notify payload of type INVALID_KE_PAYLOAD. See also + Section 1.2 and Section 2.7. The payload type for the Key Exchange payload is thirty four (34). 3.5. Identification Payloads - The Identification Payloads, denoted IDi and IDr in this memo, allow - peers to assert an identity to one another. This identity may be - used for policy lookup, but does not necessarily have to match + The Identification Payloads, denoted IDi and IDr in this document, + allow peers to assert an identity to one another. This identity may + be used for policy lookup, but does not necessarily have to match anything in the CERT payload; both fields may be used by an implementation to perform access control decisions. When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 does not require this address to match the address in the IP header of IKEv2 packets, or anything in the TSi/TSr payloads. The contents of IDi/IDr is used purely to fetch the policy and authentication data related to the other party. NOTE: In IKEv1, two ID payloads were used in each direction to hold Traffic Selector (TS) information for data passing over the SA. In @@ -3986,28 +4029,28 @@ of this document. Readers should refer to [IKEV2IANA] for the latest values. ID Type Value ------------------------------------------------------------------- ID_IPV4_ADDR 1 A single four (4) octet IPv4 address. ID_FQDN 2 A fully-qualified domain name string. An example of a ID_FQDN - is, "example.com". The string MUST not contain any terminators + is, "example.com". The string MUST NOT contain any terminators (e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII; for an "internationalized domain name", the syntax is as defined in [IDNA], for example "xn--tmonesimerkki-bfbb.example.net". ID_RFC822_ADDR 3 A fully-qualified RFC822 email address string, An example of a - ID_RFC822_ADDR is, "jsmith@example.com". The string MUST not + ID_RFC822_ADDR is, "jsmith@example.com". The string MUST NOT contain any terminators. Because of [EAI], implementations would be wise to treat this field as UTF-8 encoded text, not as pure ASCII. ID_IPV6_ADDR 5 A single sixteen (16) octet IPv6 address. ID_DER_ASN1_DN 9 The binary Distinguished Encoding Rules (DER) encoding of an ASN.1 X.500 Distinguished Name [X.501]. @@ -4037,23 +4080,28 @@ same as the syntax of email address in [MAILFORMAT]. For those NAIs that include the realm component, the ID_RFC822_ADDR identification type SHOULD be used. Responder implementations should not attempt to verify that the contents actually conform to the exact syntax given in [MAILFORMAT], but instead should accept any reasonable-looking NAI. For NAIs that do not include the realm component,the ID_KEY_ID identification type SHOULD be used. 3.6. Certificate Payload - The Certificate Payload, denoted CERT in this memo, provides a means - to transport certificates or other authentication-related information - via IKE. Certificate payloads SHOULD be included in an exchange if + The Certificate Payload, denoted CERT in this document, provides a + means to transport certificates or other authentication-related + information via IKE. Certificate payloads SHOULD be included in an + exchange if certificates are available to the sender. The Hash and + URL formats of the Certificate payloads should be used in case the + peer has indicated an ability to retrieve this information from + elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. + Certificate payloads SHOULD be included in an exchange if certificates are available to the sender unless the peer has indicated an ability to retrieve this information from elsewhere 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: 1 2 3 @@ -4095,31 +4143,31 @@ o Certificate Data (variable length) - Actual encoding of certificate data. The type of certificate is indicated by the Certificate Encoding field. The payload type for the Certificate Payload is thirty seven (37). Specific syntax for some of the certificate type codes above is not defined in this document. The types whose syntax is defined in this document are: - o X.509 Certificate - Signature contains a DER encoded X.509 + o "X.509 Certificate - Signature" contains a DER encoded X.509 certificate whose public key is used to validate the sender's AUTH payload. Note that with this encoding, if a chain of certificates needs to be sent, multiple CERT payloads are used, only the first of which holds the public key used to validate the sender's AUTH payload. - o Certificate Revocation List contains a DER encoded X.509 + o "Certificate Revocation List" contains a DER encoded X.509 certificate revocation list. - o Raw RSA Key contains a PKCS #1 encoded RSA key, that is, a DER- + o "Raw RSA Key" contains a PKCS #1 encoded RSA key, that is, a DER- encoded RSAPublicKey structure (see [RSA] and [PKCS1]). o Hash and URL encodings allow IKE messages to remain short by replacing long data structures with a 20 octet SHA-1 hash (see [SHA]) of the replaced value followed by a variable-length URL that resolves to the DER encoded data structure itself. This improves efficiency when the endpoints have certificate data cached and makes IKE less subject to denial of service attacks that become easier to mount when IKE messages are large enough to require IP fragmentation [DOSUDPPROT]. @@ -4158,21 +4206,21 @@ the public key used to sign the AUTH payload. The other certificates may be sent in any order. Implementations MUST support the HTTP method for hash-and-URL lookup. The behavior of other URL methods is not currently specified, and such methods SHOULD NOT be used in the absence of a document specifying them. 3.7. Certificate Request Payload - The Certificate Request Payload, denoted CERTREQ in this memo, + The Certificate Request Payload, denoted CERTREQ in this document, provides a means to request preferred certificates via IKE and can appear in the IKE_INIT_SA response and/or the IKE_AUTH request. Certificate Request payloads MAY be included in an exchange when the sender needs to get the certificate of the receiver. If multiple CAs 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: 1 2 3 @@ -4260,23 +4308,24 @@ acceptable (perhaps after prompting a human operator). The HTTP_CERT_LOOKUP_SUPPORTED notification MAY be included in any message that can include a CERTREQ payload and indicates that the sender is capable of looking up certificates based on an HTTP-based URL (and hence presumably would prefer to receive certificate specifications in that format). 3.8. Authentication Payload - The Authentication Payload, denoted AUTH in this memo, contains data - used for authentication purposes. The syntax of the Authentication - data varies according to the Auth Method as specified below. + The Authentication Payload, denoted AUTH in this document, contains + data used for authentication purposes. The syntax of the + Authentication data varies according to the Auth Method as specified + below. The Authentication Payload is defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth Method | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -4306,36 +4355,36 @@ function when generating signatures. Implementations can use the certificates received from a given peer as a hint for selecting a mutually-understood hash function for the AUTH payload signature. Note, however, that the hash algorithm used in the AUTH payload signature doesn't have to be the same as any hash algorithm(s) used in the certificate(s). Shared Key Message Integrity Code 2 Computed as specified in Section 2.15 using the shared key associated with the identity in the ID payload and the negotiated - prf function. + PRF. DSS Digital Signature 3 Computed as specified in Section 2.15 using a DSS private key (see [DSS]) over a SHA-1 hash. o Authentication Data (variable length) - see Section 2.15. The payload type for the Authentication Payload is thirty nine (39). 3.9. Nonce Payload - The Nonce Payload, denoted Ni and Nr in this memo for the initiator's - and responder's nonce respectively, contains random data used to - guarantee liveness during an exchange and protect against replay - attacks. + The Nonce Payload, denoted Ni and Nr in this document for the + initiator's and responder's nonce respectively, contains random data + used to guarantee liveness during an exchange and protect against + replay attacks. The Nonce Payload is defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Nonce Data ~ @@ -4377,21 +4426,21 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Notification Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 16: Notify Payload Format o Protocol ID (1 octet) - If this notification concerns an existing SA whose SPI is given in the SPI field, this field indicates the - type of that SA. For notifications concerning IPsec SAs this + type of that SA. For notifications concerning Child SAs this field MUST contain either (2) to indicate AH or (3) to indicate ESP. Of the notifications defined in this document, the SPI is included only with INVALID_SELECTORS and REKEY_SA. If the SPI field is empty, this field MUST be sent as zero and MUST be ignored on receipt. o SPI Size (1 octet) - Length in octets of the SPI as defined by the IPsec protocol ID or zero if no SPI is applicable. For a notification concerning the IKE SA, the SPI Size MUST be zero and the field must be empty. @@ -4423,24 +4472,27 @@ that it does not recognize in a response MUST assume that the corresponding request has failed entirely. Unrecognized error types in a request and status types in a request or response MUST be ignored, and they should be logged. Notify payloads with status types MAY be added to any message and MUST be ignored if not recognized. They are intended to indicate capabilities, and as part of SA negotiation are used to negotiate non-cryptographic parameters. + More information on error handling can be found in Section 2.21. + The values in the following table are only current as of the - publication date of RFC 4306. Other values may have been added since - then or will be added after the publication of this document. - Readers should refer to [IKEV2IANA] for the latest values. + publication date of RFC 4306, plus two error types added in this + document. Other values may have been added since then or will be + added after the publication of this document. Readers should refer + to [IKEV2IANA] for the latest values. NOTIFY messages: error types Value ------------------------------------------------------------------- UNSUPPORTED_CRITICAL_PAYLOAD 1 See Section 2.5. INVALID_IKE_SPI 4 See Section 2.21. INVALID_MAJOR_VERSION 5 @@ -4448,43 +4500,44 @@ INVALID_SYNTAX 7 Indicates the IKE message that was received was invalid because some type, length, or value was out of range or because the request was rejected for policy reasons. To avoid a denial of service attack using forged messages, this status may only be returned for and in an encrypted packet if the message ID and cryptographic checksum were valid. To avoid leaking information to someone probing a node, this status MUST be sent in response to any error not covered by one of the other status types. - {{ Demoted the SHOULD }} To aid debugging, more detailed error - information should be written to a console or log. + To aid debugging, more detailed error information should be + written to a console or log. INVALID_MESSAGE_ID 9 See Section 2.3. INVALID_SPI 11 See Section 1.5. NO_PROPOSAL_CHOSEN 14 None of the proposed crypto suites was acceptable. This can be sent in any case where the offered proposal (including but not limited to SA payload values, USE_TRANSPORT_MODE notify, IPCOMP_SUPPORTED notify) are not acceptable for the responder. 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. INVALID_KE_PAYLOAD 17 - See Section 1.3. + See Section 1.3 and 2.7. AUTHENTICATION_FAILED 24 Sent in the response to an IKE_AUTH message when for some reason - the authentication failed. There is no associated data. + the authentication failed. There is no associated data. See also + Section 2.21.2. SINGLE_PAIR_REQUIRED 34 See Section 2.9. NO_ADDITIONAL_SAS 35 See Section 1.3. INTERNAL_ADDRESS_FAILURE 36 See Section 3.15.4. @@ -4493,21 +4546,27 @@ TS_UNACCEPTABLE 38 See Section 2.9. INVALID_SELECTORS 39 MAY be sent in an IKE INFORMATIONAL exchange when a node receives an ESP or AH packet whose selectors do not match those of the SA on which it was delivered (and that caused the packet to be dropped). The Notification Data contains the start of the offending packet (as in ICMP messages) and the SPI field of the - notification is set to match the SPI of the IPsec SA. + notification is set to match the SPI of the Child SA. + + TEMPORARY_FAILURE {TBA1} + See section 2.25. + + CHILD_SA_NOT_FOUND {TBA2} + See section 2.25. NOTIFY messages: status types Value ------------------------------------------------------------------- INITIAL_CONTACT 16384 See Section 2.4. SET_WINDOW_SIZE 16385 See Section 2.3. ADDITIONAL_TS_POSSIBLE 16386 @@ -4535,21 +4594,21 @@ See Section 1.3.3. ESP_TFC_PADDING_NOT_SUPPORTED 16394 See Section 1.3.1. NON_FIRST_FRAGMENTS_ALSO 16395 See Section 1.3.1. 3.11. Delete Payload - The Delete Payload, denoted D in this memo, contains a protocol + The Delete Payload, denoted D in this document, contains a protocol specific security association identifier that the sender has removed from its security association database and is, therefore, no longer valid. Figure 17 shows the format of the Delete Payload. It is possible to send multiple SPIs in a Delete payload; however, each SPI MUST be for the same protocol. Mixing of protocol identifiers MUST NOT be performed in the Delete payload. It is permitted, however, to include multiple Delete payloads in a single INFORMATIONAL exchange where each Delete payload lists SPIs for a different protocol. Deletion of the IKE SA is indicated by a protocol ID of 1 (IKE) but @@ -4585,39 +4644,39 @@ payload. The size of each SPI is defined by the SPI Size field. o Security Parameter Index(es) (variable length) - Identifies the specific security association(s) to delete. The length of this field is determined by the SPI Size and # of SPIs fields. The payload type for the Delete Payload is forty two (42). 3.12. Vendor ID Payload - The Vendor ID Payload, denoted V in this memo, contains a vendor + The Vendor ID Payload, denoted V in this document, contains a vendor defined constant. The constant is used by vendors to identify and recognize remote instances of their implementations. This mechanism allows a vendor to experiment with new features while maintaining backward compatibility. A Vendor ID payload MAY announce that the sender is capable of accepting certain extensions to the protocol, or it MAY simply identify the implementation as an aid in debugging. A Vendor ID payload MUST NOT change the interpretation of any information defined in this specification (i.e., the critical bit MUST be set to 0). Multiple Vendor ID payloads MAY be sent. An implementation is NOT REQUIRED to send any Vendor ID payload at all. 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 - Private USE numbers described throughout this memo-- private - payloads, private exchanges, private notifications, etc. Unfamiliar - Vendor IDs MUST be ignored. + private use numbers described throughout this document, such as + private payloads, private exchanges, private notifications, etc. + Unfamiliar Vendor IDs MUST be ignored. Writers of Internet-Drafts who wish to extend this protocol MUST define a Vendor ID payload to announce the ability to implement the extension in the Internet-Draft. It is expected that Internet-Drafts that gain acceptance and are standardized will be given "magic numbers" out of the Future Use range by IANA, and the requirement to use a Vendor ID will go away. The Vendor ID Payload fields are defined as follows: @@ -4639,24 +4698,24 @@ include a company name, a person name, or some such. If you want to show off, you might include the latitude and longitude and time where you were when you chose the ID and some random input. A message digest of a long unique string is preferable to the long unique string itself. The payload type for the Vendor ID Payload is forty three (43). 3.13. Traffic Selector Payload - The Traffic Selector Payload, denoted TS in this memo, allows peers - to identify packet flows for processing by IPsec security services. - The Traffic Selector Payload consists of the IKE generic payload - header followed by individual traffic selectors as follows: + The Traffic Selector Payload, denoted TS in this document, allows + peers to identify packet flows for processing by IPsec security + services. The Traffic Selector Payload consists of the IKE generic + payload header followed by individual traffic selectors as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of TSs | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ @@ -4682,28 +4741,28 @@ for addresses at the responder's end. There is no requirement that TSi and TSr contain the same number of individual traffic selectors. Thus, they are interpreted as follows: a packet matches a given TSi/TSr if it matches at least one of the individual selectors in TSi, and at least one of the individual selectors in TSr. For instance, the following traffic selectors: - TSi = ((17, 100, 192.0.1.66-192.0.1.66), - (17, 200, 192.0.1.66-192.0.1.66)) + TSi = ((17, 100, 198.51.100.66-198.51.100.66), + (17, 200, 198.51.100.66-198.51.100.66)) TSr = ((17, 300, 0.0.0.0-255.255.255.255), (17, 400, 0.0.0.0-255.255.255.255)) - would match UDP packets from 192.0.1.66 to anywhere, with any of the - four combinations of source/destination ports (100,300), (100,400), - (200,300), and (200, 400). + would match UDP packets from 198.51.100.66 to anywhere, with any of + the four combinations of source/destination ports (100,300), + (100,400), (200,300), and (200, 400). Thus, some types of policies may require several Child SA pairs. For instance, a policy matching only source/destination ports (100,300) and (200,400), but not the other two combinations, cannot be negotiated as a single Child SA pair. 3.13.1. Traffic Selector 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 @@ -4723,79 +4782,78 @@ Figure 20: Traffic Selector *Note: All fields other than TS Type and Selector Length depend on the TS Type. The fields shown are for TS Types 7 and 8, the only two values currently defined. o TS Type (one octet) - Specifies the type of traffic selector. o IP protocol ID (1 octet) - Value specifying an associated IP - protocol ID (e.g., UDP/TCP/ICMP). A value of zero means that the - protocol ID is not relevant to this traffic selector-- the SA can - carry all protocols. + protocol ID (such as UDP, TCP, and ICMP). A value of zero means + that the protocol ID is not relevant to this traffic selector-- + the SA can carry all protocols. o Selector Length - Specifies the length of this Traffic Selector - Substructure including the header. + substructure including the header. o Start Port (2 octets) - Value specifying the smallest port number allowed by this Traffic Selector. For protocols for which port is undefined (including protocol 0), or if all ports are allowed, - this field MUST be zero. For the ICMP protocol, the two one-octet - fields Type and Code are treated as a single 16-bit integer (with + this field MUST be zero. ICMP and ICMPv6 Type and Code values, as + well as MIPv6 MH Type values, are represented in this field as + specified in Section 4.4.1.1 of [IPSECARCH]. ICMP Type and Code + values are treated as a single 16-bit integer port number, with Type in the most significant eight bits and Code in the least - significant eight bits) port number for the purposes of filtering - based on this field. + significant eight bits. MIPv6 MH Type values are treated as a + single 16-bit integer port number, with Type in the most + significant eight bits and the least significant eight bits set to + zero. o End Port (2 octets) - Value specifying the largest port number allowed by this Traffic Selector. For protocols for which port is undefined (including protocol 0), or if all ports are allowed, - this field MUST be 65535. For the ICMP protocol, the two one- - octet fields Type and Code are treated as a single 16-bit integer - (with Type in the most significant eight bits and Code in the - least significant eight bits) port number for the purposed of - filtering based on this field. + this field MUST be 65535. ICMP and ICMPv6 Type and Code values, + as well as MIPv6 MH Type values, are represented in this field as + specified in Section 4.4.1.1 of [IPSECARCH]. ICMP Type and Code + values are treated as a single 16-bit integer port number, with + Type in the most significant eight bits and Code in the least + significant eight bits. MIPv6 MH Type values are treated as a + single 16-bit integer port number, with Type in the most + significant eight bits and the least significant eight bits set to + zero. o Starting Address - The smallest address included in this Traffic Selector (length determined by TS type). o Ending Address - The largest address included in this Traffic Selector (length determined by TS type). Systems that are complying with [IPSECARCH] that wish to indicate "ANY" ports MUST set the start port to 0 and the end port to 65535; note that according to [IPSECARCH], "ANY" includes "OPAQUE". Systems working with [IPSECARCH] that wish to indicate "OPAQUE" ports, but not "ANY" ports, MUST set the start port to 65535 and the end port to 0. - The traffic selector types 7 and 8 can also refer to ICMP type and - code fields. Note, however, that ICMP packets do not have separate - source and destination port fields. The method for specifying the - traffic selectors for ICMP is shown by example in Section 4.4.1.3 of - [IPSECARCH]. - - Traffic selectors can use IP Protocol ID 135 to match the IPv6 - mobility header [MIPV6]. This document does not specify how to - represent the "MH Type" field in traffic selectors, although it is - likely that a different document will specify this in the future. - Note that [IPSECARCH] says that the IPv6 mobility header (MH) message - type is placed in the most significant eight bits of the 16-bit local - port selector. The direction semantics of TSi/TSr port fields are - the same as for ICMP. + The traffic selector types 7 and 8 can also refer to ICMP or ICMPv6 + type and code fields, as well as MH Type fields for the IPv6 mobility + header [MIPV6]. Note, however, that neither ICMP nor MIPv6 packets + have separate source and destination fields. The method for + specifying the traffic selectors for ICMP and MIPv6 is shown by + example in Section 4.4.1.3 of [IPSECARCH]. The following table lists values for the Traffic Selector Type field and the corresponding Address Selector Data. The values in the following table are only current as of the publication date of RFC 4306. Other values may have been added since then or will be added after the publication of this document. Readers should refer to - [IKEV2IANA] for the latest values. TS Type Value ------------------------------------------------------------------- TS_IPV4_ADDR_RANGE 7 A range of IPv4 addresses, represented by two four-octet values. The first value is the beginning IPv4 address (inclusive) and the second value is the ending IPv4 address (inclusive). All addresses falling between the two specified @@ -4804,24 +4862,24 @@ TS_IPV6_ADDR_RANGE 8 A range of IPv6 addresses, represented by two sixteen-octet values. The first value is the beginning IPv6 address (inclusive) and the second value is the ending IPv6 address (inclusive). All addresses falling between the two specified addresses are considered to be within the list. 3.14. Encrypted Payload - The Encrypted Payload, denoted SK{...} or E in this memo, contains - other payloads in encrypted form. The Encrypted Payload, if present - in a message, MUST be the last payload in the message. Often, it is - the only payload in the message. + The Encrypted Payload, denoted SK{...} or E in this document, + contains other payloads in encrypted form. The Encrypted Payload, if + present in a message, MUST be the last payload in the message. + Often, it is the only payload in the message. The algorithms for encryption and integrity protection are negotiated during IKE SA setup, and the keys are computed as specified in Section 2.14 and Section 2.18. This document specifies the cryptographic processing of Encrypted payloads using a block cipher in CBC mode and an integrity check algorithm that computes a fixed-length checksum over a variable size message. The design is modeled after the ESP algorithms described in RFCs 2104 [HMAC], 4303 [ESP], and 2451 [ESPCBC]. This document @@ -4968,27 +5026,28 @@ ignored on receipt. o Attribute Type (15 bits) - A unique identifier for each of the Configuration Attribute Types. o Length (2 octets) - Length in octets of Value. o Value (0 or more octets) - The variable-length value of this 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. Other values may have been added - since then or will be added after the publication of this - document. Readers should refer to [IKEV2IANA] for the latest - values. + publication date of RFC 4306 (except INTERNAL_ADDRESS_EXPIRY and + INTERNAL_IP6_NBNS which were removed by this document). Other + values may have been added since then or will be added after the + publication of this document. Readers should refer to [IKEV2IANA] + for the latest values. - Attribute Type Value Valued Length - ------------------------------------------------------- + Attribute Type Value Multi-Valued Length + ------------------------------------------------------------ INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets INTERNAL_IP4_DNS 3 YES 0 or 4 octets INTERNAL_IP4_NBNS 4 YES 0 or 4 octets INTERNAL_IP4_DHCP 6 YES 0 or 4 octets APPLICATION_VERSION 7 NO 0 or more INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets INTERNAL_IP6_DNS 10 YES 0 or 16 octets INTERNAL_IP6_DHCP 12 YES 0 or 16 octets INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets @@ -5010,21 +5069,21 @@ MAY be requested by requesting multiple internal address attributes. The responder MAY only send up to the number of addresses requested. The INTERNAL_IP6_ADDRESS is made up of two fields: the first is a 16-octet IPv6 address, and the second is a one-octet prefix-length as defined in [ADDRIPV6]. The requested address is valid as long as this IKE SA (or its rekeyed successors) requesting the address is valid. This is described in more detail in Section 3.15.3. o INTERNAL_IP4_NETMASK - The internal network's netmask. Only one - netmask is allowed in the request and reply messages (e.g., + netmask is allowed in the request and response messages (e.g., 255.255.255.0), and it MUST be used only with an INTERNAL_IP4_ADDRESS attribute. INTERNAL_IP4_NETMASK in a CFG_REPLY means roughly the same thing as INTERNAL_IP4_SUBNET containing the same information ("send traffic to these addresses through me"), but also implies a link boundary. For instance, the client could use its own address and the netmask to calculate the broadcast address of the link. An empty INTERNAL_IP4_NETMASK attribute can be included in a CFG_REQUEST to request this information (although the gateway can send the information even when not requested). Non-empty values for this attribute in a @@ -5061,27 +5120,28 @@ response contains an attribute that contains a set of attribute identifiers each in 2 octets. The length divided by 2 (octets) would state the number of supported attributes contained in the response. o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge- device protects. This attribute is made up of two fields: the first is a 16-octet IPv6 address, and the second is a one-octet prefix-length as defined in [ADDRIPV6]. Multiple sub-networks MAY be requested. The responder MAY respond with zero or more sub- - network attributes. This is discussed in more detail in Section - 3.15.2. + network attributes. This is discussed in more detail in + Section 3.15.2. Note that no recommendations are made in this document as to how an implementation actually figures out what information to send in a - reply. That is, we do not recommend any specific method of an IRAS - determining which DNS server should be returned to a requesting IRAC. + response. That is, we do not recommend any specific method of an + IRAS determining which DNS server should be returned to a requesting + IRAC. The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to request information from its peer. If an attribute in the CFG_REQUEST Configuration Payload is not zero-length, it is taken as a suggestion for that attribute. The CFG_REPLY Configuration Payload MAY return that value, or a new one. It MAY also add new attributes and not include some requested ones. Unrecognized or unsupported attributes MUST be ignored in both requests and responses. The CFG_SET and CFG_ACK pair allows an IKE endpoint to push @@ -5091,99 +5151,99 @@ it accepted any of the configuration data and it MUST contain the attributes that the responder accepted with zero-length data. Those attributes that it did not accept MUST NOT be in the CFG_ACK Configuration Payload. If no attributes were accepted, the responder MUST return either an empty CFG_ACK payload or a response message without a CFG_ACK payload. There are currently no defined uses for the CFG_SET/CFG_ACK exchange, though they may be used in connection with extensions based on Vendor IDs. An implementation of this specification MAY ignore CFG_SET payloads. -3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET +3.15.2. Meaning of INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET INTERNAL_IP4/6_SUBNET attributes can indicate additional subnets, ones that need one or more separate SAs, that can be reached through the gateway that announces the attributes. INTERNAL_IP4/6_SUBNET attributes may also express the gateway's policy about what traffic should be sent through the gateway; the client can choose whether other traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is sent through the gateway or directly to the destination. Thus, traffic to the addresses listed in the INTERNAL_IP4/6_SUBNET attributes should be sent through the gateway that announces the - attributes. If there are no existing IPsec SAs whose traffic + attributes. If there are no existing Child SAs whose traffic selectors cover the address in question, new SAs need to be created. - For instance, if there are two subnets, 192.0.1.0/26 and + For instance, if there are two subnets, 198.51.100.0/26 and 192.0.2.0/24, and the client's request contains the following: CP(CFG_REQUEST) = INTERNAL_IP4_ADDRESS() TSi = (0, 0-65535, 0.0.0.0-255.255.255.255) TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) then a valid response could be the following (in which TSr and INTERNAL_IP4_SUBNET contain the same information): CP(CFG_REPLY) = - INTERNAL_IP4_ADDRESS(192.0.1.234) - INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) + INTERNAL_IP4_ADDRESS(198.51.100.234) + INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192) INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) - TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) - TSr = ((0, 0-65535, 192.0.1.0-192.0.1.63), + TSi = (0, 0-65535, 198.51.100.234-198.51.100.234) + TSr = ((0, 0-65535, 198.51.100.0-198.51.100.63), (0, 0-65535, 192.0.2.0-192.0.2.255)) In these cases, the INTERNAL_IP4_SUBNET does not really carry any useful information. - A different possible reply would have been this: + A different possible response would have been this: CP(CFG_REPLY) = - INTERNAL_IP4_ADDRESS(192.0.1.234) - INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) + INTERNAL_IP4_ADDRESS(198.51.100.234) + INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192) INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) - TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) + TSi = (0, 0-65535, 198.51.100.234-198.51.100.234) TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) - That reply would mean that the client can send all its traffic + That response would mean that the client can send all its traffic through the gateway, but the gateway does not mind if the client sends traffic not included by INTERNAL_IP4_SUBNET directly to the destination (without going through the gateway). A different situation arises if the gateway has a policy that requires the traffic for the two subnets to be carried in separate SAs. Then a response like this would indicate to the client that if it wants access to the second subnet, it needs to create a separate SA: CP(CFG_REPLY) = - INTERNAL_IP4_ADDRESS(192.0.1.234) - INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) + INTERNAL_IP4_ADDRESS(198.51.100.234) + INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192) INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) - TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) - TSr = (0, 0-65535, 192.0.1.0-192.0.1.63) + TSi = (0, 0-65535, 198.51.100.234-198.51.100.234) + TSr = (0, 0-65535, 198.51.100.0-198.51.100.63) INTERNAL_IP4_SUBNET can also be useful if the client's TSr included only part of the address space. For instance, if the client requests the following: CP(CFG_REQUEST) = INTERNAL_IP4_ADDRESS() TSi = (0, 0-65535, 0.0.0.0-255.255.255.255) TSr = (0, 0-65535, 192.0.2.155-192.0.2.155) - then the gateway's reply might be: + then the gateway's response might be: CP(CFG_REPLY) = - INTERNAL_IP4_ADDRESS(192.0.1.234) - INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) + INTERNAL_IP4_ADDRESS(198.51.100.234) + INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192) INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) - TSi = (0, 0-65535, 192.0.1.234-192.0.1.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) Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET is in CFG_REQUESTs is unclear, they cannot be used reliably in CFG_REQUESTs. 3.15.3. Configuration payloads for IPv6 The configuration payloads for IPv6 are based on the corresponding IPv4 payloads, and do not fully follow the "normal IPv6 way of doing @@ -5219,21 +5280,21 @@ prefix; if even that fails, the gateway selects another interface identifier. The INTERNAL_IP6_ADDRESS attribute also contains a prefix length field. When used in a CFG_REPLY, this corresponds to the INTERNAL_IP4_NETMASK attribute in the IPv4 case. Although this approach to configuring IPv6 addresses is reasonably simple, it has some limitations. IPsec tunnels configured using IKEv2 are not fully-featured "interfaces" in the IPv6 addressing - architecture sense [IPV6ADDR]. In particular, they do not + architecture sense [ADDRIPV6]. In particular, they do not necessarily have link-local addresses, and this may complicate the use of protocols that assume them, such as [MLDV2]. 3.15.4. Address Assignment Failures If the responder encounters an error while attempting to assign an IP address to the initiator during the processing of a Configuration Payload, it responds with an INTERNAL_ADDRESS_FAILURE notification. The IKE SA is still created even if the initial Child SA cannot be created because of this failure. If this error is generated within @@ -5250,28 +5311,42 @@ that the responder does not support, even though the responder supports configuration payloads. In this case, the responder simply ignores the type of address it does not support and processes the rest of the request as usual. If the initiator requests multiple addresses of a type that the responder supports, and some (but not all) of the requests fail, the responder replies with the successful addresses only. The responder sends INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned. + If the initiator does not receive the IP address(es) required by its + policy, it MAY keep the IKE SA up and retry the configuration payload + as separate INFORMATIONAL exchange after suitable timeout, or it MAY + tear down the IKE SA by sending a DELETE payload inside a separate + INFORMATIONAL exchange and later retry IKE SA from the beginning + after some timeout. Such a timeout should not be too short + (especially if the IKE SA is started from the beginning) because + these error situations may not be able to be fixed quickly; the + timeout should likely be several minutes. For example, an address + shortage problem on the responder will probably only be fixed when + more entries are returned to the address pool when other clients + disconnect or when responder is reconfigured with larger address + pool. + 3.16. Extensible Authentication Protocol (EAP) Payload The Extensible Authentication Protocol Payload, denoted EAP in this - memo, allows IKE SAs to be authenticated using the protocol defined - in RFC 3748 [EAP] and subsequent extensions to that protocol. The - full set of acceptable values for the payload is defined elsewhere, - but a short summary of RFC 3748 is included here to make this - document stand alone in the common cases. + document, allows IKE SAs to be authenticated using the protocol + defined in RFC 3748 [EAP] and subsequent extensions to that protocol. + The full set of acceptable values for the payload is defined + elsewhere, but a short summary of RFC 3748 is included here to make + this document stand alone in the common cases. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ EAP Message ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -5365,21 +5440,21 @@ in the payload header. If the critical bit is set in an unsupported payload header, all implementations MUST reject the messages containing those payloads. Every implementation MUST be capable of doing four-message IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, one for ESP or AH). Implementations MAY be initiate-only or respond- only if appropriate for their platform. Every implementation MUST be capable of responding to an INFORMATIONAL exchange, but a minimal implementation MAY respond to any INFORMATIONAL message with an empty - INFORMATIONAL reply (note that within the context of an IKE SA, an + INFORMATIONAL response (note that within the context of an IKE SA, an "empty" message consists of an IKE header followed by an Encrypted payload with no payloads contained in it). A minimal implementation MAY support the CREATE_CHILD_SA exchange only in so far as to recognize requests and reject them with a Notify payload of type NO_ADDITIONAL_SAS. A minimal implementation need not be able to initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA expires (based on locally configured values of either lifetime or octets passed), and implementation MAY either try to renew it with a CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and create a new one. If the responder rejects the CREATE_CHILD_SA @@ -5441,60 +5516,59 @@ Use of EAP authentication changes the probing possibilities somewhat. When EAP authentication is used, the responder proves its identity before the initiator does, so an initiator that knew the name of a valid initiator could probe the responder for both its name and certificates. Repeated rekeying using CREATE_CHILD_SA without additional Diffie- Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a single key or overrun of either endpoint. Implementers should take note of this fact and set a limit on CREATE_CHILD_SA exchanges - between exponentiations. This memo does not prescribe such a limit. + between exponentiations. This document does not prescribe such a + limit. The strength of a key derived from a Diffie-Hellman exchange using 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 random number generator used. Due to these inputs, it is difficult to determine the strength of a key for any of the defined groups. Diffie-Hellman group number two, when used with a strong random number generator and an exponent no less than 200 bits, is common for use with 3DES. Group five provides greater security than group two. Group one is for historic purposes only and does not provide sufficient strength except for use with DES, which is also for historic use only. Implementations should make note of these estimates when establishing policy and negotiating security parameters. Note that these limitations are on the Diffie-Hellman groups themselves. There is nothing in IKE that prohibits using stronger groups nor is there anything that will dilute the strength obtained from stronger groups (limited by the strength of the other algorithms - negotiated including the prf function). In fact, the extensible - framework of IKE encourages the definition of more groups; use of - elliptical curve groups may greatly increase strength using much - smaller numbers. + negotiated including the PRF). In fact, the extensible framework of + IKE encourages the definition of more groups; use of elliptical curve + groups may greatly increase strength using much smaller numbers. It is assumed that all Diffie-Hellman exponents are erased from memory after use. The IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator has been authenticated. As a result, an implementation of this protocol needs to be completely robust when deployed on any insecure - network. Implementation vulnerabilities, particularly denial-of- + network. Implementation vulnerabilities, particularly denial of service attacks, can be exploited by unauthenticated peers. This issue is particularly worrisome because of the unlimited number of messages in EAP-based authentication. The strength of all keys is limited by the size of the output of the - negotiated prf function. For this reason, a prf function whose - output is less than 128 bits (e.g., 3DES-CBC) MUST NOT be used with - this protocol. + negotiated PRF. For this reason, a PRF whose output is less than 128 + bits (e.g., 3DES-CBC) MUST NOT be used with this protocol. The security of this protocol is critically dependent on the randomness of the randomly chosen parameters. These should be generated by a strong random or properly seeded pseudo-random source (see [RANDOMNESS]). Implementers should take care to ensure that use of random numbers for both keys and nonces is engineered in a fashion that does not undermine the security of the keys. For information on the rationale of many of the cryptographic design choices in this protocol, see [SIGMA] and [SKEME]. Though the @@ -5541,104 +5615,108 @@ exchange, and use it to initiate an IKEv2 connection. For this reason, use of non-key-generating EAP methods SHOULD be avoided where possible. Where they are used, it is extremely important that all usages of these EAP methods SHOULD utilize a protected tunnel, where the initiator validates the responder's certificate before initiating the EAP authentication. Implementers should describe the vulnerabilities of using non-key-generating EAP methods in the documentation of their implementations so that the administrators deploying IPsec solutions are aware of these dangers. - An implementation using EAP MUST also use strong authentication of - the server to the client before the EAP authentication begins, even - if the EAP method offers mutual authentication. This avoids having - additional IKEv2 protocol variations and protects the EAP data from - active attackers. + An implementation using EAP MUST also use a public-key-based + authentication of the server to the client before the EAP + authentication begins, even if the EAP method offers mutual + authentication. This avoids having additional IKEv2 protocol + variations and protects the EAP data from active attackers. If the messages of IKEv2 are long enough that IP-level fragmentation is necessary, it is possible that attackers could prevent the exchange from completing by exhausting the reassembly buffers. The chances of this can be minimized by using the Hash and URL encodings instead of sending certificates (see Section 3.6). Additional mitigations are discussed in [DOSUDPPROT]. Admission control is critical to the security of the protocol. For example, trust anchors used for identifying IKE peers should probably be different than those used for other forms of trust, such as those used to identify public web servers. Moreover, although IKE provides a great deal of leeway in defining the security policy for a trusted peer's identity, credentials, and the correlation between them, having such security policy defined explicitly is essential to a secure implementation. 5.1. Traffic selector authorization IKEv2 relies on information in the Peer Authorization Database (PAD) - when determining what kind of IPsec SAs a peer is allowed to create. + when determining what kind of Child SAs a peer is allowed to create. This process is described in [IPSECARCH] Section 4.4.3. When a peer - requests the creation of an IPsec SA with some traffic selectors, the + requests the creation of an Child SA with some traffic selectors, the PAD must contain "Child SA Authorization Data" linking the identity authenticated by IKEv2 and the addresses permitted for traffic selectors. For example, the PAD might be configured so that authenticated - identity "sgw23.example.com" is allowed to create IPsec SAs for + identity "sgw23.example.com" is allowed to create Child SAs for 192.0.2.0/24, meaning this security gateway is a valid "representative" for these addresses. Host-to-host IPsec requires similar entries, linking, for example, "fooserver4.example.com" with - 192.0.1.66/32, meaning this identity a valid "owner" or + 198.51.100.66/32, meaning this identity a valid "owner" or "representative" of the address in question. As noted in [IPSECARCH], "It is necessary to impose these constraints on creation of child SAs to prevent an authenticated peer from spoofing IDs associated with other, legitimate peers." In the example given above, a correct configuration of the PAD prevents - sgw23 from creating IPsec SAs with address 192.0.1.66, and prevents - fooserver4 from creating IPsec SAs with addresses from 192.0.2.0/24. + sgw23 from creating Child SAs with address 198.51.100.66, and + prevents fooserver4 from creating Child SAs with addresses from + 192.0.2.0/24. It is important to note that simply sending IKEv2 packets using some - particular address does not imply a permission to create IPsec SAs + particular address does not imply a permission to create Child SAs with that address in the traffic selectors. For example, even if - sgw23 would be able to spoof its IP address as 192.0.1.66, it could - not create IPsec SAs matching fooserver4's traffic. + sgw23 would be able to spoof its IP address as 198.51.100.66, it + could not create Child SAs matching fooserver4's traffic. The IKEv2 specification does not specify how exactly IP address assignment using configuration payloads interacts with the PAD. Our interpretation is that when a security gateway assigns an address using configuration payloads, it also creates a temporary PAD entry linking the authenticated peer identity and the newly allocated inner address. It has been recognized that configuring the PAD correctly may be difficult in some environments. For instance, if IPsec is used between a pair of hosts whose addresses are allocated dynamically using DHCP, it is extremely difficult to ensure that the PAD specifies the correct "owner" for each IP address. This would require a mechanism to securely convey address assignments from the DHCP server, and link them to identities authenticated using IKEv2. Due to this limitation, some vendors have been known to configure - their PADs to allow an authenticated peer to create IPsec SAs with + their PADs to allow an authenticated peer to create Child SAs with traffic selectors containing the same address that was used for the IKEv2 packets. In environments where IP spoofing is possible (i.e., - almost everywhere) this essentially allows any peer to create IPsec + almost everywhere) this essentially allows any peer to create Child SAs with any traffic selectors. This is not an appropriate or secure configuration in most circumstances. See [H2HIPSEC] for an extensive discussion about this issue, and the limitations of host-to-host IPsec in general. 6. IANA Considerations [IKEV2] defined many field types and values. IANA has already registered those types and values in [IKEV2IANA], so the are not listed here again. + Two items are removed from the IKEv2 Configuration Payload Attribute + Types table: INTERNAL_IP6_NBNS and INTERNAL_ADDRESS_EXPIRY. + Two new additions to the IKEv2 parameters "NOTIFY MESSAGES - ERROR TYPES" registry are defined here that were not defined in [IKEV2]: {TBA1} TEMPORARY_FAILURE {TBA2} CHILD_SA_NOT_FOUND IANA should update all references to RFC 4306 to point to this document. 7. Acknowledgements @@ -5660,25 +5738,24 @@ the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI, each of which has its own list of authors. Hugh Daniel suggested the feature of having the initiator, in message 3, specify a name for the responder, and gave the feature the cute name "You Tarzan, Me Jane". David Faucher and Valery Smyslov helped refine the design of the traffic selector negotiation. This paragraph lists references that appear only in figures. The section is only here to keep the 'xml2rfc' program happy, and needs to be removed when the document is published. The RFC Editor will - remove it before publication. [AEAD] [EAI] [DES] [IDEA] [MD5] - [X.501] [X.509] [DSS] + remove it before publication. [EAI] [DES] [IDEA] [MD5] [X.501] + [X.509] [DSS] 8. References - 8.1. Normative References [ADDGROUP] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003. [ADDRIPV6] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 4291, February 2006. @@ -5827,36 +5904,32 @@ RFC 4306, December 2005. [IP-COMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 3173, September 2001. [IPSECARCH-OLD] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. - [IPV6ADDR] - Hinden, R. and S. Deering, "Internet Protocol Version 6 - (IPv6) Addressing Architecture", RFC 4291, February 2006. - [IPV6CONFIG] Eronen, et. al., P., "IPv6 Configuration in IKEv2", draft-ietf-ipsecme-ikev2-ipv6-config (work in progress), August 2009. [ISAKMP] Maughan, D., Schneider, M., and M. Schertler, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [MAILFORMAT] - Resnick, P., "Internet Message Format", RFC 2822, - April 2001. + Resnick, P., "Internet Message Format", RFC 5322, + October 2008. [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [MIPV6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [MLDV2] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. @@ -5975,21 +6048,21 @@ 9. To specify Traffic Selectors in their own payloads type rather than overloading ID payloads, and making more flexible the Traffic Selectors that may be specified; 10. To specify required behavior under certain error conditions or when data that is not understood is received in order to make it easier to make future revisions in a way that does not break backwards compatibility; 11. To simplify and clarify how shared state is maintained in the - presence of network failures and Denial of Service attacks; and + presence of network failures and denial of service attacks; and 12. To maintain existing syntax and magic numbers to the extent possible to make it likely that implementations of IKEv1 can be enhanced to support IKEv2 with minimum effort. Appendix B. Diffie-Hellman Groups There are two Diffie-Hellman groups defined here for use in IKE. These groups were generated by Richard Schroeppel at the University of Arizona. Properties of these primes are described in [OAKLEY]. @@ -6144,69 +6217,61 @@ [N(ADDITIONAL_TS_POSSIBLE)] [V+][N+] error case <-- N(error) different D-H <-- N(INVALID_KE_PAYLOAD), group wanted [V+][N+] C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA - request --> SA, Ni, [KEi] + request --> SA, Ni, KEi [V+][N+] - response <-- SA, Nr, [KEr] + response <-- SA, Nr, KEr [V+][N+] C.6. INFORMATIONAL Exchange request --> [N+], [D+], [CP(CFG_REQUEST)] response <-- [N+], [D+], [CP(CFG_REPLY)] -Appendix D. Significant Changes from RFC 4306 - - This is a placeholder that will be filled in. The WG needs to decide - what level of specificity is most useful here. For example, it might - only be changes that involve SHOULD-level or MUST-level requirements, - or it might also include additional "significant" advice that was - added. - -Appendix E. Changes Between Internet Draft Versions +Appendix D. Changes Between Internet Draft Versions This section will be removed before publication as an RFC, but should be left intact until then so that reviewers can follow what has changed. -E.1. Changes from IKEv2 to draft -00 +D.1. Changes from IKEv2 to draft -00 There were a zillion additions from RFC 4718. These are noted with "{{ Clarif-nn }}". Cleaned up many of the figures. Made the table headings consistent. Made some tables easier to read by removing blank spaces. Removed the "reserved to IANA" and "private use" text wording and moved it into the tables. Changed many SHOULD requirements to better match RFC 2119. These are also marked with comments such as "{{ Demoted the SHOULD }}". In Section 2.16, changed the MUST requirement of authenticating the responder from "public key signature based" to "strong" because that is what most current IKEv2 implementations do, and it better matches the actual security requirement. -E.2. Changes from draft -00 to draft -01 +D.2. Changes from draft -00 to draft -01 The most significant technical change was to make KE optional but strongly recommended in Section 1.3.2. Updated all references to the IKEv2 Clarifications document to RFC 4718. Moved a lot of the protocol description out of the long tables in Section 3.10.1 into the body of the document. These are noted with "{{ 3.10.1-nnnn }}", where "nnnn" is the notification type number. @@ -6298,39 +6363,39 @@ address is valid until there are no IKE SAs between the peers." In Section 3.15.1, changed "INTERNAL_IP6_NBNS" to unspecified. Made [ADDRIPV6] an informative reference instead of a normative reference and updated it. Made [PKCS1] a normative reference instead of an informative reference and changed the pointer to RFC 3447. -E.3. Changes from draft -00 to draft -01 +D.3. Changes from draft -00 to draft -01 In Section 1.5, added "request" to first sentence to make it "If an encrypted IKE request packet arrives on port 500 or 4500 with an unrecognized SPI...". In Section 3.3, fifth paragraph, upped the number of transforms for AH and ESP by one each to account for ESN, which is now mandatory. In Section 2.1, added "or equal to" in "The responder MUST remember each response until it receives a request whose sequence number is larger than or equal to the sequence number in the response plus its window size." In Section 2.18, removed " Note that this may not work if the new IKE SA's PRF has a fixed key size because the output of the PRF may not be of the correct size." because it is no longer relevant. -E.4. Changes from draft -01 to draft -02 +D.4. Changes from draft -01 to draft -02 Many grammatical fixes. In Section 1.2, reworded Clarif-4.3 to be clearer. In Section 1.3.3, reworded 3.10.1-16393 and Clarif-5.4 to remove redundant text. In Section 2.13, replaced text about variable length keys with clearer explanation and requirement on non-HMAC PRFs. Also added @@ -6368,21 +6433,21 @@ In Section 3.10, clarified 3.10.1-16394. Updated Section 6 to indicate that there is nothing new for IANA in this spec. Also removed the definition of "Expert Review" from Section 1.6 for the same reason. In Appendix A, removed "and not commit any state to an exchange until the initiator can be cryptographically authenticated" because that was only true in an earlier version of IKEv2. -E.5. Changes from draft -02 to draft -03 +D.5. Changes from draft -02 to draft -03 In Section 1.3, changed "If the responder rejects the Diffie-Hellman group of the KEi payload, the responder MUST reject the request and indicate its preferred Diffie-Hellman group in the INVALID_KE_PAYLOAD Notification payload." to "If the responder selects a proposal using a different Diffie-Hellman group (other than NONE), the responder MUST reject the request and indicate its preferred Diffie-Hellman group in the INVALID_KE_PAYLOAD Notification payload. In Section 2.3, added the last two paragraphs covering why you @@ -6437,21 +6503,21 @@ modes, and to clarify which encryption and integrity protection we are talking about. Changed the "Initialization Vector" bullet in Section 3.14 to specify better what is needed for the IV. Upgraded the SHOULDs to MUSTs. Also added the reference for [MODES]. In Section 5, in the second-to-last paragraph, changed "a public-key- based" to "strong" to match the wording in Section 2.16. -E.6. Changes from draft -03 to draft-ietf-ipsecme-ikev2bis-00 +D.6. Changes from draft -03 to draft-ietf-ipsecme-ikev2bis-00 Changed the document's filename to draft-ietf-ipsecme-ikev2bis-00. Added Yoav Nir as a co-author. In many places in the document, changed "and/or" to "or" when talking about combinations of ESP and AH SAs. For example, in the intro, it said "can be used to efficiently establish SAs for Encapsulating Security Payload (ESP) and/or Authentication Header (AH)". This is changed to "or" to indicate that you can only establish one type of SA at a time. @@ -6458,38 +6524,37 @@ In Section 1, clarified that RFC 4306 already replaced IKEv1, and that this document replaces RFC 4306. Also fixed Section 2.5 for similar issue. Also updated the Abstract to cover this. In Section 2.15, in the responder's signed octets, changed: RestOfRespIDPayload = IDType | RESERVED | InitIDData to RestOfRespIDPayload = IDType | RESERVED | RespIDData - In 2.16, changed "strong" back to "public key signature based" to make it the same as 4306. In section 3.10, added "and the field must be empty" to make it clear that a zero-length SPI is really empty. -E.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to +D.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to draft-ietf-ipsecme-ikev2bis-01 Throughout, changed "IKE_SA" to "IKE SA", and changed "CHILD_SA" to "Child SA" (except left "CREATE_CHILD_SA" alone). Added the middle sentence in the Abstract to say what IKE actually does. Added in section 1 "(unless there is failure setting up the AH or ESP - Child SA, in which case the IKE SA is still established without IPsec + Child SA, in which case the IKE SA is still established without Child SA)". Clarified the titles of 1.1.1, 1.1.2, and 1.1.3. In 1.1.2, changed "If there is an inner IP header, the inner addresses will be the same as the outer addresses." because we are talking about transport mode here. Added reference to section 2.14 to setion 1.2 and 1.3. @@ -6660,21 +6724,21 @@ most implementations to do so. Updated a bunch of reference to their newer versions. Added "[V+]" to the end of the exchanges in C.4 and C.5. Added two more response templates to Appendix C.1. Added another response template in Appendix C.2. Added two more responses in Appendix C.4. -E.8. Changes from draft-ietf-ipsecme-ikev2bis-01 to +D.8. Changes from draft-ietf-ipsecme-ikev2bis-01 to draft-ietf-ipsecme-ikev2bis-02 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 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 not be able to authenticate that message." This may be changed again in the future. [Issue #9] In section 1.3.2, changed "The KEi payload SHOULD be included" to be @@ -6760,21 +6823,21 @@ been authenticated. As a result, an implementation of this protocol needs to be completely robust when deployed on any insecure network. Implementation vulnerabilities, particularly denial-of-service attacks, can be exploited by unauthenticated peers. This issue is particularly worrisome because of the unlimited number of messages in EAP-based authentication." [Issue #62] Added new Appendix D, "Significant Changes from RFC 4306", as a placeholder for now. [Issue #3] -E.9. Changes from draft-ietf-ipsecme-ikev2bis-01 to +D.9. Changes from draft-ietf-ipsecme-ikev2bis-01 to draft-ietf-ipsecme-ikev2bis-02 Near the end of 1.3, changed "If the guess turns out to be wrong, 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 retrying the first message." to "If the responder selects a proposal using a different Diffie-Hellman group (other than NONE), 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 retrying the first message." [Issue #6] @@ -6803,63 +6867,68 @@ Changed the last bullet item in section 2.23 to discuss MOBIKE in more detail. [Issue #41] In section 3.1, the bullet about bit 4, changed "must" to "MUST". In section 3.3.6, added two sentences at the end of the second paragraph to indicate that there is an exception for when the proposal is a DH group of NONE. [Issue #6] -E.10. Changes from draft-ietf-ipsecme-ikev2bis-02 to +D.10. Changes from draft-ietf-ipsecme-ikev2bis-02 to draft-ietf-ipsecme-ikev2bis-03 In section 2.4, change "The INITIAL_CONTACT notification, if sent, MUST be in the first IKE_AUTH request, not as a separate exchange afterwards; however, receiving parties need to deal with it in other requests." to "The INITIAL_CONTACT notification, if sent, MUST be in the first IKE_AUTH request or response, not as a separate exchange - afterwards; however, receiving parties MAY ignore it in other - messages." [Issue #53] + afterwards; receiving parties MAY ignore it in other messages." + [Issue #53] Added to the security considerations: "Admission control is critical to the security of the protocol. For example, trust anchors used for identifying IKE peers should probably be different than those used for other forms of trust, such as those used to identify public web servers. Moreover, although IKE provides a great deal of leeway in defining the security policy for a trusted peer's identity, credentials, and the correlation between them, having such security policy defined explicitly is essential to a secure implementation." [Issue #61] Changed "[V+]" to "[V+][N+]" throughout Appendix C. [Issue #63] -E.11. Changes from draft-ietf-ipsecme-ikev2bis-03 to +D.11. Changes from draft-ietf-ipsecme-ikev2bis-03 to draft-ietf-ipsecme-ikev2bis-04 Throughout, removed the marks that showed where text from the Clarifications RFC was inserted, or where a "SHOULD" was demoted to weaker language. In section 1, added "IKEv2 was a change to the IKE protocol that was not backward compatible. In contrast, the current document not only provides a clarification of IKEv2, but makes minimum changes to the IKE protocol." [Issue #48] In 1.5, added "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." [Issue #35] In 1.5, added "(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.)" [Issue #13] + In 1.7, added "This document removes the allowance for rejecting + messages where the payloads were not in the "right" order; now + implementations MUST NOT reject them. This is due to the lack of + clarity where the orders for th payloads are described." + Added "The Message ID is reset to zero in the new IKE SA after the IKE SA is rekeyed" in the first paragraph of 2.2. [Issue #15] In 2.5, changed "implementations MUST send the payloads defined in this specification in the order shown in the figures in Section 2; implementations are explicitly allowed to reject as invalid a message with those payloads in any other order" to "implementations SHOULD send the payloads defined in this specification in the order shown in the figures in Section 2; implementations MUST NOT reject as invalid a message with those payloads in any other order". [Issue #16] @@ -6868,28 +6937,33 @@ In 2.9, added "Maintenance of a system's SPD is outside the scope of IKE (see [PFKEY] for an example programming interface, although it only applies to IKEv1), though some implementations might update their SPD in connection with the running of IKE (for an example scenario, see Section 1.1.3)." This was actually done in -03 but not noted in the change notes. [Issue #64] [Issue #54] In 2.18, added "using SPIi, SPIr, Ni, and Nr from the new exchange" to the last sentence. + In the last paragraph of 2.25, added "The SA that 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 + notification." + Removed INTERNAL_IP6_NBNS from 3.15.1. [Issue #44] Changed "The requested address is valid until there are no IKE_SAs between the peers" to "The requested address is valid as long as this IKE SA (or its rekeyed successors) requesting the address is valid." [Issue #43] -E.12. Changes from draft-ietf-ipsecme-ikev2bis-04 to +D.12. Changes from draft-ietf-ipsecme-ikev2bis-04 to draft-ietf-ipsecme-ikev2bis-05 Added the following near the end of 1.2: "If the failure is related to creating the IKE SA (for example, AUTHENTICATION_FAILED), the IKE SA is not created. Note that although the IKE_AUTH messages are encrypted and integrity protected, if the peer receiving this notification has not yet authenticated the other end (or if the peer fails to authenticate the other end for some reason), the information needs to be treated with caution. More precisely, assuming that the MAC verifies correctly, the sender of the error indication is known @@ -6951,21 +7025,21 @@ parts of the document. [Issue #108] Added the following to 3.15.3: "Note that there is an additional document that discusses IPv6 configuration in IKEv2, [IPV6CONFIG]. At the present time, it is an experimental document, but there is a hope that with more implementation experience, it will gain the same standards treatment as this document." [Issue #47 and Issue #60] Reworded the acknowledgements to be more inclusive. -E.13. Changes from draft-ietf-ipsecme-ikev2bis-05 to +D.13. Changes from draft-ietf-ipsecme-ikev2bis-05 to draft-ietf-ipsecme-ikev2bis-06 Many small editorial nits fixed. Changed all the tables to only list the values that were defined in RFC 4306. Removed reserved and private use ranges. Also, a pointer to the IANA registry is given repeatedly. At the end of 1.3.1, added "See Section 2.21 for a list of error messages that might occur if creating a Child SA fails." @@ -7055,20 +7131,294 @@ some text that was removed a few iterations ago. In 4, changed "If an implementation does support issuing such requests" to "If an implementation does support issuing such requests and its policy requires using temporary IP addresses". In 8 (Refereneces), changed the reference for AEAD from RFC 5116 to RFC 5282. Also added IKEV2IANA as a normative reference. Also changed the FTP URLs to the RFC Editor to HTTP references. +D.14. Changes from draft-ietf-ipsecme-ikev2bis-06 to + draft-ietf-ipsecme-ikev2bis-07 + + These changes were made during and after WG Last Call. + + Many small editorial nits fixed. + + In 1.2, added "(A man-in-the-middle who cannot complete the IKE_AUTH + exchange can nonetheless see the identity of the initiator.)" + + In the table in 1.2, added " (not a payload)" to "IKE Header" because + the other items are, in fact, payloads. Also changed "E Encrypted" + to "SK Encrypted and Authenticated". + + Removed "When an IKE SA is not created, the error message return + SHOULD NOT be encrypted because the other party will not be able to + authenticate that message." from the end of 1.3.1. [Issue #127] + + In 1.3.1, added "An IPCOMP_SUPPORTED notification, covered in + Section 2.22, can also be included in the request/response pair." + In 1.3.2, changed "New initiator and responder SPIs are supplied in + the SPI fields of the SA payload." to "A new initiator SPI is + supplied in the SPI field of the SA payload." Also added "A new + responder SPI is supplied in the SPI field of the SA payload." a few + paragraphs down. + + In 1.3.3, changed the figure for the initiator from: + + Initiator Responder + ------------------------------------------------------------------- + HDR, SK {N, SA, Ni, [KEi], + TSi, TSr} --> + + to: + + Initiator Responder + ------------------------------------------------------------------- + HDR, SK {N(REKEY_SA), SA, Ni, [KEi], + TSi, TSr} --> + + Added to 1.4: "Note that some informational messages, not exchanges, + can be sent outside the context of an IKE SA." + + In 1.5, changed "it MAY send an informational message" to "it MAY + indicate this with a Notify payload". Made a similar change in the + following paragraph. + + In 1.5, changed "If the receiving node has an active IKE SA to the IP + address from whence the packet came, it MAY send a notification of + the wayward packet over that IKE SA in an INFORMATIONAL exchange. If + it does not have such an IKE SA, it MAY indicate this with a Notify + payload without cryptographic protection to the source IP address." + to "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." + + Fixed the boilerplate wording in 1.6. + + Added and clarified materila in 1.7. Also added "Significant" to the + title of the section because it cannot list all the differences. + [Issue #126] + + In 2.1, changed "IKE is a reliable protocol, in the sense that the + initiator MUST retransmit a request until either it receives a + corresponding reply OR it deems the IKE security association to have + failed and it discards all state associated with the IKE SA and any + Child SAs negotiated using that IKE SA." to "IKE is a reliable + protocol: the initiator MUST retransmit a request until either it + receives a corresponding reply, or until it deems 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 were negotiated + using that IKE SA." + + In 2.1, removed ", and the zero non-ESP marker" because it was + confusing. + + In 2.2, rearranged the paragraphs beginning "The Message ID is a 32- + bit.." and "Throughout this document, "initiator"...". + + In 2.5, changed "implementations SHOULD send the payloads defined in + this specification in the order shown in the figures in Section 2" to + "...the figures in Sections 1 and 2". + + In 2.6, changed "Also, incorporating Ni" to "Also, incorporating + SPi". + + In 2.6, removed the paragraph that started "In addition to cookies" + because it was redundant with information in 2.7 that was stated + better. + + In 2.8, changed "It should do so if there has been no traffic since + the last time the SA was rekeyed." to "It can also do so if ..." + + In 2.8.1, changed NO_PROPOSAL_CHOSEN to CHILD_SA_NOT_FOUND in the + paragraph that starts "To B, it looks like A is trying to rekey" and + the artwork after it. + + In 2.8.2, changed "In this case, when the peer that did not notice + the simultaneous rekey gets the request to rekey the IKE SA that it + has already successfully rekeyed, it MUST return + TEMPORARY_FAILURE..." to "...it SHOULD return TEMPORARY_FAILURE...". + [Issue #131] + + In 2.9, changed "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" to "If + the initiator requests an SA because it wants to sen 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". + + In 2.9, removed "Such misconfigurations should be recorded in error + logs." [Issue #125] + In 2.9, changed the end of the paragraph that starts "It is possible + for the responder's policy..." to actually match the scenario, which + is not a triggering packet. + + In 2.9, changed the "192.0.1" example network to "198.51.100" and + removed the parenthetical comment about the old ones. Did the same + change in 3.15.2 and 5.1. + + Rewrote parts of 2.13 to make it clearer when general functions and + specific functions were being discussed. Also cleaned up + inconsistent use of "prf" and "PRF" throughout the document. + + In 2.18, added "to generate SKEYSEED" to the end of "The old and new + IKE SA...", and added "and using the new IKE SA's PRF" to the end of + the last paragraph. [Issue #121] + + At the end of 2.19, removed some redundancy and split the final + paragraph into two. + + In 2.21.2, removed "NOTE FOR WG DISCUSSION: Having other payloads in + the message is allowed but there are none suggested. One WG member + mentioned the possibility of adding a DELETE payload when the error + is sent in a separate INFORMATIONAL exchange. Do we want to allow + such additional payloads that have operational semantics?" + + In 2.23, changed "float to" to "use". + + In 2.23, changed "In the case of a mismatching + NAT_DETECTION_SOURCE_IP hash, the recipient MAY reject the connection + attempt if NAT traversal is not supported." to "In the case there is + a mismatch of the NAT_DETECTION_SOURCE_IP hash with all of the + NAT_DETECTION_SOURCE_IP payloads received, the recipient MAY reject + the connection attempt if NAT traversal is not supported." Also + removed the bullet that started "If the NAT_DETECTION_DESTINATION_IP + payload received does not match the hash of the destination IP" + because it was already covered above. + + In 2.23, removed "so this method MUST NOT be used when MOBIKE is + used" but left in the reference to section 3.8 in MOBIKE so that + readers can see what is and is not allowed. + + In 2.23.1, in the first bullet for the responder in transport mode, + changed "Store the original traffic selector IP addresses as received + source and destination address in case we need to undo address + substitution." to "Store the original traffic selector IP addresses + as received source and destination address, both in case we need to + undo address substitution, and to use as the "real source and + destination address" specified by [UDPENCAPS], and for TCP/UDP + checksum fixup." + + In 2.25, changed: "A peer that receives a CHILD_SA_NOT_FOUND + notification SHOULD silently delete the Child SA and send a request + to create a new Child SA from scratch." to "A peer that receives a + CHILD_SA_NOT_FOUND notification 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 not yet exist)." + + In the flags description in 3.1, replaced "The bits are defined LSB + first, so bit 0 would be the least significant bit of the Flags + octet. " with "The bits are as follows: + + +-+-+-+-+-+-+-+-+ + |X|X|R|V|I|X|X|X| + +-+-+-+-+-+-+-+-+ + + Also added: ""X" bits MUST be cleared when sending and MUST be + ignored on receipt." Then removed the bit positions from the + description. + + In 3.1, added "See Section 2.5 for more information on this bit" to + the end of the Critical bit description. + + In 3.2, changed "E Encrypted" to "SK Encrypted and Authenticated". + + In 3.3, fourth paragraph, changed "Combined-mode ciphers include both + integrity and encryption in a single encryption algorithm, and are + not allowed to be offered with a separate integrity algorithm other + than "none"." to "Combined-mode ciphers include both integrity and + encryption in a single encryption algorithm, and MUST either offer no + integrity algorithm or a single integrity algorithm of "none", with + no integrity algorithm being the RECOMMENDED method." Also, removed + "If an algorithm that combines encryption and integrity protection is + proposed, it MUST be proposed as an encryption algorithm and an + integrity protection algorithm MUST NOT be proposed" from the + following paragraph. [Issue #122] + + In 3.3.6, moved the last sentence from the second paragraph and moved + it to third paragraph. It now reads "If one of the proposals offered + is for the Diffie-Hellman group of NONE, the responder MUST ignore + the initiator's KE payload and omit the KE payload from the + response." + + In 3.4, added "See also Section 1.2 and Section 2.7." + + In 3.6, changed "Certificate payloads SHOULD be included in an + exchange if certificates are available to the sender unless the peer + has indicated an ability to retrieve this information from elsewhere + using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload." to "Certificate + payloads SHOULD be included in an exchange if certificates are + available to the sender. The Hash and URL formats of the Certificate + payloads should be used in case the peer has indicated an ability to + retrieve this information from elsewhere using an + HTTP_CERT_LOOKUP_SUPPORTED Notify payload." + + In 3.10.1, added "More information on error handling can be found in + Section 2.21." + + Added TEMPORARY_FAILURE and CHILD_SA_NOT_FOUND to the table in + 3.10.1. + + Replaced the Start Port and End Port discussions in 3.13.1 with ones + that describe the ICMP and ICMPv6 in more detail. Also replaced the + two paragraphs starting "The traffic selector types 7..." and + "Traffic selectors can use" with "he traffic selector types 7 and 8 + can also refer to ICMP or ICMPv6 type and code fields, as well as MH + Type fields for the IPv6 mobility header [MIPV6]. Note, however, + that neither ICMP nor MIPv6 packets have separate source and + destination fields. The method for specifying the traffic selectors + for ICMP and MIPv6 is shown by example in Section 4.4.1.3 of + [IPSECARCH]". [Issue #129] + + In 3.15.1, made the table heading "Multi-Valued" instead of "Valued". + + In 3.15.1, added "(except INTERNAL_ADDRESS_EXPIRY and + INTERNAL_IP6_NBNS which were removed by this document)" to the bullet + point for "Value" because those two were removed from the table. + + Added new paragraph at the end of 3.15.4 to suggest what the + initiator should do if they don't get enough addresses. [Issue #124] + + In 5, changed "An implementation using EAP MUST also use strong + authentication" back to "An implementation using EAP MUST also use a + public-key-based authentication" soas not to change mandatory + requirements from RFC 4306. + + Added to section 6: "Two items are removed from the IKEv2 + Configuration Payload Attribute Types table: INTERNAL_IP6_NBNS and + INTERNAL_ADDRESS_EXPIRY." + + Removed Appendix C, "Significant Changes from RFC 4306", because this + information is actually going in section 1.7. + + In C.5, changed the figure from: + + request --> SA, Ni, [KEi] + [V+][N+] + + response <-- SA, Nr, [KEr] + [V+][N+] + + to + + request --> SA, Ni, KEi + [V+][N+] + + response <-- SA, Nr, KEr + [V+][N+] + Authors' Addresses Charlie Kaufman Microsoft 1 Microsoft Way Redmond, WA 98052 US Phone: 1-425-707-3335 Email: charliek@microsoft.com