< draft-kivinen-ipsecme-ikev2-rfc5996bis-01.txt   draft-kivinen-ipsecme-ikev2-rfc5996bis-02.txt >
Network Working Group C. Kaufman Network Working Group C. Kaufman
Internet-Draft Microsoft Internet-Draft Microsoft
Obsoletes: 5996 (if approved) P. Hoffman Obsoletes: 5996 (if approved) P. Hoffman
Intended status: Standards Track VPN Consortium Intended status: Standards Track VPN Consortium
Expires: April 20, 2014 Y. Nir Expires: May 17, 2014 Y. Nir
Check Point Check Point
P. Eronen P. Eronen
Independent Independent
T. Kivinen T. Kivinen
INSIDE Secure INSIDE Secure
October 17, 2013 November 13, 2013
Internet Key Exchange Protocol Version 2 (IKEv2) Internet Key Exchange Protocol Version 2 (IKEv2)
draft-kivinen-ipsecme-ikev2-rfc5996bis-01.txt draft-kivinen-ipsecme-ikev2-rfc5996bis-02.txt
Abstract Abstract
This document describes version 2 of the Internet Key Exchange (IKE) This document describes version 2 of the Internet Key Exchange (IKE)
protocol. IKE is a component of IPsec used for performing mutual protocol. IKE is a component of IPsec used for performing mutual
authentication and establishing and maintaining Security Associations authentication and establishing and maintaining Security Associations
(SAs). This document replaces and updates RFC 5996, and includes all (SAs). This document replaces and updates RFC 5996, and includes all
of the errata for it, and it is intended to update IKEv2 to be of the errata for it, and it is intended to update IKEv2 to be
Internet Standard. Internet Standard.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on April 20, 2014. This Internet-Draft will expire on May 17, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 40 skipping to change at page 2, line 40
1.1.2. Endpoint-to-Endpoint Transport Mode . . . . . . . . . 7 1.1.2. Endpoint-to-Endpoint Transport Mode . . . . . . . . . 7
1.1.3. Endpoint to Security Gateway in Tunnel Mode . . . . . 8 1.1.3. Endpoint to Security Gateway in Tunnel Mode . . . . . 8
1.1.4. Other Scenarios . . . . . . . . . . . . . . . . . . . 9 1.1.4. Other Scenarios . . . . . . . . . . . . . . . . . . . 9
1.2. The Initial Exchanges . . . . . . . . . . . . . . . . . . 9 1.2. The Initial Exchanges . . . . . . . . . . . . . . . . . . 9
1.3. The CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 13 1.3. The CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 13
1.3.1. Creating New Child SAs with the CREATE_CHILD_SA 1.3.1. Creating New Child SAs with the CREATE_CHILD_SA
Exchange . . . . . . . . . . . . . . . . . . . . . . 14 Exchange . . . . . . . . . . . . . . . . . . . . . . 14
1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange . 15 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange . 15
1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA
Exchange . . . . . . . . . . . . . . . . . . . . . . 16 Exchange . . . . . . . . . . . . . . . . . . . . . . 16
1.4. The INFORMATIONAL Exchange . . . . . . . . . . . . . . . 16 1.4. The INFORMATIONAL Exchange . . . . . . . . . . . . . . . 17
1.4.1. Deleting an SA with INFORMATIONAL Exchanges . . . . . 17 1.4.1. Deleting an SA with INFORMATIONAL Exchanges . . . . . 17
1.5. Informational Messages outside of an IKE SA . . . . . . . 18 1.5. Informational Messages outside of an IKE SA . . . . . . . 18
1.6. Requirements Terminology . . . . . . . . . . . . . . . . 19 1.6. Requirements Terminology . . . . . . . . . . . . . . . . 19
1.7. Significant Differences between RFC 4306 and This 1.7. Significant Differences between RFC 4306 and RFC5996 . . 19
Document . . . . . . . . . . . . . . . . . . . . . . . . 19
1.8. Differences between RFC 5996 and This Document . . . . . 22 1.8. Differences between RFC 5996 and This Document . . . . . 22
2. IKE Protocol Details and Variations . . . . . . . . . . . . . 22 2. IKE Protocol Details and Variations . . . . . . . . . . . . . 23
2.1. Use of Retransmission Timers . . . . . . . . . . . . . . 23 2.1. Use of Retransmission Timers . . . . . . . . . . . . . . 23
2.2. Use of Sequence Numbers for Message ID . . . . . . . . . 24 2.2. Use of Sequence Numbers for Message ID . . . . . . . . . 25
2.3. Window Size for Overlapping Requests . . . . . . . . . . 25 2.3. Window Size for Overlapping Requests . . . . . . . . . . 26
2.4. State Synchronization and Connection Timeouts . . . . . . 27 2.4. State Synchronization and Connection Timeouts . . . . . . 27
2.5. Version Numbers and Forward Compatibility . . . . . . . . 29 2.5. Version Numbers and Forward Compatibility . . . . . . . . 29
2.6. IKE SA SPIs and Cookies . . . . . . . . . . . . . . . . . 30 2.6. IKE SA SPIs and Cookies . . . . . . . . . . . . . . . . . 30
2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . 33 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . 33
2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 34 2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 34
2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 34 2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 35
2.8.1. Simultaneous Child SA Rekeying . . . . . . . . . . . 36 2.8.1. Simultaneous Child SA Rekeying . . . . . . . . . . . 37
2.8.2. Simultaneous IKE SA Rekeying . . . . . . . . . . . . 39 2.8.2. Simultaneous IKE SA Rekeying . . . . . . . . . . . . 39
2.8.3. Rekeying the IKE SA versus Reauthentication . . . . . 40 2.8.3. Rekeying the IKE SA versus Reauthentication . . . . . 40
2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 40 2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 41
2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 43 2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 44
2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.11. Address and Port Agility . . . . . . . . . . . . . . . . 44 2.11. Address and Port Agility . . . . . . . . . . . . . . . . 45
2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 44 2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 45
2.13. Generating Keying Material . . . . . . . . . . . . . . . 45 2.13. Generating Keying Material . . . . . . . . . . . . . . . 46
2.14. Generating Keying Material for the IKE SA . . . . . . . . 46 2.14. Generating Keying Material for the IKE SA . . . . . . . . 47
2.15. Authentication of the IKE SA . . . . . . . . . . . . . . 47 2.15. Authentication of the IKE SA . . . . . . . . . . . . . . 48
2.16. Extensible Authentication Protocol Methods . . . . . . . 49 2.16. Extensible Authentication Protocol Methods . . . . . . . 50
2.17. Generating Keying Material for Child SAs . . . . . . . . 51 2.17. Generating Keying Material for Child SAs . . . . . . . . 52
2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange . . . . 52 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange . . . . 53
2.19. Requesting an Internal Address on a Remote Network . . . 53 2.19. Requesting an Internal Address on a Remote Network . . . 54
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 . . . . . . . . . . . . . . . . . . . . . 56
2.21.1. Error Handling in IKE_SA_INIT . . . . . . . . . . . . 56 2.21.1. Error Handling in IKE_SA_INIT . . . . . . . . . . . . 56
2.21.2. Error Handling in IKE_AUTH . . . . . . . . . . . . . 56 2.21.2. Error Handling in IKE_AUTH . . . . . . . . . . . . . 57
2.21.3. Error Handling after IKE SA is Authenticated . . . . 57 2.21.3. Error Handling after IKE SA is Authenticated . . . . 58
2.21.4. Error Handling Outside IKE SA . . . . . . . . . . . . 57 2.21.4. Error Handling Outside IKE SA . . . . . . . . . . . . 58
2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 58 2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 60 2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 60
2.23.1. Transport Mode NAT Traversal . . . . . . . . . . . . 63 2.23.1. Transport Mode NAT Traversal . . . . . . . . . . . . 64
2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 67 2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 68
2.25. Exchange Collisions . . . . . . . . . . . . . . . . . . . 67 2.25. Exchange Collisions . . . . . . . . . . . . . . . . . . . 68
2.25.1. Collisions while Rekeying or Closing Child SAs . . . 68 2.25.1. Collisions while Rekeying or Closing Child SAs . . . 69
2.25.2. Collisions while Rekeying or Closing IKE SAs . . . . 69 2.25.2. Collisions while Rekeying or Closing IKE SAs . . . . 70
3. Header and Payload Formats . . . . . . . . . . . . . . . . . 69 3. Header and Payload Formats . . . . . . . . . . . . . . . . . 70
3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 69 3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 70
3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 72 3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 73
3.3. Security Association Payload . . . . . . . . . . . . . . 74 3.3. Security Association Payload . . . . . . . . . . . . . . 75
3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 78 3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 79
3.3.2. Transform Substructure . . . . . . . . . . . . . . . 79 3.3.2. Transform Substructure . . . . . . . . . . . . . . . 80
3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 83 3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 84
3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 83 3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 84
3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 84 3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 85
3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 86 3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 87
3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 87 3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 88
3.5. Identification Payloads . . . . . . . . . . . . . . . . . 88 3.5. Identification Payloads . . . . . . . . . . . . . . . . . 89
3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 90 3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 91
3.7. Certificate Request Payload . . . . . . . . . . . . . . . 93 3.7. Certificate Request Payload . . . . . . . . . . . . . . . 94
3.8. Authentication Payload . . . . . . . . . . . . . . . . . 95 3.8. Authentication Payload . . . . . . . . . . . . . . . . . 96
3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 96 3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 97
3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 97 3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 98
3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 98 3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 99
3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 101 3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 102
3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 102 3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 103
3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 104 3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 105
3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 105 3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 106
3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 107 3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 108
3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 109 3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 110
3.15.1. Configuration Attributes . . . . . . . . . . . . . . 110 3.15.1. Configuration Attributes . . . . . . . . . . . . . . 111
3.15.2. Meaning of INTERNAL_IP4_SUBNET and 3.15.2. Meaning of INTERNAL_IP4_SUBNET and
INTERNAL_IP6_SUBNET . . . . . . . . . . . . . . . . . 113 INTERNAL_IP6_SUBNET . . . . . . . . . . . . . . . . . 114
3.15.3. Configuration Payloads for IPv6 . . . . . . . . . . . 115 3.15.3. Configuration Payloads for IPv6 . . . . . . . . . . . 116
3.15.4. Address Assignment Failures . . . . . . . . . . . . . 116 3.15.4. Address Assignment Failures . . . . . . . . . . . . . 117
3.16. Extensible Authentication Protocol (EAP) Payload . . . . 117 3.16. Extensible Authentication Protocol (EAP) Payload . . . . 118
4. Conformance Requirements . . . . . . . . . . . . . . . . . . 118 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 119
5. Security Considerations . . . . . . . . . . . . . . . . . . . 120 5. Security Considerations . . . . . . . . . . . . . . . . . . . 121
5.1. Traffic Selector Authorization . . . . . . . . . . . . . 123 5.1. Traffic Selector Authorization . . . . . . . . . . . . . 124
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 124 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 125
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 124 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 125
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 126 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 127
8.1. Normative References . . . . . . . . . . . . . . . . . . 126 8.1. Normative References . . . . . . . . . . . . . . . . . . 127
8.2. Informative References . . . . . . . . . . . . . . . . . 127 8.2. Informative References . . . . . . . . . . . . . . . . . 128
Appendix A. Summary of Changes from IKEv1 . . . . . . . . . . . 131 Appendix A. Summary of Changes from IKEv1 . . . . . . . . . . . 132
Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 133 Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 134
B.1. Group 1 - 768-bit MODP . . . . . . . . . . . . . . . . . 133 B.1. Group 1 - 768-bit MODP . . . . . . . . . . . . . . . . . 134
B.2. Group 2 - 1024-bit MODP . . . . . . . . . . . . . . . . . 133 B.2. Group 2 - 1024-bit MODP . . . . . . . . . . . . . . . . . 134
Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 133 Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 134
C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 134 C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 135
C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 135 C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 136
C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 136 C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 137
C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying
Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 137 Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 138
C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA . . . . 137 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA . . . . 138
C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 137 C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 138
1. Introduction 1. Introduction
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
and the sink of an IP datagram. This state defines, among other and the sink of an IP datagram. This state defines, among other
things, the specific services provided to the datagram, which things, the specific services provided to the datagram, which
cryptographic algorithms will be used to provide the services, and cryptographic algorithms will be used to provide the services, and
the keys used as input to the cryptographic algorithms. the keys used as input to the cryptographic algorithms.
Establishing this shared state in a manual fashion does not scale Establishing this shared state in a manual fashion does not scale
well. Therefore, a protocol to establish this state dynamically is well. Therefore, a protocol to establish this state dynamically is
needed. This document describes such a protocol -- the Internet Key needed. This document describes such a protocol -- the Internet Key
Exchange (IKE). Version 1 of IKE was defined in RFCs 2407 [DOI], Exchange (IKE). Version 1 of IKE was defined in RFCs 2407 [DOI],
2408 [ISAKMP], and 2409 [IKEV1]. IKEv2 replaced all of those RFCs. 2408 [ISAKMP], and 2409 [IKEV1]. IKEv2 replaced all of those RFCs.
IKEv2 was defined in [IKEV2] (RFC 4306) and was clarified in [Clarif] IKEv2 was defined in [IKEV2] (RFC 4306) and was clarified in [Clarif]
(RFC 4718). The [RFC5996] replaced and updated RFC 4306 and RFC (RFC 4718). The [RFC5996] replaced and updated RFC 4306 and RFC
4718, and this document replaces the RFC 5996 and the intended status 4718, and this document replaces the RFC 5996 and the intended status
for this document will be Internet Standard. IKEv2 was a change to for this document will be Internet Standard. IKEv2 as stated in RFC
the IKE protocol that was not backward compatible. In contrast, the 4306 was a change to the IKE protocol that was not backward
current document not only provides a clarification of IKEv2, but compatible. RFC 5996 revised RFC 4306 to provide a clarification of
makes minimum changes to the IKE protocol. A list of the significant IKEv2, making minimum changes to the IKEv2 protocol. The current
document slightly revises RFC 5996 to make it suitable for
progression to Internet Standard. A list of the significant
differences between RFC 4306 and RFC 5996 is given in Section 1.7 and differences between RFC 4306 and RFC 5996 is given in Section 1.7 and
differences between RFC 5996 and this document is given in differences between RFC 5996 and this document is given in
Section 1.8. Section 1.8.
IKE performs mutual authentication between two parties and IKE performs mutual authentication between two parties and
establishes an IKE security association (SA) that includes shared establishes an IKE security association (SA) that includes shared
secret information that can be used to efficiently establish SAs for secret information that can be used to efficiently establish SAs for
Encapsulating Security Payload (ESP) [ESP] or Authentication Header Encapsulating Security Payload (ESP) [ESP] or Authentication Header
(AH) [AH] and a set of cryptographic algorithms to be used by the SAs (AH) [AH] and a set of cryptographic algorithms to be used by the SAs
to protect the traffic that they carry. In this document, the term to protect the traffic that they carry. In this document, the term
skipping to change at page 10, line 40 skipping to change at page 10, line 40
such as [CERTREQ]; this indicates that a Certificate Request payload such as [CERTREQ]; this indicates that a Certificate Request payload
can optionally be included. can optionally be included.
The initial exchanges are as follows: The initial exchanges are as follows:
Initiator Responder Initiator Responder
------------------------------------------------------------------- -------------------------------------------------------------------
HDR, SAi1, KEi, Ni --> HDR, SAi1, KEi, Ni -->
HDR contains the Security Parameter Indexes (SPIs), version numbers, HDR contains the Security Parameter Indexes (SPIs), version numbers,
and flags of various sorts. The SAi1 payload states the Exchange Type, Message ID, and flags of various sorts. The SAi1
cryptographic algorithms the initiator supports for the IKE SA. The payload states the cryptographic algorithms the initiator supports
KE payload sends the initiator's Diffie-Hellman value. Ni is the for the IKE SA. The KE payload sends the initiator's Diffie-Hellman
initiator's nonce. value. Ni is the initiator's nonce.
<-- HDR, SAr1, KEr, Nr, [CERTREQ] <-- HDR, SAr1, KEr, Nr, [CERTREQ]
The responder chooses a cryptographic suite from the initiator's The responder chooses a cryptographic suite from the initiator's
offered choices and expresses that choice in the SAr1 payload, offered choices and expresses that choice in the SAr1 payload,
completes the Diffie-Hellman exchange with the KEr payload, and sends completes the Diffie-Hellman exchange with the KEr payload, and sends
its nonce in the Nr payload. its nonce in the Nr payload.
At this point in the negotiation, each party can generate SKEYSEED, At this point in the negotiation, each party can generate a quantity
from which all keys are derived for that IKE SA. The messages that called SKEYSEED (see Section 2.14), from which all keys are derived
follow are encrypted and integrity protected in their entirety, with for that IKE SA. The messages that follow are encrypted and
the exception of the message headers. The keys used for the integrity protected in their entirety, with the exception of the
encryption and integrity protection are derived from SKEYSEED and are message headers. The keys used for the encryption and integrity
known as SK_e (encryption) and SK_a (authentication, a.k.a. integrity protection are derived from SKEYSEED and are known as SK_e
protection); see Sections 2.13 and 2.14 for details on the key (encryption) and SK_a (authentication, a.k.a. integrity protection);
derivation. A separate SK_e and SK_a is computed for each direction. see Sections 2.13 and 2.14 for details on the key derivation. A
In addition to the keys SK_e and SK_a derived from the Diffie-Hellman separate SK_e and SK_a is computed for each direction. In addition
value for protection of the IKE SA, another quantity SK_d is derived to the keys SK_e and SK_a derived from the Diffie-Hellman value for
and used for derivation of further keying material for Child SAs. protection of the IKE SA, another quantity SK_d is derived and used
The notation SK { ... } indicates that these payloads are encrypted for derivation of further keying material for Child SAs. The
and integrity protected using that direction's SK_e and SK_a. notation SK { ... } indicates that these payloads are encrypted and
integrity protected using that direction's SK_e and SK_a.
HDR, SK {IDi, [CERT,] [CERTREQ,] HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2, [IDr,] AUTH, SAi2,
TSi, TSr} --> TSi, TSr} -->
The initiator asserts its identity with the IDi payload, proves The initiator asserts its identity with the IDi payload, proves
knowledge of the secret corresponding to IDi and integrity protects knowledge of the secret corresponding to IDi and integrity protects
the contents of the first message using the AUTH payload (see the contents of the first message using the AUTH payload (see
Section 2.15). It might also send its certificate(s) in CERT Section 2.15). It might also send its certificate(s) in CERT
payload(s) and a list of its trust anchors in CERTREQ payload(s). If payload(s) and a list of its trust anchors in CERTREQ payload(s). If
skipping to change at page 14, line 27 skipping to change at page 14, line 27
payload, optionally a Diffie-Hellman value in the KEi payload, and payload, optionally a Diffie-Hellman value in the KEi payload, and
the proposed Traffic Selectors for the proposed Child SA in the TSi the proposed Traffic Selectors for the proposed Child SA in the TSi
and TSr payloads. and TSr payloads.
The CREATE_CHILD_SA response for creating a new Child SA is: The CREATE_CHILD_SA response for creating a new Child SA is:
<-- HDR, SK {SA, Nr, [KEr], <-- HDR, SK {SA, Nr, [KEr],
TSi, TSr} TSi, TSr}
The responder replies (using the same Message ID to respond) with the 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 accepted offer in an SA payload, nonce in the Nr payload, and a
KEr payload if KEi was included in the request and the selected Diffie-Hellman value in the KEr payload if KEi was included in the
cryptographic suite includes that group. request and the selected cryptographic suite includes that group.
The Traffic Selectors for traffic to be sent on that SA are specified The Traffic Selectors for traffic to be sent on that SA are specified
in the TS payloads in the response, which may be a subset of what the in the TS payloads in the response, which may be a subset of what the
initiator of the Child SA proposed. initiator of the Child SA proposed.
The USE_TRANSPORT_MODE notification MAY be included in a request The USE_TRANSPORT_MODE notification MAY be included in a request
message that also includes an SA payload requesting a Child SA. It message that also includes an SA payload requesting a Child SA. It
requests that the Child SA use transport mode rather than tunnel mode requests that the Child SA use transport mode rather than tunnel mode
for the SA created. If the request is accepted, the response MUST for the SA created. If the request is accepted, the response MUST
also include a notification of type USE_TRANSPORT_MODE. If the also include a notification of type USE_TRANSPORT_MODE. If the
skipping to change at page 15, line 42 skipping to change at page 15, line 42
payload MUST be included. A new initiator SPI is supplied in the SPI payload MUST be included. A new initiator SPI is supplied in the SPI
field of the SA payload. Once a peer receives a request to rekey an field of the SA payload. Once a peer receives a request to rekey an
IKE SA or sends a request to rekey an IKE SA, it SHOULD NOT start any IKE SA or sends a request to rekey an IKE SA, it SHOULD NOT start any
new CREATE_CHILD_SA exchanges on the IKE SA that is being rekeyed. new CREATE_CHILD_SA exchanges on the IKE SA that is being rekeyed.
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}
The responder replies (using the same Message ID to respond) with the 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 accepted offer in an SA payload, nonce in the Nr payload, and a
KEr payload if the selected cryptographic suite includes that group. Diffie-Hellman value in the KEr payload if the selected cryptographic
A new responder SPI is supplied in the SPI field of the SA payload. suite includes that group. A new responder SPI is supplied in the
SPI field of the SA payload.
The new IKE SA has its message counters set to 0, regardless of what The new IKE SA has its message counters set to 0, regardless of what
they were in the earlier IKE SA. The first IKE requests from both 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 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 retains its numbering, so any further requests (for example, to
delete the IKE SA) will have consecutive numbering. The new IKE SA 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 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. exchange is the new "original initiator" of the new IKE SA.
Section 2.18 also covers IKE SA rekeying in detail. Section 2.18 also covers IKE SA rekeying in detail.
skipping to change at page 16, line 41 skipping to change at page 16, line 42
Notify message type. The Protocol ID field of the REKEY_SA Notify message type. The Protocol ID field of the REKEY_SA
notification is set to match the protocol of the SA we are rekeying, notification is set to match the protocol of the SA we are rekeying,
for example, 3 for ESP and 2 for AH. for example, 3 for ESP and 2 for AH.
The CREATE_CHILD_SA response for rekeying a Child SA is: The CREATE_CHILD_SA response for rekeying a Child SA is:
<-- HDR, SK {SA, Nr, [KEr], <-- HDR, SK {SA, Nr, [KEr],
TSi, TSr} TSi, TSr}
The responder replies (using the same Message ID to respond) with the 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 accepted offer in an SA payload, nonce in the Nr, and a Diffie-
KEr payload if KEi was included in the request and the selected Hellman value in the KEr payload if KEi was included in the request
cryptographic suite includes that group. and the selected cryptographic suite includes that group.
The Traffic Selectors for traffic to be sent on that SA are specified The Traffic Selectors for traffic to be sent on that SA are specified
in the TS payloads in the response, which may be a subset of what the in the TS payloads in the response, which may be a subset of what the
initiator of the Child SA proposed. initiator of the Child SA proposed.
1.4. The INFORMATIONAL Exchange 1.4. The INFORMATIONAL Exchange
At various points during the operation of an IKE SA, peers may desire At various points during the operation of an IKE SA, peers may desire
to convey control messages to each other regarding errors or to convey control messages to each other regarding errors or
notifications of certain events. To accomplish this, IKE defines an notifications of certain events. To accomplish this, IKE defines an
skipping to change at page 19, line 5 skipping to change at page 19, line 9
o If an IKE request packet arrives with a higher major version o If an IKE request packet arrives with a higher major version
number than the implementation supports. number than the implementation supports.
In the first case, if the receiving node has an active IKE SA to the In the first case, if the receiving node has an active IKE SA to the
IP address from whence the packet came, it MAY send an INVALID_SPI IP address from whence the packet came, it MAY send an INVALID_SPI
notification of the wayward packet over that IKE SA in an notification of the wayward packet over that IKE SA in an
INFORMATIONAL exchange. The Notification Data contains the SPI of INFORMATIONAL exchange. The Notification Data contains the SPI of
the invalid packet. The recipient of this notification cannot tell the invalid packet. The recipient of this notification cannot tell
whether the SPI is for AH or ESP, but this is not important because whether the SPI is for AH or ESP, but this is not important because
the SPIs are supposed to be different for the two. If no suitable in many cases the SPIs will be different for the two. If no suitable
IKE SA exists, the node MAY send an informational message without IKE SA exists, the node MAY send an informational message without
cryptographic protection to the source IP address, using the source cryptographic protection to the source IP address, using the source
UDP port as the destination port if the packet was UDP (UDP- UDP port as the destination port if the packet was UDP (UDP-
encapsulated ESP or AH). In this case, it should only be used by the encapsulated ESP or AH). In this case, it should only be used by the
recipient as a hint that something might be wrong (because it could recipient as a hint that something might be wrong (because it could
easily be forged). This message is not part of an INFORMATIONAL easily be forged). This message is not part of an INFORMATIONAL
exchange, and the receiving node MUST NOT respond to it because doing exchange, and the receiving node MUST NOT respond to it because doing
so could cause a message loop. The message is constructed as so could cause a message loop. The message is constructed as
follows: there are no IKE SPI values that would be meaningful to the follows: there are no IKE SPI values that would be meaningful to the
recipient of such a notification; using zero values or random values recipient of such a notification; using zero values or random values
skipping to change at page 19, line 42 skipping to change at page 19, line 46
Definitions of the primitive terms in this document (such as Security Definitions of the primitive terms in this document (such as Security
Association or SA) can be found in [IPSECARCH]. It should be noted Association or SA) can be found in [IPSECARCH]. It should be noted
that parts of IKEv2 rely on some of the processing rules in that parts of IKEv2 rely on some of the processing rules in
[IPSECARCH], as described in various sections of this document. [IPSECARCH], as described in various sections of this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [MUSTSHOULD]. document are to be interpreted as described in [MUSTSHOULD].
1.7. Significant Differences between RFC 4306 and This Document 1.7. Significant Differences between RFC 4306 and RFC5996
This document contains clarifications and amplifications to IKEv2 This document contains clarifications and amplifications to IKEv2
[IKEV2]. Many of the clarifications are based on [Clarif]. The [IKEV2]. Many of the clarifications are based on [Clarif]. The
changes listed in that document were discussed in the IPsec Working changes listed in that document were discussed in the IPsec Working
Group and, after the Working Group was disbanded, on the IPsec Group and, after the Working Group was disbanded, on the IPsec
mailing list. That document contains detailed explanations of areas mailing list. That document contains detailed explanations of areas
that were unclear in IKEv2, and is thus useful to implementers of that were unclear in IKEv2, and is thus useful to implementers of
IKEv2. IKEv2.
The protocol described in this document retains the same major The protocol described in this document retains the same major
skipping to change at page 22, line 45 skipping to change at page 22, line 49
section. section.
Added IANA Considerations section note about removing the Raw RSA Added IANA Considerations section note about removing the Raw RSA
Key, and removed the old contents which was already done during Key, and removed the old contents which was already done during
RFC5996 processing. Added note that IANA should update IKEv2 RFC5996 processing. Added note that IANA should update IKEv2
registry to point to this document instead of RFC5996. registry to point to this document instead of RFC5996.
Clarified that the intended status of this document is Internet Clarified that the intended status of this document is Internet
Standard both in abstract and Introduction section. Standard both in abstract and Introduction section.
Added name Last Substruc for the Proposal and Transform Substructure
header for the 0 (last) or 2/3 (more) field.
2. IKE Protocol Details and Variations 2. IKE Protocol Details and Variations
IKE normally listens and sends on UDP port 500, though IKE messages IKE normally listens and sends on UDP port 500, though IKE messages
may also be received on UDP port 4500 with a slightly different may also be received on UDP port 4500 with a slightly different
format (see Section 2.23). Since UDP is a datagram (unreliable) format (see Section 2.23). Since UDP is a datagram (unreliable)
protocol, IKE includes in its definition recovery from transmission protocol, IKE includes in its definition recovery from transmission
errors, including packet loss, packet replay, and packet forgery. errors, including packet loss, packet replay, and packet forgery.
IKE is designed to function so long as (1) at least one of a series IKE is designed to function so long as (1) at least one of a series
of retransmitted packets reaches its destination before timing out; of retransmitted packets reaches its destination before timing out;
and (2) the channel is not so full of forged and replayed packets so and (2) the channel is not so full of forged and replayed packets so
skipping to change at page 31, line 14 skipping to change at page 31, line 23
message. Since the SPI chosen by the original initiator of the IKE message. Since the SPI chosen by the original initiator of the IKE
SA is always sent first, an endpoint with multiple IKE SAs open that SA is always sent first, an endpoint with multiple IKE SAs open that
wants to find the appropriate IKE SA using the SPI it assigned must wants to find the appropriate IKE SA using the SPI it assigned must
look at the Initiator flag in the header to determine whether it look at the Initiator flag in the header to determine whether it
assigned the first or the second eight octets. assigned the first or the second eight octets.
In the first message of an initial IKE exchange, the initiator will In the first message of an initial IKE exchange, the initiator will
not know the responder's SPI value and will therefore set that field not know the responder's SPI value and will therefore set that field
to zero. When the IKE_SA_INIT exchange does not result in the to zero. When the IKE_SA_INIT exchange does not result in the
creation of an IKE SA due to INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN, creation of an IKE SA due to INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN,
or COOKIE (see Section 2.6), the responder's SPI will be zero also in or COOKIE, the responder's SPI will be zero also in the response
the response message. However, if the responder sends a non-zero message. However, if the responder sends a non-zero responder SPI,
responder SPI, the initiator should not reject the response for only the initiator should not reject the response for only that reason.
that reason.
Two expected attacks against IKE are state and CPU exhaustion, where Two expected attacks against IKE are state and CPU exhaustion, where
the target is flooded with session initiation requests from forged IP the target is flooded with session initiation requests from forged IP
addresses. These attacks can be made less effective if a responder addresses. These attacks can be made less effective if a responder
uses minimal CPU and commits no state to an SA until it knows the uses minimal CPU and commits no state to an SA until it knows the
initiator can receive packets at the address from which it claims to initiator can receive packets at the address from which it claims to
be sending them. be sending them.
When a responder detects a large number of half-open IKE SAs, it When a responder detects a large number of half-open IKE SAs, it
SHOULD reply to IKE_SA_INIT requests with a response containing the SHOULD reply to IKE_SA_INIT requests with a response containing the
skipping to change at page 50, line 42 skipping to change at page 51, line 21
TSi, TSr} --> TSi, TSr} -->
<-- HDR, SK {IDr, [CERT,] AUTH, <-- HDR, SK {IDr, [CERT,] AUTH,
EAP } EAP }
HDR, SK {EAP} --> HDR, SK {EAP} -->
<-- HDR, SK {EAP (success)} <-- HDR, SK {EAP (success)}
HDR, SK {AUTH} --> HDR, SK {AUTH} -->
<-- HDR, SK {AUTH, SAr2, TSi, TSr } <-- HDR, SK {AUTH, SAr2, TSi, TSr }
As described in Section 2.2, when EAP is used, each pair of IKE SA As described in Section 2.2, when EAP is used, each pair of IKE SA
initial setup messages will have their message numbers incremented; initial setup messages will have their message numbers incremented;
the first pair of AUTH messages will have an ID of 1, the second will the first pair of IKE_AUTH messages will have an ID of 1, the second
be 2, and so on. will be 2, and so on.
For EAP methods that create a shared key as a side effect of For EAP methods that create a shared key as a side effect of
authentication, that shared key MUST be used by both the initiator authentication, that shared key MUST be used by both the initiator
and responder to generate AUTH payloads in messages 7 and 8 using the and responder to generate AUTH payloads in messages 7 and 8 using the
syntax for shared secrets specified in Section 2.15. The shared key syntax for shared secrets specified in Section 2.15. The shared key
from EAP is the field from the EAP specification named MSK. This from EAP is the field from the EAP specification named MSK. This
shared key generated during an IKE exchange MUST NOT be used for any shared key generated during an IKE exchange MUST NOT be used for any
other purpose. other purpose.
EAP methods that do not establish a shared key SHOULD NOT be used, as EAP methods that do not establish a shared key SHOULD NOT be used, as
skipping to change at page 52, line 13 skipping to change at page 52, line 40
For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman
exchange, the keying material is defined as: exchange, the keying material is defined as:
KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr ) KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr )
where g^ir (new) is the shared secret from the ephemeral Diffie- where g^ir (new) is the shared secret from the ephemeral Diffie-
Hellman exchange of this CREATE_CHILD_SA exchange (represented as an Hellman exchange of this CREATE_CHILD_SA exchange (represented as an
octet string in big endian order padded with zeros in the high-order octet string in big endian order padded with zeros in the high-order
bits if necessary to make it the length of the modulus). bits if necessary to make it the length of the modulus).
A single CHILD_SA negotiation may result in multiple Security A single CREATE_CHILD_SA negotiation may result in multiple Security
Associations. ESP and AH SAs exist in pairs (one in each direction), Associations. ESP and AH SAs exist in pairs (one in each direction),
so two SAs are created in a single Child SA negotiation for them. so two SAs are created in a single Child SA negotiation for them.
Furthermore, Child SA negotiation may include some future IPsec Furthermore, Child SA negotiation may include some future IPsec
protocol(s) in addition to, or instead of, ESP or AH (for example, protocol(s) in addition to, or instead of, ESP or AH (for example,
ROHC_INTEG as described in [ROHCV2]). In any case, keying material ROHC_INTEG as described in [ROHCV2]). In any case, keying material
for each Child SA MUST be taken from the expanded KEYMAT using the for each Child SA MUST be taken from the expanded KEYMAT using the
following rules: following rules:
o All keys for SAs carrying data from the initiator to the responder o All keys for SAs carrying data from the initiator to the responder
are taken before SAs going from the responder to the initiator. are taken before SAs going from the responder to the initiator.
skipping to change at page 73, line 9 skipping to change at page 74, line 9
in the message, then this field will be 0. This field provides a in the message, then this field will be 0. This field provides a
"chaining" capability whereby additional payloads can be added to "chaining" capability whereby additional payloads can be added to
a message by appending each one to the end of the message and a message by appending each one to the end of the message and
setting the "Next Payload" field of the preceding payload to setting the "Next Payload" field of the preceding payload to
indicate the new payload's type. An Encrypted payload, which must indicate the new payload's type. An Encrypted payload, which must
always be the last payload of a message, is an exception. It always be the last payload of a message, is an exception. It
contains data structures in the format of additional payloads. In contains data structures in the format of additional payloads. In
the header of an Encrypted payload, the Next Payload field is set the header of an Encrypted payload, the Next Payload field is set
to the payload type of the first contained payload (instead of 0); to the payload type of the first contained payload (instead of 0);
conversely, the Next Payload field of the last contained payload conversely, the Next Payload field of the last contained payload
is set to zero). The payload type values are listed here. The is set to zero. The payload type values are listed here. The
values in the following table are only current as of the values in the following table are only current as of the
publication date of RFC 4306. Other values may have been added publication date of RFC 4306. Other values may have been added
since then or will be added after the publication of this since then or will be added after the publication of this
document. Readers should refer to [IKEV2IANA] for the latest document. Readers should refer to [IKEV2IANA] for the latest
values. values.
Next Payload Type Notation Value Next Payload Type Notation Value
-------------------------------------------------- --------------------------------------------------
No Next Payload 0 No Next Payload 0
Security Association SA 33 Security Association SA 33
skipping to change at page 78, line 10 skipping to change at page 79, line 10
o Proposals (variable) - One or more proposal substructures. o Proposals (variable) - One or more proposal substructures.
The payload type for the Security Association payload is thirty-three The payload type for the Security Association payload is thirty-three
(33). (33).
3.3.1. Proposal Substructure 3.3.1. Proposal Substructure
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (last) or 2 | RESERVED | Proposal Length | | Last Substruc | RESERVED | Proposal Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Proposal Num | Protocol ID | SPI Size |Num Transforms| | Proposal Num | Protocol ID | SPI Size |Num Transforms|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SPI (variable) ~ ~ SPI (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ <Transforms> ~ ~ <Transforms> ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Proposal Substructure Figure 7: Proposal Substructure
o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the o Last Substruc (1 octet) - Specifies whether or not this is the
last Proposal Substructure in the SA. This syntax is inherited last Proposal Substructure in the SA. This field has a value of 0
from ISAKMP, but is unnecessary because the last Proposal could be if this was last Proposal Substructure, and a value of 2 if there
are more Proposal Substructures. This syntax is inherited from
ISAKMP, but is unnecessary because the last Proposal could be
identified from the length of the SA. The value (2) corresponds identified from the length of the SA. The value (2) corresponds
to a payload type of Proposal in IKEv1, and the first four octets to a payload type of Proposal in IKEv1, and the first four octets
of the Proposal structure are designed to look somewhat like the of the Proposal structure are designed to look somewhat like the
header of a payload. header of a payload.
o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on
receipt. receipt.
o Proposal Length (2 octets, unsigned integer) - Length of this o Proposal Length (2 octets, unsigned integer) - Length of this
proposal, including all transforms and attributes that follow. proposal, including all transforms and attributes that follow.
skipping to change at page 79, line 32 skipping to change at page 80, line 32
payload. When the SPI Size field is zero, this field is not payload. When the SPI Size field is zero, this field is not
present in the Security Association payload. present in the Security Association payload.
o Transforms (variable) - One or more transform substructures. o Transforms (variable) - One or more transform substructures.
3.3.2. Transform Substructure 3.3.2. Transform Substructure
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (last) or 3 | RESERVED | Transform Length | | Last Substruc | RESERVED | Transform Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Transform Type | RESERVED | Transform ID | |Transform Type | RESERVED | Transform ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Transform Attributes ~ ~ Transform Attributes ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Transform Substructure Figure 8: Transform Substructure
o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the o Last Substruc (1 octet) - Specifies whether or not this is the
last Transform Substructure in the Proposal. This syntax is last Transform Substructure in the Proposal. This field has a
value of 0 if this was last Transform Substructure, and a value of
3 if there are more Transform Substructures. This syntax is
inherited from ISAKMP, but is unnecessary because the last inherited from ISAKMP, but is unnecessary because the last
transform could be identified from the length of the proposal. transform could be identified from the length of the proposal.
The value (3) corresponds to a payload type of Transform in IKEv1, The value (3) corresponds to a payload type of Transform in IKEv1,
and the first four octets of the Transform structure are designed and the first four octets of the Transform structure are designed
to look somewhat like the header of a payload. to look somewhat like the header of a payload.
o RESERVED - MUST be sent as zero; MUST be ignored on receipt. o RESERVED - MUST be sent as zero; MUST be ignored on receipt.
o Transform Length - The length (in octets) of the Transform o Transform Length - The length (in octets) of the Transform
Substructure including Header and Attributes. Substructure including Header and Attributes.
skipping to change at page 82, line 25 skipping to change at page 83, line 25
8192-bit MODP 18 [ADDGROUP] 8192-bit MODP 18 [ADDGROUP]
Although ESP and AH do not directly include a Diffie-Hellman Although ESP and AH do not directly include a Diffie-Hellman
exchange, a Diffie-Hellman group MAY be negotiated for the Child SA. exchange, a Diffie-Hellman group MAY be negotiated for the Child SA.
This allows the peers to employ Diffie-Hellman in the CREATE_CHILD_SA This allows the peers to employ Diffie-Hellman in the CREATE_CHILD_SA
exchange, providing perfect forward secrecy for the generated Child exchange, providing perfect forward secrecy for the generated Child
SA keys. SA keys.
Note, that MODP Diffie-Hellman groups listed above does not need any Note, that MODP Diffie-Hellman groups listed above does not need any
special validity tests to be performed, but other types of groups special validity tests to be performed, but other types of groups
(ECP and MODP groups with small subgroups) needs to have some (ECP and MODP groups with small subgroups) need to have some
additional tests to be performed on them to use them securely. See additional tests to be performed on them to use them securely. See
"Additional Diffie-Hellman Tests for IKEv2" ([RFC6989]) for more "Additional Diffie-Hellman Tests for IKEv2" ([RFC6989]) for more
information. information.
For Transform Type 5 (Extended Sequence Numbers), defined Transform For Transform Type 5 (Extended Sequence Numbers), defined Transform
IDs are listed below. The values in the following table are only IDs are listed below. The values in the following table are only
current as of the publication date of RFC 4306. Other values may current as of the publication date of RFC 4306. Other values may
have been added since then or will be added after the publication of have been added since then or will be added after the publication of
this document. Readers should refer to [IKEV2IANA] for the latest this document. Readers should refer to [IKEV2IANA] for the latest
values. values.
 End of changes. 34 change blocks. 
129 lines changed or deleted 138 lines changed or added

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