--- 1/draft-ietf-ipsecme-ikev2bis-02.txt 2009-04-25 00:12:05.000000000 +0200 +++ 2/draft-ietf-ipsecme-ikev2bis-03.txt 2009-04-25 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: August 30, 2009 Check Point +Expires: October 26, 2009 Check Point P. Eronen Nokia - February 26, 2009 + April 24, 2009 Internet Key Exchange Protocol: IKEv2 - draft-ietf-ipsecme-ikev2bis-02 + draft-ietf-ipsecme-ikev2bis-03 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 August 30, 2009. + This Internet-Draft will expire on October 26, 2009. 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. @@ -105,85 +105,89 @@ 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.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 58 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 + 3. Header and Payload Formats . . . . . . . . . . . . . . . . . 62 + 3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 62 + 3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 65 + 3.3. Security Association Payload . . . . . . . . . . . . . . 67 + 3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 69 + 3.3.2. Transform Substructure . . . . . . . . . . . . . . . 71 + 3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 74 + 3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 74 + 3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 75 + 3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 77 + 3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 78 + 3.5. Identification Payloads . . . . . . . . . . . . . . . . . 79 + 3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 81 + 3.7. Certificate Request Payload . . . . . . . . . . . . . . . 83 + 3.8. Authentication Payload . . . . . . . . . . . . . . . . . 85 + 3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 87 + 3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 87 + 3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 88 + 3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 91 + 3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 93 + 3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 94 + 3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 95 + 3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 97 + 3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 99 + 3.15.1. Configuration Attributes . . . . . . . . . . . . . . 100 + 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 103 + 3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 105 + 3.15.4. Address Assignment Failures . . . . . . . . . . . . . 106 + 3.16. Extensible Authentication Protocol (EAP) Payload . . . . 106 + 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 108 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 110 + 5.1. Traffic selector authorization . . . . . . . . . . . . . 113 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 114 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 114 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 115 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 115 + 8.2. Informative References . . . . . . . . . . . . . . . . . 116 + Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 120 + Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 121 + B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 122 + B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 122 + Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 122 + C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 123 + C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 124 + C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 125 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 . . . . . . . . . . . . . . . . . . . . . . . . 126 + C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA . . . . 126 + C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 126 + Appendix D. Significant Changes from RFC 4306 . . . . . . . . . 126 + Appendix E. Changes Between Internet Draft Versions . . . . . . 127 + E.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 127 + E.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 127 + E.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 129 + E.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 130 + E.5. Changes from draft -02 to draft -03 . . . . . . . . . . . 131 E.6. Changes from draft -03 to - draft-ietf-ipsecme-ikev2bis-00 . . . . . . . . . . . . . 131 + draft-ietf-ipsecme-ikev2bis-00 . . . . . . . . . . . . . 132 E.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to - draft-ietf-ipsecme-ikev2bis-01 . . . . . . . . . . . . . 132 + draft-ietf-ipsecme-ikev2bis-01 . . . . . . . . . . . . . 133 E.8. Changes from draft-ietf-ipsecme-ikev2bis-01 to - draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 136 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 138 + draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 137 + E.9. Changes from draft-ietf-ipsecme-ikev2bis-01 to + draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 139 + E.10. Changes from draft-ietf-ipsecme-ikev2bis-02 to + draft-ietf-ipsecme-ikev2bis-03 . . . . . . . . . . . . . 140 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 140 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 @@ -641,21 +645,21 @@ 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]} --> + HDR, SK {SA, Ni, KEi} --> The initiator sends SA offer(s) in the SA payload, a nonce in the Ni payload, and a Diffie-Hellman value in the KEi payload. The KEi payload MUST be included. New initiator and responder SPIs are supplied in the SPI fields of the SA payload. The CREATE_CHILD_SA response for rekeying an IKE SA is: <-- HDR, SK {SA, Nr,[KEr]} @@ -1033,51 +1037,45 @@ the "original responder" starts rekeying the IKE SA, that party becomes the "original initiator" of the new IKE SA. Note that Message IDs are cryptographically protected and provide protection against message replays. In the unlikely event that Message IDs grow too large to fit in 32 bits, the IKE SA MUST be closed or rekeyed. 2.3. Window Size for Overlapping Requests - In order to maximize IKE throughput, an IKE endpoint MAY issue - multiple requests before getting a response to any of them if the - other endpoint has indicated its ability to handle such requests. - For simplicity, an IKE implementation MAY choose to process requests - strictly in order and/or wait for a response to one request before - issuing another. Certain rules must be followed to ensure - interoperability between implementations using different strategies. - - After an IKE SA is set up, either end can initiate one or more - requests. These requests may pass one another over the network. An - IKE endpoint MUST be prepared to accept and process a request while - it has a request outstanding in order to avoid a deadlock in this - situation. {{ Downgraded the SHOULD }} An IKE endpoint may also - accept and process multiple requests while it has a request - outstanding. - {{ 3.10.1-16385 }} The SET_WINDOW_SIZE notification asserts that the sending endpoint is capable of keeping state for multiple outstanding exchanges, permitting the recipient to send multiple requests before getting a response to the first. The data associated with a SET_WINDOW_SIZE notification MUST be 4 octets long and contain the big endian representation of the number of messages the sender promises to keep. The window size is always one until the initial exchanges complete. An IKE endpoint MUST wait for a response to each of its messages before sending a subsequent message unless it has received a SET_WINDOW_SIZE Notify message from its peer informing it that the peer is prepared to maintain state for multiple outstanding messages in order to allow greater throughput. + After an IKE SA is set up, in order to maximize IKE throughput, an + IKE endpoint MAY issue multiple requests before getting a response to + any of them, up to the limit set by its peer's SET_WINDOW_SIZE. + These requests may pass one another over the network. An IKE + endpoint MUST be prepared to accept and process a request while it + has a request outstanding in order to avoid a deadlock in this + situation. {{ Downgraded the SHOULD }} An IKE endpoint may also + accept and process multiple requests while it has a request + outstanding. + An IKE endpoint MUST NOT exceed the peer's stated window size for transmitted IKE requests. In other words, if the responder stated its window size is N, then when the initiator needs to make a request X, it MUST wait until it has received responses to all requests up through request X-N. An IKE endpoint MUST keep a copy of (or be able to regenerate exactly) each request it has sent until it receives the corresponding response. An IKE endpoint MUST keep a copy of (or be able to regenerate exactly) the number of previous responses equal to its declared window size in case its response was lost and the initiator requests its retransmission by retransmitting the request. @@ -1117,23 +1115,23 @@ {{ 3.10.1-16384 }} The INITIAL_CONTACT notification asserts that this IKE SA is the only IKE SA currently active between the authenticated identities. It MAY be sent when an IKE SA is established after a crash, and the recipient MAY use this information to delete any other IKE SAs it has to the same authenticated identity without waiting for a timeout. This notification MUST NOT be sent by an entity that may be replicated (e.g., a roaming user's credentials where the user is allowed to connect to the corporate firewall from two remote systems at the same time). {{ Clarif-7.9 }} The INITIAL_CONTACT notification, - if sent, MUST be in the first IKE_AUTH request, not as a separate - exchange afterwards; however, receiving parties need to deal with it - in other requests. + if sent, MUST be in the first IKE_AUTH request or response, not as a + separate exchange afterwards; however, receiving parties MAY ignore + it in other messages. Since IKE is designed to operate in spite of Denial of Service (DoS) attacks from the network, an endpoint MUST NOT conclude that the other endpoint has failed based on any routing information (e.g., ICMP messages) or IKE messages that arrive without cryptographic protection (e.g., Notify messages complaining about unknown SPIs). An endpoint MUST conclude that the other endpoint has failed only when repeated attempts to contact it have gone unanswered for a timeout period or when a cryptographically protected INITIAL_CONTACT notification is received on a different IKE SA to the same @@ -2175,21 +2172,26 @@ insecure because user-chosen passwords are unlikely to have sufficient unpredictability to resist dictionary attacks and these attacks are not prevented in this authentication method. (Applications using password-based authentication for bootstrapping and IKE SA should use the authentication method in Section 2.16, which is designed to prevent off-line dictionary attacks.) {{ Demoted the SHOULD }} The pre-shared key needs to contain as much unpredictability as the strongest key being negotiated. In the case of a pre-shared key, the AUTH value is computed as: - AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), ) + For the initiator: + AUTH = prf( prf( Shared Secret,"Key Pad for IKEv2"), + ) + For the responder: + AUTH = prf( prf( Shared Secret,"Key Pad for IKEv2"), + ) where the string "Key Pad for IKEv2" is 17 ASCII characters without null termination. The shared secret can be variable length. The pad string is added so that if the shared secret is derived from a password, the IKE implementation need not store the password in cleartext, but rather can store the value prf(Shared Secret,"Key Pad for IKEv2"), which could not be used as a password equivalent for protocols other than IKEv2. As noted above, deriving the shared secret from a password is not secure. This construction is used because it is anticipated that people will do it anyway. The @@ -2809,20 +2811,37 @@ are still alive (for example, the keepalive interval is too long, or the NAT box is rebooted). To recover in these cases, hosts that are not behind a NAT SHOULD send all packets (including retransmission packets) to the IP address and port from the last valid authenticated packet from the other end (i.e., dynamically update the address). A host behind a NAT SHOULD NOT do this because it opens a DoS attack possibility. 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. + o There are cases where a NAT box decides to remove mappings that + are still alive (for example, the keepalive interval is too long, + or the NAT box is rebooted). To recover in these cases, hosts + that do not support other methods of recovery such as MOBIKE + [MOBIKE], and that are not behind a NAT, SHOULD send all packets + (including retransmission packets) to the IP address and port from + the last valid authenticated packet from the other end (that is, + they should dynamically update the address). A host behind a NAT + SHOULD NOT do this because it opens a possible denial-of-service + attack. Any authenticated IKE packet or any authenticated UDP- + encapsulated ESP packet can be used to detect that the IP address + or the port has changed. When IKEv2 is used with MOBIKE, + dynamically updating the addresses described above interferes with + MOBIKE's way of recovering from the same situation, so this method + MUST NOT be used when MOBIKE is used. See Section 3.8 of [MOBIKE] + for more information. + 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 @@ -2948,21 +2967,21 @@ * I(nitiator) (bit 3 of Flags) - This bit MUST be set in messages sent by the original initiator of the IKE SA and MUST be cleared in messages sent by the original responder. It is used by the recipient to determine which eight octets of the SPI were generated by the recipient. This bit changes to reflect who initiated the last rekey of the IKE SA. * V(ersion) (bit 4 of Flags) - This bit indicates that the transmitter is capable of speaking a higher major version number of the protocol than the one indicated in the major - version number field. Implementations of IKEv2 must clear this + version number field. Implementations of IKEv2 MUST clear this bit when sending and MUST ignore it in incoming messages. * R(esponse) (bit 5 of Flags) - This bit indicates that this message is a response to a message containing the same message ID. This bit MUST be cleared in all request messages and MUST be set in all responses. An IKE endpoint MUST NOT generate a response to a message that is marked as being a response. * X(reserved) (bits 6-7 of Flags) - These bits MUST be cleared when sending and MUST be ignored on receipt. @@ -3523,21 +3543,21 @@ upgrading endpoints independently, implementers of this protocol SHOULD accept values that they deem to supply greater security. For instance, if a peer is configured to accept a variable-length cipher with a key length of X bits and is offered that cipher with a larger key length, the implementation SHOULD accept the offer if it supports use of the longer key. Support of this capability allows a responder to express a concept of "at least" a certain level of security -- "a key length of _at least_ X bits for cipher Y". However, as the attribute is always returned - unchanged (see Section 3.3.6), an initiator willing to accept + unchanged (see the next section), an initiator willing to accept multiple key lengths has to include multiple transforms with the same Transform Type, each with different Key Length attribute. 3.3.6. Attribute Negotiation During security association negotiation initiators present offers to responders. Responders MUST select a single complete set of parameters from the offers (or reject all offers if none are acceptable). If there are multiple proposals, the responder MUST choose a single proposal. If the selected proposal has multiple @@ -3548,33 +3568,37 @@ that response MUST be rejected. If the responder receives a proposal that contains a Transform Type it does not understand, or a proposal that is missing a mandatory Transform Type, it MUST consider this proposal unacceptable; however, other proposals in the same SA payload are processed as usual. Similarly, if the responder receives a transform that contains a Transform Attribute it does not understand, it MUST consider this transform unacceptable; other transforms with the same Transform Type are processed as usual. This allows new Transform Types and - Transform Attributes to be defined in the future. + Transform Attributes to be defined in the future. An exception is + the case where one of the proposals offered is for the Diffie-Hellman + group of NONE. In this case, the responder MUST ignore the + initiator's KE payload and omit the KE payload from the response. Negotiating Diffie-Hellman groups presents some special challenges. SA offers include proposed attributes and a Diffie-Hellman public number (KE) in the same message. If in the initial exchange the initiator offers to use one of several Diffie-Hellman groups, it SHOULD pick the one the responder is most likely to accept and - include a KE corresponding to that group. If the guess turns out to - be wrong, the responder will indicate the correct group in the - response and the initiator SHOULD pick an element of that group for - its KE value when retrying the first message. It SHOULD, however, - continue to propose its full supported set of groups in order to - prevent a man-in-the-middle downgrade attack. + include a KE corresponding to that group. If the responder selects a + proposal using a different Diffie-Hellman group (other than NONE), + the responder will indicate the correct group in the response and the + initiator SHOULD pick an element of that group for its KE value when + retrying the first message. It SHOULD, however, continue to propose + its full supported set of groups in order to prevent a man-in-the- + middle downgrade attack. 3.4. Key Exchange Payload The Key Exchange Payload, denoted KE in this memo, is used to exchange Diffie-Hellman public numbers as part of a Diffie-Hellman key exchange. The Key Exchange Payload consists of the IKE generic payload header followed by the Diffie-Hellman public value itself. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 @@ -3590,21 +3614,21 @@ 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. This Group # MUST + Exchange Data was computed (see Section 3.3.2). This Group # MUST match a DH Group specified in a proposal in the SA payload that is 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). @@ -5202,20 +5224,29 @@ additional IKEv2 protocol variations and protects the EAP data from active attackers. If the messages of IKEv2 are long enough that IP-level fragmentation is necessary, it is possible that attackers could prevent the exchange from completing by exhausting the reassembly buffers. The chances of this can be minimized by using the Hash and URL encodings instead of sending certificates (see Section 3.6). Additional mitigations are discussed in [DOSUDPPROT]. + Admission control is critical to the security of the protocol. For + example, trust anchors used for identifying IKE peers should probably + be different than those used for other forms of trust, such as those + used to identify public web servers. Moreover, although IKE provides + a great deal of leeway in defining the security policy for a trusted + peer's identity, credentials, and the correlation between them, + having such security policy defined explicitly is essential to a + secure implementation. + 5.1. Traffic selector authorization {{ Added this section from Clarif-4.13 }} IKEv2 relies on information in the Peer Authorization Database (PAD) when determining what kind of IPsec SAs a peer is allowed to create. This process is described in [IPSECARCH] Section 4.4.3. When a peer requests the creation of an IPsec SA with some traffic selectors, the PAD must contain "Child SA Authorization Data" linking the identity authenticated by IKEv2 and the addresses permitted for traffic @@ -5484,20 +5515,23 @@ [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [MIPV6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [MLDV2] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. + [MOBIKE] Eronen, P., "IKEv2 Mobility and Multihoming Protocol + (MOBIKE)", RFC 4555, June 2006. + [MODES] National Institute of Standards and Technology, U.S. Department of Commerce, "Recommendation for Block Cipher Modes of Operation", SP 800-38A, 2001. [NAI] Aboba, B., Beadles, M., Eronen, P., and J. Arkko, "The Network Access Identifier", RFC 4282, December 2005. [NATREQ] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004. @@ -5672,131 +5706,131 @@ Vendor-ID (V) payloads may be included in any place in any message. This sequence here shows what are the most logical places for them. C.1. IKE_SA_INIT Exchange request --> [N(COOKIE)], SA, KE, Ni, [N(NAT_DETECTION_SOURCE_IP)+, N(NAT_DETECTION_DESTINATION_IP)], - [V+] + [V+][N+] normal response <-- SA, KE, Nr, (no cookie) [N(NAT_DETECTION_SOURCE_IP), N(NAT_DETECTION_DESTINATION_IP)], [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], - [V+] + [V+][N+] cookie response <-- N(COOKIE), - [V+] + [V+][N+] different D-H <-- N(INVALID_KE_PAYLOAD), - group wanted [V+] + group wanted [V+][N+] C.2. IKE_AUTH Exchange without EAP request --> IDi, [CERT+], [N(INITIAL_CONTACT)], [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], [IDr], AUTH, [CP(CFG_REQUEST)], [N(IPCOMP_SUPPORTED)+], [N(USE_TRANSPORT_MODE)], [N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(NON_FIRST_FRAGMENTS_ALSO)], SA, TSi, TSr, - [V+] + [V+][N+] response <-- IDr, [CERT+], AUTH, [CP(CFG_REPLY)], [N(IPCOMP_SUPPORTED)], [N(USE_TRANSPORT_MODE)], [N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(NON_FIRST_FRAGMENTS_ALSO)], SA, TSi, TSr, [N(ADDITIONAL_TS_POSSIBLE)], - [V+] + [V+][N+] error in Child SA <-- IDr, [CERT+], creation AUTH, N(error), - [V+] + [V+][N+] C.3. IKE_AUTH Exchange with EAP first request --> IDi, [N(INITIAL_CONTACT)], [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], [IDr], [CP(CFG_REQUEST)], [N(IPCOMP_SUPPORTED)+], [N(USE_TRANSPORT_MODE)], [N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(NON_FIRST_FRAGMENTS_ALSO)], SA, TSi, TSr, - [V+] + [V+][N+] first response <-- IDr, [CERT+], AUTH, EAP, - [V+] + [V+][N+] / --> EAP repeat 1..N times | \ <-- EAP last request --> AUTH last response <-- AUTH, [CP(CFG_REPLY)], [N(IPCOMP_SUPPORTED)], [N(USE_TRANSPORT_MODE)], [N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(NON_FIRST_FRAGMENTS_ALSO)], SA, TSi, TSr, [N(ADDITIONAL_TS_POSSIBLE)], - [V+] + [V+][N+] C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying Child SAs request --> [N(REKEY_SA)], [CP(CFG_REQUEST)], [N(IPCOMP_SUPPORTED)+], [N(USE_TRANSPORT_MODE)], [N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(NON_FIRST_FRAGMENTS_ALSO)], SA, Ni, [KEi], TSi, TSr - [V+] + [V+][N+] normal <-- [CP(CFG_REPLY)], response [N(IPCOMP_SUPPORTED)], [N(USE_TRANSPORT_MODE)], [N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(NON_FIRST_FRAGMENTS_ALSO)], SA, Nr, [KEr], TSi, TSr, [N(ADDITIONAL_TS_POSSIBLE)] - [V+] + [V+][N+] error case <-- N(error) different D-H <-- N(INVALID_KE_PAYLOAD), - group wanted [V+] + group wanted [V+][N+] C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA request --> SA, Ni, [KEi] - [V+] + [V+][N+] response <-- SA, Nr, [KEr] - [V+] + [V+][N+] C.6. INFORMATIONAL Exchange request --> [N+], [D+], [CP(CFG_REQUEST)] response <-- [N+], [D+], [CP(CFG_REPLY)] @@ -6394,20 +6428,86 @@ been authenticated. As a result, an implementation of this protocol needs to be completely robust when deployed on any insecure network. Implementation vulnerabilities, particularly denial-of-service attacks, can be exploited by unauthenticated peers. This issue is particularly worrisome because of the unlimited number of messages in EAP-based authentication." [Issue #62] Added new Appendix D, "Significant Changes from RFC 4306", as a placeholder for now. [Issue #3] +E.9. Changes from draft-ietf-ipsecme-ikev2bis-01 to + draft-ietf-ipsecme-ikev2bis-02 + + Near the end of 1.3, changed "If the guess turns out to be wrong, the + responder will indicate the correct group in the response and the + initiator SHOULD pick an element of that group for its KE value when + retrying the first message." to "If the responder selects a proposal + using a different Diffie-Hellman group (other than NONE), the + responder will indicate the correct group in the response and the + initiator SHOULD pick an element of that group for its KE value when + retrying the first message." [Issue #6] + + In the figures in 1.3.2, changed the diagrams from "HDR, SK {SA, Ni, + [KEi]}" to "HDR, SK {SA, Ni, KEi}", and "HDR, SK {SA, Nr,[KEr]}" to + "HDR, SK {SA, Nr,KEr}". This matches the text in the section, which + was updated in the last revision. [Issue #50] + + Reorganized the beginning of section 2.3 and clarified some of the + logic. [Issue #52] + + Clarified the octets to be signed in setion 2.15. Changed + + AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), ) + + to + For the initiator: + AUTH = prf( prf( Shared Secret,"Key Pad for IKEv2"), + ) + For the responder: + AUTH = prf( prf( Shared Secret,"Key Pad for IKEv2"), + ) + + [Issue #72] + + Changed the last bullet item in section 2.23 to discuss MOBIKE in + more detail. [Issue #41] + + In section 3.1, the bullet about bit 4, changed "must" to "MUST". + + In section 3.3.6, added two sentences at the end of the second + paragraph to indicate that there is an exception for when the + proposal is a DH group of NONE. [Issue #6] + +E.10. Changes from draft-ietf-ipsecme-ikev2bis-02 to + draft-ietf-ipsecme-ikev2bis-03 + + In section 2.4, change "The INITIAL_CONTACT notification, if sent, + MUST be in the first IKE_AUTH request, not as a separate exchange + afterwards; however, receiving parties need to deal with it in other + requests." to "The INITIAL_CONTACT notification, if sent, MUST be in + the first IKE_AUTH request or response, not as a separate exchange + afterwards; however, receiving parties MAY ignore it in other + messages." [Issue #53] + + Added to the security considerations: "Admission control is critical + to the security of the protocol. For example, trust anchors used for + identifying IKE peers should probably be different than those used + for other forms of trust, such as those used to identify public web + servers. Moreover, although IKE provides a great deal of leeway in + defining the security policy for a trusted peer's identity, + credentials, and the correlation between them, having such security + policy defined explicitly is essential to a secure implementation." + [Issue #61] + + Changed "[V+]" to "[V+][N+]" throughout Appendix C. [Issue #63] + Authors' Addresses Charlie Kaufman Microsoft 1 Microsoft Way Redmond, WA 98052 US Phone: 1-425-707-3335 Email: charliek@microsoft.com