draft-ietf-ipsecme-ikev2bis-02.txt   draft-ietf-ipsecme-ikev2bis-03.txt 
Network Working Group C. Kaufman Network Working Group C. Kaufman
Internet-Draft Microsoft Internet-Draft Microsoft
Obsoletes: 4306, 4718 P. Hoffman Obsoletes: 4306, 4718 P. Hoffman
(if approved) VPN Consortium (if approved) VPN Consortium
Intended status: Standards Track Y. Nir Intended status: Standards Track Y. Nir
Expires: August 30, 2009 Check Point Expires: October 26, 2009 Check Point
P. Eronen P. Eronen
Nokia Nokia
February 26, 2009 April 24, 2009
Internet Key Exchange Protocol: IKEv2 Internet Key Exchange Protocol: IKEv2
draft-ietf-ipsecme-ikev2bis-02 draft-ietf-ipsecme-ikev2bis-03
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 47 skipping to change at page 1, line 47
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
skipping to change at page 4, line 5 skipping to change at page 4, line 5
2.14. Generating Keying Material for the IKE SA . . . . . . . . 45 2.14. Generating Keying Material for the IKE SA . . . . . . . . 45
2.15. Authentication of the IKE SA . . . . . . . . . . . . . . 46 2.15. Authentication of the IKE SA . . . . . . . . . . . . . . 46
2.16. Extensible Authentication Protocol Methods . . . . . . . 48 2.16. Extensible Authentication Protocol Methods . . . . . . . 48
2.17. Generating Keying Material for Child SAs . . . . . . . . 50 2.17. Generating Keying Material for Child SAs . . . . . . . . 50
2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange . . . . 51 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. Requesting an Internal Address on a Remote Network . . . 52
2.19.1. Configuration Payloads . . . . . . . . . . . . . . . 53 2.19.1. Configuration Payloads . . . . . . . . . . . . . . . 53
2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 55 2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 55
2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 55 2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 55
2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 56 2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 57 2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 58
2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 61 2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 61
3. Header and Payload Formats . . . . . . . . . . . . . . . . . 61 3. Header and Payload Formats . . . . . . . . . . . . . . . . . 62
3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 61 3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 62
3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 64 3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 65
3.3. Security Association Payload . . . . . . . . . . . . . . 66 3.3. Security Association Payload . . . . . . . . . . . . . . 67
3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 68 3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 69
3.3.2. Transform Substructure . . . . . . . . . . . . . . . 70 3.3.2. Transform Substructure . . . . . . . . . . . . . . . 71
3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 73 3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 74
3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 73 3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 74
3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 74 3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 75
3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 76 3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 77
3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 77 3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 78
3.5. Identification Payloads . . . . . . . . . . . . . . . . . 78 3.5. Identification Payloads . . . . . . . . . . . . . . . . . 79
3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 80 3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 81
3.7. Certificate Request Payload . . . . . . . . . . . . . . . 82 3.7. Certificate Request Payload . . . . . . . . . . . . . . . 83
3.8. Authentication Payload . . . . . . . . . . . . . . . . . 84 3.8. Authentication Payload . . . . . . . . . . . . . . . . . 85
3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 85 3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 87
3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 86 3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 87
3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 87 3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 88
3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 90 3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 91
3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 92 3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 93
3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 93 3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 94
3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 94 3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 95
3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 96 3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 97
3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 98 3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 99
3.15.1. Configuration Attributes . . . . . . . . . . . . . . 99 3.15.1. Configuration Attributes . . . . . . . . . . . . . . 100
3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 102 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 103
3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 104 3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 105
3.15.4. Address Assignment Failures . . . . . . . . . . . . . 105 3.15.4. Address Assignment Failures . . . . . . . . . . . . . 106
3.16. Extensible Authentication Protocol (EAP) Payload . . . . 105 3.16. Extensible Authentication Protocol (EAP) Payload . . . . 106
4. Conformance Requirements . . . . . . . . . . . . . . . . . . 107 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 108
5. Security Considerations . . . . . . . . . . . . . . . . . . . 109 5. Security Considerations . . . . . . . . . . . . . . . . . . . 110
5.1. Traffic selector authorization . . . . . . . . . . . . . 112 5.1. Traffic selector authorization . . . . . . . . . . . . . 113
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 113 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 114
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 113 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 114
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 114 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 115
8.1. Normative References . . . . . . . . . . . . . . . . . . 114 8.1. Normative References . . . . . . . . . . . . . . . . . . 115
8.2. Informative References . . . . . . . . . . . . . . . . . 115 8.2. Informative References . . . . . . . . . . . . . . . . . 116
Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 119 Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 120
Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 120 Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 121
B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 120 B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 122
B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 121 B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 122
Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 121 Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 122
C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 122 C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 123
C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 123 C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 124
C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 124 C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 125
C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying
Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 125 Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 126
C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA . . . . 125 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA . . . . 126
C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 125 C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 126
Appendix D. Significant Changes from RFC 4306 . . . . . . . . . 125 Appendix D. Significant Changes from RFC 4306 . . . . . . . . . 126
Appendix E. Changes Between Internet Draft Versions . . . . . . 126 Appendix E. Changes Between Internet Draft Versions . . . . . . 127
E.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 126 E.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 127
E.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 126 E.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 127
E.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 128 E.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 129
E.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 129 E.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 130
E.5. Changes from draft -02 to draft -03 . . . . . . . . . . . 130 E.5. Changes from draft -02 to draft -03 . . . . . . . . . . . 131
E.6. Changes from draft -03 to 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 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 E.8. Changes from draft-ietf-ipsecme-ikev2bis-01 to
draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 136 draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 137
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 138 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 1. Introduction
{{ An introduction to the differences between RFC 4306 [IKEV2] and {{ An introduction to the differences between RFC 4306 [IKEV2] and
this document is given at the end of Section 1. It is put there 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. }} (instead of here) to preserve the section numbering of RFC 4306. }}
IP Security (IPsec) provides confidentiality, data integrity, access IP Security (IPsec) provides confidentiality, data integrity, access
control, and data source authentication to IP datagrams. These control, and data source authentication to IP datagrams. These
services are provided by maintaining shared state between the source services are provided by maintaining shared state between the source
skipping to change at page 16, line 11 skipping to change at page 16, line 11
NOT be encrypted because the other party will not be able to NOT be encrypted because the other party will not be able to
authenticate that message. [[ Note: this text may be changed in the authenticate that message. [[ Note: this text may be changed in the
future. ]] future. ]]
1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange
The CREATE_CHILD_SA request for rekeying an IKE SA is: The CREATE_CHILD_SA request for rekeying an IKE SA is:
Initiator Responder 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 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, and a Diffie-Hellman value in the KEi payload. The KEi
payload MUST 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. supplied in the SPI fields of the SA payload.
The CREATE_CHILD_SA response for rekeying an IKE SA is: The CREATE_CHILD_SA response for rekeying an IKE SA is:
<-- HDR, SK {SA, Nr,[KEr]} <-- HDR, SK {SA, Nr,[KEr]}
skipping to change at page 24, line 18 skipping to change at page 24, line 18
the "original responder" starts rekeying the IKE SA, that party the "original responder" starts rekeying the IKE SA, that party
becomes the "original initiator" of the new IKE SA. becomes the "original initiator" of the new IKE SA.
Note that Message IDs are cryptographically protected and provide Note that Message IDs are cryptographically protected and provide
protection against message replays. In the unlikely event that protection against message replays. In the unlikely event that
Message IDs grow too large to fit in 32 bits, the IKE SA MUST be Message IDs grow too large to fit in 32 bits, the IKE SA MUST be
closed or rekeyed. closed or rekeyed.
2.3. Window Size for Overlapping Requests 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 {{ 3.10.1-16385 }} The SET_WINDOW_SIZE notification asserts that the
sending endpoint is capable of keeping state for multiple outstanding sending endpoint is capable of keeping state for multiple outstanding
exchanges, permitting the recipient to send multiple requests before exchanges, permitting the recipient to send multiple requests before
getting a response to the first. The data associated with a getting a response to the first. The data associated with a
SET_WINDOW_SIZE notification MUST be 4 octets long and contain the SET_WINDOW_SIZE notification MUST be 4 octets long and contain the
big endian representation of the number of messages the sender big endian representation of the number of messages the sender
promises to keep. The window size is always one until the initial promises to keep. The window size is always one until the initial
exchanges complete. exchanges complete.
An IKE endpoint MUST wait for a response to each of its messages An IKE endpoint MUST wait for a response to each of its messages
before sending a subsequent message unless it has received a before sending a subsequent message unless it has received a
SET_WINDOW_SIZE Notify message from its peer informing it that the SET_WINDOW_SIZE Notify message from its peer informing it that the
peer is prepared to maintain state for multiple outstanding messages peer is prepared to maintain state for multiple outstanding messages
in order to allow greater throughput. 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 An IKE endpoint MUST NOT exceed the peer's stated window size for
transmitted IKE requests. In other words, if the responder stated transmitted IKE requests. In other words, if the responder stated
its window size is N, then when the initiator needs to make a request 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 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 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 to regenerate exactly) each request it has sent until it receives the
corresponding response. An IKE endpoint MUST keep a copy of (or be corresponding response. An IKE endpoint MUST keep a copy of (or be
able to regenerate exactly) the number of previous responses equal to able to regenerate exactly) the number of previous responses equal to
its declared window size in case its response was lost and the its declared window size in case its response was lost and the
initiator requests its retransmission by retransmitting the request. initiator requests its retransmission by retransmitting the request.
skipping to change at page 26, line 6 skipping to change at page 25, line 48
{{ 3.10.1-16384 }} The INITIAL_CONTACT notification asserts that this {{ 3.10.1-16384 }} The INITIAL_CONTACT notification asserts that this
IKE SA is the only IKE SA currently active between the authenticated 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 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 crash, and the recipient MAY use this information to delete any other
IKE SAs it has to the same authenticated identity without waiting for 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 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 be replicated (e.g., a roaming user's credentials where the user is
allowed to connect to the corporate firewall from two remote systems allowed to connect to the corporate firewall from two remote systems
at the same time). {{ Clarif-7.9 }} The INITIAL_CONTACT notification, 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 if sent, MUST be in the first IKE_AUTH request or response, not as a
exchange afterwards; however, receiving parties need to deal with it separate exchange afterwards; however, receiving parties MAY ignore
in other requests. it in other messages.
Since IKE is designed to operate in spite of Denial of Service (DoS) Since IKE is designed to operate in spite of Denial of Service (DoS)
attacks from the network, an endpoint MUST NOT conclude that the attacks from the network, an endpoint MUST NOT conclude that the
other endpoint has failed based on any routing information (e.g., other endpoint has failed based on any routing information (e.g.,
ICMP messages) or IKE messages that arrive without cryptographic ICMP messages) or IKE messages that arrive without cryptographic
protection (e.g., Notify messages complaining about unknown SPIs). protection (e.g., Notify messages complaining about unknown SPIs).
An endpoint MUST conclude that the other endpoint has failed only An endpoint MUST conclude that the other endpoint has failed only
when repeated attempts to contact it have gone unanswered for a when repeated attempts to contact it have gone unanswered for a
timeout period or when a cryptographically protected INITIAL_CONTACT timeout period or when a cryptographically protected INITIAL_CONTACT
notification is received on a different IKE SA to the same notification is received on a different IKE SA to the same
skipping to change at page 48, line 9 skipping to change at page 48, line 9
insecure because user-chosen passwords are unlikely to have insecure because user-chosen passwords are unlikely to have
sufficient unpredictability to resist dictionary attacks and these sufficient unpredictability to resist dictionary attacks and these
attacks are not prevented in this authentication method. attacks are not prevented in this authentication method.
(Applications using password-based authentication for bootstrapping (Applications using password-based authentication for bootstrapping
and IKE SA should use the authentication method in Section 2.16, and IKE SA should use the authentication method in Section 2.16,
which is designed to prevent off-line dictionary attacks.) {{ Demoted which is designed to prevent off-line dictionary attacks.) {{ Demoted
the SHOULD }} The pre-shared key needs to contain as much the SHOULD }} The pre-shared key needs to contain as much
unpredictability as the strongest key being negotiated. In the case unpredictability as the strongest key being negotiated. In the case
of a pre-shared key, the AUTH value is computed as: of a pre-shared key, the AUTH value is computed as:
AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), <msg octets>) For the initiator:
AUTH = prf( prf( Shared Secret,"Key Pad for IKEv2"),
<InitiatorSignedOctets>)
For the responder:
AUTH = prf( prf( Shared Secret,"Key Pad for IKEv2"),
<ResponderSignedOctets>)
where the string "Key Pad for IKEv2" is 17 ASCII characters without where the string "Key Pad for IKEv2" is 17 ASCII characters without
null termination. The shared secret can be variable length. The pad null termination. The shared secret can be variable length. The pad
string is added so that if the shared secret is derived from a string is added so that if the shared secret is derived from a
password, the IKE implementation need not store the password in password, the IKE implementation need not store the password in
cleartext, but rather can store the value prf(Shared Secret,"Key Pad cleartext, but rather can store the value prf(Shared Secret,"Key Pad
for IKEv2"), which could not be used as a password equivalent for for IKEv2"), which could not be used as a password equivalent for
protocols other than IKEv2. As noted above, deriving the shared protocols other than IKEv2. As noted above, deriving the shared
secret from a password is not secure. This construction is used secret from a password is not secure. This construction is used
because it is anticipated that people will do it anyway. The because it is anticipated that people will do it anyway. The
skipping to change at page 61, line 17 skipping to change at page 61, line 26
are still alive (for example, the keepalive interval is too long, are still alive (for example, the keepalive interval is too long,
or the NAT box is rebooted). To recover in these cases, hosts or the NAT box is rebooted). To recover in these cases, hosts
that are not behind a NAT SHOULD send all packets (including that are not behind a NAT SHOULD send all packets (including
retransmission packets) to the IP address and port from the last retransmission packets) to the IP address and port from the last
valid authenticated packet from the other end (i.e., dynamically valid authenticated packet from the other end (i.e., dynamically
update the address). A host behind a NAT SHOULD NOT do this update the address). A host behind a NAT SHOULD NOT do this
because it opens a DoS attack possibility. Any authenticated IKE because it opens a DoS attack possibility. Any authenticated IKE
packet or any authenticated UDP-encapsulated ESP packet can be packet or any authenticated UDP-encapsulated ESP packet can be
used to detect that the IP address or the port has changed. 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) 2.24. Explicit Congestion Notification (ECN)
When IPsec tunnels behave as originally specified in [IPSECARCH-OLD], When IPsec tunnels behave as originally specified in [IPSECARCH-OLD],
ECN usage is not appropriate for the outer IP headers because tunnel ECN usage is not appropriate for the outer IP headers because tunnel
decapsulation processing discards ECN congestion indications to the decapsulation processing discards ECN congestion indications to the
detriment of the network. ECN support for IPsec tunnels for IKEv1- detriment of the network. ECN support for IPsec tunnels for IKEv1-
based IPsec requires multiple operating modes and negotiation (see based IPsec requires multiple operating modes and negotiation (see
[ECN]). IKEv2 simplifies this situation by requiring that ECN be [ECN]). IKEv2 simplifies this situation by requiring that ECN be
usable in the outer IP headers of all tunnel-mode IPsec SAs created usable in the outer IP headers of all tunnel-mode IPsec SAs created
by IKEv2. Specifically, tunnel encapsulators and decapsulators for by IKEv2. Specifically, tunnel encapsulators and decapsulators for
skipping to change at page 64, line 15 skipping to change at page 64, line 39
* I(nitiator) (bit 3 of Flags) - This bit MUST be set in messages * 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 sent by the original initiator of the IKE SA and MUST be
cleared in messages sent by the original responder. It is used cleared in messages sent by the original responder. It is used
by the recipient to determine which eight octets of the SPI by the recipient to determine which eight octets of the SPI
were generated by the recipient. This bit changes to reflect were generated by the recipient. This bit changes to reflect
who initiated the last rekey of the IKE SA. who initiated the last rekey of the IKE SA.
* V(ersion) (bit 4 of Flags) - This bit indicates that the * V(ersion) (bit 4 of Flags) - This bit indicates that the
transmitter is capable of speaking a higher major version transmitter is capable of speaking a higher major version
number of the protocol than the one indicated in the major 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. bit when sending and MUST ignore it in incoming messages.
* R(esponse) (bit 5 of Flags) - This bit indicates that this * R(esponse) (bit 5 of Flags) - This bit indicates that this
message is a response to a message containing the same message message is a response to a message containing the same message
ID. This bit MUST be cleared in all request messages and MUST ID. This bit MUST be cleared in all request messages and MUST
be set in all responses. An IKE endpoint MUST NOT generate a be set in all responses. An IKE endpoint MUST NOT generate a
response to a message that is marked as being a response. response to a message that is marked as being a response.
* X(reserved) (bits 6-7 of Flags) - These bits MUST be cleared * X(reserved) (bits 6-7 of Flags) - These bits MUST be cleared
when sending and MUST be ignored on receipt. when sending and MUST be ignored on receipt.
skipping to change at page 76, line 22 skipping to change at page 77, line 22
upgrading endpoints independently, implementers of this protocol upgrading endpoints independently, implementers of this protocol
SHOULD accept values that they deem to supply greater security. For SHOULD accept values that they deem to supply greater security. For
instance, if a peer is configured to accept a variable-length cipher 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 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 key length, the implementation SHOULD accept the offer if it supports
use of the longer key. use of the longer key.
Support of this capability allows a responder to express a concept of 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_ "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 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 multiple key lengths has to include multiple transforms with the same
Transform Type, each with different Key Length attribute. Transform Type, each with different Key Length attribute.
3.3.6. Attribute Negotiation 3.3.6. Attribute Negotiation
During security association negotiation initiators present offers to During security association negotiation initiators present offers to
responders. Responders MUST select a single complete set of responders. Responders MUST select a single complete set of
parameters from the offers (or reject all offers if none are parameters from the offers (or reject all offers if none are
acceptable). If there are multiple proposals, the responder MUST acceptable). If there are multiple proposals, the responder MUST
choose a single proposal. If the selected proposal has multiple choose a single proposal. If the selected proposal has multiple
skipping to change at page 76, line 47 skipping to change at page 77, line 47
that response MUST be rejected. that response MUST be rejected.
If the responder receives a proposal that contains a Transform Type If the responder receives a proposal that contains a Transform Type
it does not understand, or a proposal that is missing a mandatory it does not understand, or a proposal that is missing a mandatory
Transform Type, it MUST consider this proposal unacceptable; however, Transform Type, it MUST consider this proposal unacceptable; however,
other proposals in the same SA payload are processed as usual. other proposals in the same SA payload are processed as usual.
Similarly, if the responder receives a transform that contains a Similarly, if the responder receives a transform that contains a
Transform Attribute it does not understand, it MUST consider this Transform Attribute it does not understand, it MUST consider this
transform unacceptable; other transforms with the same Transform Type transform unacceptable; other transforms with the same Transform Type
are processed as usual. This allows new Transform Types and 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. Negotiating Diffie-Hellman groups presents some special challenges.
SA offers include proposed attributes and a Diffie-Hellman public SA offers include proposed attributes and a Diffie-Hellman public
number (KE) in the same message. If in the initial exchange the number (KE) in the same message. If in the initial exchange the
initiator offers to use one of several Diffie-Hellman groups, it initiator offers to use one of several Diffie-Hellman groups, it
SHOULD pick the one the responder is most likely to accept and 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 include a KE corresponding to that group. If the responder selects a
be wrong, the responder will indicate the correct group in the proposal using a different Diffie-Hellman group (other than NONE),
response and the initiator SHOULD pick an element of that group for the responder will indicate the correct group in the response and the
its KE value when retrying the first message. It SHOULD, however, initiator SHOULD pick an element of that group for its KE value when
continue to propose its full supported set of groups in order to retrying the first message. It SHOULD, however, continue to propose
prevent a man-in-the-middle downgrade attack. its full supported set of groups in order to prevent a man-in-the-
middle downgrade attack.
3.4. Key Exchange Payload 3.4. Key Exchange Payload
The Key Exchange Payload, denoted KE in this memo, is used to The Key Exchange Payload, denoted KE in this memo, is used to
exchange Diffie-Hellman public numbers as part of a Diffie-Hellman exchange Diffie-Hellman public numbers as part of a Diffie-Hellman
key exchange. The Key Exchange Payload consists of the IKE generic key exchange. The Key Exchange Payload consists of the IKE generic
payload header followed by the Diffie-Hellman public value itself. payload header followed by the Diffie-Hellman public value itself.
1 2 3 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 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
skipping to change at page 77, line 41 skipping to change at page 78, line 46
Figure 10: Key Exchange Payload Format Figure 10: Key Exchange Payload Format
A key exchange payload is constructed by copying one's Diffie-Hellman A key exchange payload is constructed by copying one's Diffie-Hellman
public value into the "Key Exchange Data" portion of the payload. public value into the "Key Exchange Data" portion of the payload.
The length of the Diffie-Hellman public value MUST be equal to the The length of the Diffie-Hellman public value MUST be equal to the
length of the prime modulus over which the exponentiation was length of the prime modulus over which the exponentiation was
performed, prepending zero bits to the value if necessary. performed, prepending zero bits to the value if necessary.
The DH Group # identifies the Diffie-Hellman group in which the Key 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 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 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 group in the first proposal, if such exists. If none of the
proposals in that SA payload specifies a DH Group, the KE payload proposals in that SA payload specifies a DH Group, the KE payload
MUST NOT be present. If the selected proposal uses a different MUST NOT be present. If the selected proposal uses a different
Diffie-Hellman group (other than NONE), the message MUST be rejected Diffie-Hellman group (other than NONE), the message MUST be rejected
with a Notify payload of type INVALID_KE_PAYLOAD. with a Notify payload of type INVALID_KE_PAYLOAD.
The payload type for the Key Exchange payload is thirty four (34). The payload type for the Key Exchange payload is thirty four (34).
skipping to change at page 112, line 5 skipping to change at page 112, line 50
additional IKEv2 protocol variations and protects the EAP data from additional IKEv2 protocol variations and protects the EAP data from
active attackers. active attackers.
If the messages of IKEv2 are long enough that IP-level fragmentation If the messages of IKEv2 are long enough that IP-level fragmentation
is necessary, it is possible that attackers could prevent the is necessary, it is possible that attackers could prevent the
exchange from completing by exhausting the reassembly buffers. The exchange from completing by exhausting the reassembly buffers. The
chances of this can be minimized by using the Hash and URL encodings chances of this can be minimized by using the Hash and URL encodings
instead of sending certificates (see Section 3.6). Additional instead of sending certificates (see Section 3.6). Additional
mitigations are discussed in [DOSUDPPROT]. 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 5.1. Traffic selector authorization
{{ Added this section from Clarif-4.13 }} {{ Added this section from Clarif-4.13 }}
IKEv2 relies on information in the Peer Authorization Database (PAD) IKEv2 relies on information in the Peer Authorization Database (PAD)
when determining what kind of IPsec SAs a peer is allowed to create. when determining what kind of IPsec SAs a peer is allowed to create.
This process is described in [IPSECARCH] Section 4.4.3. When a peer This process is described in [IPSECARCH] Section 4.4.3. When a peer
requests the creation of an IPsec SA with some traffic selectors, the requests the creation of an IPsec SA with some traffic selectors, the
PAD must contain "Child SA Authorization Data" linking the identity PAD must contain "Child SA Authorization Data" linking the identity
authenticated by IKEv2 and the addresses permitted for traffic authenticated by IKEv2 and the addresses permitted for traffic
skipping to change at page 117, line 49 skipping to change at page 119, line 8
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[MIPV6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [MIPV6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[MLDV2] Vida, R. and L. Costa, "Multicast Listener Discovery [MLDV2] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 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. [MODES] National Institute of Standards and Technology, U.S.
Department of Commerce, "Recommendation for Block Cipher Department of Commerce, "Recommendation for Block Cipher
Modes of Operation", SP 800-38A, 2001. Modes of Operation", SP 800-38A, 2001.
[NAI] Aboba, B., Beadles, M., Eronen, P., and J. Arkko, "The [NAI] Aboba, B., Beadles, M., Eronen, P., and J. Arkko, "The
Network Access Identifier", RFC 4282, December 2005. Network Access Identifier", RFC 4282, December 2005.
[NATREQ] Aboba, B. and W. Dixon, "IPsec-Network Address Translation [NATREQ] Aboba, B. and W. Dixon, "IPsec-Network Address Translation
(NAT) Compatibility Requirements", RFC 3715, March 2004. (NAT) Compatibility Requirements", RFC 3715, March 2004.
skipping to change at page 122, line 11 skipping to change at page 123, line 11
Vendor-ID (V) payloads may be included in any place in any message. 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. This sequence here shows what are the most logical places for them.
C.1. IKE_SA_INIT Exchange C.1. IKE_SA_INIT Exchange
request --> [N(COOKIE)], request --> [N(COOKIE)],
SA, KE, Ni, SA, KE, Ni,
[N(NAT_DETECTION_SOURCE_IP)+, [N(NAT_DETECTION_SOURCE_IP)+,
N(NAT_DETECTION_DESTINATION_IP)], N(NAT_DETECTION_DESTINATION_IP)],
[V+] [V+][N+]
normal response <-- SA, KE, Nr, normal response <-- SA, KE, Nr,
(no cookie) [N(NAT_DETECTION_SOURCE_IP), (no cookie) [N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)], N(NAT_DETECTION_DESTINATION_IP)],
[[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
[V+] [V+][N+]
cookie response <-- N(COOKIE), cookie response <-- N(COOKIE),
[V+] [V+][N+]
different D-H <-- N(INVALID_KE_PAYLOAD), different D-H <-- N(INVALID_KE_PAYLOAD),
group wanted [V+] group wanted [V+][N+]
C.2. IKE_AUTH Exchange without EAP C.2. IKE_AUTH Exchange without EAP
request --> IDi, [CERT+], request --> IDi, [CERT+],
[N(INITIAL_CONTACT)], [N(INITIAL_CONTACT)],
[[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
[IDr], [IDr],
AUTH, AUTH,
[CP(CFG_REQUEST)], [CP(CFG_REQUEST)],
[N(IPCOMP_SUPPORTED)+], [N(IPCOMP_SUPPORTED)+],
[N(USE_TRANSPORT_MODE)], [N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)], [N(NON_FIRST_FRAGMENTS_ALSO)],
SA, TSi, TSr, SA, TSi, TSr,
[V+] [V+][N+]
response <-- IDr, [CERT+], response <-- IDr, [CERT+],
AUTH, AUTH,
[CP(CFG_REPLY)], [CP(CFG_REPLY)],
[N(IPCOMP_SUPPORTED)], [N(IPCOMP_SUPPORTED)],
[N(USE_TRANSPORT_MODE)], [N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)], [N(NON_FIRST_FRAGMENTS_ALSO)],
SA, TSi, TSr, SA, TSi, TSr,
[N(ADDITIONAL_TS_POSSIBLE)], [N(ADDITIONAL_TS_POSSIBLE)],
[V+] [V+][N+]
error in Child SA <-- IDr, [CERT+], error in Child SA <-- IDr, [CERT+],
creation AUTH, creation AUTH,
N(error), N(error),
[V+] [V+][N+]
C.3. IKE_AUTH Exchange with EAP C.3. IKE_AUTH Exchange with EAP
first request --> IDi, first request --> IDi,
[N(INITIAL_CONTACT)], [N(INITIAL_CONTACT)],
[[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
[IDr], [IDr],
[CP(CFG_REQUEST)], [CP(CFG_REQUEST)],
[N(IPCOMP_SUPPORTED)+], [N(IPCOMP_SUPPORTED)+],
[N(USE_TRANSPORT_MODE)], [N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)], [N(NON_FIRST_FRAGMENTS_ALSO)],
SA, TSi, TSr, SA, TSi, TSr,
[V+] [V+][N+]
first response <-- IDr, [CERT+], AUTH, first response <-- IDr, [CERT+], AUTH,
EAP, EAP,
[V+] [V+][N+]
/ --> EAP / --> EAP
repeat 1..N times | repeat 1..N times |
\ <-- EAP \ <-- EAP
last request --> AUTH last request --> AUTH
last response <-- AUTH, last response <-- AUTH,
[CP(CFG_REPLY)], [CP(CFG_REPLY)],
[N(IPCOMP_SUPPORTED)], [N(IPCOMP_SUPPORTED)],
[N(USE_TRANSPORT_MODE)], [N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)], [N(NON_FIRST_FRAGMENTS_ALSO)],
SA, TSi, TSr, SA, TSi, TSr,
[N(ADDITIONAL_TS_POSSIBLE)], [N(ADDITIONAL_TS_POSSIBLE)],
[V+] [V+][N+]
C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying Child SAs C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying Child SAs
request --> [N(REKEY_SA)], request --> [N(REKEY_SA)],
[CP(CFG_REQUEST)], [CP(CFG_REQUEST)],
[N(IPCOMP_SUPPORTED)+], [N(IPCOMP_SUPPORTED)+],
[N(USE_TRANSPORT_MODE)], [N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)], [N(NON_FIRST_FRAGMENTS_ALSO)],
SA, Ni, [KEi], TSi, TSr SA, Ni, [KEi], TSi, TSr
[V+] [V+][N+]
normal <-- [CP(CFG_REPLY)], normal <-- [CP(CFG_REPLY)],
response [N(IPCOMP_SUPPORTED)], response [N(IPCOMP_SUPPORTED)],
[N(USE_TRANSPORT_MODE)], [N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)], [N(NON_FIRST_FRAGMENTS_ALSO)],
SA, Nr, [KEr], TSi, TSr, SA, Nr, [KEr], TSi, TSr,
[N(ADDITIONAL_TS_POSSIBLE)] [N(ADDITIONAL_TS_POSSIBLE)]
[V+] [V+][N+]
error case <-- N(error) error case <-- N(error)
different D-H <-- N(INVALID_KE_PAYLOAD), 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 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA
request --> SA, Ni, [KEi] request --> SA, Ni, [KEi]
[V+] [V+][N+]
response <-- SA, Nr, [KEr] response <-- SA, Nr, [KEr]
[V+] [V+][N+]
C.6. INFORMATIONAL Exchange C.6. INFORMATIONAL Exchange
request --> [N+], request --> [N+],
[D+], [D+],
[CP(CFG_REQUEST)] [CP(CFG_REQUEST)]
response <-- [N+], response <-- [N+],
[D+], [D+],
[CP(CFG_REPLY)] [CP(CFG_REPLY)]
skipping to change at page 138, line 26 skipping to change at page 139, line 26
been authenticated. As a result, an implementation of this protocol been authenticated. As a result, an implementation of this protocol
needs to be completely robust when deployed on any insecure network. needs to be completely robust when deployed on any insecure network.
Implementation vulnerabilities, particularly denial-of-service Implementation vulnerabilities, particularly denial-of-service
attacks, can be exploited by unauthenticated peers. This issue is attacks, can be exploited by unauthenticated peers. This issue is
particularly worrisome because of the unlimited number of messages in particularly worrisome because of the unlimited number of messages in
EAP-based authentication." [Issue #62] EAP-based authentication." [Issue #62]
Added new Appendix D, "Significant Changes from RFC 4306", as a Added new Appendix D, "Significant Changes from RFC 4306", as a
placeholder for now. [Issue #3] 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"), <msg octets>)
to
For the initiator:
AUTH = prf( prf( Shared Secret,"Key Pad for IKEv2"),
<InitiatorSignedOctets>)
For the responder:
AUTH = prf( prf( Shared Secret,"Key Pad for IKEv2"),
<ResponderSignedOctets>)
[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 Authors' Addresses
Charlie Kaufman Charlie Kaufman
Microsoft Microsoft
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
US US
Phone: 1-425-707-3335 Phone: 1-425-707-3335
Email: charliek@microsoft.com Email: charliek@microsoft.com
 End of changes. 39 change blocks. 
110 lines changed or deleted 212 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/