--- 1/draft-ietf-ipsecme-ikev2bis-07.txt 2010-03-01 19:11:13.000000000 +0100 +++ 2/draft-ietf-ipsecme-ikev2bis-08.txt 2010-03-01 19:11:13.000000000 +0100 @@ -1,23 +1,23 @@ Network Working Group C. Kaufman Internet-Draft Microsoft Obsoletes: 4306, 4718 P. Hoffman (if approved) VPN Consortium Intended status: Standards Track Y. Nir -Expires: July 24, 2010 Check Point +Expires: August 30, 2010 Check Point P. Eronen Nokia - January 20, 2010 + February 26, 2010 Internet Key Exchange Protocol: IKEv2 - draft-ietf-ipsecme-ikev2bis-07 + draft-ietf-ipsecme-ikev2bis-08 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). This document replaces and updates RFC 4306, and includes all of the clarifications from RFC 4718. Status of this Memo @@ -34,21 +34,21 @@ 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 July 24, 2010. + This Internet-Draft will expire on August 30, 2010. Copyright Notice 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 @@ -65,152 +65,154 @@ modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 - 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 6 - 1.1.1. Security Gateway to Security Gateway Tunnel Mode . . 7 - 1.1.2. Endpoint-to-Endpoint Transport Mode . . . . . . . . . 7 - 1.1.3. Endpoint to Security Gateway Tunnel Mode . . . . . . 8 - 1.1.4. Other Scenarios . . . . . . . . . . . . . . . . . . . 9 - 1.2. The Initial Exchanges . . . . . . . . . . . . . . . . . . 9 - 1.3. The CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 12 + 1. Introduction + 1.1. Usage Scenarios + 1.1.1. Security Gateway to Security Gateway Tunnel Mode + 1.1.2. Endpoint-to-Endpoint Transport Mode + 1.1.3. Endpoint to Security Gateway Tunnel Mode + 1.1.4. Other Scenarios + 1.2. The Initial Exchanges + 1.3. The CREATE_CHILD_SA Exchange 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 + Exchange + 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange 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 + Exchange + 1.4. The INFORMATIONAL Exchange + 1.4.1. Deleting an SA with INFORMATIONAL Exchanges + 1.5. Informational Messages outside of an IKE SA + 1.6. Requirements Terminology 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 - 3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 79 - 3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 79 - 3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 80 - 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 . . . . . . . . . . . . . . . . . . . . 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 + Document + 2. IKE Protocol Details and Variations + 2.1. Use of Retransmission Timers + 2.2. Use of Sequence Numbers for Message ID + 2.3. Window Size for Overlapping Requests + 2.4. State Synchronization and Connection Timeouts + 2.5. Version Numbers and Forward Compatibility + 2.6. IKE SA SPIs and Cookies + 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD + 2.7. Cryptographic Algorithm Negotiation + 2.8. Rekeying + 2.8.1. Simultaneous Child SA rekeying + 2.8.2. Simultaneous IKE SA Rekeying + 2.8.3. Rekeying the IKE SA Versus Reauthentication + 2.9. Traffic Selector Negotiation + 2.9.1. Traffic Selectors Violating Own Policy + 2.10. Nonces + 2.11. Address and Port Agility + 2.12. Reuse of Diffie-Hellman Exponentials + 2.13. Generating Keying Material + 2.14. Generating Keying Material for the IKE SA + 2.15. Authentication of the IKE SA + 2.16. Extensible Authentication Protocol Methods + 2.17. Generating Keying Material for Child SAs + 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange + 2.19. Requesting an Internal Address on a Remote Network + 2.20. Requesting the Peer's Version + 2.21. Error Handling + 2.21.1. Error Handling in IKE_SA_INIT + 2.21.2. Error Handling in IKE_AUTH + 2.21.3. Error Handling after IKE SA is Authenticated + 2.21.4. Error Handling Outside IKE SA + 2.22. IPComp + 2.23. NAT Traversal + 2.23.1. Transport Mode NAT Traversal + 2.24. Explicit Congestion Notification (ECN) + 2.25. Exchange Collisions + 2.25.1. Collisions While Rekeying or Closing Child SAs + 2.25.2. Collisions While Rekeying or Closing IKE SAs + 3. Header and Payload Formats + 3.1. The IKE Header + 3.2. Generic Payload Header + 3.3. Security Association Payload + 3.3.1. Proposal Substructure + 3.3.2. Transform Substructure + 3.3.3. Valid Transform Types by Protocol + 3.3.4. Mandatory Transform IDs + 3.3.5. Transform Attributes + 3.3.6. Attribute Negotiation + 3.4. Key Exchange Payload + 3.5. Identification Payloads + 3.6. Certificate Payload + 3.7. Certificate Request Payload + 3.8. Authentication Payload + 3.9. Nonce Payload + 3.10. Notify Payload + 3.10.1. Notify Message Types + 3.11. Delete Payload + 3.12. Vendor ID Payload + 3.13. Traffic Selector Payload + 3.13.1. Traffic Selector + 3.14. Encrypted Payload + 3.15. Configuration Payload + 3.15.1. Configuration Attributes 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 . . . . 113 - 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 114 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 116 - 5.1. Traffic selector authorization . . . . . . . . . . . . . 119 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 120 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 121 - 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 . . . . . . . . . . . . . . . . . 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 + INTERNAL_IP6_SUBNET + 3.15.3. Configuration payloads for IPv6 + 3.15.4. Address Assignment Failures + 3.16. Extensible Authentication Protocol (EAP) Payload + 4. Conformance Requirements + 5. Security Considerations + 5.1. Traffic selector authorization + 6. IANA Considerations + 7. Acknowledgements + 8. References + 8.1. Normative References + 8.2. Informative References + Appendix A. Summary of changes from IKEv1 + Appendix B. Diffie-Hellman Groups + B.1. Group 1 - 768 Bit MODP + B.2. Group 2 - 1024 Bit MODP + Appendix C. Exchanges and Payloads + C.1. IKE_SA_INIT Exchange + C.2. IKE_AUTH Exchange without EAP + C.3. IKE_AUTH Exchange with EAP 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. 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 + Child SAs + C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA + C.6. INFORMATIONAL Exchange + Appendix D. Changes Between Internet Draft Versions + D.1. Changes from IKEv2 to draft -00 + D.2. Changes from draft -00 to draft -01 + D.3. Changes from draft -00 to draft -01 + D.4. Changes from draft -01 to draft -02 + D.5. Changes from draft -02 to draft -03 D.6. Changes from draft -03 to - draft-ietf-ipsecme-ikev2bis-00 . . . . . . . . . . . . . 138 + draft-ietf-ipsecme-ikev2bis-00 D.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to - draft-ietf-ipsecme-ikev2bis-01 . . . . . . . . . . . . . 139 + draft-ietf-ipsecme-ikev2bis-01 D.8. Changes from draft-ietf-ipsecme-ikev2bis-01 to - draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 143 + draft-ietf-ipsecme-ikev2bis-02 D.9. Changes from draft-ietf-ipsecme-ikev2bis-01 to - draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 145 + draft-ietf-ipsecme-ikev2bis-02 D.10. Changes from draft-ietf-ipsecme-ikev2bis-02 to - draft-ietf-ipsecme-ikev2bis-03 . . . . . . . . . . . . . 146 + draft-ietf-ipsecme-ikev2bis-03 D.11. Changes from draft-ietf-ipsecme-ikev2bis-03 to - draft-ietf-ipsecme-ikev2bis-04 . . . . . . . . . . . . . 146 + draft-ietf-ipsecme-ikev2bis-04 D.12. Changes from draft-ietf-ipsecme-ikev2bis-04 to - draft-ietf-ipsecme-ikev2bis-05 . . . . . . . . . . . . . 147 + draft-ietf-ipsecme-ikev2bis-05 D.13. Changes from draft-ietf-ipsecme-ikev2bis-05 to - draft-ietf-ipsecme-ikev2bis-06 . . . . . . . . . . . . . 149 + draft-ietf-ipsecme-ikev2bis-06 D.14. Changes from draft-ietf-ipsecme-ikev2bis-06 to - draft-ietf-ipsecme-ikev2bis-07 . . . . . . . . . . . . . 151 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 157 + draft-ietf-ipsecme-ikev2bis-07 + D.15. Changes from draft-ietf-ipsecme-ikev2bis-07 to + draft-ietf-ipsecme-ikev2bis-08 + Authors' Addresses 1. Introduction 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. @@ -521,22 +523,35 @@ SAr2, TSi, TSr} The responder asserts its identity with the IDr payload, optionally sends one or more certificates (again with the certificate containing the public key used to verify AUTH listed first), authenticates its identity and protects the integrity of the second message with the AUTH payload, and completes negotiation of a Child SA with the additional fields described below in the CREATE_CHILD_SA exchange. The recipients of messages 3 and 4 MUST verify that all signatures - and MACs are computed correctly and that the names in the ID payloads - correspond to the keys used to generate the AUTH payload. + and MACs are computed correctly. If either side uses a shared secret + for authentication, the names in the ID payload MUST correspond to + the key used to generate the AUTH payload. + + Because the initiator sends its Diffie-Hellman value in the + IKE_SA_INIT, it must guess the Diffie-Hellman group that the + responder will select from its list of supported groups. If the + initiator guesses wrong, the responder will respond with a Notify + payload of type INVALID_KE_PAYLOAD indicating the selected group. In + this case, the initiator MUST retry the IKE_SA_INIT with the + corrected Diffie-Hellman group. The initiator MUST again propose its + full set of acceptable cryptographic suites because the rejection + message was unauthenticated and otherwise an active attacker could + trick the endpoints into negotiating a weaker suite than a stronger + one that they both prefer. If creating the Child SA during the IKE_AUTH exchange fails for some reason, the IKE SA is still created as usual. The list of responses in the IKE_AUTH exchange that do not prevent an IKE SA from being set up include at least the following: NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED. If the failure is related to creating the IKE SA (for example, AUTHENTICATION_FAILED), the IKE SA is not created. Note that @@ -603,21 +618,22 @@ reject the request and indicate its preferred Diffie-Hellman group in 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 + unwilling to accept any more Child SAs on this IKE SA. This notify + can also be used to reject IKE SA rekey. Some minimal implementations may only accept a single Child SA setup in the context of an initial IKE exchange and reject any subsequent attempts to add more. 1.3.1. Creating New Child SAs with the CREATE_CHILD_SA Exchange A Child SA may be created by sending a CREATE_CHILD_SA request. The CREATE_CHILD_SA request for creating a new Child SA is: Initiator Responder @@ -704,34 +720,41 @@ 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. + Section 2.18 also covers IKE SA rekeying in detail. + 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(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 notifications described in Section 1.3.1 may also be sent in a + rekeying exchange. Usually these will be the same notifications that + were used in the original exchange; for example, when rekeying a + transport mode SA, the USE_TRANSPORT_MODE notification will be used. + The REKEY_SA notification MUST be included in a CREATE_CHILD_SA 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 Notify payload; this is the SPI the exchange initiator would expect in inbound ESP or AH packets. There is no data associated with this Notify type. The Protocol ID field of the REKEY_SA notification is set to match the protocol of the SA we are rekeying, for example, 3 for ESP and 2 for AH. The CREATE_CHILD_SA response for rekeying a Child SA is: @@ -804,74 +827,81 @@ 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. + Similar to ESP and AH SAs, IKE SAs are also deleted by sending an + Informational exchange. Deleting an IKE SA implicitly closes any + remaining Child SAs negotiated under it. The response to a request + that deletes the IKE SA is an empty INFORMATIONAL response. + Half-closed ESP or AH connections are anomalous, and a node with 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. + the IKE SA, as described above. It can then rebuild the SAs it needs + on a clean base under a new IKE SA. 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 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. + There are some cases in which a node receives a packet that it cannot + process, but it may want to notify the sender about this situation. - 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 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. + o If an ESP or AH packet arrives with an unrecognized SPI. This + might be due to the receiving node having recently crashed and + lost state, or because of some other system malfunction or attack. - 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 - 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.) + o If an encrypted IKE request packet arrives on port 500 or 4500 + with an unrecognized IKE SPI. This might be due to the receiving + node having recently crashed and lost state, or because of some + other system malfunction or attack. - 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, - the responder SHOULD copy the Exchange Type from the request. + o If an IKE request packet arrives with a higher major version + number than the implementation supports. - In case of INVALID_SPI, however, there are no IKE SPI values that - would be meaningful to the recipient of such a notification. Using - zero values or random values are both acceptable. The Initiator flag - is set, the Response bit is set to 0, and the version flags are set + In the first case, if the receiving node has an active IKE SA to the + IP address from whence the packet came, it MAY send an INVALID_SPI + notification of the wayward packet over that IKE SA in an + INFORMATIONAL exchange. The Notification Data contains the SPI of + the invalid packet. The recipient of this notification cannot tell + whether the SPI is for AH or ESP, but this is not important because + the SPIs are supposed to be different for the two. If no suitable + IKE SA exists, the node MAY send an informational message without + cryptographic protection to the source IP address, using the source + UDP port as the destination port if the packet was UDP (UDP- + encapsulated ESP or AH). In this case, it should only be used by the + recipient as a hint that something might be wrong (because it could + easily be forged). This message is not part of an INFORMATIONAL + exchange, and the receiving node MUST NOT respond to it because doing + so could cause a message loop. The message is constructed as + follows: there are no IKE SPI values that would be meaningful to the + recipient of such a notification; using zero values or random values + are both acceptable, this being the exception to the rule in + Section 3.1 that prohibits zero IKE Initiator SPIs. The Initiator + flag is set, the Response bit is set to 0, and the version flags are + set in the normal fashion. + + In the second and third cases, the message is always sent without + cryptographic protection (outside of an IKE SA), and includes either + an INVALID_IKE_SPI or an INVALID_MAJOR_VERSION notification (with no + notification data). The message is a response message, and thus it + is sent to the IP address and port from whence it came with the same + IKE SPIs and the Message ID and Exchange Type are copied from the + request. The Response bit is set to 1, and the version flags are set in the normal fashion. 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. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", @@ -939,24 +969,24 @@ 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 + "The KEi payload MUST be included". This also led to changes in section 2.18. - In Section 2.3, there is new material covering how the initiator's + In Section 2.1, there is new material covering how the initiator's SPI and/or IP is used to differentiate if this is a "half-open" IKE 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". @@ -971,20 +1001,24 @@ 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. + Section 2.23 clarified that, in NAT traversal, now both UDP + encapsulated IPsec packets and non-UDP encapsulated IPsec packets + packets need to be understood when receiving. + Added Section 2.23.1 to describe NAT traversal when transport mode is requested. All of Section 2.25 was added to explain how to act when there are timing collisions when deleting and/or rekeying SAs, and two new 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 @@ -1045,30 +1079,30 @@ initiate requests at any time, and there can be many requests and responses "in flight" at any given moment. But each message is labeled as either a request or a response, and for each request/ response pair one end of the security association is the initiator and the other is the responder. 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 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). + request except insofar as it causes 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 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: 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. @@ -1081,20 +1115,28 @@ 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). It is not sufficient to use the initiator's SPI and/or IP address to differentiate between these three cases because two different peers behind a single NAT could choose the same initiator SPI. Instead, a robust responder will do the IKE SA lookup using the whole packet, its hash, or the Ni payload. + The retransmission policy for one-way messages is somewhat different + from that for regular messages. Because no acknowledgement is ever + sent, there is no reason to gratuitously retransmit one-way messages. + Given that all these messages are errors, it makes sense to send them + only once per "offending" packet, and only retransmit if further + offending packets are received. Still, it also makes sense to limit + retransmissions of such error messages. + 2.2. Use of Sequence Numbers for Message ID 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. Thus, the first pair of IKE_AUTH messages @@ -1362,32 +1403,26 @@ 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 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 - and IKEv2, although in IKEv2 they are referred to as the "IKE SPI" - and there is a new separate field in a Notify payload holding the - cookie. The initial two eight-octet fields in the header are used as - a connection identifier at the beginning of IKE packets. Each - endpoint chooses one of the two SPIs and MUST choose them so as to be - unique identifiers of an IKE SA. An SPI value of zero is special and - indicates that the remote SPI value is not yet known by the sender. + The initial two eight-octet fields in the header, called the "IKE + SPIs", are used as a connection identifier at the beginning of IKE + packets. Each endpoint chooses one of the two SPIs and MUST choose + them so as to be unique identifiers of an IKE SA. An SPI value of + zero is special: it indicates that the remote SPI value is not yet + known by the sender. Incoming IKE packets are mapped to an IKE SA only using the packet's SPI, not using (for example) the source IP address of the packet. Unlike ESP and AH where only the recipient's SPI appears in the header of a message, in IKE the sender's SPI is also sent in every message. Since the SPI chosen by the original initiator of the IKE SA is always sent first, an endpoint with multiple IKE SAs open that wants to find the appropriate IKE SA using the SPI it assigned must look at the I(nitiator) Flag bit in the header to determine whether @@ -1452,21 +1487,21 @@ 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 SPi in the hash prevents an + forge a message 3. Also, incorporating SPIi in the hash prevents an attacker from fetching one cookie from the other end, and then 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 @@ -1477,41 +1512,50 @@ protection. The responder should change the value of frequently, especially if under attack. 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 + forged cookie replies will cause two packets: one packet from the initiator to the responder (which will reject those cookies), and one response from responder to initiator that includes the correct cookie. + A note on terminology: the term "cookies" originates with Karn and + Simpson [PHOTURIS] in Photuris, an early proposal for key management + with IPsec, and it has persisted. The Internet Security Association + and Key Management Protocol (ISAKMP) [ISAKMP] fixed message header + includes two eight-octet fields called "cookies", and that syntax is + used by both IKEv1 and IKEv2, although in IKEv2 they are referred to + as the "IKE SPI" and there is a new separate field in a Notify + payload holding the cookie. + 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD 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. If the initiator includes the cookie only in the next retry, one additional roundtrip may be needed in some cases. An additional roundtrip is needed also if the initiator includes the cookie in all retries, but the responder does not support this. For instance, if - the responder includes the SAi1 and KEi payloads in cookie - calculation, it will reject the request by sending a new cookie. + the responder includes the KEi payloads in cookie calculation, it + will reject the request by sending a new cookie. If both peers support including the cookie in all retries, a slightly shorter exchange can happen. Initiator Responder ----------------------------------------------------------- HDR(A,0), SAi1, KEi, Ni --> <-- HDR(A,0), N(COOKIE) HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> <-- HDR(A,0), N(INVALID_KE_PAYLOAD) @@ -1555,32 +1599,20 @@ combinations are acceptable. If an initiator proposes both normal ciphers with integrity protection as well as combined-mode ciphers, then two proposals are needed. One of the proposals includes the normal ciphers with the integrity algoritms for them, and the other proposal includes all the combined mode ciphers without the integrity algorithms (because combined mode ciphers are not allowed to have any integrity algorithm other than "none"). - Since the initiator sends its Diffie-Hellman value in the - IKE_SA_INIT, it must guess the Diffie-Hellman group that the - responder will select from its list of supported groups. If the - initiator guesses wrong, the responder will respond with a Notify - payload of type INVALID_KE_PAYLOAD indicating the selected group. In - this case, the initiator MUST retry the IKE_SA_INIT with the - corrected Diffie-Hellman group. The initiator MUST again propose its - full set of acceptable cryptographic suites because the rejection - message was unauthenticated and otherwise an active attacker could - trick the endpoints into negotiating a weaker suite than a stronger - one that they both prefer. - When the IKE_SA_INIT exchange does not result in the creation of an IKE SA due to INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN, or COOKIE (see Section 2.6), the responder's SPI will be zero. However, if the responder sends a non-zero responder SPI, the initiator should not reject the response for only that reason. 2.8. Rekeying IKE, ESP, and AH security associations use secret keys that should be used only for a limited amount of time and to protect a limited @@ -1654,32 +1685,32 @@ the responder to know when it is OK to send on the newly created SA? From a technical correctness and interoperability perspective, the responder MAY begin sending on an SA as soon as it sends its response to the CREATE_CHILD_SA request. In some situations, however, this could result in packets unnecessarily being dropped, so an implementation MAY defer such sending. The responder can be assured that the initiator is prepared to receive messages on an SA if either (1) it has received a - cryptographically valid message on the new SA, or (2) the new SA - rekeys an existing SA and it receives an IKE request to close the - replaced SA. When rekeying an SA, the responder continues to send - traffic on the old SA until one of those events occurs. When - establishing a new SA, the responder MAY defer sending messages on a - new SA until either it receives one or a timeout has occurred. If an - initiator receives a message on an SA for which it has not received a - response to its CREATE_CHILD_SA request, it interprets that as a - likely packet loss and retransmits the CREATE_CHILD_SA request. An - initiator MAY send a dummy message on a newly created SA if it has no - messages queued in order to assure the responder that the initiator - is ready to receive messages. + cryptographically valid message on the other half of the SA pair, or + (2) the new SA rekeys an existing SA and it receives an IKE request + to close the replaced SA. When rekeying an SA, the responder + continues to send traffic on the old SA until one of those events + occurs. When establishing a new SA, the responder MAY defer sending + messages on a new SA until either it receives one or a timeout has + occurred. If an initiator receives a message on an SA for which it + has not received a response to its CREATE_CHILD_SA request, it + interprets that as a likely packet loss and retransmits the + CREATE_CHILD_SA request. An initiator MAY send a dummy ESP message + on a newly created ESP SA if it has no messages queued in order to + assure the responder that the initiator is ready to receive messages. 2.8.1. Simultaneous Child SA rekeying If the two ends have the same lifetime policies, it is possible that both will initiate a rekeying at the same time (which will result in redundant SAs). To reduce the probability of this happening, the timing of rekeying requests SHOULD be jittered (delayed by a random amount of time after the need for rekeying is noticed). This form of rekeying may temporarily result in multiple similar SAs @@ -1777,58 +1808,67 @@ 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 Child SAs are inherited by the correct 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. + SAs. The new IKE SA containing the lowest nonce SHOULD be deleted by + the node that created it, and the other suriving new IKE SA MUST + inherit all the Child SAs. - 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 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. + In addition to normal simultaneous rekeying cases, there is a special + case where one peer finishes its rekey before it even notices that + other peer is doing a rekey. 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 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. 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 At this point, host B sees a request to close the IKE_SA. There's not much more to do than to reply as usual. However, at this point host B should stop retransmitting req2, since once host A receives resp3, it will delete all the state associated with the old IKE_SA and will not be able to reply to it. <-- send resp3: () + Support of the TEMPORARY_FAILURE notification is not negotiated, so + older peers may receive these notifications. In that case, they will + treat it the same as any other unknown error notification, and will + stop the exchange. Because the other peer has already rekeyed the + exchange, doing so does not have any ill effects. + 2.8.3. Rekeying the IKE SA Versus Reauthentication Rekeying the IKE SA and reauthentication are different concepts in IKEv2. Rekeying the IKE SA establishes new keys for the IKE SA and resets the Message ID counters, but it does not authenticate the parties again (no AUTH or EAP payloads are involved). Although rekeying the IKE SA may be important in some environments, reauthentication (the verification that the parties still have access to the long-term credentials) is often more important. @@ -1898,37 +1938,38 @@ 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 + ignores that traffic selector, so that the unknown type is not returned in the narrowed set. - 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. + 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 (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. @@ -2162,21 +2203,22 @@ (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr are taken in order from the generated bits of the prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman exchange. g^ir is represented as a string of octets in big endian order padded with zeros if necessary to make it the length of the modulus. Ni and Nr are the nonces, stripped of any headers. For historical backwards-compatibility reasons, there are two PRFs that are treated specially in this calculation. If the negotiated PRF is AES-XCBC-PRF-128 [AESXCBCPRF128] or AES-CMAC-PRF-128 [AESCMACPRF128], only the first 64 bits of Ni and the first 64 bits of Nr are used in - the calculation. + calculating SKEYSEED, but all the bits are used for input to the prf+ + function. The two directions of traffic flow use different keys. The keys used to protect messages from the original initiator are SK_ai and SK_ei. The keys used to protect messages in the other direction are SK_ar and SK_er. 2.15. Authentication of the IKE SA When not using extensible authentication (see Section 2.16), the peers are authenticated by having each sign (or MAC using a padded @@ -2269,20 +2311,27 @@ protocols other than IKEv2. As noted above, deriving the shared secret from a password is not secure. This construction is used because it is anticipated that people will do it anyway. The management interface by which the Shared Secret is provided MUST accept ASCII strings of at least 64 octets and MUST NOT add a null terminator before using them as shared secrets. It MUST also accept a hex encoding of the Shared Secret. The management interface MAY accept other encodings if the algorithm for translating the encoding to a binary string is specified. + There are two types of EAP authentication (described in + Section 2.16), and each type uses different values in the AUTH + computations shown above. If the EAP method is key-generating, + substitute MSK for the Shared Secret in the computation. For non- + key-generating methods, substitute SK_pi and SK_pr, respectively, for + the Shared Secret in the two AUTH computations. + 2.16. Extensible Authentication Protocol Methods 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 @@ -2356,22 +2405,23 @@ included in the two messages following the one containing the EAP Success message. When the initiator authentication uses EAP, it is possible that the contents of the IDi payload is used only for AAA routing purposes and selecting which EAP method to use. This value may be different from the identity authenticated by the EAP method. It is important that policy lookups and access control decisions use the actual authenticated identity. Often the EAP server is implemented in a separate AAA server that communicates with the IKEv2 responder. In - this case, the authenticated identity has to be sent from the AAA - server to the IKEv2 responder. + this case, the authenticated identity, if different from that in the + IDi payload, has to be sent from the AAA server to the IKEv2 + responder. 2.17. Generating Keying Material for Child SAs A single Child SA is created by the IKE_AUTH exchange, and additional Child SAs can optionally be created in CREATE_CHILD_SA exchanges. Keying material for them is generated as follows: KEYMAT = prf+(SK_d, Ni | Nr) Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this @@ -2381,51 +2431,57 @@ For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman exchange, the keying material is defined as: KEYMAT = prf+(SK_d, 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 in the high-order bits if necessary to make it the length of the modulus). - For ESP and AH, a single Child SA negotiation results in two security - associations (one in each direction). Keying material MUST be taken - from the expanded KEYMAT in the following order: - - o The encryption key (if any) for the SA carrying data from the - initiator to the responder. + A single CHILD_SA negotiation may result in multiple security + associations. ESP and AH SAs exist in pairs (one in each direction), + so two SAs are created in a single Child SA negotiation for them. + Furthermore, Child SA negotiation may include some future IPsec + protocol(s) in addition to, or instead of, ESP or AH (for example, + ROHC_INTEG). In any case, keying material for each child SA MUST be + taken from the expanded KEYMAT using the following rules: - o The authentication key (if any) for the SA carrying data from the - initiator to the responder. + o All keys for SAs carrying data from the initiator to the responder + are taken before SAs going from the responder to the initiator. - o The encryption key (if any) for the SA carrying data from the - responder to the initiator. + o If multiple IPsec protocols are negotiated, keying material for + each Child SA is taken in the order in which the protocol headers + will appear in the encapsulated packet. - o The authentication key (if any) for the SA carrying data from the - responder to the initiator. + o If an IPsec protocol requires multiple keys, the order in which + they are taken from the SA's keying material needs to be described + in protocol specification. For ESP and AH, [IPSECARCH] defines + the order, namely: the encryption key (if any) MUST be taken from + the first bits and the integrity key (if any) MUST be taken from + the remaining bits. Each cryptographic algorithm takes a fixed number of bits of keying material specified as part of the algorithm, or negotiated in SA payloads (see Section 2.13 for description of key lengths, and Section 3.3.5 for the definition of the Key Length transform attribute). 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange The CREATE_CHILD_SA exchange can be used to rekey an existing IKE SA - (see Section 2.8). New initiator and responder SPIs are supplied in - the SPI fields in the Proposal structures inside the Security - Association (SA) payloads (not the SPI fields in the IKE header). - The TS payloads are omitted when rekeying an IKE SA. SKEYSEED for - the new IKE SA is computed using SK_d from the existing IKE SA as - follows: + (see and Section 1.3.2 and Section 2.8). New initiator and responder + SPIs are supplied in the SPI fields in the Proposal structures inside + the Security Association (SA) payloads (not the SPI fields in the IKE + header). The TS payloads are omitted when rekeying an IKE SA. + SKEYSEED for the new IKE SA is computed using SK_d from the existing + IKE SA as follows: 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 @@ -2512,21 +2568,21 @@ 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 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 + is not fatal to the IKE SA; it simply causes the Child SA creation to fail. The initiator can fix this by later starting a new 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. @@ -2557,25 +2613,27 @@ indicating the error. The decision whether or not to send such a response depends whether or not there is an authenticated IKE SA. If there is an error parsing or processing a response packet, the general rule is to not send back any error message because responses should not generate new requests (and a new request would be the only way to send back an error message). Such errors in parsing or processing response packets should still cause the recipient to clean up the IKE state (for example, by sending a DELETE for a bad SA). - Only authentication failures (AUTHENTICATION_FAILED) and malformed - messages (INVALID_SYNTAX) lead to a deletion of the IKE SA without - requiring an explicit INFORMATIONAL exchange carrying a DELETE - payload. Other error conditions MAY require such an exchange if - policy dictates that this is needed. + Only authentication failures (AUTHENTICATION_FAILED and EAP failure) + and malformed messages (INVALID_SYNTAX) lead to a deletion of the IKE + SA without requiring an explicit INFORMATIONAL exchange carrying a + DELETE payload. Other error conditions MAY require such an exchange + if policy dictates that this is needed. If the exchange is + terminated with EAP Failure, an AUTHENTICATION_FAILED notification is + not sent. 2.21.1. Error Handling in IKE_SA_INIT Errors that occur before a cryptographically protected IKE SA is established need to be handled very carefully. There is a trade-off between wanting to help the peer to diagnose a problem and thus responding to the error, and wanting to avoid being part of a denial of service attack based on forged messages. In an IKE_SA_INIT exchange, any error notification causes the @@ -2612,47 +2670,48 @@ and MUST only lead to an UNSUPPORTED_CRITICAL_PAYLOAD or INVALID_SYNTAX Notification sent as a response. The receiver should not verify the payloads related to authentication in this case. If authentication has succeeded in the IKE_AUTH exchange, the IKE SA is established; however, establishing the Child SA or requesting configuration information may still fail. This failure does not automatically cause the IKE SA to be deleted. Specifically, a responder may include all the payloads associated with authentication (IDr, Cert and AUTH) while sending error notifications for the - piggybacked exchanges (FAILED_CP_REQUIRED, INVALID_SELECTORS, - NO_PROPOSAL_CHOSEN, and so on), and the initiator MUST NOT fail the - authentication because of this. The initiator MAY, of course, for - reasons of policy later delete such an IKE SA. + piggybacked exchanges (FAILED_CP_REQUIRED, NO_PROPOSAL_CHOSEN, and so + on), and the initiator MUST NOT fail the authentication because of + this. The initiator MAY, of course, for reasons of policy later + delete such an IKE SA. 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 + following it (in case an error happened 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. 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. + result in a 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 - could cause loops, such errors SHOULD NOT be sent. If errors are - seen that indicate that the peers do not have same state, it might be - good to delete the IKE SA to clean up state and start over. + In normal situations, there should not be cases where a 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 an INFORMATIONAL exchange might lead to further + errors that could cause loops, such errors SHOULD NOT be sent. If + errors are seen that indicate that the peers do not have the same + state, it might be good to delete the IKE SA to clean up state and + start over. If a peer parsing a request notices that it is badly formatted (after it has passed the message authentication code checks and window checks) and it returns an INVALID_SYNTAX notification, then this error notification is considered fatal in both peers, meaning that the IKE SA is deleted without needing an explicit DELETE payload. 2.21.4. Error Handling Outside IKE SA A node needs to limit the rate at which it will send messages in @@ -2787,50 +2846,51 @@ Opening an IPsec connection through a NAT introduces special problems. If the connection runs in transport mode, changing the IP addresses on packets will cause the checksums to fail and the NAT cannot correct the checksums because they are cryptographically protected. Even in tunnel mode, there are routing problems because transparently translating the addresses of AH and ESP packets requires special logic in the NAT and that logic is heuristic and unreliable in nature. For that reason, IKEv2 will use UDP encapsulation of IKE and ESP packets. This encoding is slightly less efficient but is easier for NATs to process. In addition, firewalls - may be configured to pass IPsec traffic over UDP but not ESP/AH or - vice versa. + may be configured to pass UDP-encapsulated IPsec traffic but not + plain, unencapsulated ESP/AH or vice versa. It is a common practice of NATs to translate TCP and UDP port numbers as well as addresses and use the port numbers of inbound packets to decide which internal node should get a given packet. For this reason, even though IKE packets MUST be sent from and to UDP port 500 or 4500, they MUST be accepted coming from any port and responses MUST be sent to the port from whence they came. This is because the 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 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. + An initiator can use port 4500 for both IKE and ESP, regardless of + whether or not there is a NAT, even at the beginning of IKE. When + either side is using port 4500, sending with UDP encapsulation is not + required, but understanding received IKE and ESP 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. The specific requirements for supporting NAT traversal [NATREQ] are listed below. Support for NAT traversal is optional. In this section only, requirements listed as MUST apply only to implementations supporting NAT traversal. o IKE MUST listen on port 4500 as well as port 500. IKE MUST respond to the IP address and port from which packets arrived. o Both IKE initiator and responder MUST include in their IKE_SA_INIT @@ -2848,31 +2908,31 @@ 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 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. + value to a SHA-1 hash of the SPIs, source or recipient IP address + (respectively), address, and port, and if they don't match it + SHOULD enable NAT traversal. 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. + 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. @@ -2888,39 +2948,49 @@ octets of the ESP header contain the SPI, and the SPI cannot validly be zero, it is always possible to distinguish ESP and IKE messages. o Implementations MUST process received UDP-encapsulated ESP packets even when no NAT was detected. o The original source and destination IP address required for the transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) are obtained from the Traffic Selectors associated with the - exchange. In the case of NAT traversal, the Traffic Selectors - MUST contain exactly one IP address, which is then used as the - original IP address. + exchange. In the case of transport mode NAT traversal, the + Traffic Selectors MUST contain exactly one IP address, which is + then used as the original IP address. This is covered in greater + detail in Section 2.23.1. 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 - 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. See Section - 3.8 of [MOBIKE] for more information. + or the NAT box is rebooted). This will be apparent to a host if + it receives a packet whose integrity protection validates, but has + a different port, address, or both from the one that was + associated with the SA in the validated packet. When such a + validated packet is found, a host that does not support other + methods of recovery such as MOBIKE [MOBIKE], and that is not + behind a NAT, SHOULD send all packets (including retransmission + packets) to the IP address and port in the validated packet, and + SHOULD store this as the new address and port combination for the + SA (that is, they SHOULD dynamically update the address). A host + behind a NAT SHOULD NOT do this type of dynamic address update if + a validated packet has different port and/or address values + because it opens a possible denial of service attack (such as + allowing an attacker to break the connection with a single + packet). Also, dynamic address update should only be done in + response to a new packet; otherwise, an attacker can revert the + addresses with old replayed packets. Because of this, dynamic + update can only be done safely if replay protection is enabled. + When IKEv2 is used with MOBIKE, dynamically updating the addresses + described above interferes with MOBIKE's way of recovering from + the same situation. See Section 3.8 of [MOBIKE] for more + information. 2.23.1. Transport Mode NAT Traversal 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 |<------->| | @@ -2940,62 +3010,63 @@ 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 destined to the server. When the client starts creating the IKEv2 SA and Child SA for sending - traffic to the server, it has a triggering packet with source IP + traffic to the server, it may hve a triggering packet with source IP address of IP1, and a destination IP address of IPN2. Its PAD and 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 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. + very specific traffic selectors including protocol and port numbers, + such as 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. When the server receives this packet, it normally looks the PAD based on the ID and then searches the SPD based on the traffic selectors. 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. + address client has behind the NAT), it is useless to do a 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 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). + In this case, the server should first check that the initiator + requested transport mode, and then 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 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. @@ -3031,22 +3102,22 @@ 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. + traffic selectors including protocol and port numbers, such as + 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 response): - 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 @@ -3119,22 +3189,22 @@ size of 1, and recommends solutions. A TEMPORARY_FAILURE notification SHOULD be sent when a peer receives a request that cannot be completed due to a temporary condition such 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. + it SHOULD conclude that the 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. 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). @@ -3144,23 +3214,23 @@ 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 (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 (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. + that it is currently rekeying, it SHOULD reply as usual, with a + 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 @@ -3196,33 +3266,34 @@ 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 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 preceding payload. Payloads are identified in the order in which + they appear in an IKE message by looking in the "Next Payload" field + in the IKE header, and subsequently according to the "Next Payload" + field in the IKE payload itself until a "Next Payload" field of zero + indicates that no payloads follow. 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 + The responder's SPI in the header identifies an instance of an IKE security association. It is therefore possible for a single instance - of IKE to multiplex distinct sessions with multiple peers. + of IKE to multiplex distinct sessions with multiple peers, including + multiple sessions per peer. All multi-octet fields representing integers are laid out in big endian order (also known as "most significant byte first", or "network byte order"). The format of the IKE header is shown in Figure 4. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -3288,38 +3359,38 @@ in the flags field being set. The bits are as follows: +-+-+-+-+-+-+-+-+ |X|X|R|V|I|X|X|X| +-+-+-+-+-+-+-+-+ 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. - * 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) - 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. - * 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. + * 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. 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. @@ -3337,32 +3408,34 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Generic Payload Header The Generic Payload Header fields are defined as follows: 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). 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. + a message by appending each one 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); + conversely, the Next Payload field of the last contained payload + is set to zero). 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 @@ -3446,24 +3519,56 @@ 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 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. + have two proposal structures. Proposal 1 is ESP with AES-128, AES- + 192, and AES-256 bits in CBC mode, with either HMAC-SHA1-96 or + XCBC-96 as the integrity algorithm; Proposal 2 is AES-128 or AES-256 + in GCM mode with an 8-octet ICV. Both proposals allow but do not + require the use of ESN. This can be illustrated as: + + SA Payload + | + +--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4, + | | 7 transforms, SPI = 0x052357bb ) + | | + | +-- Transform ENCR ( Name = ENCR_AES_CBC ) + | | +-- Attribute ( Key Length = 128 ) + | | + | +-- Transform ENCR ( Name = ENCR_AES_CBC ) + | | +-- Attribute ( Key Length = 192 ) + | | + | +-- Transform ENCR ( Name = ENCR_AES_CBC ) + | | +-- Attribute ( Key Length = 256 ) + | | + | +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 ) + | +-- Transform INTEG ( Name = AUTH_AES_XCBC_96 ) + | +-- Transform ESN ( Name = ESNs ) + | +-- Transform ESN ( Name = No ESNs ) + | + +--- Proposal #2 ( Proto ID = ESP(3), SPI size = 4, + | 4 transforms, SPI = 0x35a1d6f2 ) + | + +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV ) + | +-- Attribute ( Key Length = 128 ) + | + +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV ) + | +-- Attribute ( Key Length = 256 ) + | + +-- Transform ESN ( Name = ESNs ) + +-- Transform ESN ( Name = No ESNs ) Each Proposal/Protocol structure is followed by one or more transform 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. For each Protocol, the set of permissible transforms is assigned transform ID numbers, which appear @@ -3670,21 +3775,22 @@ For Transform Type 2 (Pseudo-random Function), the Transform IDs are listed below. 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. Name Number Defined In ------------------------------------------------------ PRF_HMAC_MD5 1 (RFC2104), [MD5] PRF_HMAC_SHA1 2 (RFC2104), [SHA] - PRF_HMAC_TIGER 3 (RFC2104) + PRF_HMAC_TIGER 3 (UNSPECIFIED) + For Transform Type 3 (Integrity Algorithm), defined Transform IDs are listed below. 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. Name Number Defined In ---------------------------------------- NONE 0 AUTH_HMAC_MD5_96 1 (RFC2403) @@ -3814,42 +3920,43 @@ |A| Attribute Type | AF=0 Attribute Length | |F| | AF=1 Attribute Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AF=0 Attribute Value | | AF=1 Not Transmitted | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Data Attributes o Attribute Format (AF) (1 bit) - Indicates whether the data - attribute follow the Type/Length/Value (TLV) format or a shortened - Type/Value (TV) format. If the AF bit is zero (0), then the - attribute uses TLV format; if the AF bit is one (1), the TV format - (with two-byte value) is used. + attribute follows the Type/Length/Value (TLV) format or a + shortened Type/Value (TV) format. If the AF bit is zero (0), then + the attribute uses TLV format; if the AF bit is one (1), the TV + format (with two-byte value) is used. o Attribute Type (15 bits) - Unique identifier for each type of attribute (see below). o Attribute Value (variable length) - Value of the Attribute associated with the Attribute Type. If the AF bit is a zero (0), this field has a variable length defined by the Attribute Length field. If the AF bit is a one (1), the Attribute Value has a length of 2 octets. The only currently defined attribute type (Key Length) is fixed length; the variable-length encoding specification is included only for future extensions. Attributes described as fixed length MUST NOT - be encoded using the variable-length encoding. Variable-length - attributes MUST NOT be encoded as fixed-length even if their value - can fit into two octets. NOTE: This is a change from IKEv1, where - increased flexibility may have simplified the composer of messages - but certainly complicated the parser. + be encoded using the variable-length encoding unless that length + exceeds two bytes. Variable-length attributes MUST NOT be encoded as + fixed-length even if their value can fit into two octets. NOTE: This + is a change from IKEv1, where increased flexibility may have + simplified the composer of messages but certainly complicated the + parser. 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. Attribute Type Value Attribute Format ------------------------------------------------------------ Key Length (in bits) 14 TV @@ -3894,31 +4001,32 @@ During security association negotiation initiators present offers to responders. Responders MUST select a single complete set of parameters from the offers (or reject all offers if none are acceptable). If there are multiple proposals, the responder MUST choose a single proposal. If the selected proposal has multiple Transforms with the same type, the responder MUST choose a single one. Any attributes of a selected transform MUST be returned unmodified. The initiator of an exchange MUST check that the accepted offer is consistent with one of its proposals, and if not - that response MUST be rejected. + MUST terminate the exchange. 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. + Similarly, if the responder receives a transform that it does not + understand, or one 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. 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 @@ -3944,23 +4052,24 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Key Exchange Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: Key Exchange Payload Format A key exchange payload is constructed by copying one's Diffie-Hellman public value into the "Key Exchange Data" portion of the payload. - The length of the Diffie-Hellman public value MUST be equal to the - length of the prime modulus over which the exponentiation was - performed, prepending zero bits to the value if necessary. + The length of the Diffie-Hellman public value for MODP groups MUST be + equal to the length of the prime modulus over which the + exponentiation was 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. See also @@ -4064,21 +4173,21 @@ types of identification. Two implementations will interoperate only if each can generate a type of ID acceptable to the other. To assure maximum interoperability, implementations MUST be configurable to send at least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and MUST be configurable to accept all of these types. Implementations SHOULD be capable of generating and accepting all of these types. IPv6-capable implementations MUST additionally be configurable to accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable - to send only ID_IPV6_ADDR. + to send only ID_IPV6_ADDR instead of ID_IPV6_ADDR for IP addresses. EAP [EAP] does not mandate the use of any particular type of identifier, but often EAP is used with Network Access Identifiers (NAIs) defined in [NAI]. Although NAIs look a bit like email addresses (e.g., "joe@example.com"), the syntax is not exactly the 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 @@ -4086,28 +4195,24 @@ identification type SHOULD be used. 3.6. Certificate Payload 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. + 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 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cert Encoding | | +-+-+-+-+-+-+-+-+ | @@ -4165,21 +4270,22 @@ 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]. - Use the following ASN.1 definition for an X.509 bundle: + The "Hash and URL of a bundle" type uses the following ASN.1 + definition for the X.509 bundle: CertBundle { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-cert-bundle(34) } DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS @@ -4210,23 +4316,21 @@ 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 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. + sender needs to get the certificate of the receiver. The Certificate Request 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cert Encoding | | +-+-+-+-+-+-+-+-+ | @@ -4391,21 +4495,21 @@ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15: Nonce Payload Format o Nonce Data (variable length) - Contains the random data generated by the transmitting entity. The payload type for the Nonce Payload is forty (40). - The size of a Nonce MUST be between 16 and 256 octets inclusive. + The size the Nonce Data MUST be between 16 and 256 octets inclusive. Nonce values MUST NOT be reused. 3.10. Notify Payload The Notify Payload, denoted N in this document, is used to transmit informational data, such as error conditions and state transitions, to an IKE peer. A Notify Payload may appear in a response message (usually specifying why a request was rejected), in an INFORMATIONAL Exchange (to report an error not in an IKE request), or in any other message to indicate sender capabilities or to modify the meaning of @@ -4511,28 +4614,28 @@ 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 + sent in any case where the offered proposals (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 and 2.7. + See Section 1.2 and 1.3. AUTHENTICATION_FAILED 24 Sent in the response to an IKE_AUTH message when for some reason 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 @@ -4655,22 +4758,22 @@ 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. + 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 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 @@ -4862,24 +4965,25 @@ 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 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 Encrypted Payload, denoted SK{...} 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. This payload is also called the + "Encrypted and Authenticated" payload. 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 @@ -4997,23 +5101,23 @@ -------------------------- CFG_REQUEST 1 CFG_REPLY 2 CFG_SET 3 CFG_ACK 4 o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on receipt. o Configuration Attributes (variable length) - These are type length - values specific to the Configuration Payload and are defined - below. There may be zero or more Configuration Attributes in this - payload. + value (TLV) structures specific to the Configuration Payload and + are defined below. There may be zero or more Configuration + Attributes in this payload. 3.15.1. Configuration Attributes 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| Attribute Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Value ~ @@ -5025,26 +5129,27 @@ o Reserved (1 bit) - This bit MUST be set to zero and MUST be 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 (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. + 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 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 @@ -5232,21 +5337,21 @@ then the gateway's response might be: CP(CFG_REPLY) = 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, 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 + Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET 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 things". In particular, IPv6 stateless autoconfiguration or router advertisement messages are not used; neither is neighbor discovery. Note that there is an additional document that discusses IPv6 @@ -5365,40 +5469,35 @@ Figure 25: EAP Message Format o Code (1 octet) indicates whether this message is a Request (1), Response (2), Success (3), or Failure (4). o Identifier (1 octet) is used in PPP to distinguish replayed messages from repeated ones. Since in IKE, EAP runs over a reliable protocol, it serves no function here. In a response message, this octet MUST be set to match the identifier in the - corresponding request. In other messages, this field MAY be set - to any value. + corresponding request. o Length (2 octets) is the length of the EAP message and MUST be four less than the Payload Length of the encapsulating payload. o Type (1 octet) is present only if the Code field is Request (1) or Response (2). For other codes, the EAP message length MUST be four octets and the Type and Type_Data fields MUST NOT be present. In a Request (1) message, Type indicates the data being requested. In a Response (2) message, Type MUST either be Nak or match the - type of the data requested. The following types are defined in - [EAP]: - - 1 Identity - 2 Notification - 3 Nak (Response Only) - 4 MD5-Challenge - 5 One-Time Password (OTP) - 6 Generic Token Card + type of the data requested. Note that since IKE passes an + indication of initiator identity in message 3 of the protocol, the + responder SHOULD NOT send EAP Identity requests (type 1). The + initiator MAY, however, respond to such requests if it receives + them. o Type_Data (Variable Length) varies with the Type of Request and the associated Response. For the documentation of the EAP methods, see [EAP]. Note that since IKE passes an indication of initiator identity in message 3 of the protocol, the responder should not send EAP Identity requests. The initiator may, however, respond to such requests if it receives them. @@ -5418,21 +5517,21 @@ of optional features that can easily be ignored by a particular implementation if it does not support that feature. Those features include: o Ability to negotiate SAs through a NAT and tunnel the resulting ESP SA over UDP. o Ability to request (and respond to a request for) a temporary IP address on the remote end of a tunnel. - o Ability to support various types of legacy authentication. + o Ability to support EAP-based authentication. o Ability to support window sizes greater than one. o Ability to establish multiple ESP or AH SAs within a single IKE SA. o Ability to rekey SAs. To assure interoperability, all implementations MUST be capable of parsing all payload types (if only to skip over them) and to ignore @@ -5468,30 +5567,20 @@ IP addresses, it MUST include a CP payload in message 3 containing at least a field of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. All other fields are optional. If an implementation supports responding to such requests, it MUST parse the CP payload of type CFG_REQUEST in message 3 and recognize a field of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports leasing an address of the appropriate type, it MUST return a CP payload of type CFG_REPLY containing an address of the requested type. The responder may include any other related attributes. - A minimal IPv4 responder implementation will ignore the contents of - the CP payload except to determine that it includes an - INTERNAL_IP4_ADDRESS attribute and will respond with the address and - other related attributes regardless of whether the initiator - requested them. - - A minimal IPv4 initiator will generate a CP payload containing only - an INTERNAL_IP4_ADDRESS attribute and will parse the response - ignoring attributes it does not know how to use. - For an implementation to be called conforming to this specification, it MUST be possible to configure it to accept the following: o PKIX Certificates containing and signed by RSA keys of size 1024 or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR, or ID_DER_ASN1_DN. o Shared key authentication where the ID passed is any of ID_KEY_ID, ID_FQDN, or ID_RFC822_ADDR. @@ -5514,24 +5603,23 @@ initiator is willing to use. 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 document does not prescribe such a - limit. + single key. Implementers should take note of this fact and set a + limit on CREATE_CHILD_SA exchanges 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 @@ -5697,32 +5785,40 @@ IKEv2 packets. In environments where IP spoofing is possible (i.e., 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 + registered those types and values in [IKEV2IANA], so they 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 change the exiting IKEv2 Payload Types table from: + + 46 Encrypted E [RFC4306] + + to + + 46 Encrypted and Authenticated SK [This document] + IANA should update all references to RFC 4306 to point to this document. 7. Acknowledgements Many individuals in the IPsecME Working Group were very helpful in contributing ideas and text for this document, as well as in reviewing the clarifications suggested by others. The acknowledgements from the IKEv2 document were: @@ -5906,22 +6003,21 @@ [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. [IPV6CONFIG] Eronen, et. al., P., "IPv6 Configuration in IKEv2", - draft-ietf-ipsecme-ikev2-ipv6-config (work in progress), - August 2009. + RFC 5739, February 2010. [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 5322, October 2008. [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, @@ -6735,21 +6834,21 @@ 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 - "The KEi payload MUST be included". This also lead to changes in + "The KEi payload MUST be included". This also led to changes in section 2.18. The square brackets around "g^ir (new)" in the SKEYSEED calculation are eliminated, and the requirement language in the paragraph starting "The main rekeying" is changed from SHOULD to MUST. [Issue #50] In section 1.3.2, changed "The window size starts at 1 for any new IKE SA." to "The first IKE requests from both sides on the new IKE SA 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 @@ -7405,20 +7507,265 @@ [V+][N+] to request --> SA, Ni, KEi [V+][N+] response <-- SA, Nr, KEr [V+][N+] +D.15. Changes from draft-ietf-ipsecme-ikev2bis-07 to + draft-ietf-ipsecme-ikev2bis-08 + + Lots more small editorial issues fixed. + + These changes were made after WG Last Call, mostly to close out open + issues. + + In 1.2, changed "The recipients of messages 3 and 4 MUST verify that + all signatures and MACs are computed correctly and that the names in + the ID payloads correspond to the keys used to generate the AUTH + payload." to "The recipients of messages 3 and 4 MUST verify that all + signatures and MACs are computed correctly. If either side uses a + shared secret for authentication, the names in the ID payload MUST + correspond to the key used to generate the AUTH payload." + + In 1.3, added "This notify can also be used to reject IKE SA rekey" + to the discussion of sending the NO_ADDITIONAL_SAS notification. + [Issue #132] + + In 1.3.2, added a pointer to 2.18; vice versa. + + Added to 1.3.3: "The notifications described in Section 1.3.1 may + also be sent in a rekeying exchange. Usually these will be the same + notifications that were used in the original exchange; for example, + when rekeying a transport mode SA, the USE_TRANSPORT_MODE + notification will be used." [Issue #133] + + In 1.4.1, replaced the last paragraph ("Half-closed ESP or AH + connections...") with two paragraphs that clarify deleting IKE SAs as + compared to half-closed ESP or AH connections. + + In 1.5, changed "If the receiving node does not have an active IKE SA + to the IP address from whence the packet came, it" to "The receiving + node". + + In 1.5, replaced the last three paragraphs ("There are two cases...", + "In case of INVALID_IKE_SPI...", and "In case of INVALID_SPI...") + with a more detailed description. [Issue #143] + + In 1.7, added "Section 2.23 clarified that, in NAT traversal, now + both UDP encapsulated IPsec packets and non-UDP encapsulated IPsec + packets packets need to be understood when receiving." + + Added a new paragraph at the end of 2.1 ("The retransmission policy + for one-way messages is somewhat different..."). [Issue #147] + + Replaced the first paragraph in 2.6 with a shorter one, and moved the + historical material to the end of the section. [Issue #148] + + In 2.6.1, removed "SAi1 and" from "For instance, if the responder + includes the SAi1 and KEi payloads in cookie calculation..." [Issue + #134] + + In 2.7, moved the paragraph that begins "Because the initiator sends + its Diffie-Hellman value in the IKE_SA_INIT" to 1.2. [Issue #144] + + In 2.8, replaced "MAY send a dummy message on a newly created SA" + with "MAY send a dummy ESP message on a newly created ESP SA". + [Issue #154] + + In 2.8, changed "...it has received a cryptographically valid message + on the new SA..." to "...it has received a cryptographically valid + message on the other half of the SA pair...". [Issue #149] + + In 2.8.2, changed "The new IKE SA containing the lowest nonce + inherits the Child SAs" to "The new IKE SA containing the lowest + nonce SHOULD be deleted by the node that created it, and the other + suriving new IKE SA MUST inherit all the Child SAs". [Issue #135] + + In 2.8.2, added "In addition to normal simultaneous rekeying cases, + there is a special case where one peer finishes its rekey before it + even notices that other peer is doing a rekey." [Issue #171] + + In 2.8.2, added "Support of the TEMPORARY_FAILURE notification is not + negotiated, so older peers may receive these notifications. In that + case, they will treat it the same as any other unknown error + notification, and will stop the exchange. Because the other peer has + already rekeyed the exchange, doing so does not have any ill + effects." [Issue #150] + + In 2.9, reverted to using a SHOULD for trigger packets. Replaced "If + the initiator requests an SA because it wants to send a data packet, + including the specific addresses in the packet triggering the request + in the first traffic selector in both TSi and TSr enables the + responder to choose the appropriate range" with "To enable the + responder to choose the appropriate range in this case, if the + initiator has requested the SA due to a data packet, the initiator + SHOULD include as the first traffic selector in each of TSi and TSr a + very specific traffic selector including the addresses in the packet + triggering the request." [Issue #155] + + In 2.14, changed "only the first 64 bits of Ni and the first 64 bits + of Nr are used in the calculation" to "only the first 64 bits of Ni + and the first 64 bits of Nr are used in calculating SKEYSEED, but all + the bits are used for input to the prf+ function". [Issue #138] + + Added to the end of 2.15: "There are two types of EAP authentication + (described in Section 2.16), and each type uses different values in + the AUTH computations shown above. If the EAP method is key- + generating, substitute MSK for the Shared Secret in the computation. + For non-key-generating methods, substitute SK_pi and SK_pr, + respectively, for the Shared Secret in the two AUTH computations." + [Issue #151] + + In 2.16, changed "the authenticated identity has to be sent" to "the + authenticated identity, if different from that in the IDi payload, + has to be sent". [Issue #174] + + In 2.17, significantly changed the discussion of the order in which + keying material is taken from KEYMAT. The result is the same, but + the description is quite different, and now also refers to ROHC. + [Issue #139] + + In 2.21, changed "Only authentication failures + (AUTHENTICATION_FAILED)..." to "Only authentication failures + (AUTHENTICATION_FAILED and EAP failure)...". Also added "If the + exchange is terminated with EAP Failure, an AUTHENTICATION_FAILED + notification is not sent." [Issue #152 and #160] + + In 2.21.2, removed INVALID_SELECTORS from the list of things that are + returned from the piggybacked exchanges. [Issue #166] + + In 2.23, changed "In the case of NAT traversal, the Traffic Selectors + MUST contain exactly one IP address, which is then used as the + original IP address" to "In the case of transport mode NAT traversal, + the Traffic Selectors MUST contain exactly one IP address, which is + then used as the original IP address". [Issue #136] + + In 2.23, completely replaced the paragraph that begins "An initiator + can use port 4500". [Issue #146] + + In 2.23, changed "In addition, firewalls may be configured to pass + IPsec traffic over UDP but not ESP/AH or vice versa." to "In + addition, firewalls may be configured to pass UDP-encapsulated IPsec + traffic but not plain, unencapsulated ESP/AH or vice versa". + + In 2.23, changed "SPIs, source IP address, and port" to "SPIs, source + or recipient IP address respectively, and port". [Issue #162]. + + In 2.23, completely replaced the last paragraph ("There are cases + where a NAT box..."). [Issue #175] + + In 2.23.1, changed "When the client starts creating the IKEv2 SA and + Child SA for sending traffic to the server, it has a triggering + packet with source IP address of IP1, and a destination IP address of + IPN2" to "...it may have a triggering packet...". Changed "The first + traffic selector of TSi and TSr SHOULD have very specific traffic + selectors including protocol and port numbers from the packet + triggering the request" to "...SHOULD have very specific traffic + selectors including protocol and port numbers, such as from the + packet...". The same change is made in the third bullet of the + client list near the end of the section. [Issue #173] + + At the beginning of the second paragraph of 3.1, changed "The + Recipient SPI" to the "The responder's SPI". + + In 3.1, changed "Payloads are processed in the order in which they + appear in an IKE message by invoking the appropriate processing + routine according to the "Next Payload" field in the IKE header and + subsequently according to the "Next Payload" field in the IKE payload + itself until a "Next Payload" field of zero indicates that no + payloads follow" to "Payloads are identified in the order in which + they appear in an IKE message by looking in the "Next Payload" field + in the IKE header, and subsequently according to the "Next Payload" + field in the IKE payload itself until a "Next Payload" field of zero + indicates that no payloads follow". [Issue #159] + + In 3.1, added "including multiple sessions per peer" to the end of + the second paragraph. + + In 3.2, changed "In the header of an Encrypted payload, the Next + Payload field is set to the payload type of the first contained + payload (instead of 0)" to "In the header of an Encrypted payload, + the Next Payload field is set to the payload type of the first + contained payload (instead of 0); conversely, the Next Payload field + of the last contained payload is set to zero." [Issue #164] + + In 3.3, changed the example of the two proposals and added a worked- + out figure for them. [Issue #157] + + In 3.3.2, changed PRF_HMAC_TIGER to UNSPECIFIED. + + In 3.3.5, added "unless that length exceeds two bytes" to the end of + "Attributes described as fixed length MUST NOT be encoded using the + variable-length encoding". [Issue #167] + + In 3.3.6, changed "The initiator of an exchange MUST check that the + accepted offer is consistent with one of its proposals, and if not + that response MUST be rejected" to "The initiator of an exchange MUST + check that the accepted offer is consistent with one of its + proposals, and if not MUST terminate the exchange". + + In 3.3.6, changed "Similarly, if the responder receives a transform + that contains a Transform Attribute it does not understand..." to + "Similarly, if the responder receives a transform that it does not + understand, or one that contains a Transform Attribute it does not + understand...". + + In 3.4, changed "The length of the Diffie-Hellman public value MUST + be equal to the length of the prime modulus over which the + exponentiation was performed, prepending zero bits to the value if + necessary" to "The length of the the Diffie-Hellman public value for + MODP groups..." (because it is not true for elliptic curve groups). + + In 3.5, changed "IPv6-only implementations MAY be configurable to + send only ID_IPV6_ADDR" to "IPv6-only implementations MAY be + configurable to send ID_IPV6_ADDR instead of ID_IPV6_ADDR for IP + addresses." + + In 3.6, replaced "Use the following ASN.1 definition for an X.509 + bundle" by "The "Hash and URL of a bundle" type uses the following + ASN.1 definition for the X.509 bundle". + + In 3.7, removed "If multiple CAs are trusted and the certificate + encoding does not allow a list, then multiple Certificate Request + payloads would need to be transmitted". + + In 3.14, added "This payload is also called the "Encrypted and + Authenticated" payload." + + In 3.16, removed the table of EAP types and replaced it with "Note + that since IKE passes an indication of initiator identity in message + 3 of the protocol, the responder SHOULD NOT send EAP Identity + requests (type 1). The initiator MAY, however, respond to such + requests if it receives them." [Issue #153] + + In 3.16, removed "In other messages, this field MAY be set to any + value" from the bullet defining Identifier. [Issue #168] + + In 4, changed "Ability to support various types of legacy + authentication" to "Ability to support EAP-based authentication". + + In section 4, removed two sentences ("A minimal IPv4 responder + implementation..." and "A minimal IPv4 initiator...") because they + were redundant with the preceding text but also used new terms that + were not defined. [Issue #172] + + In 5, removed "or overrun of either endpoint". [Issue #169] + + In 6, added that IANA should change "46 Encrypted E" to "46 Encrypted + SK". + + In 8.2, updated the pointer for IPV6CONFIG to RFC 5739. + Authors' Addresses Charlie Kaufman Microsoft 1 Microsoft Way Redmond, WA 98052 US Phone: 1-425-707-3335 Email: charliek@microsoft.com