--- 1/draft-ietf-ipsecme-ikev2bis-01.txt 2009-02-27 03:12:10.000000000 +0100 +++ 2/draft-ietf-ipsecme-ikev2bis-02.txt 2009-02-27 03:12:10.000000000 +0100 @@ -1,172 +1,189 @@ Network Working Group C. Kaufman Internet-Draft Microsoft Obsoletes: 4306, 4718 P. Hoffman (if approved) VPN Consortium Intended status: Standards Track Y. Nir -Expires: May 3, 2009 Check Point +Expires: August 30, 2009 Check Point P. Eronen Nokia - October 30, 2008 + February 26, 2009 Internet Key Exchange Protocol: IKEv2 - draft-ietf-ipsecme-ikev2bis-01 + draft-ietf-ipsecme-ikev2bis-02 Status of this Memo - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. + 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 + 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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months 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 May 3, 2009. + This Internet-Draft will expire on August 30, 2009. Copyright Notice + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. - Copyright (C) The IETF Trust (2008). + 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. Abstract This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs). It replaces and updates RFC 4306, and includes all of the clarifications from RFC 4718. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 - 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 6 - 1.1.1. Security Gateway to Security Gateway Tunnel Mode . . 6 - 1.1.2. Endpoint-to-Endpoint Transport Mode . . . . . . . . . 7 - 1.1.3. Endpoint to Security Gateway Tunnel Mode . . . . . . 8 - 1.1.4. Other Scenarios . . . . . . . . . . . . . . . . . . . 8 - 1.2. The Initial Exchanges . . . . . . . . . . . . . . . . . . 9 - 1.3. The CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 12 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 + 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 7 + 1.1.1. Security Gateway to Security Gateway Tunnel Mode . . 7 + 1.1.2. Endpoint-to-Endpoint Transport Mode . . . . . . . . . 8 + 1.1.3. Endpoint to Security Gateway Tunnel Mode . . . . . . 9 + 1.1.4. Other Scenarios . . . . . . . . . . . . . . . . . . . 9 + 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 . . . . . . . . . . . . . . . . . . . . . . 13 - 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange . 14 + Exchange . . . . . . . . . . . . . . . . . . . . . . 14 + 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 . . . . . . . . . . . . . . . . . . . . . . 15 - 1.4. The INFORMATIONAL Exchange . . . . . . . . . . . . . . . 16 - 1.4.1. Deleting an SA with INFORMATIONAL Exchanges . . . . . 16 - 1.5. Informational Messages outside of an IKE SA . . . . . . . 17 - 1.6. Requirements Terminology . . . . . . . . . . . . . . . . 18 - 1.7. Differences Between RFC 4306 and This Document . . . . . 18 - 2. IKE Protocol Details and Variations . . . . . . . . . . . . . 20 - 2.1. Use of Retransmission Timers . . . . . . . . . . . . . . 21 - 2.2. Use of Sequence Numbers for Message ID . . . . . . . . . 22 - 2.3. Window Size for Overlapping Requests . . . . . . . . . . 22 - 2.4. State Synchronization and Connection Timeouts . . . . . . 24 - 2.5. Version Numbers and Forward Compatibility . . . . . . . . 26 - 2.6. IKE SA SPIs and Cookies . . . . . . . . . . . . . . . . . 28 - 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . 30 - 2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 31 - 2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 32 - 2.8.1. Simultaneous Child SA rekeying . . . . . . . . . . . 34 - 2.8.2. Rekeying the IKE SA Versus Reauthentication . . . . . 36 - 2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 37 - 2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 40 - 2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 40 - 2.11. Address and Port Agility . . . . . . . . . . . . . . . . 41 - 2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 41 - 2.13. Generating Keying Material . . . . . . . . . . . . . . . 42 - 2.14. Generating Keying Material for the IKE SA . . . . . . . . 43 - 2.15. Authentication of the IKE SA . . . . . . . . . . . . . . 44 - 2.16. Extensible Authentication Protocol Methods . . . . . . . 46 - 2.17. Generating Keying Material for Child SAs . . . . . . . . 48 - 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange . . . . 49 - 2.19. Requesting an Internal Address on a Remote Network . . . 50 - 2.19.1. Configuration Payloads . . . . . . . . . . . . . . . 51 - 2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 53 - 2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 53 - 2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 54 - 2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 55 - 2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 59 - 3. Header and Payload Formats . . . . . . . . . . . . . . . . . 59 - 3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 59 - 3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 62 - 3.3. Security Association Payload . . . . . . . . . . . . . . 64 - 3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 66 - 3.3.2. Transform Substructure . . . . . . . . . . . . . . . 68 - 3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 71 - 3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 71 - 3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 72 - 3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 74 - 3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 75 - 3.5. Identification Payloads . . . . . . . . . . . . . . . . . 75 - 3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 78 - 3.7. Certificate Request Payload . . . . . . . . . . . . . . . 80 - 3.8. Authentication Payload . . . . . . . . . . . . . . . . . 82 - 3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 83 - 3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 84 - 3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 85 - 3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 88 - 3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 90 - 3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 91 - 3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 92 - 3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 94 - 3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 96 - 3.15.1. Configuration Attributes . . . . . . . . . . . . . . 97 - 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 100 - 3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 102 - 3.15.4. Address Assignment Failures . . . . . . . . . . . . . 103 - 3.16. Extensible Authentication Protocol (EAP) Payload . . . . 103 - 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 105 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 107 - 5.1. Traffic selector authorization . . . . . . . . . . . . . 109 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 111 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 111 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 111 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 111 - 8.2. Informative References . . . . . . . . . . . . . . . . . 113 - Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 117 - Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 118 - B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 118 - B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 118 - Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 119 - C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 119 - C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 120 - C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 121 + Exchange . . . . . . . . . . . . . . . . . . . . . . 16 + 1.4. The INFORMATIONAL Exchange . . . . . . . . . . . . . . . 17 + 1.4.1. Deleting an SA with INFORMATIONAL Exchanges . . . . . 18 + 1.5. Informational Messages outside of an IKE SA . . . . . . . 18 + 1.6. Requirements Terminology . . . . . . . . . . . . . . . . 19 + 1.7. Differences Between RFC 4306 and This Document . . . . . 20 + 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 . . . . 32 + 2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 32 + 2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 34 + 2.8.1. Simultaneous Child SA rekeying . . . . . . . . . . . 36 + 2.8.2. Simultaneous IKE SA Rekeying . . . . . . . . . . . . 38 + 2.8.3. Rekeying the IKE SA Versus Reauthentication . . . . . 39 + 2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 39 + 2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 42 + 2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 43 + 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.19.1. Configuration Payloads . . . . . . . . . . . . . . . 53 + 2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 55 + 2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 55 + 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 . . . . . . . . . . . . . 105 + 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 C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying - Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 122 - C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA . . . . 122 - C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 122 - Appendix D. Changes Between Internet Draft Versions . . . . . . 122 - D.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 123 - D.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 123 - D.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 125 - D.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 126 - D.5. Changes from draft -02 to draft -03 . . . . . . . . . . . 127 - D.6. Changes from draft -03 to - draft-ietf-ipsecme-ikev2bis-00 . . . . . . . . . . . . . 128 - D.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to - draft-ietf-ipsecme-ikev2bis-01 . . . . . . . . . . . . . 129 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 133 - Intellectual Property and Copyright Statements . . . . . . . . . 134 + 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 + E.6. Changes from draft -03 to + draft-ietf-ipsecme-ikev2bis-00 . . . . . . . . . . . . . 131 + E.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to + draft-ietf-ipsecme-ikev2bis-01 . . . . . . . . . . . . . 132 + E.8. Changes from draft-ietf-ipsecme-ikev2bis-01 to + draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 136 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 138 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 @@ -611,44 +628,55 @@ {{ 3.10.1-16395 }} The NON_FIRST_FRAGMENTS_ALSO notification is used for fragmentation control. See [IPSECARCH] for a fuller explanation. {{ Clarif-4.6 }} Both parties need to agree to sending non-first fragments before either party does so. It is enabled only if NON_FIRST_FRAGMENTS_ALSO notification is included in both the request proposing an SA and the response accepting it. If the responder does not want to send or receive non-first fragments, it only omits NON_FIRST_FRAGMENTS_ALSO notification from its response, but does not reject the whole Child SA creation. + 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. [[ Note: this text may be changed in the + future. ]] + 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange The CREATE_CHILD_SA request for rekeying an IKE SA is: Initiator Responder ------------------------------------------------------------------- HDR, SK {SA, Ni, [KEi]} --> The initiator sends SA offer(s) in the SA payload, a nonce in the Ni payload, and a Diffie-Hellman value in the KEi payload. The KEi - payload SHOULD be included. New initiator and responder SPIs are + payload MUST be included. New initiator and responder SPIs are supplied in the SPI fields of the SA payload. The CREATE_CHILD_SA response for rekeying an IKE SA is: <-- HDR, SK {SA, Nr,[KEr]} The responder replies (using the same Message ID to respond) with the accepted offer in an SA payload, and a Diffie-Hellman value in the KEr payload if the selected cryptographic suite includes that group. The new IKE SA has its message counters set to 0, regardless of what - they were in the earlier IKE SA. The window size starts at 1 for any - new IKE SA. + they were in the earlier IKE SA. The first IKE requests from both + sides on the new IKE SA will have message ID 0. The old IKE SA + retains its numbering, so any further requests (for example, to + delete the IKE SA) will have consecutive numbering. The new IKE SA + also has its window size reset to 1, and the initiator in this rekey + exchange is the new "original initiator" of the new IKE SA. 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA Exchange The CREATE_CHILD_SA request for rekeying a Child SA is: Initiator Responder ------------------------------------------------------------------- HDR, SK {N, SA, Ni, [KEi], TSi, TSr} --> @@ -780,20 +809,22 @@ {{ Clarif-7.7 }} 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. 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 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 normal fashion. 1.6. Requirements Terminology Definitions of the primitive terms in this document (such as Security @@ -926,36 +957,40 @@ 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). + size (see Section 2.3). In order to allow saving memory, responders + are allowed to forget response after a timeout of several minutes. + If the responder receives a retransmitted request for which it has + already forgotten the response, it MUST ignore the request (and not, + for example, attempt constructing a new response). IKE is a reliable protocol, in the sense that the initiator MUST retransmit a request until either it receives a corresponding reply OR it deems the IKE security association to have failed and it discards all state associated with the IKE SA and any Child SAs negotiated using that IKE SA. A retransmission from the initiator MUST be bitwise identical to the original request. That is, everything starting from the IKE Header (the IKE SA Initiator's SPI onwards) must be bitwise identical; items before it (such as the IP and UDP headers, and the zero non-ESP marker) do not have to be identical. {{ Clarif-2.3 }} Retransmissions of the IKE_SA_INIT request require some special handling. When a responder receives an IKE_SA_INIT - request, it has to determine whether the packet is retransmission + request, it has to determine whether the packet is a retransmission belonging to an existing "half-open" IKE SA (in which case the responder retransmits the same response), or a new request (in which case the responder creates a new IKE SA and sends a fresh response), or it belongs to an existing IKE SA where the IKE_AUTH request has been already received (in which case the responder ignores it). 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, @@ -1333,23 +1369,28 @@ where is a randomly generated secret known only to the responder and periodically changed and | indicates concatenation. should be changed whenever is regenerated. The cookie can be recomputed when the IKE_SA_INIT arrives the second time and compared to the cookie in the received message. If it matches, the responder knows that the cookie was generated since the last change to and that IPi must be the same as the source address it saw the first time. Incorporating SPIi into the calculation ensures that if multiple IKE SAs are being set up in parallel they will all get different cookies (assuming the - initiator chooses unique SPIi's). Incorporating Ni into the hash + 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. + forge a message 3. Also, incorporating Ni in the hash prevents an + attacker from fetching one one cookie from the other end, and then + initiating many IKE_SA_INIT exchanges all with different initiator + SPIs (and perhaps port numbers) so that the responder thinks that + there are lots of machines behind one NAT box who are all trying to + connect. If a new value for is chosen while there are connections in the process of being initialized, an IKE_SA_INIT might be returned with other than the current . The responder in that case MAY reject the message by sending another response with a new cookie or it MAY keep the old value of around for a short time and accept cookies computed from either one. {{ Demoted the SHOULD NOT }} The responder should not accept cookies indefinitely after is changed, since that would defeat part of the denial of service protection. {{ Demoted the SHOULD }} The @@ -1663,21 +1703,55 @@ To B, it looks like A is trying to rekey an SA that no longer exists; thus, B responds to the request with something non-fatal such as NO_PROPOSAL_CHOSEN. <-- send resp1: N(NO_PROPOSAL_CHOSEN) recv resp1 <-- When A receives this error, it already knows there was simultaneous rekeying, so it can ignore the error message. -2.8.2. Rekeying the IKE SA Versus Reauthentication +2.8.2. Simultaneous IKE SA Rekeying + + Probably the most complex case occurs when both peers try to rekey + the IKE_SA at the same time. Basically, the text in Section 2.8 + applies to this case as well; however, it is important to ensure that + the CHILD_SAs are inherited by the right IKE_SA. + + The case where both endpoints notice the simultaneous rekeying works + the same way as with CHILD_SAs. After the CREATE_CHILD_SA exchanges, + three IKE_SAs exist between A and B; the one containing the lowest + nonce inherits the CHILD_SAs. + + However, there is a twist to the other case where one rekeying + finishes first: + + Host A Host B + ------------------------------------------------------------------- + send req1: + SA(..,SPIa1,..),Ni1,.. --> + <-- send req2: SA(..,SPIb1,..),Ni2,.. + --> recv req1 + <-- send resp1: SA(..,SPIb2,..),Nr2,.. + recv resp1 <-- + send req3: D() --> + --> recv req3 + + 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: () + +2.8.3. Rekeying the IKE SA Versus Reauthentication {{ Added this section from Clarif-5.2 }} 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 @@ -1926,21 +2000,23 @@ associated with the exponential only when some corresponding connection was closed. This would allow the exponential to be reused without losing perfect forward secrecy at the cost of maintaining more state. Decisions as to whether and when to reuse Diffie-Hellman exponentials is a private decision in the sense that it will not affect interoperability. An implementation that reuses exponentials MAY choose to remember the exponential used by the other endpoint on past exchanges and if one is reused to avoid the second half of the - calculation. + calculation. See [REUSE] for a security analysis of this practice + and for additional security considerations when reusing ephemeral DH + keys. 2.13. Generating Keying Material In the context of the IKE SA, four cryptographic algorithms are negotiated: an encryption algorithm, an integrity protection algorithm, a Diffie-Hellman group, and a pseudo-random function (prf). The pseudo-random function is used for the construction of keying material for all of the cryptographic algorithms used in both the IKE SA and the Child SAs. @@ -2260,54 +2337,56 @@ 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). {{ Clarif-5.3 }} 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) + 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. {{ Clarif-5.5 }} The old and new IKE SA may have selected a different PRF. Because the rekeying exchange belongs to the old IKE SA, it is the old IKE SA's PRF that is used. - {{ Clarif-5.12}} The main rekeying the IKE SA is to ensure that the - compromise of old keying material does not provide information about - the current keys, or vice versa. Therefore, implementations SHOULD - perform a new Diffie-Hellman exchange when rekeying the IKE SA. In - other words, an initiator SHOULD NOT propose the value "NONE" for the - D-H transform, and a responder SHOULD NOT accept such a proposal. - This means that a succesful exchange rekeying the IKE SA always - includes the KEi/KEr payloads. + {{ Clarif-5.12}} The main reason for rekeying the IKE SA is to ensure + that the compromise of old keying material does not provide + information about the current keys, or vice versa. Therefore, + implementations MUST perform a new Diffie-Hellman exchange when + rekeying the IKE SA. In other words, an initiator MUST NOT propose + the value "NONE" for the D-H transform, and a responder MUST NOT + accept such a proposal. This means that a succesful exchange + rekeying the IKE SA always includes the KEi/KEr payloads. The new IKE SA MUST reset its message counters to 0. SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as specified in Section 2.14. 2.19. Requesting an Internal Address on a Remote Network Most commonly occurring in the endpoint-to-security-gateway scenario, an endpoint may need an IP address in the network protected by the security gateway and may need to have that address dynamically assigned. A request for such a temporary address can be included in any request to create a Child SA (including the implicit request in - message 3) by including a CP payload. + message 3) by including a CP payload. Note, however, it is usual to + only assign one IP address during the IKE_AUTH exchange. That + address persists at least until the deletion of the IKE SA. This function provides address allocation to an IPsec Remote Access Client (IRAC) trying to tunnel into a network protected by an IPsec Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an IKE SA and a Child SA, the IRAC MUST request the IRAS-controlled address (and optionally other information concerning the protected network) in the IKE_AUTH exchange. The IRAS may procure an address for the IRAC from any number of sources such as a DHCP/BOOTP server or its own address pool. @@ -2626,20 +2705,32 @@ 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. {{ Clarif-7.6 }} An IPsec endpoint that discovers a NAT between it and its correspondent MUST send all subsequent traffic from port 4500, which NATs should not treat specially (as they might with port 500). + An initiator can float to port 4500, regardless whether or not there + is NAT, even at the beginning of IKE. When either side is using port + 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. + 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 packets Notify payloads of type NAT_DETECTION_SOURCE_IP and @@ -3500,24 +3590,28 @@ 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 DH Group # identifies the Diffie-Hellman group in which the Key - Exchange Data was computed (see Section 3.3.2). 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. + 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. The payload type for the Key Exchange payload is thirty four (34). 3.5. Identification Payloads The Identification Payloads, denoted IDi and IDr in this memo, allow peers to assert an identity to one another. This identity may be used for policy lookup, but does not necessarily have to match anything in the CERT payload; both fields may be used by an implementation to perform access control decisions. {{ Clarif-7.1 }} @@ -4026,21 +4120,26 @@ {{ Demoted the SHOULD }} To aid debugging, more detailed error information should be written to a console or log. INVALID_MESSAGE_ID 9 See Section 2.3. INVALID_SPI 11 See Section 1.5. NO_PROPOSAL_CHOSEN 14 - See Section 2.7. + None of the proposed crypto suites was acceptable. This can be + sent in any case where the offered proposal (including but not + limited to SA payload values, USE_TRANSPORT_MODE notify, + IPCOMP_SUPPORTED notify) are not acceptable for the responder. + This can also be used as "generic" Child SA error when Child SA + cannot be created for some other reason. See also Section 2.7. INVALID_KE_PAYLOAD 17 See Section 1.3. AUTHENTICATION_FAILED 24 Sent in the response to an IKE_AUTH message when for some reason the authentication failed. There is no associated data. SINGLE_PAIR_REQUIRED 34 See Section 2.9. @@ -4434,25 +4533,25 @@ was no natural place to put the type of the first one, that type is placed here. o Payload Length - Includes the lengths of the header, IV, Encrypted IKE Payloads, Padding, Pad Length, and Integrity Checksum Data. o Initialization Vector - For CBC mode ciphers, the length of the initialization vector (IV) is equal to the block length of the underlying encryption algorithm. Senders MUST select a new unpredictable IV for every message; recipients MUST accept any - value. For other modes than CBC, the IV format and processing is - specified in the document specifying the encryption algorithm and - mode. The reader is encouraged to consult [MODES] for advice on + value. The reader is encouraged to consult [MODES] for advice on IV generation. In particular, using the final ciphertext block of - the previous message is not considered unpredictable. + the previous message is not considered unpredictable. For modes + other than CBC, the IV format and processing is specified in the + document specifying the encryption algorithm and mode. o IKE Payloads are as specified earlier in this section. This field is encrypted with the negotiated cipher. o Padding MAY contain any value chosen by the sender, and MUST have a length that makes the combination of the Payloads, the Padding, and the Pad Length to be a multiple of the encryption block size. This field is encrypted with the negotiated cipher. o Pad Length is the length of the Padding field. The sender SHOULD @@ -5018,20 +5117,28 @@ groups nor is there anything that will dilute the strength obtained from stronger groups (limited by the strength of the other algorithms negotiated including the prf function). In fact, the extensible framework of IKE encourages the definition of more groups; use of elliptical curve groups may greatly increase strength using much smaller numbers. It is assumed that all Diffie-Hellman exponents are erased from memory after use. + The IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator + has been authenticated. As a result, an implementation of this + protocol needs to be completely robust when deployed on any insecure + network. Implementation vulnerabilities, particularly denial-of- + service attacks, can be exploited by unauthenticated peers. This + issue is particularly worrisome because of the unlimited number of + messages in EAP-based authentication. + The strength of all keys is limited by the size of the output of the negotiated prf function. For this reason, a prf function whose output is less than 128 bits (e.g., 3DES-CBC) MUST NOT be used with this protocol. The security of this protocol is critically dependent on the randomness of the randomly chosen parameters. These should be generated by a strong random or properly seeded pseudo-random source (see [RANDOMNESS]). Implementers should take care to ensure that use of random numbers for both keys and nonces is engineered in a fashion @@ -5408,20 +5515,25 @@ "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. [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. @@ -5682,45 +5794,53 @@ C.6. INFORMATIONAL Exchange request --> [N+], [D+], [CP(CFG_REQUEST)] response <-- [N+], [D+], [CP(CFG_REPLY)] -Appendix D. Changes Between Internet Draft Versions +Appendix D. Significant Changes from RFC 4306 + + This is a placeholder that will be filled in. The WG needs to decide + what level of specificity is most useful here. For example, it might + only be changes that involve SHOULD-level or MUST-level requirements, + or it might also include additional "significant" advice that was + added. + +Appendix E. Changes Between Internet Draft Versions This section will be removed before publication as an RFC, but should be left intact until then so that reviewers can follow what has changed. -D.1. Changes from IKEv2 to draft -00 +E.1. Changes from IKEv2 to draft -00 There were a zillion additions from RFC 4718. These are noted with "{{ Clarif-nn }}". Cleaned up many of the figures. Made the table headings consistent. Made some tables easier to read by removing blank spaces. Removed the "reserved to IANA" and "private use" text wording and moved it into the tables. Changed many SHOULD requirements to better match RFC 2119. These are also marked with comments such as "{{ Demoted the SHOULD }}". In Section 2.16, changed the MUST requirement of authenticating the responder from "public key signature based" to "strong" because that is what most current IKEv2 implementations do, and it better matches the actual security requirement. -D.2. Changes from draft -00 to draft -01 +E.2. Changes from draft -00 to draft -01 The most significant technical change was to make KE optional but strongly recommended in Section 1.3.2. Updated all references to the IKEv2 Clarifications document to RFC 4718. Moved a lot of the protocol description out of the long tables in Section 3.10.1 into the body of the document. These are noted with "{{ 3.10.1-nnnn }}", where "nnnn" is the notification type number. @@ -5812,39 +5932,39 @@ address is valid until there are no IKE SAs between the peers." In Section 3.15.1, changed "INTERNAL_IP6_NBNS" to unspecified. Made [ADDRIPV6] an informative reference instead of a normative reference and updated it. Made [PKCS1] a normative reference instead of an informative reference and changed the pointer to RFC 3447. -D.3. Changes from draft -00 to draft -01 +E.3. Changes from draft -00 to draft -01 In Section 1.5, added "request" to first sentence to make it "If an encrypted IKE request packet arrives on port 500 or 4500 with an unrecognized SPI...". In Section 3.3, fifth paragraph, upped the number of transforms for AH and ESP by one each to account for ESN, which is now mandatory. In Section 2.1, added "or equal to" in "The responder MUST remember each response until it receives a request whose sequence number is larger than or equal to the sequence number in the response plus its window size." In Section 2.18, removed " Note that this may not work if the new IKE SA's PRF has a fixed key size because the output of the PRF may not be of the correct size." because it is no longer relevant. -D.4. Changes from draft -01 to draft -02 +E.4. Changes from draft -01 to draft -02 Many grammatical fixes. In Section 1.2, reworded Clarif-4.3 to be clearer. In Section 1.3.3, reworded 3.10.1-16393 and Clarif-5.4 to remove redundant text. In Section 2.13, replaced text about variable length keys with clearer explanation and requirement on non-HMAC PRFs. Also added @@ -5882,21 +6002,21 @@ In Section 3.10, clarified 3.10.1-16394. Updated Section 6 to indicate that there is nothing new for IANA in this spec. Also removed the definition of "Expert Review" from Section 1.6 for the same reason. In Appendix A, removed "and not commit any state to an exchange until the initiator can be cryptographically authenticated" because that was only true in an earlier version of IKEv2. -D.5. Changes from draft -02 to draft -03 +E.5. Changes from draft -02 to draft -03 In Section 1.3, changed "If the responder rejects the Diffie-Hellman group of the KEi payload, the responder MUST reject the request and indicate its preferred Diffie-Hellman group in the INVALID_KE_PAYLOAD Notification payload." to "If the responder selects a proposal using a different Diffie-Hellman group (other than NONE), the responder MUST reject the request and indicate its preferred Diffie-Hellman group in the INVALID_KE_PAYLOAD Notification payload. In Section 2.3, added the last two paragraphs covering why you @@ -5952,21 +6071,21 @@ modes, and to clarify which encryption and integrity protection we are talking about. Changed the "Initialization Vector" bullet in Section 3.14 to specify better what is needed for the IV. Upgraded the SHOULDs to MUSTs. Also added the reference for [MODES]. In Section 5, in the second-to-last paragraph, changed "a public-key- based" to "strong" to match the wording in Section 2.16. -D.6. Changes from draft -03 to draft-ietf-ipsecme-ikev2bis-00 +E.6. Changes from draft -03 to draft-ietf-ipsecme-ikev2bis-00 Changed the document's filename to draft-ietf-ipsecme-ikev2bis-00. Added Yoav Nir as a co-author. In many places in the document, changed "and/or" to "or" when talking about combinations of ESP and AH SAs. For example, in the intro, it said "can be used to efficiently establish SAs for Encapsulating Security Payload (ESP) and/or Authentication Header (AH)". This is changed to "or" to indicate that you can only establish one type of SA at a time. @@ -5973,27 +6092,28 @@ In Section 1, clarified that RFC 4306 already replaced IKEv1, and that this document replaces RFC 4306. Also fixed Section 2.5 for similar issue. Also updated the Abstract to cover this. In Section 2.15, in the responder's signed octets, changed: RestOfRespIDPayload = IDType | RESERVED | InitIDData to RestOfRespIDPayload = IDType | RESERVED | RespIDData + In 2.16, changed "strong" back to "public key signature based" to make it the same as 4306. In section 3.10, added "and the field must be empty" to make it clear that a zero-length SPI is really empty. -D.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to +E.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to draft-ietf-ipsecme-ikev2bis-01 Throughout, changed "IKE_SA" to "IKE SA", and changed "CHILD_SA" to "Child SA" (except left "CREATE_CHILD_SA" alone). Added the middle sentence in the Abstract to say what IKE actually does. Added in section 1 "(unless there is failure setting up the AH or ESP Child SA, in which case the IKE SA is still established without IPsec @@ -6173,20 +6294,120 @@ most implementations to do so. Updated a bunch of reference to their newer versions. Added "[V+]" to the end of the exchanges in C.4 and C.5. Added two more response templates to Appendix C.1. Added another response template in Appendix C.2. Added two more responses in Appendix C.4. +E.8. Changes from draft-ietf-ipsecme-ikev2bis-01 to + 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 + 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 + to 1, and the initiator in this rekey exchange is the new "original + initiator" of the new IKE SA." [Issue #65] + + Added to section 1.5: For a one-way INVALID_IKE_SPI notification for + an unrecognized SPI, the responder SHOULD copy the Exchange Type from + the request. [Issue #46] + + In 2.1, at the end of the paragraph about retransmission timers, + added "In order to allow saving memory, responders are allowed to + forget response after a timeout of several minutes. If the responder + receives a retransmitted request for which it has already forgotten + the response, it MUST ignore the request (and not, for example, + attempt constructing a new response)." [Issue #14] + + In 2.6, added: "Also, incorporating Ni in the hash prevents an + attacker from fetching one 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." [Issue #19] + + Added text for the new 2.8.2, and bumped the section number of the + old 2.8.2 to 2.8.3. [Issue #22] + + Added a reference to the end of 2.12 on key reuse. + + Added to the end of the first paragraph in 2.19: Note, however, it is + usual to only assign one IP address during the IKE_AUTH exchange. + That address persists at least until the deletion of the IKE SA. + [Issue #79] + + Added the following to 2.23: An initiator can float to port 4500, + regardless whether or not there is NAT, even at the beginning of IKE. + When either side is using port 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. [Issue #40] + + The second-to-last paragraph in section 3.4 is changed to: 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. [Issue #30] + + In 3.10.1, changed the definition of NO_PROPOSAL_CHOSEN, 14, to: None + of the proposed crypto suites was acceptable. This can be sent in + any case where the offered proposal (including but not limited to SA + payload values, USE_TRANSPORT_MODE notify, IPCOMP_SUPPORTED notify) + are not acceptable for the responder. This can also be used as + "generic" Child SA error when Child SA cannot be created for some + other reason. See also Section 2.7. [Issue #81] + + In the description of IVs in 3.14, reorganized the text a bit to + emphasize when we are and are not talking about CBC. [Issue #68] + + Added the following to section 5 (Security Considerations): "The + IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator has + been authenticated. As a result, an implementation of this protocol + needs to be completely robust when deployed on any insecure network. + Implementation vulnerabilities, particularly denial-of-service + attacks, can be exploited by unauthenticated peers. This issue is + particularly worrisome because of the unlimited number of messages in + EAP-based authentication." [Issue #62] + + Added new Appendix D, "Significant Changes from RFC 4306", as a + placeholder for now. [Issue #3] + Authors' Addresses Charlie Kaufman Microsoft 1 Microsoft Way Redmond, WA 98052 US Phone: 1-425-707-3335 Email: charliek@microsoft.com @@ -6208,55 +6428,10 @@ Email: ynir@checkpoint.com Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland Email: pasi.eronen@nokia.com - -Full Copyright Statement - - Copyright (C) The IETF Trust (2008). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA).