< draft-kivinen-ipsecme-ikev2-rfc5996bis-00.txt   draft-kivinen-ipsecme-ikev2-rfc5996bis-01.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: February 10, 2014 Y. Nir Expires: April 20, 2014 Y. Nir
Check Point Check Point
P. Eronen P. Eronen
Independent Independent
T. Kivinen T. Kivinen
INSIDE Secure INSIDE Secure
August 9, 2013 October 17, 2013
Internet Key Exchange Protocol Version 2 (IKEv2) Internet Key Exchange Protocol Version 2 (IKEv2)
draft-kivinen-ipsecme-ikev2-rfc5996bis-00.txt draft-kivinen-ipsecme-ikev2-rfc5996bis-01.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 4306, and includes all (SAs). This document replaces and updates RFC 5996, and includes all
of the clarifications from RFC 4718. of the errata for it, and it is intended to update IKEv2 to be
Internet Standard.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 February 10, 2014. This Internet-Draft will expire on April 20, 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 50 skipping to change at page 2, line 51
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 This
Document . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . 22
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 . . . . . . . . . 24
2.3. Window Size for Overlapping Requests . . . . . . . . . . 25 2.3. Window Size for Overlapping Requests . . . . . . . . . . 25
2.4. State Synchronization and Connection Timeouts . . . . . . 26 2.4. State Synchronization and Connection Timeouts . . . . . . 27
2.5. Version Numbers and Forward Compatibility . . . . . . . . 28 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 . . . . . . . . . . . 33 2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 34
2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 34 2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 34
2.8.1. Simultaneous Child SA Rekeying . . . . . . . . . . . 36 2.8.1. Simultaneous Child SA Rekeying . . . . . . . . . . . 36
2.8.2. Simultaneous IKE SA Rekeying . . . . . . . . . . . . 38 2.8.2. Simultaneous IKE SA Rekeying . . . . . . . . . . . . 39
2.8.3. Rekeying the IKE SA versus Reauthentication . . . . . 39 2.8.3. Rekeying the IKE SA versus Reauthentication . . . . . 40
2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 40 2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 40
2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 43 2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 43
2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.11. Address and Port Agility . . . . . . . . . . . . . . . . 44 2.11. Address and Port Agility . . . . . . . . . . . . . . . . 44
2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 44 2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 44
2.13. Generating Keying Material . . . . . . . . . . . . . . . 45 2.13. Generating Keying Material . . . . . . . . . . . . . . . 45
2.14. Generating Keying Material for the IKE SA . . . . . . . . 46 2.14. Generating Keying Material for the IKE SA . . . . . . . . 46
2.15. Authentication of the IKE SA . . . . . . . . . . . . . . 47 2.15. Authentication of the IKE SA . . . . . . . . . . . . . . 47
2.16. Extensible Authentication Protocol Methods . . . . . . . 49 2.16. Extensible Authentication Protocol Methods . . . . . . . 49
2.17. Generating Keying Material for Child SAs . . . . . . . . 51 2.17. Generating Keying Material for Child SAs . . . . . . . . 51
2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange . . . . 52 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange . . . . 52
2.19. Requesting an Internal Address on a Remote Network . . . 53 2.19. Requesting an Internal Address on a Remote Network . . . 53
2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 54 2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 55
2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 55 2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 55
2.21.1. Error Handling in IKE_SA_INIT . . . . . . . . . . . . 55 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 . . . . . . . . . . . . . 56
2.21.3. Error Handling after IKE SA is Authenticated . . . . 57 2.21.3. Error Handling after IKE SA is Authenticated . . . . 57
2.21.4. Error Handling Outside IKE SA . . . . . . . . . . . . 57 2.21.4. Error Handling Outside IKE SA . . . . . . . . . . . . 57
2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 58 2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 59 2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 60
2.23.1. Transport Mode NAT Traversal . . . . . . . . . . . . 63 2.23.1. Transport Mode NAT Traversal . . . . . . . . . . . . 63
2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 67 2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 67
2.25. Exchange Collisions . . . . . . . . . . . . . . . . . . . 67 2.25. Exchange Collisions . . . . . . . . . . . . . . . . . . . 67
2.25.1. Collisions while Rekeying or Closing Child SAs . . . 68 2.25.1. Collisions while Rekeying or Closing Child SAs . . . 68
2.25.2. Collisions while Rekeying or Closing IKE SAs . . . . 69 2.25.2. Collisions while Rekeying or Closing IKE SAs . . . . 69
3. Header and Payload Formats . . . . . . . . . . . . . . . . . 69 3. Header and Payload Formats . . . . . . . . . . . . . . . . . 69
3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 69 3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 69
3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 72 3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 72
3.3. Security Association Payload . . . . . . . . . . . . . . 74 3.3. Security Association Payload . . . . . . . . . . . . . . 74
3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 78 3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 78
3.3.2. Transform Substructure . . . . . . . . . . . . . . . 79 3.3.2. Transform Substructure . . . . . . . . . . . . . . . 79
3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 82 3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 83
3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 83 3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 83
3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 84 3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 84
3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 86 3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 86
3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 86 3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 87
3.5. Identification Payloads . . . . . . . . . . . . . . . . . 87 3.5. Identification Payloads . . . . . . . . . . . . . . . . . 88
3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 90 3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 90
3.7. Certificate Request Payload . . . . . . . . . . . . . . . 92 3.7. Certificate Request Payload . . . . . . . . . . . . . . . 93
3.8. Authentication Payload . . . . . . . . . . . . . . . . . 94 3.8. Authentication Payload . . . . . . . . . . . . . . . . . 95
3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 96 3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 96
3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 96 3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 97
3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 97 3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 98
3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 100 3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 101
3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 102 3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 102
3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 103 3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 104
3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 104 3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 105
3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 106 3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 107
3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 108 3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 109
3.15.1. Configuration Attributes . . . . . . . . . . . . . . 109 3.15.1. Configuration Attributes . . . . . . . . . . . . . . 110
3.15.2. Meaning of INTERNAL_IP4_SUBNET and 3.15.2. Meaning of INTERNAL_IP4_SUBNET and
INTERNAL_IP6_SUBNET . . . . . . . . . . . . . . . . . 112 INTERNAL_IP6_SUBNET . . . . . . . . . . . . . . . . . 113
3.15.3. Configuration Payloads for IPv6 . . . . . . . . . . . 114 3.15.3. Configuration Payloads for IPv6 . . . . . . . . . . . 115
3.15.4. Address Assignment Failures . . . . . . . . . . . . . 115 3.15.4. Address Assignment Failures . . . . . . . . . . . . . 116
3.16. Extensible Authentication Protocol (EAP) Payload . . . . 116 3.16. Extensible Authentication Protocol (EAP) Payload . . . . 117
4. Conformance Requirements . . . . . . . . . . . . . . . . . . 117 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 118
5. Security Considerations . . . . . . . . . . . . . . . . . . . 119 5. Security Considerations . . . . . . . . . . . . . . . . . . . 120
5.1. Traffic Selector Authorization . . . . . . . . . . . . . 122 5.1. Traffic Selector Authorization . . . . . . . . . . . . . 123
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 123 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 124
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 124 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 124
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 125 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 126
8.1. Normative References . . . . . . . . . . . . . . . . . . 125 8.1. Normative References . . . . . . . . . . . . . . . . . . 126
8.2. Informative References . . . . . . . . . . . . . . . . . 126 8.2. Informative References . . . . . . . . . . . . . . . . . 127
Appendix A. Summary of Changes from IKEv1 . . . . . . . . . . . 130 Appendix A. Summary of Changes from IKEv1 . . . . . . . . . . . 131
Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 131 Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 133
B.1. Group 1 - 768-bit MODP . . . . . . . . . . . . . . . . . 132 B.1. Group 1 - 768-bit MODP . . . . . . . . . . . . . . . . . 133
B.2. Group 2 - 1024-bit MODP . . . . . . . . . . . . . . . . . 132 B.2. Group 2 - 1024-bit MODP . . . . . . . . . . . . . . . . . 133
Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 132 Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 133
C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 133 C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 134
C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 134 C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 135
C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 135 C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 136
C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying
Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 136 Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 137
C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA . . . . 136 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA . . . . 137
C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 136 C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 137
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). This document replaces and updates RFC 4306 and RFC (RFC 4718). The [RFC5996] replaced and updated RFC 4306 and RFC
4718. IKEv2 was a change to the IKE protocol that was not backward 4718, and this document replaces the RFC 5996 and the intended status
compatible. In contrast, the current document not only provides a for this document will be Internet Standard. IKEv2 was a change to
clarification of IKEv2, but makes minimum changes to the IKE the IKE protocol that was not backward compatible. In contrast, the
protocol. A list of the significant differences between RFC 4306 and current document not only provides a clarification of IKEv2, but
this document is given in Section 1.7. makes minimum changes to the IKE protocol. A list of the significant
differences between RFC 4306 and RFC 5996 is given in Section 1.7 and
differences between RFC 5996 and this document is given in
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
"suite" or "cryptographic suite" refers to a complete set of "suite" or "cryptographic suite" refers to a complete set of
algorithms used to protect an SA. An initiator proposes one or more algorithms used to protect an SA. An initiator proposes one or more
suites by listing supported algorithms that can be combined into suites by listing supported algorithms that can be combined into
skipping to change at page 22, line 28 skipping to change at page 22, line 28
In Section 3.15.3, a pointer to a new document that is related to In Section 3.15.3, a pointer to a new document that is related to
configuration of IPv6 addresses was added. configuration of IPv6 addresses was added.
Appendix C was expanded and clarified. Appendix C was expanded and clarified.
1.8. Differences between RFC 5996 and This Document 1.8. Differences between RFC 5996 and This Document
Fixed section 3.6 and 3.10 as specified in the RFC5996 errata 2707 Fixed section 3.6 and 3.10 as specified in the RFC5996 errata 2707
and 3036. and 3036.
Removed Raw RSA Public keys. There is new work ongoing to replace
that with more generic format for generic raw public keys.
Added reference to the RFC6989 when using non Sophie-Germain Diffie-
Hellman groups, or when reusing Diffie-Hellman Exponentials.
Added reference to the RFC4945 in the Identification Payloads
section.
Added IANA Considerations section note about removing the Raw RSA
Key, and removed the old contents which was already done during
RFC5996 processing. Added note that IANA should update IKEv2
registry to point to this document instead of RFC5996.
Clarified that the intended status of this document is Internet
Standard both in abstract and Introduction section.
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 45, line 12 skipping to change at page 45, line 26
associated with the exponential only when some corresponding associated with the exponential only when some corresponding
connection was closed. This would allow the exponential to be reused connection was closed. This would allow the exponential to be reused
without losing perfect forward secrecy at the cost of maintaining without losing perfect forward secrecy at the cost of maintaining
more state. more state.
Whether and when to reuse Diffie-Hellman exponentials are private Whether and when to reuse Diffie-Hellman exponentials are private
decisions in the sense that they will not affect interoperability. decisions in the sense that they will not affect interoperability.
An implementation that reuses exponentials MAY choose to remember the An implementation that reuses exponentials MAY choose to remember the
exponential used by the other endpoint on past exchanges and if one exponential used by the other endpoint on past exchanges and if one
is reused to avoid the second half of the calculation. See [REUSE] is reused to avoid the second half of the calculation. See [REUSE]
for a security analysis of this practice and for additional security and [RFC6989] for a security analysis of this practice and for
considerations when reusing ephemeral Diffie-Hellman keys. additional security considerations when reusing ephemeral Diffie-
Hellman keys.
2.13. Generating Keying Material 2.13. Generating Keying Material
In the context of the IKE SA, four cryptographic algorithms are In the context of the IKE SA, four cryptographic algorithms are
negotiated: an encryption algorithm, an integrity protection negotiated: an encryption algorithm, an integrity protection
algorithm, a Diffie-Hellman group, and a pseudorandom function (PRF). algorithm, a Diffie-Hellman group, and a pseudorandom function (PRF).
The PRF is used for the construction of keying material for all of The PRF is used for the construction of keying material for all of
the cryptographic algorithms used in both the IKE SA and the Child the cryptographic algorithms used in both the IKE SA and the Child
SAs. SAs.
skipping to change at page 82, line 23 skipping to change at page 82, line 23
4096-bit MODP 16 [ADDGROUP] 4096-bit MODP 16 [ADDGROUP]
6144-bit MODP 17 [ADDGROUP] 6144-bit MODP 17 [ADDGROUP]
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
special validity tests to be performed, but other types of groups
(ECP and MODP groups with small subgroups) needs to have some
additional tests to be performed on them to use them securely. See
"Additional Diffie-Hellman Tests for IKEv2" ([RFC6989]) for more
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.
Name Number Name Number
-------------------------------------------- --------------------------------------------
No Extended Sequence Numbers 0 No Extended Sequence Numbers 0
skipping to change at page 90, line 13 skipping to change at page 90, line 28
(NAIs) defined in [NAI]. Although NAIs look a bit like email (NAIs) defined in [NAI]. Although NAIs look a bit like email
addresses (e.g., "joe@example.com"), the syntax is not exactly the addresses (e.g., "joe@example.com"), the syntax is not exactly the
same as the syntax of email address in [MAILFORMAT]. For those NAIs same as the syntax of email address in [MAILFORMAT]. For those NAIs
that include the realm component, the ID_RFC822_ADDR identification that include the realm component, the ID_RFC822_ADDR identification
type SHOULD be used. Responder implementations should not attempt to type SHOULD be used. Responder implementations should not attempt to
verify that the contents actually conform to the exact syntax given verify that the contents actually conform to the exact syntax given
in [MAILFORMAT], but instead should accept any reasonable-looking in [MAILFORMAT], but instead should accept any reasonable-looking
NAI. For NAIs that do not include the realm component, the ID_KEY_ID NAI. For NAIs that do not include the realm component, the ID_KEY_ID
identification type SHOULD be used. identification type SHOULD be used.
See "IPsec PKI Profile of IKEv1, IKEv2 and PKIX" ([RFC4945]) for more
information about matching Identification payloads and the contents
of the PKIX Certificates.
3.6. Certificate Payload 3.6. Certificate Payload
The Certificate payload, denoted CERT in this document, provides a The Certificate payload, denoted CERT in this document, provides a
means to transport certificates or other authentication-related means to transport certificates or other authentication-related
information via IKE. Certificate payloads SHOULD be included in an information via IKE. Certificate payloads SHOULD be included in an
exchange if certificates are available to the sender. The Hash and exchange if certificates are available to the sender. The Hash and
URL formats of the Certificate payloads should be used in case the URL formats of the Certificate payloads should be used in case the
peer has indicated an ability to retrieve this information from peer has indicated an ability to retrieve this information from
elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note
that the term "Certificate payload" is somewhat misleading, because that the term "Certificate payload" is somewhat misleading, because
skipping to change at page 91, line 16 skipping to change at page 91, line 37
---------------------------------------------------- ----------------------------------------------------
PKCS #7 wrapped X.509 certificate 1 UNSPECIFIED PKCS #7 wrapped X.509 certificate 1 UNSPECIFIED
PGP Certificate 2 UNSPECIFIED PGP Certificate 2 UNSPECIFIED
DNS Signed Key 3 UNSPECIFIED DNS Signed Key 3 UNSPECIFIED
X.509 Certificate - Signature 4 X.509 Certificate - Signature 4
Kerberos Token 6 UNSPECIFIED Kerberos Token 6 UNSPECIFIED
Certificate Revocation List (CRL) 7 Certificate Revocation List (CRL) 7
Authority Revocation List (ARL) 8 UNSPECIFIED Authority Revocation List (ARL) 8 UNSPECIFIED
SPKI Certificate 9 UNSPECIFIED SPKI Certificate 9 UNSPECIFIED
X.509 Certificate - Attribute 10 UNSPECIFIED X.509 Certificate - Attribute 10 UNSPECIFIED
Raw RSA Key 11 Deprecated (Was Raw RSA Key) 11 DEPRECATED
Hash and URL of X.509 certificate 12 Hash and URL of X.509 certificate 12
Hash and URL of X.509 bundle 13 Hash and URL of X.509 bundle 13
o Certificate Data (variable length) - Actual encoding of o Certificate Data (variable length) - Actual encoding of
certificate data. The type of certificate is indicated by the certificate data. The type of certificate is indicated by the
Certificate Encoding field. Certificate Encoding field.
The payload type for the Certificate payload is thirty-seven (37). The payload type for the Certificate payload is thirty-seven (37).
Specific syntax for some of the certificate type codes above is not Specific syntax for some of the certificate type codes above is not
skipping to change at page 91, line 40 skipping to change at page 92, line 15
o "X.509 Certificate - Signature" contains a DER-encoded X.509 o "X.509 Certificate - Signature" contains a DER-encoded X.509
certificate whose public key is used to validate the sender's AUTH certificate whose public key is used to validate the sender's AUTH
payload. Note that with this encoding, if a chain of certificates payload. Note that with this encoding, if a chain of certificates
needs to be sent, multiple CERT payloads are used, only the first needs to be sent, multiple CERT payloads are used, only the first
of which holds the public key used to validate the sender's AUTH of which holds the public key used to validate the sender's AUTH
payload. payload.
o "Certificate Revocation List" contains a DER-encoded X.509 o "Certificate Revocation List" contains a DER-encoded X.509
certificate revocation list. certificate revocation list.
o "Raw RSA Key" contains a PKCS #1 encoded RSA key, that is, a DER-
encoded RSAPublicKey structure (see [RSA] and [PKCS1]).
o Hash and URL encodings allow IKE messages to remain short by o Hash and URL encodings allow IKE messages to remain short by
replacing long data structures with a 20-octet SHA-1 hash (see replacing long data structures with a 20-octet SHA-1 hash (see
[SHA]) of the replaced value followed by a variable-length URL [SHA]) of the replaced value followed by a variable-length URL
that resolves to the DER-encoded data structure itself. This that resolves to the DER-encoded data structure itself. This
improves efficiency when the endpoints have certificate data improves efficiency when the endpoints have certificate data
cached and makes IKE less subject to DoS attacks that become cached and makes IKE less subject to DoS attacks that become
easier to mount when IKE messages are large enough to require IP easier to mount when IKE messages are large enough to require IP
fragmentation [DOSUDPPROT]. fragmentation [DOSUDPPROT].
The "Hash and URL of a bundle" type uses the following ASN.1 The "Hash and URL of a bundle" type uses the following ASN.1
skipping to change at page 92, line 32 skipping to change at page 93, line 4
cert [0] Certificate, cert [0] Certificate,
crl [1] CertificateList } crl [1] CertificateList }
CertificateBundle ::= SEQUENCE OF CertificateOrCRL CertificateBundle ::= SEQUENCE OF CertificateOrCRL
END END
Implementations MUST be capable of being configured to send and Implementations MUST be capable of being configured to send and
accept up to four X.509 certificates in support of authentication, accept up to four X.509 certificates in support of authentication,
and also MUST be capable of being configured to send and accept the and also MUST be capable of being configured to send and accept the
two Hash and URL format (with HTTP URLs). Implementations SHOULD be two Hash and URL formats (with HTTP URLs). If multiple certificates
capable of being configured to send and accept Raw RSA keys. If are sent, the first certificate MUST contain the public key used to
multiple certificates are sent, the first certificate MUST contain sign the AUTH payload. The other certificates may be sent in any
the public key used to sign the AUTH payload. The other certificates order.
may be sent in any order.
Implementations MUST support the HTTP [HTTP] method for hash-and-URL Implementations MUST support the HTTP [HTTP] method for hash-and-URL
lookup. The behavior of other URL methods [URLS] is not currently lookup. The behavior of other URL methods [URLS] is not currently
specified, and such methods SHOULD NOT be used in the absence of a specified, and such methods SHOULD NOT be used in the absence of a
document specifying them. document specifying them.
3.7. Certificate Request Payload 3.7. Certificate Request Payload
The Certificate Request payload, denoted CERTREQ in this document, The Certificate Request payload, denoted CERTREQ in this document,
provides a means to request preferred certificates via IKE and can provides a means to request preferred certificates via IKE and can
skipping to change at page 123, line 43 skipping to change at page 124, line 40
configuration in most circumstances. See [H2HIPSEC] for an extensive configuration in most circumstances. See [H2HIPSEC] for an extensive
discussion about this issue, and the limitations of host-to-host discussion about this issue, and the limitations of host-to-host
IPsec in general. IPsec in general.
6. IANA Considerations 6. IANA Considerations
[IKEV2] defined many field types and values. IANA has already [IKEV2] defined many field types and values. IANA has already
registered those types and values in [IKEV2IANA], so they are not registered those types and values in [IKEV2IANA], so they are not
listed here again. listed here again.
Two items have been removed from the IKEv2 Configuration Payload One item has been removed from the IKEv2 Certificate Encodings table:
Attribute Types table: INTERNAL_IP6_NBNS and INTERNAL_ADDRESS_EXPIRY. "Raw RSA Key".
Two new additions to the IKEv2 parameters "NOTIFY MESSAGES - ERROR
TYPES" registry are defined here that were not defined in [IKEV2]:
43 TEMPORARY_FAILURE
44 CHILD_SA_NOT_FOUND
IANA has changed the existing IKEv2 Payload Types table from:
46 Encrypted E [IKEV2]
to
46 Encrypted and Authenticated SK [This document]
IANA has updated all references to RFC 4306 to point to this IANA has updated all references to RFC 5996 to point to this
document. document.
7. Acknowledgements 7. Acknowledgements
Many individuals in the IPsecME Working Group were very helpful in Many individuals in the IPsecME Working Group were very helpful in
contributing ideas and text for this document, as well as in contributing ideas and text for this document, as well as in
reviewing the clarifications suggested by others. reviewing the clarifications suggested by others.
The acknowledgements from the IKEv2 document were: The acknowledgements from the IKEv2 document were:
skipping to change at page 130, line 5 skipping to change at page 131, line 5
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[REAUTH] Nir, Y., "Repeated Authentication in Internet Key Exchange [REAUTH] Nir, Y., "Repeated Authentication in Internet Key Exchange
(IKEv2) Protocol", RFC 4478, April 2006. (IKEv2) Protocol", RFC 4478, April 2006.
[REUSE] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In [REUSE] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In
Diffie-Hellman Key Agreement Protocols", December 2008, < Diffie-Hellman Key Agreement Protocols", December 2008, <
http://www.cacr.math.uwaterloo.ca/techreports/2008/ http://www.cacr.math.uwaterloo.ca/techreports/2008/
cacr2008-24.pdf>. cacr2008-24.pdf>.
[RFC4945] Korver, B., "The Internet IP Security PKI Profile of
IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
[RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman
Tests for the Internet Key Exchange Protocol Version 2
(IKEv2)", RFC 6989, July 2013.
[ROHCV2] Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C. [ROHCV2] Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C.
Bormann, "IKEv2 Extensions to Support Robust Header Bormann, "IKEv2 Extensions to Support Robust Header
Compression over IPsec", RFC 5857, May 2010. Compression over IPsec", RFC 5857, May 2010.
[RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for [RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for
Obtaining Digital Signatures and Public-Key Obtaining Digital Signatures and Public-Key
Cryptosystems", February 1978. Cryptosystems", February 1978.
[SHA] National Institute of Standards and Technology, U.S. [SHA] National Institute of Standards and Technology, U.S.
Department of Commerce, "Secure Hash Standard", Department of Commerce, "Secure Hash Standard",
 End of changes. 31 change blocks. 
83 lines changed or deleted 110 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/