--- 1/draft-ietf-ipsecme-ikev2bis-04.txt 2009-10-06 00:12:05.000000000 +0200 +++ 2/draft-ietf-ipsecme-ikev2bis-05.txt 2009-10-06 00:12:05.000000000 +0200 @@ -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: January 9, 2010 Check Point +Expires: April 8, 2010 Check Point P. Eronen Nokia - July 8, 2009 + October 5, 2009 Internet Key Exchange Protocol: IKEv2 - draft-ietf-ipsecme-ikev2bis-04 + draft-ietf-ipsecme-ikev2bis-05 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from @@ -36,21 +36,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 January 9, 2010. + This Internet-Draft will expire on April 8, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. @@ -68,128 +68,135 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 7 1.1.1. Security Gateway to Security Gateway Tunnel Mode . . 8 1.1.2. Endpoint-to-Endpoint Transport Mode . . . . . . . . . 8 1.1.3. Endpoint to Security Gateway Tunnel Mode . . . . . . 9 1.1.4. Other Scenarios . . . . . . . . . . . . . . . . . . . 10 1.2. The Initial Exchanges . . . . . . . . . . . . . . . . . . 10 1.3. The CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 13 1.3.1. Creating New Child SAs with the CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . . . . . . . . . 14 - 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange . 15 + 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange . 16 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . . . . . . . . . 16 1.4. The INFORMATIONAL Exchange . . . . . . . . . . . . . . . 17 - 1.4.1. Deleting an SA with INFORMATIONAL Exchanges . . . . . 17 - 1.5. Informational Messages outside of an IKE SA . . . . . . . 18 - 1.6. Requirements Terminology . . . . . . . . . . . . . . . . 19 - 1.7. Differences Between RFC 4306 and This Document . . . . . 19 + 1.4.1. Deleting an SA with INFORMATIONAL Exchanges . . . . . 18 + 1.5. Informational Messages outside of an IKE SA . . . . . . . 19 + 1.6. Requirements Terminology . . . . . . . . . . . . . . . . 20 + 1.7. Differences Between RFC 4306 and This Document . . . . . 20 2. IKE Protocol Details and Variations . . . . . . . . . . . . . 21 - 2.1. Use of Retransmission Timers . . . . . . . . . . . . . . 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 . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 28 + 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 . . . . . . . . . . . . 37 2.8.3. Rekeying the IKE SA Versus Reauthentication . . . . . 38 2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 39 2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 41 2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.11. Address and Port Agility . . . . . . . . . . . . . . . . 42 2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 43 - 2.13. Generating Keying Material . . . . . . . . . . . . . . . 43 + 2.13. Generating Keying Material . . . . . . . . . . . . . . . 44 2.14. Generating Keying Material for the IKE SA . . . . . . . . 45 - 2.15. Authentication of the IKE SA . . . . . . . . . . . . . . 45 - 2.16. Extensible Authentication Protocol Methods . . . . . . . 47 + 2.15. Authentication of the IKE SA . . . . . . . . . . . . . . 46 + 2.16. Extensible Authentication Protocol Methods . . . . . . . 48 2.17. Generating Keying Material for Child SAs . . . . . . . . 49 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange . . . . 50 2.19. Requesting an Internal Address on a Remote Network . . . 51 - 2.19.1. Configuration Payloads . . . . . . . . . . . . . . . 53 - 2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 54 - 2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 55 + 2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 53 + 2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 53 + 2.21.1. Error Handling in IKE_SA_INIT . . . . . . . . . . . . 54 + 2.21.2. Error Handling in IKE_AUTH . . . . . . . . . . . . . 54 + 2.21.3. Error Handling after IKE SA is Authenticated . . . . 55 + 2.21.4. Error Handling Outside IKE SA . . . . . . . . . . . . 56 2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 56 - 2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 57 - 2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 61 - 3. Header and Payload Formats . . . . . . . . . . . . . . . . . 61 - 3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 61 - 3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 64 - 3.3. Security Association Payload . . . . . . . . . . . . . . 66 - 3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 68 - 3.3.2. Transform Substructure . . . . . . . . . . . . . . . 70 - 3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 73 - 3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 73 - 3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 74 - 3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 76 - 3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 77 - 3.5. Identification Payloads . . . . . . . . . . . . . . . . . 78 - 3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 80 - 3.7. Certificate Request Payload . . . . . . . . . . . . . . . 82 - 3.8. Authentication Payload . . . . . . . . . . . . . . . . . 84 - 3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 85 - 3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 86 - 3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 87 - 3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 90 - 3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 92 - 3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 93 - 3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 94 - 3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 96 - 3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 98 - 3.15.1. Configuration Attributes . . . . . . . . . . . . . . 99 - 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 102 - 3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 104 - 3.15.4. Address Assignment Failures . . . . . . . . . . . . . 104 - 3.16. Extensible Authentication Protocol (EAP) Payload . . . . 105 - 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 107 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 109 - 5.1. Traffic selector authorization . . . . . . . . . . . . . 112 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 113 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 113 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 114 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 114 - 8.2. Informative References . . . . . . . . . . . . . . . . . 115 - Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 119 - Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 120 - B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 120 - B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 121 - Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 121 - C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 122 - C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 123 - C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 124 + 2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 58 + 2.23.1. Transport Mode NAT Traversal . . . . . . . . . . . . 61 + 2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 65 + 3. Header and Payload Formats . . . . . . . . . . . . . . . . . 65 + 3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 66 + 3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 69 + 3.3. Security Association Payload . . . . . . . . . . . . . . 71 + 3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 73 + 3.3.2. Transform Substructure . . . . . . . . . . . . . . . 75 + 3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 78 + 3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 78 + 3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 79 + 3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 81 + 3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 82 + 3.5. Identification Payloads . . . . . . . . . . . . . . . . . 83 + 3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 86 + 3.7. Certificate Request Payload . . . . . . . . . . . . . . . 88 + 3.8. Authentication Payload . . . . . . . . . . . . . . . . . 90 + 3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 91 + 3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 92 + 3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 93 + 3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 96 + 3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 98 + 3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 99 + 3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 100 + 3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 102 + 3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 104 + 3.15.1. Configuration Attributes . . . . . . . . . . . . . . 105 + 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 108 + 3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 110 + 3.15.4. Address Assignment Failures . . . . . . . . . . . . . 111 + 3.16. Extensible Authentication Protocol (EAP) Payload . . . . 112 + 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 113 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 115 + 5.1. Traffic selector authorization . . . . . . . . . . . . . 118 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 119 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 119 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 120 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 120 + 8.2. Informative References . . . . . . . . . . . . . . . . . 121 + Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 126 + Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 127 + B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 127 + B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 127 + + Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 128 + C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 128 + C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 129 + C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 130 C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying - Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 125 - C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA . . . . 125 - C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 125 - Appendix D. Significant Changes from RFC 4306 . . . . . . . . . 125 - Appendix E. Changes Between Internet Draft Versions . . . . . . 126 - E.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 126 - E.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 126 - E.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 128 - E.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 129 - E.5. Changes from draft -02 to draft -03 . . . . . . . . . . . 130 + Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 131 + C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA . . . . 131 + C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 131 + Appendix D. Significant Changes from RFC 4306 . . . . . . . . . 131 + Appendix E. Changes Between Internet Draft Versions . . . . . . 132 + E.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 132 + E.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 132 + E.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 134 + E.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 135 + E.5. Changes from draft -02 to draft -03 . . . . . . . . . . . 136 E.6. Changes from draft -03 to - draft-ietf-ipsecme-ikev2bis-00 . . . . . . . . . . . . . 131 + draft-ietf-ipsecme-ikev2bis-00 . . . . . . . . . . . . . 137 E.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to - draft-ietf-ipsecme-ikev2bis-01 . . . . . . . . . . . . . 132 + draft-ietf-ipsecme-ikev2bis-01 . . . . . . . . . . . . . 138 E.8. Changes from draft-ietf-ipsecme-ikev2bis-01 to - draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 136 + draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 142 E.9. Changes from draft-ietf-ipsecme-ikev2bis-01 to - draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 138 + draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 144 E.10. Changes from draft-ietf-ipsecme-ikev2bis-02 to - draft-ietf-ipsecme-ikev2bis-03 . . . . . . . . . . . . . 139 + draft-ietf-ipsecme-ikev2bis-03 . . . . . . . . . . . . . 145 E.11. Changes from draft-ietf-ipsecme-ikev2bis-03 to - draft-ietf-ipsecme-ikev2bis-04 . . . . . . . . . . . . . 139 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 140 + draft-ietf-ipsecme-ikev2bis-04 . . . . . . . . . . . . . 145 + E.12. Changes from draft-ietf-ipsecme-ikev2bis-04 to + draft-ietf-ipsecme-ikev2bis-05 . . . . . . . . . . . . . 146 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 148 1. Introduction {{ An introduction to the differences between RFC 4306 [IKEV2] and this document is given at the end of Section 1. It is put there (instead of here) to preserve the section numbering of RFC 4306. }} IP Security (IPsec) provides confidentiality, data integrity, access control, and data source authentication to IP datagrams. These services are provided by maintaining shared state between the source @@ -511,20 +518,30 @@ and MACs are computed correctly and that the names in the ID payloads correspond to the keys used to generate the AUTH payload. 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 + although the IKE_AUTH messages are encrypted and integrity protected, + if the peer receiving this notification has not yet authenticated the + other end (or if the peer fails to authenticate the other end for + some reason), the information needs to be treated with caution. More + precisely, assuming that the MAC verifies correctly, the sender of + the error indication is known to be the responder of the IKE_SA_INIT + exchange, but the sender's identity cannot be assured. + Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads. Thus, the SA payloads in the IKE_AUTH exchange cannot contain Transform Type 4 (Diffie-Hellman Group) with any value other than NONE. Implementations SHOULD omit the whole transform substructure instead of sending value NONE. 1.3. The CREATE_CHILD_SA Exchange The CREATE_CHILD_SA exchange is used to create new Child SAs and to rekey both IKE SAs and Child SAs. This exchange consists of a single @@ -713,21 +731,22 @@ in the TS payloads in the response, which may be a subset of what the initiator of the Child SA proposed. 1.4. The INFORMATIONAL Exchange At various points during the operation of an IKE SA, peers may desire to convey control messages to each other regarding errors or notifications of certain events. To accomplish this, IKE defines an INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur after the initial exchanges and are cryptographically protected with - the negotiated keys. + the negotiated keys. Section 2.21 also covers error messages in + great detail. Control messages that pertain to an IKE SA MUST be sent under that IKE SA. Control messages that pertain to Child SAs MUST be sent under the protection of the IKE SA which generated them (or its successor if the IKE SA was rekeyed). Messages in an INFORMATIONAL exchange contain zero or more Notification, Delete, and Configuration payloads. The Recipient of an INFORMATIONAL exchange request MUST send some response (else the Sender will assume the message was lost in the network and will @@ -804,27 +823,27 @@ exchange when a node receives an ESP or AH packet with an invalid SPI. The Notification Data contains the SPI of the invalid packet. This usually indicates a node has rebooted and forgotten an SA. If this Informational Message is sent outside the context of an IKE SA, it should only be used by the recipient as a "hint" that something might be wrong (because it could easily be forged). The recipient of this notification cannot tell whether the SPI is for AH or ESP, but this is not important because the SPIs are supposed to be different for the two. - There are two cases when such a one-way notification is sent: - INVALID_IKE_SPI and INVALID_SPI. These notifications are sent - outside of an IKE SA. Note that such notifications 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.) + 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.) 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. In case of INVALID_SPI, however, there are no IKE SPI values that would be meaningful to the recipient of such a notification. Using @@ -890,20 +908,24 @@ configuration attribute because its implementation was very problematic. Implementations that conform to this document MUST ignore proposals that have configuration attribute type 5, the old value for INTERNAL_ADDRESS_EXPIRY. This document adds the restriction in Section 2.13 that all PRFs used with IKEv2 MUST take variable-sized keys. This should not affect any implementations because there were no standardized PRFs that have fixed-size keys. + Section 2.21 has been greatly expanded to cover the different cases + where error responses are needed and the appropriate responses to + them. + 2. IKE Protocol Details and Variations IKE normally listens and sends on UDP port 500, though IKE messages may also be received on UDP port 4500 with a slightly different format (see Section 2.23). Since UDP is a datagram (unreliable) protocol, IKE includes in its definition recovery from transmission errors, including packet loss, packet replay, and packet forgery. IKE is designed to function so long as (1) at least one of a series of retransmitted packets reaches its destination before timing out; and (2) the channel is not so full of forged and replayed packets so @@ -1513,22 +1533,22 @@ To rekey a Child SA within an existing IKE SA, create a new, equivalent SA (see Section 2.17 below), and when the new one is established, delete the old one. To rekey an IKE SA, establish a new equivalent IKE SA (see Section 2.18 below) with the peer to whom the old IKE SA is shared using a CREATE_CHILD_SA within the existing IKE SA. An IKE SA so created inherits all of the original IKE SA's Child SAs, and the new IKE SA is used for all control messages needed to maintain those Child SAs. The old IKE SA is then deleted, and the Delete payload to delete itself MUST be the last request sent over - the old IKE SA. Note that, when rekeying, the new Child SA MAY have - different traffic selectors and algorithms than the old one. + the old IKE SA. Note that, when rekeying, the new Child SA SHOULD + NOT have different traffic selectors and algorithms than the old one. SAs should be rekeyed proactively, i.e., the new SA should be established before the old one expires and becomes unusable. Enough time should elapse between the time the new SA is established and the old one becomes unusable so that traffic can be switched over to the new SA. A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes were negotiated. In IKEv2, each end of the SA is responsible for enforcing its own lifetime policy on the SA and rekeying the SA when @@ -2419,90 +2440,20 @@ a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS to perform an unnecessary configuration lookup if the IRAC cannot process the REPLY. In the case where the IRAS's configuration requires that CP be used for a given identity IDi, but IRAC has failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and terminate the IKE exchange with a FAILED_CP_REQUIRED error. The FAILED_CP_REQUIRED is not fatal to the IKE SA; it simply causes the Child SA creation fail. The initiator can fix this by later starting a new configuration payload request. -2.19.1. Configuration Payloads - - Editor's note: some of this sub-section is redundant and will go away - in the next version of the document. - - In support of the scenario described in Section 1.1.3, an initiator - may request that the responder assign an IP address and tell the - initiator what it is. That request is done using configuration - payloads, not traffic selectors. An address in a TSi payload in a - response does not mean that the responder has assigned that address - to the initiator: it only means that if packets matching these - traffic selectors are sent by the initiator, IPsec processing can be - performed as agreed for this SA. - - Configuration payloads are of type CFG_REQUEST/CFG_REPLY or CFG_SET/ - CFG_ACK (see CFG Type in the payload description below). CFG_REQUEST - and CFG_SET payloads may optionally be added to any IKE request. The - IKE response MUST include either a corresponding CFG_REPLY or CFG_ACK - or a Notify payload with an error type indicating why the request - could not be honored. An exception is that a minimal implementation - MAY ignore all CFG_REQUEST and CFG_SET payloads, so a response - message without a corresponding CFG_REPLY or CFG_ACK MUST be accepted - as an indication that the request was not supported. - - "CFG_REQUEST/CFG_REPLY" allows an IKE endpoint to request information - from its peer. If an attribute in the CFG_REQUEST Configuration - Payload is not zero-length, it is taken as a suggestion for that - attribute. The CFG_REPLY Configuration Payload MAY return that - value, or a new one. It MAY also add new attributes and not include - some requested ones. Requestors MUST ignore returned attributes that - they do not recognize. - - Some attributes MAY be multi-valued, in which case multiple attribute - values of the same type are sent and/or returned. Generally, all - values of an attribute are returned when the attribute is requested. - For some attributes (in this version of the specification only - internal addresses), multiple requests indicates a request that - multiple values be assigned. For these attributes, the number of - values returned SHOULD NOT exceed the number requested. - - If the data type requested in a CFG_REQUEST is not recognized or not - supported, the responder MUST NOT return an error type but rather - MUST either send a CFG_REPLY that MAY be empty or a reply not - containing a CFG_REPLY payload at all. Error returns are reserved - for cases where the request is recognized but cannot be performed as - requested or the request is badly formatted. - - "CFG_SET/CFG_ACK" allows an IKE endpoint to push configuration data - to its peer. In this case, the CFG_SET Configuration Payload - contains attributes the initiator wants its peer to alter. The - responder MUST return a Configuration Payload if it accepted any of - the configuration data and it MUST contain the attributes that the - responder accepted with zero-length data. Those attributes that it - did not accept MUST NOT be in the CFG_ACK Configuration Payload. If - no attributes were accepted, the responder MUST return either an - empty CFG_ACK payload or a response message without a CFG_ACK - payload. There are currently no defined uses for the CFG_SET/CFG_ACK - exchange, though they may be used in connection with extensions based - on Vendor IDs. An minimal implementation of this specification MAY - ignore CFG_SET payloads. - - Extensions via the CP payload should not be used for general purpose - management. Its main intent is to provide a bootstrap mechanism to - exchange information within IPsec from IRAS to IRAC. While it MAY be - useful to use such a method to exchange information between some - Security Gateways (SGW) or small networks, existing management - protocols such as DHCP [DHCP], RADIUS [RADIUS], SNMP, or LDAP [LDAP] - should be preferred for enterprise management as well as subsequent - information exchanges. - 2.20. Requesting the Peer's Version An IKE peer wishing to inquire about the other peer's IKE software version information MAY use the method below. This is an example of a configuration request within an INFORMATIONAL exchange, after the IKE SA and first Child SA have been created. An IKE implementation MAY decline to give out version information prior to authentication or even after authentication to prevent trolling in case some implementation is known to have some security @@ -2516,64 +2467,167 @@ CP(CFG_REQUEST)= APPLICATION_VERSION("") CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar Inc.") 2.21. Error Handling There are many kinds of errors that can occur during IKE processing. - If a request is received that is badly formatted or unacceptable for - reasons of policy (e.g., no matching cryptographic algorithms), the - response MUST contain a Notify payload indicating the error. If an - error occurs outside the context of an IKE request (e.g., the node is - getting ESP messages on a nonexistent SPI), the node SHOULD initiate - an INFORMATIONAL exchange with a Notify payload describing the - problem. + The general rule is that if a request is received that is badly + formatted, or unacceptable for reasons of policy (such as no matching + cryptographic algorithms), the response contains a Notify payload + 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. + +2.21.1. Error Handling in IKE_SA_INIT Errors that occur before a cryptographically protected IKE SA is - established must be handled very carefully. There is a trade-off - between wanting to be helpful in diagnosing a problem and responding - to it and wanting to avoid being a dupe in a denial of service attack - based on forged messages. + 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 + exchange to fail. Note that some error notifications such as COOKIE, + INVALID_KE_PAYLOAD or INVALID_MAJOR_VERSION may lead to a subsequent + successful exchange. Because all error notifications are completely + unauthenticated, the recipient should continue trying for some time + before giving up. The recipient should not immediately act based on + the error notification unless corrective actions are defined in this + specification, such as for COOKIE, INVALID_KE_PAYLOAD, and + INVALID_MAJOR_VERSION. + +2.21.2. Error Handling in IKE_AUTH + + All errors that occur in an IKE_AUTH exchange, causing the + authentication to fail for whatever reason (invalid shared secret, + invalid ID, untrusted certificate issuer, revoked or expired + certificate, etc.) SHOULD result in an AUTHENTICATION_FAILED + notification. If the error occurred on the responder, the + notification is returned in the protected response, and is usually + the only payload in that response. Although the IKE_AUTH messages + are encrypted and integrity protected, if the peer receiving this + notification has not authenticated the other end yet, that peer needs + to treat the information with caution. + + If the error occurs on the initiator, the notification MAY be + returned in a separate INFORMATIONAL exchange, usually with no other + payloads. This is exception for the general rule of not starting new + exchanges based on errors in responses. + + Note, however, that request messages that contain an unsupported + critical payload, or where the whole message is malformed (rather + than just bad payload contents), MUST be rejected in their entirety, + and MUST only lead to an UNSUPPORTED_CRITICAL_PAYLOAD or + INVALID_SYNTAX Notification sent as 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. + + In an IKE_AUTH exchange, or in the INFORMATIONAL exchange immediately + following it (in case an error happened in when processing response + to IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and + AUTHENTICATION_FAILED notifications are the only ones to cause the + IKE SA to be deleted or not created, without a DELETE payload. + Extension documents may define new error notifications with these + semantics, but MUST NOT use them unless the peer has been shown to + understand them. + + NOTE FOR WG DISCUSSION: Having other payloads in the message is + allowed but there are none suggested. One WG member mentioned the + possibility of adding a DELETE payload when the error is sent in a + separate INFORMATIONAL exchange. Do we want to allow such additional + payloads that have operational semantics? + +2.21.3. Error Handling after IKE SA is Authenticated + + After the IKE SA is authenticated all requests having errors MUST + result in response notifying about the error. + + In normal situations, there should not be cases where valid response + from one peer results in an error situation in the other peer, so + there should not be any reason for a peer to send error messages to + the other end except as a response. Because sending such error + messages as INFORMATIONAL exchange might lead to further errors that + 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. + + 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 + response to unprotected messages. If a node receives a message on UDP port 500 or 4500 outside the - context of an IKE SA known to it (and not a request to start one), it - may be the result of a recent crash of the node. If the message is - marked as a response, the node MAY audit the suspicious event but - MUST NOT respond. If the message is marked as a request, the node - MAY audit the suspicious event and MAY send a response. If a - response is sent, the response MUST be sent to the IP address and - port from whence it came with the same IKE SPIs and the Message ID - copied. The response MUST NOT be cryptographically protected and - MUST contain a Notify payload indicating INVALID_IKE_SPI. The + context of an IKE SA known to it (and the message is not a request to + start an IKE SA), this may be the result of a recent crash of the + node. If the message is marked as a response, the node can audit the + suspicious event but MUST NOT respond. If the message is marked as a + request, the node can audit the suspicious event and MAY send a + response. If a response is sent, the response MUST be sent to the IP + address and port from where it came with the same IKE SPIs and the + Message ID copied. The response MUST NOT be cryptographically + protected and MUST contain an INVALID_IKE_SPI Notify payload. The INVALID_IKE_SPI notification indicates an IKE message was received with an unrecognized destination SPI; this usually indicates that the recipient has rebooted and forgotten the existence of an IKE SA. - A node receiving such an unprotected Notify payload MUST NOT respond + A peer receiving such an unprotected Notify payload MUST NOT respond and MUST NOT change the state of any existing SAs. The message might - be a forgery or might be a response the genuine correspondent was + be a forgery or might be a response that a genuine correspondent was tricked into sending. A node should treat such a message (and also a network message like ICMP destination unreachable) as a hint that there might be problems with SAs to that IP address and should - initiate a liveness test for any such IKE SA. An implementation + initiate a liveness check for any such IKE SA. An implementation SHOULD limit the frequency of such tests to avoid being tricked into participating in a denial of service attack. - A node receiving a suspicious message from an IP address with which - it has an IKE SA MAY send an IKE Notify payload in an IKE - INFORMATIONAL exchange over that SA. The recipient MUST NOT change - the state of any SAs as a result, but may wish to audit the event to - aid in diagnosing malfunctions. A node MUST limit the rate at which - it will send messages in response to unprotected messages. + If an error occurs outside the context of an IKE request (e.g., the + node is getting ESP messages on a nonexistent SPI), the node SHOULD + initiate an INFORMATIONAL exchange with a Notify payload describing + the problem. + + A node receiving a suspicious message from an IP address (and port, + if NAT traversal is used) with which it has an IKE SA SHOULD send an + IKE Notify payload in an IKE INFORMATIONAL exchange over that SA. + The recipient MUST NOT change the state of any SAs as a result, but + may wish to audit the event to aid in diagnosing malfunctions. 2.22. IPComp Use of IP compression [IP-COMP] can be negotiated as part of the setup of a Child SA. While IP compression involves an extra header in each packet and a compression parameter index (CPI), the virtual "compression association" has no life outside the ESP or AH SA that contains it. Compression associations disappear when the corresponding ESP or AH SA goes away. It is not explicitly mentioned in any DELETE payload. @@ -2800,20 +2854,192 @@ 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, so this method MUST NOT be used when MOBIKE is used. See Section 3.8 of [MOBIKE] for more information. +2.23.1. Transport Mode NAT Traversal + + Transport mode used with NAT Traversal requires special handling of + the traffic selectors used in the IKEv2. The complete scenario looks + like: + + +------+ +------+ +------+ +------+ + |Client| IP1 | NAT | IPN1 IPN2 | NAT | IP2 |Server| + |node |<------>| A |<---------->| B |<------->| | + +------+ +------+ +------+ +------+ + + (Other scenarios are simplications of this complex case, so this + discussion uses the complete scenario.) + + In this scenario, there are two address translating NATs: NAT A and + NAT B. NAT A is dynamic NAT that maps the clients source address IP1 + to IPN1. NAT B is static NAT configured so that connections coming + to IPN2 address are mapped to the gateways adddress IP2, that is, + IPN2 destination address is mapped to IP2. This allows the client to + connect to a server by connecting to the IPN2. NAT B does not + necessarily need to be a static NAT, but the client needs to know how + to connect to the server, and it can only do that if it somehow knows + the outer address of the NAT B, that is, the IPN2 address. If NAT B + is a static NAT, then its address can be configured to the client's + configuration. Other options would be find it using some other + protocol (like DNS), but those are outside of scope of IKEv2. + + In this scenario, both client and server are configured to use + transport mode for the traffic originating from the client node and + 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 + address of IP1, and a destination IP address of IPN2. Its PAD and + SPD needs to have configuration matching those addresses (or wildcard + entries covering them). Because this is transport mode, it uses + exactly same addresses as the traffic selectors and outer IP address + of the IKE packets. For transport mode, it MUST use exactly one IP + address in the TSi and TSr payloads. It can have multiple traffic + selectors if it has, for example, multiple port ranges that it wants + to negotiate, but all TSi entries must use IP1-IP1 range as the IP + addresses, and all TSr entries must have the IPN2-IPN2 range as IP + the addresses. The first traffic selector of TSi and TSr SHOULD have + very specific traffic selectors including protocol and port numbers + from the packet triggering the request. + + NAT A will then replace the source address of the IKE packet from IP1 + to IPN1, and NAT B will replace the destination address of the IKE + packet from IPN2 to IP2, so when the packet arrives to the server it + will still have the exactly same traffic selectors which were sent by + the client, but the IP address of the IKE packet has been replaced to + IPN1 and IP2. + + 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. + + In this case, the server should first check that as initiator + requested transport mode and do address substitution on the traffic + selectors. It needs to first store the old traffic selector IP + addresses to be used later for the incremental checksum fixup (the IP + address in the TSi can be stored as the real source address and the + IP address in the TSr can be stored as the real destination address). + After that, if the other end was detected as being behind a NAT, the + server replaces the IP address in TSi payloads with the IP address + obtained from the source address of the IKE packet received (that is, + it replaces IP1 in TSi with IPN1). If the server's end was detected + to be behind NAT, it replaces the IP address in the TSr payloads with + the IP address obtained from the destination address of the IKE + packet received (thta is, it replaces IPN2 in TSr with IP2). + + 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. + + This address substitution in transport mode is needed because the SPD + is looked up using the addresses that will be seen by the local host. + This also will make sure the SAD entries for the tunnel exit checks + and return packets is added using the addresses as seen by the local + operating system stack. + + The most common case is that the server's SPD will contain wildcard + entries matching any addresses, but this allows also making different + SPD entries, for example, for different known NATs outer addresses. + + After the SPD lookup, the server will do traffic selector narrowing + based on the SPD entry it found. It will again use the already- + substituted traffic selectors, and it will thus send back traffic + selectors having IPN1 and IP2 as their IP addresses; it can still + narrow down the protocol number or port ranges used by the traffic + selectors. The SAD entry created for the Child SA will have the + addresses as seen by the server, namely IPN1 and IP2. + + When the client receives the server's reply to the Child SA, it will + do similar processing. If the transport mode SA was created, the + client can store the original returned traffic selectors as real + source and destination addresses. It will replace the IP addresses + in the traffic selectors with the ones from the IP header of the IKE + packet: it will replace IPN1 with IP1 and IP2 with IPN2. Then it + will use those traffic selectors when verifying the SA against sent + traffic selectors, and when installing the SAD entry. + + A summary of the rules for NAT-traversal in transport mode is: + + For the client proposing transport mode: + + - The TSi entries MUST have exactly one IP address, and that MUST + match the source address of the IKE SA. + + - The TSr entries MUST have exactly one IP address, and that MUST + match the destination address of the IKE SA. + + - The first TSi and TSr traffic selectors SHOULD have very specific + traffic selectors including protocol and port numbers from the + packet triggering the request. + + - There MAY be multiple TSi and TSr entries. + + - If transport mode for the SA was selected (that is, if the server + included USE_TRANSPORT_MODE notification in its reply): + + - Store the original traffic selectors as the real source and + destination address. + + - If the server is behind a NAT, substitute the IP address in the + TSr entries with the remote address of the IKE SA. + + - If the client is behind a NAT, substitute the IP address in the + TSi entries with the local address of the IKE SA. + + - Do address substitution before using those traffic selectors + for anything else other than storing original content of them. + This includes verification that traffic selectors were narrowed + correctly by other end, creation of the SAD entry, and so on. + + For the responder, when transport mode is proposed by client: + + - Store the original traffic selector IP addresses as real source + and destination address in case we need to undo address + substitution. + + - If the client is behind a NAT, substitute the IP address in the + TSi entries with the remote address of the IKE SA. + + - If the server is behind a NAT substitute the IP address in the + TSr entries with the local address of the IKE SA. + + - Do PAD and SPD lookup using the ID and substituted traffic + selectors. + + - If no SPD entry was found, or if found SPD entry does not + allow transport mode, undo the traffic selector substitutions. + Do PAD and SPD lookup again using the ID and original traffic + selectors, but also searching for tunnel mode SPD entry (that + is, fall back to tunnel mode). + + - However, if a transport mode SPD entry was found, do normal + traffic selection narrowing based on the substituted traffic + selectors and SPD entry. Use the resulting traffic selectors when + creating SAD entries, and when sending traffic selectors back to + the client. + 2.24. Explicit Congestion Notification (ECN) When IPsec tunnels behave as originally specified in [IPSECARCH-OLD], ECN usage is not appropriate for the outer IP headers because tunnel decapsulation processing discards ECN congestion indications to the detriment of the network. ECN support for IPsec tunnels for IKEv1- based IPsec requires multiple operating modes and negotiation (see [ECN]). IKEv2 simplifies this situation by requiring that ECN be usable in the outer IP headers of all tunnel-mode IPsec SAs created by IKEv2. Specifically, tunnel encapsulators and decapsulators for @@ -3348,20 +3574,26 @@ 1536-bit MODP 5 [ADDGROUP] RESERVED TO IANA 6-13 2048-bit MODP 14 [ADDGROUP] 3072-bit MODP 15 [ADDGROUP] 4096-bit MODP 16 [ADDGROUP] 6144-bit MODP 17 [ADDGROUP] 8192-bit MODP 18 [ADDGROUP] RESERVED TO IANA 19-1023 PRIVATE USE 1024-65535 + Although ESP and AH do not directly include a Diffie-Hellman + exchange, a Diffie-Hellman group MAY be negotiated for the Child SA. + This allows the peers to employ Diffie-Hellman in the CREATE_CHILD_SA + exchange, providing perfect forward secrecy for the generated Child + SA keys. + For Transform Type 5 (Extended Sequence Numbers), defined Transform IDs are: Name Number -------------------------------------------- No Extended Sequence Numbers 0 Extended Sequence Numbers 1 RESERVED 2 - 65535 Note that an initiator who supports ESNs will usually include two ESN @@ -3613,20 +3844,28 @@ ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 does not require this address to match the address in the IP header of IKEv2 packets, or anything in the TSi/TSr payloads. The contents of IDi/IDr is used purely to fetch the policy and authentication data related to the other party. NOTE: In IKEv1, two ID payloads were used in each direction to hold Traffic Selector (TS) information for data passing over the SA. In IKEv2, this information is carried in TS payloads (see Section 3.13). + The Peer Authorization Database (PAD) as described in RFC 4301 + [IPSECARCH] describes the use of the ID payload in IKEv2 and provides + a formal model for the binding of identity to policy in addition to + providing services that deal more specifically with the details of + policy enforcement. The PAD is intended to provide a link between + the SPD and the IKE security association management. See Section + 4.4.3 of RFC 4301 for more details. + The Identification Payload consists of the IKE generic payload header followed by identification fields 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID Type | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -3772,20 +4011,23 @@ Certificate Encoding field. The payload type for the Certificate Payload is thirty seven (37). Specific syntax for some of the certificate type codes above is not defined in this document. The types whose syntax is defined in this document are: o X.509 Certificate - Signature (4) contains a DER encoded X.509 certificate whose public key is used to validate the sender's AUTH + payload. Note that with this encoding, if a chain of certificates + needs to be sent, multiple CERT payloads are used, only the first + of which holds the public key used to validate the sender's AUTH payload. o Certificate Revocation List (7) contains a DER encoded X.509 certificate revocation list. o Raw RSA Key (11) contains a PKCS #1 encoded RSA key, that is, a DER-encoded RSAPublicKey structure (see [RSA] and [PKCS1]). o Hash and URL encodings (12-13) allow IKE messages to remain short by replacing long data structures with a 20 octet SHA-1 hash (see @@ -4489,20 +4731,25 @@ 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 completely specifies the cryptographic processing of IKE data, but those documents should be consulted for design rationale. Future documents may specify the processing of Encrypted payloads for other types of transforms, such as counter mode encryption and authenticated encryption algorithms. Peers MUST NOT negotiate transforms for which no such specification exists. + When an authenticated encryption algorithm is used to protect the IKE + SA, the construction of the encrypted payload is different that what + is described here. See [RFC5282] for more information on + authenticated encryption algorithms and their use in ESP. + The payload type for an Encrypted payload is forty six (46). The Encrypted Payload consists of the IKE generic payload header followed by individual fields 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initialization Vector | @@ -4730,20 +4977,42 @@ prefix-length as defined in [ADDRIPV6]. Multiple sub-networks MAY be requested. The responder MAY respond with zero or more sub- network attributes. This is discussed in more detail in Section 3.15.2. Note that no recommendations are made in this document as to how an implementation actually figures out what information to send in a reply. That is, we do not recommend any specific method of an IRAS determining which DNS server should be returned to a requesting IRAC. + The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to request + information from its peer. If an attribute in the CFG_REQUEST + Configuration Payload is not zero-length, it is taken as a suggestion + for that attribute. The CFG_REPLY Configuration Payload MAY return + that value, or a new one. It MAY also add new attributes and not + include some requested ones. Requestors MUST ignore returned + attributes that they do not recognize. + + The CFG_SET and CFG_ACK pair allows an IKE endpoint to push + configuration data to its peer. In this case, the CFG_SET + Configuration Payload contains attributes the initiator wants its + peer to alter. The responder MUST return a Configuration Payload if + it accepted any of the configuration data and it MUST contain the + attributes that the responder accepted with zero-length data. Those + attributes that it did not accept MUST NOT be in the CFG_ACK + Configuration Payload. If no attributes were accepted, the responder + MUST return either an empty CFG_ACK payload or a response message + without a CFG_ACK payload. There are currently no defined uses for + the CFG_SET/CFG_ACK exchange, though they may be used in connection + with extensions based on Vendor IDs. An implementation of this + specification MAY ignore CFG_SET payloads. + 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET INTERNAL_IP4/6_SUBNET attributes can indicate additional subnets, ones that need one or more separate SAs, that can be reached through the gateway that announces the attributes. INTERNAL_IP4/6_SUBNET attributes may also express the gateway's policy about what traffic should be sent through the gateway; the client can choose whether other traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is sent through the gateway or directly to the destination. Thus, traffic to the addresses listed in the INTERNAL_IP4/6_SUBNET @@ -4821,20 +5090,25 @@ Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET is in CFG_REQUESTs is unclear, they cannot be used reliably in CFG_REQUESTs. 3.15.3. Configuration payloads for IPv6 The configuration payloads for IPv6 are based on the corresponding IPv4 payloads, and do not fully follow the "normal IPv6 way of doing 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 + configuration in IKEv2, [IPV6CONFIG]. At the present time, it is an + experimental document, but there is a hope that with more + implementation experience, it will gain the same standards treatment + as this document. A client can be assigned an IPv6 address using the INTERNAL_IP6_ADDRESS configuration payload. A minimal exchange might look like this: CP(CFG_REQUEST) = INTERNAL_IP6_ADDRESS() INTERNAL_IP6_DNS() TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) @@ -5262,23 +5535,23 @@ 6. IANA Considerations [IKEV2] defined many field types and values. IANA has already registered those types and values, so the are not listed here again. No new types or values are registered in this document. However, IANA should update all references to RFC 4306 to point to this document. 7. Acknowledgements - The individuals on the IPsec mailing list was very helpful in both - pointing out where clarifications and changes were needed, as well as - in reviewing the clarifications suggested by others. + 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: This document is a collaborative effort of the entire IPsec WG. If there were no limit to the number of authors that could appear on an RFC, the following, in alphabetical order, would have been listed: Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, John Ioannidis, Charlie Kaufman, Steve Kent, Angelos Keromytis, Tero Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer @@ -5340,20 +5613,25 @@ [RFC4434] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 4434, February 2006. [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC- PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 4615, August 2006. + [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption + Algorithms with the Encrypted Payload of the Internet Key + Exchange version 2 (IKEv2) Protocol", RFC 5282, + August 2008. + [UDPENCAPS] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005. 8.2. Informative References [AEAD] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, January 2008. @@ -5372,23 +5650,20 @@ Implementation Guidelines", RFC 4718, October 2006. [DES] American National Standards Institute, "American National Standard for Information Systems-Data Link Encryption", ANSI X3.106, 1983. [DH] Diffie, W. and M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory, V.IT-22 n. 6, June 1977. - [DHCP] Droms, R., "Dynamic Host Configuration Protocol", - RFC 2131, March 1997. - [DIFFSERVARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475. [DIFFSERVFIELD] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. @@ -5453,27 +5728,29 @@ September 2001. [IPSECARCH-OLD] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [IPV6ADDR] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 4291, February 2006. + [IPV6CONFIG] + Eronen, et. al., P., "IPv6 Configuration in IKEv2", + draft-ietf-ipsecme-ikev2-ipv6-config (work in progress), + August 2009. + [ISAKMP] Maughan, D., Schneider, M., and M. Schertler, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. - [LDAP] Sermersheim, J., "Lightweight Directory Access Protocol - (v3)", RFC 4511, June 2006. - [MAILFORMAT] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [MIPV6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. @@ -5496,40 +5773,36 @@ [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998. [PFKEY] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key Management API, Version 2", RFC 2367, July 1998. [PHOTURIS] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999. - [RADIUS] Rigney, C., Rubens, A., Simpson, W., and S. Willens, - "Remote Authentication Dial In User Service (RADIUS)", - RFC 2138, April 1997. - [RANDOMNESS] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [REAUTH] Nir, Y., "Repeated Authentication in Internet Key Exchange (IKEv2) Protocol", RFC 4478, April 2006. [REUSE] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In Diffie-Hellman Key Agreement Protocols", December 2008, . [ROHCV2] Ertekin, et. al., E., "IKEv2 Extensions to Support Robust Header Compression over IPsec (ROHCoIPsec)", draft-ietf-rohc-ikev2-extensions-hcoipsec (work in - progress), October 2008. + progress), August 2009. [RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", February 1978. [SHA] National Institute of Standards and Technology, U.S. Department of Commerce, "Secure Hash Standard", FIPS 180-3, October 2008. [SIGMA] H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to @@ -6500,20 +6772,96 @@ In 2.18, added "using SPIi, SPIr, Ni, and Nr from the new exchange" to the last sentence. Removed INTERNAL_IP6_NBNS from 3.15.1. [Issue #44] Changed "The requested address is valid until there are no IKE_SAs between the peers" to "The requested address is valid as long as this IKE SA (or its rekeyed successors) requesting the address is valid." [Issue #43] +E.12. Changes from draft-ietf-ipsecme-ikev2bis-04 to + draft-ietf-ipsecme-ikev2bis-05 + + Added the following near the end of 1.2: "If the failure is related + to creating the IKE SA (for example, AUTHENTICATION_FAILED), the IKE + SA is not created. Note that although the IKE_AUTH messages are + encrypted and integrity protected, if the peer receiving this + notification has not yet authenticated the other end (or if the peer + fails to authenticate the other end for some reason), the information + needs to be treated with caution. More precisely, assuming that the + MAC verifies correctly, the sender of the error indication is known + to be the responder of the IKE_SA_INIT exchange, but the sender's + identity cannot be assured." [Issue #9] + + Added "Section 2.21 also covers error messages in great detail" near + the beginning of 1.4. + + Added "Section 2.21 has been greatly expanded to cover the different + cases where error responses are needed and the appropriate responses + to them" to the end of 1.7. + + In 1.5, changed "There are two cases when such a one-way + notification" to "There are two cases when a one-way notification". + Also changed "notification" to "message" throughout this paragraph. + + 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.". [Issue #12] + + Section 2.21 was replaced and significantly expanded to cover many + different error situations. [Issue #26] + + Added 2.23.1, which covers how to handle NAT traversal when transport + mode is requested. [Issue #28] + + In 3.3.2, after the table for tranform type 4, added "Although ESP + and AH do not directly include a Diffie-Hellman exchange, a Diffie- + Hellman group MAY be negotiated for the Child SA. This allows the + peers to employ Diffie-Hellman in the CREATE_CHILD_SA exchange, + providing perfect forward secrecy for the generated Child SA keys." + [Issue #57] + + In 3.5, added "The Peer Authorization Database (PAD) as described in + RFC 4301 [IPSECARCH] describes the use of the ID payload in IKEv2 and + provides a formal model for the binding of identity to policy in + addition to providing services that deal more specifically with the + details of policy enforcement. The PAD is intended to provide a link + between the SPD and the IKE security association management. See + Section 4.4.3 of RFC 4301 for more details." [Issue #58] + + Added to the definition of "X.509 Certificate" in 3.6: "Note that + with this encoding, if a chain of certificates needs to be sent, + multiple CERT payloads are used, only the first of which holds the + public key used to validate the sender's AUTH payload." [Issue + #107]. + + In 3.14, added "When an authenticated encryption algorithm is used to + protect the IKE SA, the construction of the encrypted payload is + different that what is described here. See [RFC5282] for more + information on authenticated encryption algorithms and their use in + ESP." + + Added the last two paragraphs of 3.15 (on CFG_REQUEST and CFG_REPLY, + and CFG_SET and CFG_ACK). Removed all of 2.19.1 which contained the + same material and a lot of material that was duplicated from other + parts of the document. [Issue #108] + + Added the following to 3.15.3: "Note that there is an additional + document that discusses IPv6 configuration in IKEv2, [IPV6CONFIG]. + At the present time, it is an experimental document, but there is a + hope that with more implementation experience, it will gain the same + standards treatment as this document." [Issue #47 and Issue #60] + + Reworded the acknowledgements to be more inclusive. + Authors' Addresses Charlie Kaufman Microsoft 1 Microsoft Way Redmond, WA 98052 US Phone: 1-425-707-3335 Email: charliek@microsoft.com