draft-ietf-ipsecme-ikev2bis-00.txt   draft-ietf-ipsecme-ikev2bis-01.txt 
Network Working Group C. Kaufman Network Working Group C. Kaufman
Internet-Draft Microsoft Internet-Draft Microsoft
Obsoletes: 4306, 4718 P. Hoffman Obsoletes: 4306, 4718 P. Hoffman
(if approved) VPN Consortium (if approved) VPN Consortium
Intended status: Standards Track Y. Nir Intended status: Standards Track Y. Nir
Expires: February 27, 2009 Check Point Expires: May 3, 2009 Check Point
P. Eronen P. Eronen
Nokia Nokia
August 26, 2008 October 30, 2008
Internet Key Exchange Protocol: IKEv2 Internet Key Exchange Protocol: IKEv2
draft-ietf-ipsecme-ikev2bis-00 draft-ietf-ipsecme-ikev2bis-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 27, 2009. This Internet-Draft will expire on May 3, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
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. It replaces and updates RFC 4306, and includes all of the protocol. IKE is a component of IPsec used for performing mutual
authentication and establishing and maintaining security associations
(SAs). It replaces and updates RFC 4306, and includes all of the
clarifications from RFC 4718. clarifications from RFC 4718.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 6 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 6
1.1.1. Security Gateway to Security Gateway Tunnel . . . . . 6 1.1.1. Security Gateway to Security Gateway Tunnel Mode . . 6
1.1.2. Endpoint-to-Endpoint Transport . . . . . . . . . . . 7 1.1.2. Endpoint-to-Endpoint Transport Mode . . . . . . . . . 7
1.1.3. Endpoint to Security Gateway Tunnel . . . . . . . . . 8 1.1.3. Endpoint to Security Gateway Tunnel Mode . . . . . . 8
1.1.4. Other Scenarios . . . . . . . . . . . . . . . . . . . 8 1.1.4. Other Scenarios . . . . . . . . . . . . . . . . . . . 8
1.2. The Initial Exchanges . . . . . . . . . . . . . . . . . . 9 1.2. The Initial Exchanges . . . . . . . . . . . . . . . . . . 9
1.3. The CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 11 1.3. The CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . . . . 13 Exchange . . . . . . . . . . . . . . . . . . . . . . 13
1.3.2. Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange . 14 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange . 14
1.3.3. Rekeying CHILD_SAs with the CREATE_CHILD_SA 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA
Exchange . . . . . . . . . . . . . . . . . . . . . . 14 Exchange . . . . . . . . . . . . . . . . . . . . . . 15
1.4. The INFORMATIONAL Exchange . . . . . . . . . . . . . . . 15 1.4. The INFORMATIONAL Exchange . . . . . . . . . . . . . . . 16
1.5. Informational Messages outside of an IKE_SA . . . . . . . 17 1.4.1. Deleting an SA with INFORMATIONAL Exchanges . . . . . 16
1.6. Requirements Terminology . . . . . . . . . . . . . . . . 17 1.5. Informational Messages outside of an IKE SA . . . . . . . 17
1.6. Requirements Terminology . . . . . . . . . . . . . . . . 18
1.7. Differences Between RFC 4306 and This Document . . . . . 18 1.7. Differences Between RFC 4306 and This Document . . . . . 18
2. IKE Protocol Details and Variations . . . . . . . . . . . . . 19 2. IKE Protocol Details and Variations . . . . . . . . . . . . . 20
2.1. Use of Retransmission Timers . . . . . . . . . . . . . . 20 2.1. Use of Retransmission Timers . . . . . . . . . . . . . . 21
2.2. Use of Sequence Numbers for Message ID . . . . . . . . . 21 2.2. Use of Sequence Numbers for Message ID . . . . . . . . . 22
2.3. Window Size for Overlapping Requests . . . . . . . . . . 21 2.3. Window Size for Overlapping Requests . . . . . . . . . . 22
2.4. State Synchronization and Connection Timeouts . . . . . . 23 2.4. State Synchronization and Connection Timeouts . . . . . . 24
2.5. Version Numbers and Forward Compatibility . . . . . . . . 25 2.5. Version Numbers and Forward Compatibility . . . . . . . . 26
2.6. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.6. IKE SA SPIs and Cookies . . . . . . . . . . . . . . . . . 28
2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . 29 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . 30
2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 30 2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 31
2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 31 2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 32
2.8.1. Simultaneous CHILD_SA rekeying . . . . . . . . . . . 33 2.8.1. Simultaneous Child SA rekeying . . . . . . . . . . . 34
2.8.2. Rekeying the IKE_SA Versus Reauthentication . . . . . 35 2.8.2. Rekeying the IKE SA Versus Reauthentication . . . . . 36
2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 36 2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 37
2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 38 2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 40
2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 39 2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.11. Address and Port Agility . . . . . . . . . . . . . . . . 39 2.11. Address and Port Agility . . . . . . . . . . . . . . . . 41
2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 40 2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 41
2.13. Generating Keying Material . . . . . . . . . . . . . . . 40 2.13. Generating Keying Material . . . . . . . . . . . . . . . 42
2.14. Generating Keying Material for the IKE_SA . . . . . . . . 42 2.14. Generating Keying Material for the IKE SA . . . . . . . . 43
2.15. Authentication of the IKE_SA . . . . . . . . . . . . . . 42 2.15. Authentication of the IKE SA . . . . . . . . . . . . . . 44
2.16. Extensible Authentication Protocol Methods . . . . . . . 44 2.16. Extensible Authentication Protocol Methods . . . . . . . 46
2.17. Generating Keying Material for CHILD_SAs . . . . . . . . 46 2.17. Generating Keying Material for Child SAs . . . . . . . . 48
2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA Exchange . . . . 47 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange . . . . 49
2.19. Requesting an Internal Address on a Remote Network . . . 48 2.19. Requesting an Internal Address on a Remote Network . . . 50
2.19.1. Configuration Payloads . . . . . . . . . . . . . . . 49 2.19.1. Configuration Payloads . . . . . . . . . . . . . . . 51
2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 51 2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 53
2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 51 2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 53
2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 52 2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 54
2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 53 2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 55
2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 57 2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 59
3. Header and Payload Formats . . . . . . . . . . . . . . . . . 57 3. Header and Payload Formats . . . . . . . . . . . . . . . . . 59
3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 57 3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 59
3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 60 3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 62
3.3. Security Association Payload . . . . . . . . . . . . . . 62 3.3. Security Association Payload . . . . . . . . . . . . . . 64
3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 64 3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 66
3.3.2. Transform Substructure . . . . . . . . . . . . . . . 66 3.3.2. Transform Substructure . . . . . . . . . . . . . . . 68
3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 69 3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 71
3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 69 3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 71
3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 70 3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 72
3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 72 3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 74
3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 73 3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 75
3.5. Identification Payloads . . . . . . . . . . . . . . . . . 74 3.5. Identification Payloads . . . . . . . . . . . . . . . . . 75
3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 77 3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 78
3.7. Certificate Request Payload . . . . . . . . . . . . . . . 79 3.7. Certificate Request Payload . . . . . . . . . . . . . . . 80
3.8. Authentication Payload . . . . . . . . . . . . . . . . . 81 3.8. Authentication Payload . . . . . . . . . . . . . . . . . 82
3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 82 3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 83
3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 83 3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 84
3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 84 3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 85
3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 87 3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 88
3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 89 3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 90
3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 90 3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 91
3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 91 3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 92
3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 93 3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 94
3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 95 3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 96
3.15.1. Configuration Attributes . . . . . . . . . . . . . . 96 3.15.1. Configuration Attributes . . . . . . . . . . . . . . 97
3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 99 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 100
3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 101 3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 102
3.15.4. Address Assignment Failures . . . . . . . . . . . . . 101 3.15.4. Address Assignment Failures . . . . . . . . . . . . . 103
3.16. Extensible Authentication Protocol (EAP) Payload . . . . 102 3.16. Extensible Authentication Protocol (EAP) Payload . . . . 103
4. Conformance Requirements . . . . . . . . . . . . . . . . . . 104 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 105
5. Security Considerations . . . . . . . . . . . . . . . . . . . 106 5. Security Considerations . . . . . . . . . . . . . . . . . . . 107
5.1. Traffic selector authorization . . . . . . . . . . . . . 108 5.1. Traffic selector authorization . . . . . . . . . . . . . 109
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 109 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 111
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 110 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 111
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 110 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 111
8.1. Normative References . . . . . . . . . . . . . . . . . . 110 8.1. Normative References . . . . . . . . . . . . . . . . . . 111
8.2. Informative References . . . . . . . . . . . . . . . . . 112 8.2. Informative References . . . . . . . . . . . . . . . . . 113
Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 115 Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 117
Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 117 Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 118
B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 117 B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 118
B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 117 B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 118
Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 118 Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 119
C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 118 C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 119
C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 119 C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 120
C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 120 C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 121
C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying
CHILD_SAs . . . . . . . . . . . . . . . . . . . . . . . . 121 Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 122
C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA . . . . 121 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA . . . . 122
C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 121 C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 122
Appendix D. Changes Between Internet Draft Versions . . . . . . 121 Appendix D. Changes Between Internet Draft Versions . . . . . . 122
D.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 121 D.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 123
D.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 122 D.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 123
D.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 124 D.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 125
D.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 124 D.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 126
D.5. Changes from draft -02 to draft -03 . . . . . . . . . . . 125 D.5. Changes from draft -02 to draft -03 . . . . . . . . . . . 127
D.6. Changes from draft -03 to D.6. Changes from draft -03 to
draft-ietf-ipsecme-ikev2bis-00 . . . . . . . . . . . . . 127 draft-ietf-ipsecme-ikev2bis-00 . . . . . . . . . . . . . 128
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 128 D.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to
Intellectual Property and Copyright Statements . . . . . . . . . 129 draft-ietf-ipsecme-ikev2bis-01 . . . . . . . . . . . . . 129
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 133
Intellectual Property and Copyright Statements . . . . . . . . . 134
1. Introduction 1. Introduction
{{ An introduction to the differences between RFC 4306 [IKEV2] and {{ An introduction to the differences between RFC 4306 [IKEV2] and
this document is given at the end of Section 1. It is put there this document is given at the end of Section 1. It is put there
(instead of here) to preserve the section numbering of RFC 4306. }} (instead of here) to preserve the section numbering of RFC 4306. }}
IP Security (IPsec) provides confidentiality, data integrity, access IP Security (IPsec) provides confidentiality, data integrity, access
control, and data source authentication to IP datagrams. These control, and data source authentication to IP datagrams. These
services are provided by maintaining shared state between the source services are provided by maintaining shared state between the source
skipping to change at page 5, line 38 skipping to change at page 5, line 38
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
suites in a mix-and-match fashion. IKE can also negotiate use of IP suites in a mix-and-match fashion. IKE can also negotiate use of IP
Compression (IPComp) [IPCOMP] in connection with an ESP or AH SA. We Compression (IPComp) [IP-COMP] in connection with an ESP or AH SA.
call the IKE SA an "IKE_SA". The SAs for ESP or AH that get set up The SAs for ESP or AH that get set up through that IKE SA we call
through that IKE_SA we call "CHILD_SAs". "Child SAs".
All IKE communications consist of pairs of messages: a request and a All IKE communications consist of pairs of messages: a request and a
response. The pair is called an "exchange". We call the first response. The pair is called an "exchange". We call the first
messages establishing an IKE_SA IKE_SA_INIT and IKE_AUTH exchanges messages establishing an IKE SA IKE_SA_INIT and IKE_AUTH exchanges
and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL
exchanges. In the common case, there is a single IKE_SA_INIT exchanges. In the common case, there is a single IKE_SA_INIT
exchange and a single IKE_AUTH exchange (a total of four messages) to exchange and a single IKE_AUTH exchange (a total of four messages) to
establish the IKE_SA and the first CHILD_SA. In exceptional cases, establish the IKE SA and the first Child SA. In exceptional cases,
there may be more than one of each of these exchanges. In all cases, there may be more than one of each of these exchanges. In all cases,
all IKE_SA_INIT exchanges MUST complete before any other exchange all IKE_SA_INIT exchanges MUST complete before any other exchange
type, then all IKE_AUTH exchanges MUST complete, and following that type, then all IKE_AUTH exchanges MUST complete, and following that
any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur
in any order. In some scenarios, only a single CHILD_SA is needed in any order. In some scenarios, only a single Child SA is needed
between the IPsec endpoints, and therefore there would be no between the IPsec endpoints, and therefore there would be no
additional exchanges. Subsequent exchanges MAY be used to establish additional exchanges. Subsequent exchanges MAY be used to establish
additional CHILD_SAs between the same authenticated pair of endpoints additional Child SAs between the same authenticated pair of endpoints
and to perform housekeeping functions. and to perform housekeeping functions.
IKE message flow always consists of a request followed by a response. IKE message flow always consists of a request followed by a response.
It is the responsibility of the requester to ensure reliability. If It is the responsibility of the requester to ensure reliability. If
the response is not received within a timeout interval, the requester the response is not received within a timeout interval, the requester
needs to retransmit the request (or abandon the connection). needs to retransmit the request (or abandon the connection).
The first request/response of an IKE session (IKE_SA_INIT) negotiates The first request/response of an IKE session (IKE_SA_INIT) negotiates
security parameters for the IKE_SA, sends nonces, and sends Diffie- security parameters for the IKE SA, sends nonces, and sends Diffie-
Hellman values. Hellman values.
The second request/response (IKE_AUTH) transmits identities, proves The second request/response (IKE_AUTH) transmits identities, proves
knowledge of the secrets corresponding to the two identities, and knowledge of the secrets corresponding to the two identities, and
sets up an SA for the first (and often only) AH or ESP CHILD_SA. sets up an SA for the first (and often only) AH or ESP Child SA
(unless there is failure setting up the AH or ESP Child SA, in which
case the IKE SA is still established without IPsec SA).
The types of subsequent exchanges are CREATE_CHILD_SA (which creates The types of subsequent exchanges are CREATE_CHILD_SA (which creates
a CHILD_SA) and INFORMATIONAL (which deletes an SA, reports error a Child SA) and INFORMATIONAL (which deletes an SA, reports error
conditions, or does other housekeeping). Every request requires a conditions, or does other housekeeping). Every request requires a
response. An INFORMATIONAL request with no payloads (other than the response. An INFORMATIONAL request with no payloads (other than the
empty Encrypted payload required by the syntax) is commonly used as a empty Encrypted payload required by the syntax) is commonly used as a
check for liveness. These subsequent exchanges cannot be used until check for liveness. These subsequent exchanges cannot be used until
the initial exchanges have completed. the initial exchanges have completed.
In the description that follows, we assume that no errors occur. In the description that follows, we assume that no errors occur.
Modifications to the flow should errors occur are described in Modifications to the flow should errors occur are described in
Section 2.21. Section 2.21.
1.1. Usage Scenarios 1.1. Usage Scenarios
IKE is expected to be used to negotiate ESP or AH SAs in a number of IKE is expected to be used to negotiate ESP or AH SAs in a number of
different scenarios, each with its own special requirements. different scenarios, each with its own special requirements.
1.1.1. Security Gateway to Security Gateway Tunnel 1.1.1. Security Gateway to Security Gateway Tunnel Mode
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| | IPsec | | | | IPsec | |
Protected |Tunnel | tunnel |Tunnel | Protected Protected |Tunnel | tunnel |Tunnel | Protected
Subnet <-->|Endpoint |<---------->|Endpoint |<--> Subnet Subnet <-->|Endpoint |<---------->|Endpoint |<--> Subnet
| | | | | | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
Figure 1: Security Gateway to Security Gateway Tunnel Figure 1: Security Gateway to Security Gateway Tunnel
In this scenario, neither endpoint of the IP connection implements In this scenario, neither endpoint of the IP connection implements
IPsec, but network nodes between them protect traffic for part of the IPsec, but network nodes between them protect traffic for part of the
way. Protection is transparent to the endpoints, and depends on way. Protection is transparent to the endpoints, and depends on
ordinary routing to send packets through the tunnel endpoints for ordinary routing to send packets through the tunnel endpoints for
processing. Each endpoint would announce the set of addresses processing. Each endpoint would announce the set of addresses
"behind" it, and packets would be sent in tunnel mode where the inner "behind" it, and packets would be sent in tunnel mode where the inner
IP header would contain the IP addresses of the actual endpoints. IP header would contain the IP addresses of the actual endpoints.
1.1.2. Endpoint-to-Endpoint Transport 1.1.2. Endpoint-to-Endpoint Transport Mode
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| | IPsec transport | | | | IPsec transport | |
|Protected| or tunnel mode SA |Protected| |Protected| or tunnel mode SA |Protected|
|Endpoint |<---------------------------------------->|Endpoint | |Endpoint |<---------------------------------------->|Endpoint |
| | | | | | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
Figure 2: Endpoint to Endpoint Figure 2: Endpoint to Endpoint
In this scenario, both endpoints of the IP connection implement In this scenario, both endpoints of the IP connection implement
IPsec, as required of hosts in [IPSECARCH]. Transport mode will IPsec, as required of hosts in [IPSECARCH]. Transport mode will
commonly be used with no inner IP header. If there is an inner IP commonly be used with no inner IP header. A single pair of addresses
header, the inner addresses will be the same as the outer addresses. will be negotiated for packets to be protected by this SA. These
A single pair of addresses will be negotiated for packets to be endpoints MAY implement application layer access controls based on
protected by this SA. These endpoints MAY implement application the IPsec authenticated identities of the participants. This
layer access controls based on the IPsec authenticated identities of scenario enables the end-to-end security that has been a guiding
the participants. This scenario enables the end-to-end security that principle for the Internet since [ARCHPRINC], [TRANSPARENCY], and a
has been a guiding principle for the Internet since [ARCHPRINC], method of limiting the inherent problems with complexity in networks
[TRANSPARENCY], and a method of limiting the inherent problems with noted by [ARCHGUIDEPHIL]. Although this scenario may not be fully
complexity in networks noted by [ARCHGUIDEPHIL]. Although this applicable to the IPv4 Internet, it has been deployed successfully in
scenario may not be fully applicable to the IPv4 Internet, it has specific scenarios within intranets using IKEv1. It should be more
been deployed successfully in specific scenarios within intranets broadly enabled during the transition to IPv6 and with the adoption
using IKEv1. It should be more broadly enabled during the transition of IKEv2.
to IPv6 and with the adoption of IKEv2.
It is possible in this scenario that one or both of the protected It is possible in this scenario that one or both of the protected
endpoints will be behind a network address translation (NAT) node, in endpoints will be behind a network address translation (NAT) node, in
which case the tunneled packets will have to be UDP encapsulated so which case the tunneled packets will have to be UDP encapsulated so
that port numbers in the UDP headers can be used to identify that port numbers in the UDP headers can be used to identify
individual endpoints "behind" the NAT (see Section 2.23). individual endpoints "behind" the NAT (see Section 2.23).
1.1.3. Endpoint to Security Gateway Tunnel 1.1.3. Endpoint to Security Gateway Tunnel Mode
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| | IPsec | | Protected | | IPsec | | Protected
|Protected| tunnel |Tunnel | Subnet |Protected| tunnel |Tunnel | Subnet
|Endpoint |<------------------------>|Endpoint |<--- and/or |Endpoint |<------------------------>|Endpoint |<--- and/or
| | | | Internet | | | | Internet
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
Figure 3: Endpoint to Security Gateway Tunnel Figure 3: Endpoint to Security Gateway Tunnel
skipping to change at page 9, line 25 skipping to change at page 9, line 25
exchanges (known in IKEv1 as Phase 1). These initial exchanges exchanges (known in IKEv1 as Phase 1). These initial exchanges
normally consist of four messages, though in some scenarios that normally consist of four messages, though in some scenarios that
number can grow. All communications using IKE consist of request/ number can grow. All communications using IKE consist of request/
response pairs. We'll describe the base exchange first, followed by response pairs. We'll describe the base exchange first, followed by
variations. The first pair of messages (IKE_SA_INIT) negotiate variations. The first pair of messages (IKE_SA_INIT) negotiate
cryptographic algorithms, exchange nonces, and do a Diffie-Hellman cryptographic algorithms, exchange nonces, and do a Diffie-Hellman
exchange [DH]. exchange [DH].
The second pair of messages (IKE_AUTH) authenticate the previous The second pair of messages (IKE_AUTH) authenticate the previous
messages, exchange identities and certificates, and establish the messages, exchange identities and certificates, and establish the
first CHILD_SA. Parts of these messages are encrypted and integrity first Child SA. Parts of these messages are encrypted and integrity
protected with keys established through the IKE_SA_INIT exchange, so protected with keys established through the IKE_SA_INIT exchange, so
the identities are hidden from eavesdroppers and all fields in all the identities are hidden from eavesdroppers and all fields in all
the messages are authenticated. the messages are authenticated. (See Section 2.14 for information on
how the encyrption keys are generated.)
All messages following the initial exchange are cryptographically
protected using the cryptographic algorithms and keys negotiated in
the the IKE_SA_INIT exchange. These subsequent messages use the
syntax of the Encrypted Payload described in Section 3.14, encrypted
with keys that are derived as described in Section 2.14. All
subsequent messages include an Encrypted Payload, even if they are
referred to in the text as "empty". For the CREATE_CHILD_SA,
IKE_AUTH, or IKE_INFORMATIONAL exchanges, the message following the
header is encrypted and the message including the header is integrity
protected using the cryptographic algorithms negotiated for the IKE
SA.
In the following descriptions, the payloads contained in the message In the following descriptions, the payloads contained in the message
are indicated by names as listed below. are indicated by names as listed below.
Notation Payload Notation Payload
----------------------------------------- -----------------------------------------
AUTH Authentication AUTH Authentication
CERT Certificate CERT Certificate
CERTREQ Certificate Request CERTREQ Certificate Request
CP Configuration CP Configuration
skipping to change at page 10, line 17 skipping to change at page 10, line 38
payload can be included. payload can 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 and flags of various sorts. The SAi1 payload states the
cryptographic algorithms the initiator supports for the IKE_SA. The cryptographic algorithms the initiator supports for the IKE SA. The
KE payload sends the initiator's Diffie-Hellman value. Ni is the KE payload sends the initiator's Diffie-Hellman value. Ni is the
initiator's nonce. 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 SKEYSEED,
from which all keys are derived for that IKE_SA. All but the headers from which all keys are derived for that IKE SA. The messages that
of all the messages that follow are encrypted and integrity follow are encrypted and integrity protected in their entirety, with
protected. The keys used for the encryption and integrity protection the exception of the message headers. The keys used for the
are derived from SKEYSEED and are known as SK_e (encryption) and SK_a encryption and integrity protection are derived from SKEYSEED and are
(authentication, a.k.a. integrity protection). A separate SK_e and known as SK_e (encryption) and SK_a (authentication, a.k.a. integrity
SK_a is computed for each direction. In addition to the keys SK_e protection). A separate SK_e and SK_a is computed for each
and SK_a derived from the DH value for protection of the IKE_SA, direction. In addition to the keys SK_e and SK_a derived from the DH
another quantity SK_d is derived and used for derivation of further value for protection of the IKE SA, another quantity SK_d is derived
keying material for CHILD_SAs. The notation SK { ... } indicates and used for derivation of further keying material for Child SAs.
that these payloads are encrypted and integrity protected using that The notation SK { ... } indicates that these payloads are encrypted
direction's SK_e and SK_a. 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
any CERT payloads are included, the first certificate provided MUST any CERT payloads are included, the first certificate provided MUST
contain the public key used to verify the AUTH field. The optional contain the public key used to verify the AUTH field.
payload IDr enables the initiator to specify which of the responder's
identities it wants to talk to. This is useful when the machine on The optional payload IDr enables the initiator to specify which of
which the responder is running is hosting multiple identities at the the responder's identities it wants to talk to. This is useful when
same IP address. The initiator begins negotiation of a CHILD_SA the machine on which the responder is running is hosting multiple
using the SAi2 payload. The final fields (starting with SAi2) are identities at the same IP address. If the IDr proposed by the
described in the description of the CREATE_CHILD_SA exchange. initiator is not acceptable to the responder, the responder might use
some other IDr to finish the exchange. If the initiator then does
not accept that fact that responder used different IDr than the one
that was requested, the initiator can close the SA after noticing the
fact.
The initiator begins negotiation of a Child SA using the SAi2
payload. The final fields (starting with SAi2) are described in the
description of the CREATE_CHILD_SA exchange.
<-- HDR, SK {IDr, [CERT,] AUTH, <-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr} SAr2, TSi, TSr}
The responder asserts its identity with the IDr payload, optionally The responder asserts its identity with the IDr payload, optionally
sends one or more certificates (again with the certificate containing sends one or more certificates (again with the certificate containing
the public key used to verify AUTH listed first), authenticates its the public key used to verify AUTH listed first), authenticates its
identity and protects the integrity of the second message with the identity and protects the integrity of the second message with the
AUTH payload, and completes negotiation of a CHILD_SA with the AUTH payload, and completes negotiation of a Child SA with the
additional fields described below in the CREATE_CHILD_SA exchange. additional fields described below in the CREATE_CHILD_SA exchange.
The recipients of messages 3 and 4 MUST verify that all signatures The recipients of messages 3 and 4 MUST verify that all signatures
and MACs are computed correctly and that the names in the ID payloads and MACs are computed correctly and that the names in the ID payloads
correspond to the keys used to generate the AUTH payload. correspond to the keys used to generate the AUTH payload.
{{ Clarif-4.2}} If creating the CHILD_SA during the IKE_AUTH exchange {{ Clarif-4.2}} If creating the Child SA during the IKE_AUTH exchange
fails for some reason, the IKE_SA is still created as usual. The fails for some reason, the IKE SA is still created as usual. The
list of responses in the IKE_AUTH exchange that do not prevent an list of responses in the IKE_AUTH exchange that do not prevent an IKE
IKE_SA from being set up include at least the following: SA from being set up include at least the following:
NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED,
INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED. INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED.
{{ Clarif-4.3 }} Note that IKE_AUTH messages do not contain KEi/KEr {{ Clarif-4.3 }} Note that IKE_AUTH messages do not contain KEi/KEr
or Ni/Nr payloads. Thus, the SA payloads in the IKE_AUTH exchange or Ni/Nr payloads. Thus, the SA payloads in the IKE_AUTH exchange
cannot contain Transform Type 4 (Diffie-Hellman Group) with any value cannot contain Transform Type 4 (Diffie-Hellman Group) with any value
other than NONE. Implementations SHOULD omit the whole transform other than NONE. Implementations SHOULD omit the whole transform
substructure instead of sending value NONE. substructure instead of sending value NONE.
1.3. The CREATE_CHILD_SA Exchange 1.3. The CREATE_CHILD_SA Exchange
{{ This is a heavy rewrite of most of this section. The major {{ This is a heavy rewrite of most of this section. The major
organization changes are described in Clarif-4.1 and Clarif-5.1. }} organization changes are described in Clarif-4.1 and Clarif-5.1. }}
The CREATE_CHILD_SA exchange is used to create new CHILD_SAs and to The CREATE_CHILD_SA exchange is used to create new Child SAs and to
rekey both IKE_SAs and CHILD_SAs. This exchange consists of a single rekey both IKE SAs and Child SAs. This exchange consists of a single
request/response pair, and some of its function was referred to as a request/response pair, and some of its function was referred to as a
phase 2 exchange in IKEv1. It MAY be initiated by either end of the phase 2 exchange in IKEv1. It MAY be initiated by either end of the
IKE_SA after the initial exchanges are completed. IKE SA after the initial exchanges are completed.
All messages following the initial exchange are cryptographically All messages following the initial exchange are cryptographically
protected using the cryptographic algorithms and keys negotiated in protected using the cryptographic algorithms and keys negotiated in
the first two messages of the IKE exchange. These subsequent the first two messages of the IKE exchange. These subsequent
messages use the syntax of the Encrypted Payload described in messages use the syntax of the Encrypted Payload described in
Section 3.14. All subsequent messages include an Encrypted Payload, Section 3.14, encrypted with keys that are derived as described in
Section 2.14. All subsequent messages include an Encrypted Payload,
even if they are referred to in the text as "empty". For both even if they are referred to in the text as "empty". For both
messages in the CREATE_CHILD_SA, the message following the header is messages in the CREATE_CHILD_SA, the message following the header is
encrypted and the message including the header is integrity protected encrypted and the message including the header is integrity protected
using the cryptographic algorithms negotiated for the IKE_SA. using the cryptographic algorithms negotiated for the IKE SA.
The CREATE_CHILD_SA is also used for rekeying IKE_SAs and CHILD_SAs. The CREATE_CHILD_SA is also used for rekeying IKE SAs and Child SAs.
An SA is rekeyed by creating a new SA and then deleting the old one. An SA is rekeyed by creating a new SA and then deleting the old one.
This section describes the first part of rekeying, the creation of This section describes the first part of rekeying, the creation of
new SAs; Section 2.8 covers the mechanics of rekeying, including new SAs; Section 2.8 covers the mechanics of rekeying, including
moving traffic from old to new SAs and the deletion of the old SAs. moving traffic from old to new SAs and the deletion of the old SAs.
The two sections must be read together to understand the entire The two sections must be read together to understand the entire
process of rekeying. process of rekeying.
Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this
section the term initiator refers to the endpoint initiating this section the term initiator refers to the endpoint initiating this
exchange. An implementation MAY refuse all CREATE_CHILD_SA requests exchange. An implementation MAY refuse all CREATE_CHILD_SA requests
within an IKE_SA. within an IKE SA.
The CREATE_CHILD_SA request MAY optionally contain a KE payload for The CREATE_CHILD_SA request MAY optionally contain a KE payload for
an additional Diffie-Hellman exchange to enable stronger guarantees an additional Diffie-Hellman exchange to enable stronger guarantees
of forward secrecy for the CHILD_SA. The keying material for the of forward secrecy for the Child SA. The keying material for the
CHILD_SA is a function of SK_d established during the establishment Child SA is a function of SK_d established during the establishment
of the IKE_SA, the nonces exchanged during the CREATE_CHILD_SA of the IKE SA, the nonces exchanged during the CREATE_CHILD_SA
exchange, and the Diffie-Hellman value (if KE payloads are included exchange, and the Diffie-Hellman value (if KE payloads are included
in the CREATE_CHILD_SA exchange). in the CREATE_CHILD_SA exchange).
If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of
the SA offers MUST include the Diffie-Hellman group of the KEi. The the SA offers MUST include the Diffie-Hellman group of the KEi. The
Diffie-Hellman group of the KEi MUST be an element of the group the Diffie-Hellman group of the KEi MUST be an element of the group the
initiator expects the responder to accept (additional Diffie-Hellman initiator expects the responder to accept (additional Diffie-Hellman
groups can be proposed). If the responder selects a proposal using a groups can be proposed). If the responder selects a proposal using a
different Diffie-Hellman group (other than NONE), the responder MUST different Diffie-Hellman group (other than NONE), the responder MUST
reject the request and indicate its preferred Diffie-Hellman group in reject the request and indicate its preferred Diffie-Hellman group in
the INVALID_KE_PAYLOAD Notification payload. {{ 3.10.1-17 }} There the INVALID_KE_PAYLOAD Notification payload. {{ 3.10.1-17 }} There
are two octets of data associated with this notification: the are two octets of data associated with this notification: the
accepted D-H Group number in big endian order. In the case of such a accepted D-H Group number in big endian order. In the case of such a
rejection, the CREATE_CHILD_SA exchange fails, and the initiator will rejection, the CREATE_CHILD_SA exchange fails, and the initiator will
probably retry the exchange with a Diffie-Hellman proposal and KEi in probably retry the exchange with a Diffie-Hellman proposal and KEi in
the group that the responder gave in the INVALID_KE_PAYLOAD. the group that the responder gave in the INVALID_KE_PAYLOAD.
{{ 3.10.1-35 }} The responder sends a NO_ADDITIONAL_SAS notification {{ 3.10.1-35 }} The responder sends a NO_ADDITIONAL_SAS notification
to indicate that a CREATE_CHILD_SA request is unacceptable because to indicate that a CREATE_CHILD_SA request is unacceptable because
the responder is unwilling to accept any more CHILD_SAs on this the responder is unwilling to accept any more Child SAs on this IKE
IKE_SA. Some minimal implementations may only accept a single SA. Some minimal implementations may only accept a single Child SA
CHILD_SA setup in the context of an initial IKE exchange and reject setup in the context of an initial IKE exchange and reject any
any subsequent attempts to add more. subsequent attempts to add more.
1.3.1. Creating New CHILD_SAs with the CREATE_CHILD_SA Exchange 1.3.1. Creating New Child SAs with the CREATE_CHILD_SA Exchange
A CHILD_SA may be created by sending a CREATE_CHILD_SA request. The A Child SA may be created by sending a CREATE_CHILD_SA request. The
CREATE_CHILD_SA request for creating a new CHILD_SA is: CREATE_CHILD_SA request for creating a new Child SA is:
Initiator Responder Initiator Responder
------------------------------------------------------------------- -------------------------------------------------------------------
HDR, SK {SA, Ni, [KEi], HDR, SK {SA, Ni, [KEi],
TSi, TSr} --> TSi, TSr} -->
The initiator sends SA offer(s) in the SA payload, a nonce in the Ni The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
payload, 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, and a Diffie-Hellman value in the
KEr payload if KEi was included in the request and the selected KEr payload if KEi was included in the request and the selected
cryptographic suite includes that group. 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.
{{ 3.10.1-16391 }} The USE_TRANSPORT_MODE notification MAY be {{ 3.10.1-16391 }} The USE_TRANSPORT_MODE notification MAY be
included in a request message that also includes an SA payload included in a request message that also includes an SA payload
requesting a CHILD_SA. It requests that the CHILD_SA use transport requesting a Child SA. It requests that the Child SA use transport
mode rather than tunnel mode for the SA created. If the request is mode rather than tunnel mode for the SA created. If the request is
accepted, the response MUST also include a notification of type accepted, the response MUST also include a notification of type
USE_TRANSPORT_MODE. If the responder declines the request, the USE_TRANSPORT_MODE. If the responder declines the request, the Child
CHILD_SA will be established in tunnel mode. If this is unacceptable SA will be established in tunnel mode. If this is unacceptable to
to the initiator, the initiator MUST delete the SA. Note: Except the initiator, the initiator MUST delete the SA. Note: Except when
when using this option to negotiate transport mode, all CHILD_SAs using this option to negotiate transport mode, all Child SAs will use
will use tunnel mode. tunnel mode.
{{ 3.10.1-16394 }} The ESP_TFC_PADDING_NOT_SUPPORTED notification {{ 3.10.1-16394 }} The ESP_TFC_PADDING_NOT_SUPPORTED notification
asserts that the sending endpoint will NOT accept packets that asserts that the sending endpoint will NOT accept packets that
contain Traffic Flow Confidentiality (TFC) padding over the CHILD_SA contain Traffic Flow Confidentiality (TFC) padding over the Child SA
being negotiated. {{ Clarif-4.5 }} If neither endpoint accepts TFC being negotiated. {{ Clarif-4.5 }} If neither endpoint accepts TFC
padding, this notification is included in both the request and the padding, this notification is included in both the request and the
response. If this notification is included in only one of the response. If this notification is included in only one of the
messages, TFC padding can still be sent in the other direction. messages, TFC padding can still be sent in the other direction.
{{ 3.10.1-16395 }} The NON_FIRST_FRAGMENTS_ALSO notification is used {{ 3.10.1-16395 }} The NON_FIRST_FRAGMENTS_ALSO notification is used
for fragmentation control. See [IPSECARCH] for a fuller explanation. for fragmentation control. See [IPSECARCH] for a fuller explanation.
{{ Clarif-4.6 }} Sending non-first fragments is enabled only if {{ Clarif-4.6 }} Both parties need to agree to sending non-first
fragments before either party does so. It is enabled only if
NON_FIRST_FRAGMENTS_ALSO notification is included in both the request NON_FIRST_FRAGMENTS_ALSO notification is included in both the request
proposing an SA and the response accepting it. If the peer rejects proposing an SA and the response accepting it. If the responder does
the proposal of the SA, the peer only omits NON_FIRST_FRAGMENTS_ALSO not want to send or receive non-first fragments, it only omits
notification from the response, but does not reject the whole NON_FIRST_FRAGMENTS_ALSO notification from its response, but does not
CHILD_SA creation. reject the whole Child SA creation.
1.3.2. Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange
The CREATE_CHILD_SA request for rekeying an IKE_SA is: The CREATE_CHILD_SA request for rekeying an IKE SA is:
Initiator Responder Initiator Responder
------------------------------------------------------------------- -------------------------------------------------------------------
HDR, SK {SA, Ni, [KEi]} --> HDR, SK {SA, Ni, [KEi]} -->
The initiator sends SA offer(s) in the SA payload, a nonce in the Ni The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
payload, and a Diffie-Hellman value in the KEi payload. The KEi payload, and a Diffie-Hellman value in the KEi payload. The KEi
payload SHOULD be included. New initiator and responder SPIs are payload SHOULD be included. New initiator and responder SPIs are
supplied in the SPI fields. supplied in the SPI fields of the SA payload.
The CREATE_CHILD_SA response for rekeying an IKE_SA is: The CREATE_CHILD_SA response for rekeying an IKE SA is:
<-- HDR, SK {SA, Nr,[KEr]} <-- HDR, SK {SA, Nr,[KEr]}
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, and a Diffie-Hellman value in the
KEr payload if the selected cryptographic suite includes that group. KEr payload if the selected cryptographic suite includes that group.
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 window size starts at 1 for any they were in the earlier IKE SA. The window size starts at 1 for any
new IKE_SA. new IKE SA.
1.3.3. Rekeying CHILD_SAs with the CREATE_CHILD_SA Exchange 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA Exchange
The CREATE_CHILD_SA request for rekeying a CHILD_SA is: The CREATE_CHILD_SA request for rekeying a Child SA is:
Initiator Responder Initiator Responder
------------------------------------------------------------------- -------------------------------------------------------------------
HDR, SK {N, SA, Ni, [KEi], HDR, SK {N, SA, Ni, [KEi],
TSi, TSr} --> TSi, TSr} -->
The initiator sends SA offer(s) in the SA payload, a nonce in the Ni The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
payload, 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.
{{ 3.10.1-16393 }} The REKEY_SA notification MUST be included in a {{ 3.10.1-16393 }} The REKEY_SA notification MUST be included in a
CREATE_CHILD_SA exchange if the purpose of the exchange is to replace CREATE_CHILD_SA exchange if the purpose of the exchange is to replace
an existing ESP or AH SA. {{ Clarif-5.4 }} The SA being rekeyed is an existing ESP or AH SA. {{ Clarif-5.4 }} The SA being rekeyed is
identified by the SPI field in the Notify payload; this is the SPI identified by the SPI field in the Notify payload; this is the SPI
the exchange initiator would expect in inbound ESP or AH packets. the exchange initiator would expect in inbound ESP or AH packets.
There is no data associated with this Notify type. There is no data associated with this Notify type. The Protocol ID
field of the REKEY_SA notification is set to match the protocol of
the SA we are rekeying, 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],
Si, 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, and a Diffie-Hellman value in the
KEr payload if KEi was included in the request and the selected KEr payload if KEi was included in the request and the selected
cryptographic suite includes that group. 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
INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur
after the initial exchanges and are cryptographically protected with after the initial exchanges and are cryptographically protected with
the negotiated keys. the negotiated keys.
Control messages that pertain to an IKE_SA MUST be sent under that Control messages that pertain to an IKE SA MUST be sent under that
IKE_SA. Control messages that pertain to CHILD_SAs MUST be sent IKE SA. Control messages that pertain to Child SAs MUST be sent
under the protection of the IKE_SA which generated them (or its under the protection of the IKE SA which generated them (or its
successor if the IKE_SA was replaced for the purpose of rekeying). successor if the IKE SA was rekeyed).
Messages in an INFORMATIONAL exchange contain zero or more Messages in an INFORMATIONAL exchange contain zero or more
Notification, Delete, and Configuration payloads. The Recipient of Notification, Delete, and Configuration payloads. The Recipient of
an INFORMATIONAL exchange request MUST send some response (else the an INFORMATIONAL exchange request MUST send some response (else the
Sender will assume the message was lost in the network and will Sender will assume the message was lost in the network and will
retransmit it). That response MAY be a message with no payloads. retransmit it). That response MAY be a message with no payloads.
The request message in an INFORMATIONAL exchange MAY also contain no The request message in an INFORMATIONAL exchange MAY also contain no
payloads. This is the expected way an endpoint can ask the other payloads. This is the expected way an endpoint can ask the other
endpoint to verify that it is alive. endpoint to verify that it is alive.
The INFORMATIONAL exchange is defined as:
Initiator Responder
-------------------------------------------------------------------
HDR, SK {[N,] [D,]
[CP,] ...} -->
<-- HDR, SK {[N,] [D,]
[CP], ...}
The processing of an INFORMATIONAL exchange is determined by its
component payloads.
1.4.1. Deleting an SA with INFORMATIONAL Exchanges
{{ Clarif-5.6 }} ESP and AH SAs always exist in pairs, with one SA in {{ Clarif-5.6 }} ESP and AH SAs always exist in pairs, with one SA in
each direction. When an SA is closed, both members of the pair MUST each direction. When an SA is closed, both members of the pair MUST
be closed (that is, deleted). Each endpoint MUST close its incoming be closed (that is, deleted). Each endpoint MUST close its incoming
SAs and allow the other endpoint to close the other SA in each pair. SAs and allow the other endpoint to close the other SA in each pair.
To delete an SA, an INFORMATIONAL exchange with one or more delete To delete an SA, an INFORMATIONAL exchange with one or more delete
payloads is sent listing the SPIs (as they would be expected in the payloads is sent listing the SPIs (as they would be expected in the
headers of inbound packets) of the SAs to be deleted. The recipient headers of inbound packets) of the SAs to be deleted. The recipient
MUST close the designated SAs. {{ Clarif-5.7 }} Note that one never MUST close the designated SAs. {{ Clarif-5.7 }} Note that one never
sends delete payloads for the two sides of an SA in a single message. sends delete payloads for the two sides of an SA in a single message.
If there are many SAs to delete at the same time, one includes delete If there are many SAs to delete at the same time, one includes delete
payloads for in inbound half of each SA pair in your Informational payloads for the inbound half of each SA pair in your Informational
exchange. exchange.
Normally, the reply in the INFORMATIONAL exchange will contain delete Normally, the reply in the INFORMATIONAL exchange will contain delete
payloads for the paired SAs going in the other direction. There is payloads for the paired SAs going in the other direction. There is
one exception. If by chance both ends of a set of SAs independently one exception. If by chance both ends of a set of SAs independently
decide to close them, each may send a delete payload and the two decide to close them, each may send a delete payload and the two
requests may cross in the network. If a node receives a delete requests may cross in the network. If a node receives a delete
request for SAs for which it has already issued a delete request, it request for SAs for which it has already issued a delete request, it
MUST delete the outgoing SAs while processing the request and the MUST delete the outgoing SAs while processing the request and the
incoming SAs while processing the response. In that case, the incoming SAs while processing the response. In that case, the
skipping to change at page 16, line 33 skipping to change at page 17, line 29
that would result in duplicate deletion and could in theory delete that would result in duplicate deletion and could in theory delete
the wrong SA. the wrong SA.
{{ Demoted the SHOULD }} Half-closed ESP or AH connections are {{ Demoted the SHOULD }} Half-closed ESP or AH connections are
anomalous, and a node with auditing capability should probably audit anomalous, and a node with auditing capability should probably audit
their existence if they persist. Note that this specification their existence if they persist. Note that this specification
nowhere specifies time periods, so it is up to individual endpoints nowhere specifies time periods, so it is up to individual endpoints
to decide how long to wait. A node MAY refuse to accept incoming to decide how long to wait. A node MAY refuse to accept incoming
data on half-closed connections but MUST NOT unilaterally close them data on half-closed connections but MUST NOT unilaterally close them
and reuse the SPIs. If connection state becomes sufficiently messed and reuse the SPIs. If connection state becomes sufficiently messed
up, a node MAY close the IKE_SA; doing so will implicitly close all up, a node MAY close the IKE SA; doing so will implicitly close all
SAs negotiated under it. It can then rebuild the SAs it needs on a SAs negotiated under it. It can then rebuild the SAs it needs on a
clean base under a new IKE_SA. {{ Clarif-5.8 }} The response to a clean base under a new IKE SA. {{ Clarif-5.8 }} The response to a
request that deletes the IKE_SA is an empty Informational response. request that deletes the IKE SA is an empty Informational response.
The INFORMATIONAL exchange is defined as:
Initiator Responder
-------------------------------------------------------------------
HDR, SK {[N,] [D,]
[CP,] ...} -->
<-- HDR, SK {[N,] [D,]
[CP], ...}
The processing of an INFORMATIONAL exchange is determined by its
component payloads.
1.5. Informational Messages outside of an IKE_SA 1.5. Informational Messages outside of an IKE SA
If an encrypted IKE request packet arrives on port 500 or 4500 with If an encrypted IKE request packet arrives on port 500 or 4500 with
an unrecognized SPI, it could be because the receiving node has an unrecognized SPI, it could be because the receiving node has
recently crashed and lost state or because of some other system recently crashed and lost state or because of some other system
malfunction or attack. If the receiving node has an active IKE_SA to malfunction or attack. If the receiving node has an active IKE SA to
the IP address from whence the packet came, it MAY send a the IP address from whence the packet came, it MAY send a
notification of the wayward packet over that IKE_SA in an notification of the wayward packet over that IKE SA in an
INFORMATIONAL exchange. If it does not have such an IKE_SA, it MAY INFORMATIONAL exchange. If it does not have such an IKE SA, it MAY
send an Informational message without cryptographic protection to the send an Informational message without cryptographic protection to the
source IP address. Such a message is not part of an informational source IP address. Such a message is not part of an informational
exchange, and the receiving node MUST NOT respond to it. Doing so exchange, and the receiving node MUST NOT respond to it. Doing so
could cause a message loop. could cause a message loop.
{{ 3.10.1-11 }} The INVALID_SPI notification MAY be sent in an IKE {{ 3.10.1-11 }} The INVALID_SPI notification MAY be sent in an IKE
INFORMATIONAL exchange when a node receives an ESP or AH packet with INFORMATIONAL exchange when a node receives an ESP or AH packet with
an invalid SPI. The Notification Data contains the SPI of the an invalid SPI. The Notification Data contains the SPI of the
invalid packet. This usually indicates a node has rebooted and invalid packet. This usually indicates a node has rebooted and
forgotten an SA. If this Informational Message is sent outside the forgotten an SA. If this Informational Message is sent outside the
context of an IKE_SA, it should only be used by the recipient as a context of an IKE SA, it should only be used by the recipient as a
"hint" that something might be wrong (because it could easily be "hint" that something might be wrong (because it could easily be
forged). forged).
{{ Clarif-7.7 }} There are two cases when such a one-way notification {{ Clarif-7.7 }} There are two cases when such a one-way notification
is sent: INVALID_IKE_SPI and INVALID_SPI. These notifications are is sent: INVALID_IKE_SPI and INVALID_SPI. These notifications are
sent outside of an IKE_SA. Note that such notifications are sent outside of an IKE SA. Note that such notifications are
explicitly not Informational exchanges; these are one-way messages explicitly not Informational exchanges; these are one-way messages
that must not be responded to. In case of INVALID_IKE_SPI, the that must not be responded to.
message sent is a response message, and thus it is sent to the IP
address and port from whence it came with the same IKE SPIs and the In case of INVALID_IKE_SPI, the message sent is a response message,
Message ID copied. In case of INVALID_SPI, however, there are no IKE and thus it is sent to the IP address and port from whence it came
SPI values that would be meaningful to the recipient of such a with the same IKE SPIs and the Message ID is copied. The Response
notification. Using zero values or random values are both bit is set to 1, and the version flags are set in the normal fashion.
acceptable.
In case of INVALID_SPI, however, there are no IKE SPI values that
would be meaningful to the recipient of such a notification. Using
zero values or random values are both acceptable. The Initiator flag
is set, the Response bit is set to 0, and the version flags are set
in the normal fashion.
1.6. Requirements Terminology 1.6. Requirements Terminology
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]. {{ Clarif-7.2 }} It Association or SA) can be found in [IPSECARCH]. {{ Clarif-7.2 }} It
should be noted that parts of IKEv2 rely on some of the processing should be noted that parts of IKEv2 rely on some of the processing
rules in [IPSECARCH], as described in various sections of this rules in [IPSECARCH], as described in various sections of this
document. document.
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
skipping to change at page 18, line 19 skipping to change at page 19, line 4
This document contains clarifications and amplifications to IKEv2 This document contains clarifications and amplifications to IKEv2
[IKEV2]. The clarifications are mostly based on [Clarif]. The [IKEV2]. The clarifications are mostly 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
version number (2) and minor version number (0) as was used in RFC version number (2) and minor version number (0) as was used in RFC
4306. 4306. That is, the version number is *not* changed from RFC 4306.
This document makes the figures and references a bit more regular This document makes the figures and references a bit more regular
than in [IKEV2]. than in [IKEV2].
IKEv2 developers have noted that the SHOULD-level requirements are IKEv2 developers have noted that the SHOULD-level requirements are
often unclear in that they don't say when it is OK to not obey the often unclear in that they don't say when it is OK to not obey the
requirements. They also have noted that there are MUST-level requirements. They also have noted that there are MUST-level
requirements that are not related to interoperability. This document requirements that are not related to interoperability. This document
has more explanation of some of these requirements. All non- has more explanation of some of these requirements. All non-
capitalized uses of the words SHOULD and MUST now mean their normal capitalized uses of the words SHOULD and MUST now mean their normal
English sense, not the interoperability sense of [MUSTSHOULD]. English sense, not the interoperability sense of [MUSTSHOULD].
IKEv2 (and IKEv1) developers have noted that there is a great deal of IKEv2 (and IKEv1) developers have noted that there is a great deal of
material in the tables of codes in Section 3.10.1. This leads to material in the tables of codes in Section 3.10.1. This leads to
implementers not having all the needed information in the main body implementers not having all the needed information in the main body
of the docment. Much of the material from those tables has been of the document. Much of the material from those tables has been
moved into the associated parts of the main body of the document. moved into the associated parts of the main body of the document.
In the body of this document, notes that are enclosed in double curly In the body of this document, notes that are enclosed in double curly
braces {{ such as this }} point out changes from IKEv2. Changes that braces {{ such as this }} point out changes from IKEv2. Changes that
come from [Clarif] are marked with the section from that document, come from [Clarif] are marked with the section from that document,
such as "{{ Clarif-2.10 }}". Changes that come from moving such as "{{ Clarif-2.10 }}". Changes that come from moving
descriptive text out of the tables in Section 3.10.1 are marked with descriptive text out of the tables in Section 3.10.1 are marked with
that number and the message type that contained the text, such as "{{ that number and the message type that contained the text, such as "{{
3.10.1-16384 }}". 3.10.1-16384 }}".
skipping to change at page 20, line 19 skipping to change at page 21, line 8
established, recursion issues could prevent this technique from established, recursion issues could prevent this technique from
working. working.
{{ Clarif-7.5 }} The UDP payload of all packets containing IKE {{ Clarif-7.5 }} The UDP payload of all packets containing IKE
messages sent on port 4500 MUST begin with the prefix of four zeros; messages sent on port 4500 MUST begin with the prefix of four zeros;
otherwise, the receiver won't know how to handle them. otherwise, the receiver won't know how to handle them.
2.1. Use of Retransmission Timers 2.1. Use of Retransmission Timers
All messages in IKE exist in pairs: a request and a response. The All messages in IKE exist in pairs: a request and a response. The
setup of an IKE_SA normally consists of two request/response pairs. setup of an IKE SA normally consists of two request/response pairs.
Once the IKE_SA is set up, either end of the security association may Once the IKE SA is set up, either end of the security association may
initiate requests at any time, and there can be many requests and initiate requests at any time, and there can be many requests and
responses "in flight" at any given moment. But each message is responses "in flight" at any given moment. But each message is
labeled as either a request or a response, and for each request/ labeled as either a request or a response, and for each request/
response pair one end of the security association is the initiator response pair one end of the security association is the initiator
and the other is the responder. and the other is the responder.
For every pair of IKE messages, the initiator is responsible for For every pair of IKE messages, the initiator is responsible for
retransmission in the event of a timeout. The responder MUST never retransmission in the event of a timeout. The responder MUST never
retransmit a response unless it receives a retransmission of the retransmit a response unless it receives a retransmission of the
request. In that event, the responder MUST ignore the retransmitted request. In that event, the responder MUST ignore the retransmitted
request except insofar as it triggers a retransmission of the request except insofar as it triggers a retransmission of the
response. The initiator MUST remember each request until it receives response. The initiator MUST remember each request until it receives
the corresponding response. The responder MUST remember each the corresponding response. The responder MUST remember each
response until it receives a request whose sequence number is larger response until it receives a request whose sequence number is larger
than or equal to the sequence number in the response plus its window than or equal to the sequence number in the response plus its window
size (see Section 2.3). size (see Section 2.3).
IKE is a reliable protocol, in the sense that the initiator MUST IKE is a reliable protocol, in the sense that the initiator MUST
retransmit a request until either it receives a corresponding reply retransmit a request until either it receives a corresponding reply
OR it deems the IKE security association to have failed and it OR it deems the IKE security association to have failed and it
discards all state associated with the IKE_SA and any CHILD_SAs discards all state associated with the IKE SA and any Child SAs
negotiated using that IKE_SA. negotiated using that IKE SA. A retransmission from the initiator
MUST be bitwise identical to the original request. That is,
everything starting from the IKE Header (the IKE SA Initiator's SPI
onwards) must be bitwise identical; items before it (such as the IP
and UDP headers, and the zero non-ESP marker) do not have to be
identical.
{{ Clarif-2.3 }} Retransmissions of the IKE_SA_INIT request require {{ Clarif-2.3 }} Retransmissions of the IKE_SA_INIT request require
some special handling. When a responder receives an IKE_SA_INIT some special handling. When a responder receives an IKE_SA_INIT
request, it has to determine whether the packet is retransmission request, it has to determine whether the packet is retransmission
belonging to an existing "half-open" IKE_SA (in which case the belonging to an existing "half-open" IKE SA (in which case the
responder retransmits the same response), or a new request (in which responder retransmits the same response), or a new request (in which
case the responder creates a new IKE_SA and sends a fresh response), case the responder creates a new IKE SA and sends a fresh response),
or it belongs to an existing IKE_SA where the IKE_AUTH request has or it belongs to an existing IKE SA where the IKE_AUTH request has
been already received (in which case the responder ignores it). been already received (in which case the responder ignores it).
It is not sufficient to use the initiator's SPI and/or IP address to It is not sufficient to use the initiator's SPI and/or IP address to
differentiate between these three cases because two different peers differentiate between these three cases because two different peers
behind a single NAT could choose the same initiator SPI. Instead, a behind a single NAT could choose the same initiator SPI. Instead, a
robust responder will do the IKE_SA lookup using the whole packet, robust responder will do the IKE SA lookup using the whole packet,
its hash, or the Ni payload. its hash, or the Ni payload.
2.2. Use of Sequence Numbers for Message ID 2.2. Use of Sequence Numbers for Message ID
Every IKE message contains a Message ID as part of its fixed header. Every IKE message contains a Message ID as part of its fixed header.
This Message ID is used to match up requests and responses, and to This Message ID is used to match up requests and responses, and to
identify retransmissions of messages. identify retransmissions of messages.
The Message ID is a 32-bit quantity, which is zero for the The Message ID is a 32-bit quantity, which is zero for the
IKE_SA_INIT messages (including retries of the message due to IKE_SA_INIT messages (including retries of the message due to
responses such as COOKIE and INVALID_KE_PAYLOAD {{ Clarif-2.2 }}), responses such as COOKIE and INVALID_KE_PAYLOAD {{ Clarif-2.2 }}),
and incremented for each subsequent exchange. Thus, the first pair and incremented for each subsequent exchange. Rekeying an IKE SA
of IKE_AUTH messages will have ID of 1, the second (when EAP is used) resets the sequence numbers. Thus, the first pair of IKE_AUTH
will be 2, and so on. {{ Clarif-3.10 }} messages will have ID of 1, the second (when EAP is used) will be 2,
and so on. {{ Clarif-3.10 }}
Each endpoint in the IKE Security Association maintains two "current" Each endpoint in the IKE Security Association maintains two "current"
Message IDs: the next one to be used for a request it initiates and Message IDs: the next one to be used for a request it initiates and
the next one it expects to see in a request from the other end. the next one it expects to see in a request from the other end.
These counters increment as requests are generated and received. These counters increment as requests are generated and received.
Responses always contain the same message ID as the corresponding Responses always contain the same message ID as the corresponding
request. That means that after the initial exchange, each integer n request. That means that after the initial exchange, each integer n
may appear as the message ID in four distinct messages: the nth may appear as the message ID in four distinct messages: the nth
request from the original IKE initiator, the corresponding response, request from the original IKE initiator, the corresponding response,
the nth request from the original IKE responder, and the the nth request from the original IKE responder, and the
corresponding response. If the two ends make very different numbers corresponding response. If the two ends make very different numbers
of requests, the Message IDs in the two directions can be very of requests, the Message IDs in the two directions can be very
different. There is no ambiguity in the messages, however, because different. There is no ambiguity in the messages, however, because
the (I)nitiator and (R)esponse bits in the message header specify the (I)nitiator and (R)esponse bits in the message header specify
which of the four messages a particular one is. which of the four messages a particular one is.
{{ Clarif-5.9 }} Throughout this document, "initiator" refers to the
party who initiated the exchange being described, and "original
initiator" refers to the party who initiated the whole IKE SA. The
"original initiator" always refers to the party who initiated the
exchange which resulted in the current IKE SA. In other words, if
the "original responder" starts rekeying the IKE SA, that party
becomes the "original initiator" of the new IKE SA.
Note that Message IDs are cryptographically protected and provide Note that Message IDs are cryptographically protected and provide
protection against message replays. In the unlikely event that protection against message replays. In the unlikely event that
Message IDs grow too large to fit in 32 bits, the IKE_SA MUST be Message IDs grow too large to fit in 32 bits, the IKE SA MUST be
closed. Rekeying an IKE_SA resets the sequence numbers. closed or rekeyed.
2.3. Window Size for Overlapping Requests 2.3. Window Size for Overlapping Requests
In order to maximize IKE throughput, an IKE endpoint MAY issue In order to maximize IKE throughput, an IKE endpoint MAY issue
multiple requests before getting a response to any of them if the multiple requests before getting a response to any of them if the
other endpoint has indicated its ability to handle such requests. other endpoint has indicated its ability to handle such requests.
For simplicity, an IKE implementation MAY choose to process requests For simplicity, an IKE implementation MAY choose to process requests
strictly in order and/or wait for a response to one request before strictly in order and/or wait for a response to one request before
issuing another. Certain rules must be followed to ensure issuing another. Certain rules must be followed to ensure
interoperability between implementations using different strategies. interoperability between implementations using different strategies.
After an IKE_SA is set up, either end can initiate one or more After an IKE SA is set up, either end can initiate one or more
requests. These requests may pass one another over the network. An requests. These requests may pass one another over the network. An
IKE endpoint MUST be prepared to accept and process a request while IKE endpoint MUST be prepared to accept and process a request while
it has a request outstanding in order to avoid a deadlock in this it has a request outstanding in order to avoid a deadlock in this
situation. {{ Downgraded the SHOULD }} An IKE endpoint may also situation. {{ Downgraded the SHOULD }} An IKE endpoint may also
accept and process multiple requests while it has a request accept and process multiple requests while it has a request
outstanding. outstanding.
{{ 3.10.1-16385 }} The SET_WINDOW_SIZE notification asserts that the {{ 3.10.1-16385 }} The SET_WINDOW_SIZE notification asserts that the
sending endpoint is capable of keeping state for multiple outstanding sending endpoint is capable of keeping state for multiple outstanding
exchanges, permitting the recipient to send multiple requests before exchanges, permitting the recipient to send multiple requests before
skipping to change at page 22, line 49 skipping to change at page 24, line 4
An IKE endpoint supporting a window size greater than one ought to be An IKE endpoint supporting a window size greater than one ought to be
capable of processing incoming requests out of order to maximize capable of processing incoming requests out of order to maximize
performance in the event of network failures or packet reordering. performance in the event of network failures or packet reordering.
{{ Clarif-7.3 }} The window size is normally a (possibly {{ Clarif-7.3 }} The window size is normally a (possibly
configurable) property of a particular implementation, and is not configurable) property of a particular implementation, and is not
related to congestion control (unlike the window size in TCP, for related to congestion control (unlike the window size in TCP, for
example). In particular, it is not defined what the responder should example). In particular, it is not defined what the responder should
do when it receives a SET_WINDOW_SIZE notification containing a do when it receives a SET_WINDOW_SIZE notification containing a
smaller value than is currently in effect. Thus, there is currently smaller value than is currently in effect. Thus, there is currently
no way to reduce the window size of an existing IKE_SA; you can only no way to reduce the window size of an existing IKE SA; you can only
increase it. When rekeying an IKE_SA, the new IKE_SA starts with increase it. When rekeying an IKE SA, the new IKE SA starts with
window size 1 until it is explicitly increased by sending a new window size 1 until it is explicitly increased by sending a new
SET_WINDOW_SIZE notification. SET_WINDOW_SIZE notification.
{{ 3.10.1-9 }}The INVALID_MESSAGE_ID notification is sent when an IKE {{ 3.10.1-9 }}The INVALID_MESSAGE_ID notification is sent when an IKE
message ID outside the supported window is received. This Notify message ID outside the supported window is received. This Notify
MUST NOT be sent in a response; the invalid request MUST NOT be MUST NOT be sent in a response; the invalid request MUST NOT be
acknowledged. Instead, inform the other side by initiating an acknowledged. Instead, inform the other side by initiating an
INFORMATIONAL exchange with Notification data containing the four INFORMATIONAL exchange with Notification data containing the four
octet invalid message ID. Sending this notification is optional, and octet invalid message ID. Sending this notification is optional, and
notifications of this type MUST be rate limited. notifications of this type MUST be rate limited.
2.4. State Synchronization and Connection Timeouts 2.4. State Synchronization and Connection Timeouts
An IKE endpoint is allowed to forget all of its state associated with An IKE endpoint is allowed to forget all of its state associated with
an IKE_SA and the collection of corresponding CHILD_SAs at any time. an IKE SA and the collection of corresponding Child SAs at any time.
This is the anticipated behavior in the event of an endpoint crash This is the anticipated behavior in the event of an endpoint crash
and restart. It is important when an endpoint either fails or and restart. It is important when an endpoint either fails or
reinitializes its state that the other endpoint detect those reinitializes its state that the other endpoint detect those
conditions and not continue to waste network bandwidth by sending conditions and not continue to waste network bandwidth by sending
packets over discarded SAs and having them fall into a black hole. packets over discarded SAs and having them fall into a black hole.
{{ 3.10.1-16384 }} The INITIAL_CONTACT notification asserts that this {{ 3.10.1-16384 }} The INITIAL_CONTACT notification asserts that this
IKE_SA is the only IKE_SA currently active between the authenticated IKE SA is the only IKE SA currently active between the authenticated
identities. It MAY be sent when an IKE_SA is established after a identities. It MAY be sent when an IKE SA is established after a
crash, and the recipient MAY use this information to delete any other crash, and the recipient MAY use this information to delete any other
IKE_SAs it has to the same authenticated identity without waiting for IKE SAs it has to the same authenticated identity without waiting for
a timeout. This notification MUST NOT be sent by an entity that may a timeout. This notification MUST NOT be sent by an entity that may
be replicated (e.g., a roaming user's credentials where the user is be replicated (e.g., a roaming user's credentials where the user is
allowed to connect to the corporate firewall from two remote systems allowed to connect to the corporate firewall from two remote systems
at the same time). {{ Clarif-7.9 }} The INITIAL_CONTACT notification, at the same time). {{ Clarif-7.9 }} The INITIAL_CONTACT notification,
if sent, MUST be in the first IKE_AUTH request, not as a separate if sent, MUST be in the first IKE_AUTH request, not as a separate
exchange afterwards; however, receiving parties need to deal with it exchange afterwards; however, receiving parties need to deal with it
in other requests. in other requests.
Since IKE is designed to operate in spite of Denial of Service (DoS) Since IKE is designed to operate in spite of Denial of Service (DoS)
attacks from the network, an endpoint MUST NOT conclude that the attacks from the network, an endpoint MUST NOT conclude that the
other endpoint has failed based on any routing information (e.g., other endpoint has failed based on any routing information (e.g.,
ICMP messages) or IKE messages that arrive without cryptographic ICMP messages) or IKE messages that arrive without cryptographic
protection (e.g., Notify messages complaining about unknown SPIs). protection (e.g., Notify messages complaining about unknown SPIs).
An endpoint MUST conclude that the other endpoint has failed only An endpoint MUST conclude that the other endpoint has failed only
when repeated attempts to contact it have gone unanswered for a when repeated attempts to contact it have gone unanswered for a
timeout period or when a cryptographically protected INITIAL_CONTACT timeout period or when a cryptographically protected INITIAL_CONTACT
notification is received on a different IKE_SA to the same notification is received on a different IKE SA to the same
authenticated identity. {{ Demoted the SHOULD }} An endpoint should authenticated identity. {{ Demoted the SHOULD }} An endpoint should
suspect that the other endpoint has failed based on routing suspect that the other endpoint has failed based on routing
information and initiate a request to see whether the other endpoint information and initiate a request to see whether the other endpoint
is alive. To check whether the other side is alive, IKE specifies an is alive. To check whether the other side is alive, IKE specifies an
empty INFORMATIONAL message that (like all IKE requests) requires an empty INFORMATIONAL message that (like all IKE requests) requires an
acknowledgement (note that within the context of an IKE_SA, an acknowledgement (note that within the context of an IKE SA, an
"empty" message consists of an IKE header followed by an Encrypted "empty" message consists of an IKE header followed by an Encrypted
payload that contains no payloads). If a cryptographically protected payload that contains no payloads). If a cryptographically protected
message has been received from the other side recently, unprotected (fresh, i.e. not retransmitted) message has been received from the
notifications MAY be ignored. Implementations MUST limit the rate at other side recently, unprotected notifications MAY be ignored.
which they take actions based on unprotected messages. Implementations MUST limit the rate at which they take actions based
on unprotected messages.
Numbers of retries and lengths of timeouts are not covered in this Numbers of retries and lengths of timeouts are not covered in this
specification because they do not affect interoperability. It is specification because they do not affect interoperability. It is
suggested that messages be retransmitted at least a dozen times over suggested that messages be retransmitted at least a dozen times over
a period of at least several minutes before giving up on an SA, but a period of at least several minutes before giving up on an SA, but
different environments may require different rules. To be a good different environments may require different rules. To be a good
network citizen, retranmission times MUST increase exponentially to network citizen, retranmission times MUST increase exponentially to
avoid flooding the network and making an existing congestion avoid flooding the network and making an existing congestion
situation worse. If there has only been outgoing traffic on all of situation worse. If there has only been outgoing traffic on all of
the SAs associated with an IKE_SA, it is essential to confirm the SAs associated with an IKE SA, it is essential to confirm
liveness of the other endpoint to avoid black holes. If no liveness of the other endpoint to avoid black holes. If no
cryptographically protected messages have been received on an IKE_SA cryptographically protected messages have been received on an IKE SA
or any of its CHILD_SAs recently, the system needs to perform a or any of its Child SAs recently, the system needs to perform a
liveness check in order to prevent sending messages to a dead peer. liveness check in order to prevent sending messages to a dead peer.
Receipt of a fresh cryptographically protected message on an IKE_SA (This is sometimes called "dead peer detection" or "DPD", although it
or any of its CHILD_SAs ensures liveness of the IKE_SA and all of its is really detecting live peers, not dead ones.) Receipt of a fresh
CHILD_SAs. Note that this places requirements on the failure modes cryptographically protected message on an IKE SA or any of its Child
of an IKE endpoint. An implementation MUST NOT continue sending on SAs ensures liveness of the IKE SA and all of its Child SAs. Note
any SA if some failure prevents it from receiving on all of the that this places requirements on the failure modes of an IKE
associated SAs. If CHILD_SAs can fail independently from one another endpoint. An implementation MUST NOT continue sending on any SA if
without the associated IKE_SA being able to send a delete message, some failure prevents it from receiving on all of the associated SAs.
then they MUST be negotiated by separate IKE_SAs. If Child SAs can fail independently from one another without the
associated IKE SA being able to send a delete message, then they MUST
be negotiated by separate IKE SAs.
There is a Denial of Service attack on the initiator of an IKE_SA There is a Denial of Service attack on the initiator of an IKE SA
that can be avoided if the initiator takes the proper care. Since that can be avoided if the initiator takes the proper care. Since
the first two messages of an SA setup are not cryptographically the first two messages of an SA setup are not cryptographically
protected, an attacker could respond to the initiator's message protected, an attacker could respond to the initiator's message
before the genuine responder and poison the connection setup attempt. before the genuine responder and poison the connection setup attempt.
To prevent this, the initiator MAY be willing to accept multiple To prevent this, the initiator MAY be willing to accept multiple
responses to its first message, treat each as potentially legitimate, responses to its first message, treat each as potentially legitimate,
respond to it, and then discard all the invalid half-open connections respond to it, and then discard all the invalid half-open connections
when it receives a valid cryptographically protected response to any when it receives a valid cryptographically protected response to any
one of its requests. Once a cryptographically valid response is one of its requests. Once a cryptographically valid response is
received, all subsequent responses should be ignored whether or not received, all subsequent responses should be ignored whether or not
they are cryptographically valid. they are cryptographically valid.
Note that with these rules, there is no reason to negotiate and agree Note that with these rules, there is no reason to negotiate and agree
upon an SA lifetime. If IKE presumes the partner is dead, based on upon an SA lifetime. If IKE presumes the partner is dead, based on
repeated lack of acknowledgement to an IKE message, then the IKE SA repeated lack of acknowledgement to an IKE message, then the IKE SA
and all CHILD_SAs set up through that IKE_SA are deleted. and all Child SAs set up through that IKE SA are deleted.
An IKE endpoint may at any time delete inactive CHILD_SAs to recover An IKE endpoint may at any time delete inactive Child SAs to recover
resources used to hold their state. If an IKE endpoint chooses to resources used to hold their state. If an IKE endpoint chooses to
delete CHILD_SAs, it MUST send Delete payloads to the other end delete Child SAs, it MUST send Delete payloads to the other end
notifying it of the deletion. It MAY similarly time out the IKE_SA. notifying it of the deletion. It MAY similarly time out the IKE SA.
{{ Clarified the SHOULD }} Closing the IKE SA implicitly closes all
{{ Clarified the SHOULD }} Closing the IKE_SA implicitly closes all associated Child SAs. In this case, an IKE endpoint SHOULD send a
associated CHILD_SAs. In this case, an IKE endpoint SHOULD send a Delete payload indicating that it has closed the IKE SA unless the
Delete payload indicating that it has closed the IKE_SA unless the
other endpoint is no longer responding. other endpoint is no longer responding.
2.5. Version Numbers and Forward Compatibility 2.5. Version Numbers and Forward Compatibility
This document describes version 2.0 of IKE, meaning the major version This document describes version 2.0 of IKE, meaning the major version
number is 2 and the minor version number is 0. {{ Restated the number is 2 and the minor version number is 0. {{ Restated the
relationship to RFC 4306 }} This document is a replacement for relationship to RFC 4306 }} This document is a replacement for
[IKEV2]. It is likely that some implementations will want to support [IKEV2]. It is likely that some implementations will want to support
version 1.0 and version 2.0, and in the future, other versions. version 1.0 and version 2.0, and in the future, other versions.
skipping to change at page 26, line 37 skipping to change at page 27, line 45
Notify payload, the notification data contains the one-octet payload Notify payload, the notification data contains the one-octet payload
type. If the critical flag is not set and the payload type is type. If the critical flag is not set and the payload type is
unsupported, that payload MUST be ignored. Payloads sent in IKE unsupported, that payload MUST be ignored. Payloads sent in IKE
response messages MUST NOT have the critical flag set. Note that the response messages MUST NOT have the critical flag set. Note that the
critical flag applies only to the payload type, not the contents. If critical flag applies only to the payload type, not the contents. If
the payload type is recognized, but the payload contains something the payload type is recognized, but the payload contains something
which is not (such as an unknown transform inside an SA payload, or which is not (such as an unknown transform inside an SA payload, or
an unknown Notify Message Type inside a Notify payload), the critical an unknown Notify Message Type inside a Notify payload), the critical
flag is ignored. flag is ignored.
NOTE TO IMPLEMENTERS: Does anyone require that the payloads be in the
order shown in the figures in Section 2? Can we eliminate the
requirement in the following paragraph? If not, we will probably
have to add a new appendix with the order, but there is no reason to
do that if no one actually cares. {{ Remove this paragraph before the
document is finalized, of course. }}
{{ Demoted the SHOULD in the second clause }}Although new payload {{ Demoted the SHOULD in the second clause }}Although new payload
types may be added in the future and may appear interleaved with the types may be added in the future and may appear interleaved with the
fields defined in this specification, implementations MUST send the fields defined in this specification, implementations MUST send the
payloads defined in this specification in the order shown in the payloads defined in this specification in the order shown in the
figures in Section 2; implementations are explicitly allowed to figures in Section 2; implementations are explicitly allowed to
reject as invalid a message with those payloads in any other order. reject as invalid a message with those payloads in any other order.
2.6. Cookies 2.6. IKE SA SPIs and Cookies
The term "cookies" originates with Karn and Simpson [PHOTURIS] in The term "cookies" originates with Karn and Simpson [PHOTURIS] in
Photuris, an early proposal for key management with IPsec, and it has Photuris, an early proposal for key management with IPsec, and it has
persisted. The Internet Security Association and Key Management persisted. The Internet Security Association and Key Management
Protocol (ISAKMP) [ISAKMP] fixed message header includes two eight- Protocol (ISAKMP) [ISAKMP] fixed message header includes two eight-
octet fields titled "cookies", and that syntax is used by both IKEv1 octet fields titled "cookies", and that syntax is used by both IKEv1
and IKEv2, although in IKEv2 they are referred to as the "IKE SPI" and IKEv2, although in IKEv2 they are referred to as the "IKE SPI"
and there is a new separate field in a Notify payload holding the and there is a new separate field in a Notify payload holding the
cookie. The initial two eight-octet fields in the header are used as cookie. The initial two eight-octet fields in the header are used as
a connection identifier at the beginning of IKE packets. {{ Demoted a connection identifier at the beginning of IKE packets. Each
the SHOULD }} Each endpoint chooses one of the two SPIs and needs to endpoint chooses one of the two SPIs and MUST choose them so as to be
choose them so as to be unique identifiers of an IKE_SA. An SPI unique identifiers of an IKE SA. An SPI value of zero is special and
value of zero is special and indicates that the remote SPI value is indicates that the remote SPI value is not yet known by the sender.
not yet known by the sender.
Incoming IKE packets are mapped to an IKE SA only using the packet's
SPI, not using (for example) the source IP address of the packet.
Unlike ESP and AH where only the recipient's SPI appears in the Unlike ESP and AH where only the recipient's SPI appears in the
header of a message, in IKE the sender's SPI is also sent in every header of a message, in IKE the sender's SPI is also sent in every
message. Since the SPI chosen by the original initiator of the message. Since the SPI chosen by the original initiator of the IKE
IKE_SA is always sent first, an endpoint with multiple IKE_SAs open SA is always sent first, an endpoint with multiple IKE SAs open that
that wants to find the appropriate IKE_SA using the SPI it assigned wants to find the appropriate IKE SA using the SPI it assigned must
must look at the I(nitiator) Flag bit in the header to determine look at the I(nitiator) Flag bit in the header to determine whether
whether it assigned the first or the second eight octets. it 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. to zero.
An expected attack against IKE is state and CPU exhaustion, where the An expected attack against IKE is state and CPU exhaustion, where the
target is flooded with session initiation requests from forged IP target is flooded with session initiation requests from forged IP
addresses. This attack can be made less effective if an addresses. This attack can be made less effective if an
implementation of a responder uses minimal CPU and commits no state implementation of a responder uses minimal CPU and commits no state
to an SA until it knows the initiator can receive packets at the to an SA until it knows the initiator can receive packets at the
address from which it claims to be sending them. address from which it claims to 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
COOKIE notification. {{ 3.10.1-16390 }} The data associated with this COOKIE notification. {{ 3.10.1-16390 }} The data associated with this
notification MUST be between 1 and 64 octets in length (inclusive), notification MUST be between 1 and 64 octets in length (inclusive),
and its generation is described later in this section. If the and its generation is described later in this section. If the
IKE_SA_INIT response includes the COOKIE notification, the initiator IKE_SA_INIT response includes the COOKIE notification, the initiator
MUST then retry the IKE_SA_INIT request, and include the COOKIE MUST then retry the IKE_SA_INIT request, and include the COOKIE
notification containing the received data as the first payload, and notification containing the received data as the first payload, and
all other payloads unchanged. The initial exchange will then be as all other payloads unchanged. The initial exchange will then be as
follows: follows:
skipping to change at page 28, line 26 skipping to change at page 29, line 26
<-- HDR(A,B), SK {IDr, [CERT,] <-- HDR(A,B), SK {IDr, [CERT,]
AUTH, SAr2, TSi, TSr} AUTH, SAr2, TSi, TSr}
The first two messages do not affect any initiator or responder state The first two messages do not affect any initiator or responder state
except for communicating the cookie. In particular, the message except for communicating the cookie. In particular, the message
sequence numbers in the first four messages will all be zero and the sequence numbers in the first four messages will all be zero and the
message sequence numbers in the last two messages will be one. 'A' message sequence numbers in the last two messages will be one. 'A'
is the SPI assigned by the initiator, while 'B' is the SPI assigned is the SPI assigned by the initiator, while 'B' is the SPI assigned
by the responder. by the responder.
{{ Demoted the SHOULD }} An IKE implementation should implement its {{ Demoted the SHOULD }} An IKE implementation can implement its
responder cookie generation in such a way as to not require any saved responder cookie generation in such a way as to not require any saved
state to recognize its valid cookie when the second IKE_SA_INIT state to recognize its valid cookie when the second IKE_SA_INIT
message arrives. The exact algorithms and syntax they use to message arrives. The exact algorithms and syntax they use to
generate cookies do not affect interoperability and hence are not generate cookies do not affect interoperability and hence are not
specified here. The following is an example of how an endpoint could specified here. The following is an example of how an endpoint could
use cookies to implement limited DOS protection. use cookies to implement limited DOS protection.
A good way to do this is to set the responder cookie to be: A good way to do this is to set the responder cookie to be:
Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>) Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)
where <secret> is a randomly generated secret known only to the where <secret> is a randomly generated secret known only to the
responder and periodically changed and | indicates concatenation. responder and periodically changed and | indicates concatenation.
<VersionIDofSecret> should be changed whenever <secret> is <VersionIDofSecret> should be changed whenever <secret> is
regenerated. The cookie can be recomputed when the IKE_SA_INIT regenerated. The cookie can be recomputed when the IKE_SA_INIT
arrives the second time and compared to the cookie in the received arrives the second time and compared to the cookie in the received
message. If it matches, the responder knows that the cookie was message. If it matches, the responder knows that the cookie was
generated since the last change to <secret> and that IPi must be the generated since the last change to <secret> and that IPi must be the
same as the source address it saw the first time. Incorporating SPIi same as the source address it saw the first time. Incorporating SPIi
into the calculation ensures that if multiple IKE_SAs are being set into the calculation ensures that if multiple IKE SAs are being set
up in parallel they will all get different cookies (assuming the up in parallel they will all get different cookies (assuming the
initiator chooses unique SPIi's). Incorporating Ni into the hash initiator chooses unique SPIi's). Incorporating Ni into the hash
ensures that an attacker who sees only message 2 can't successfully ensures that an attacker who sees only message 2 can't successfully
forge a message 3. forge a message 3.
If a new value for <secret> is chosen while there are connections in If a new value for <secret> is chosen while there are connections in
the process of being initialized, an IKE_SA_INIT might be returned the process of being initialized, an IKE_SA_INIT might be returned
with other than the current <VersionIDofSecret>. The responder in with other than the current <VersionIDofSecret>. The responder in
that case MAY reject the message by sending another response with a that case MAY reject the message by sending another response with a
new cookie or it MAY keep the old value of <secret> around for a new cookie or it MAY keep the old value of <secret> around for a
short time and accept cookies computed from either one. {{ Demoted short time and accept cookies computed from either one. {{ Demoted
the SHOULD NOT }} The responder should not accept cookies the SHOULD NOT }} The responder should not accept cookies
indefinitely after <secret> is changed, since that would defeat part indefinitely after <secret> is changed, since that would defeat part
of the denial of service protection. {{ Demoted the SHOULD }} The of the denial of service protection. {{ Demoted the SHOULD }} The
responder should change the value of <secret> frequently, especially responder should change the value of <secret> frequently, especially
if under attack. if under attack.
{{ Clarif-2.1 }} In addition to cookies, there are several cases {{ Clarif-2.1 }} In addition to cookies, there are several cases
where the IKE_SA_INIT exchange does not result in the creation of an where the IKE_SA_INIT exchange does not result in the creation of an
IKE_SA (such as INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). In such a IKE SA (such as INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). In such a
case, sending a zero value for the Responder's SPI is correct. If case, sending a zero value for the Responder's SPI is correct. If
the responder sends a non-zero responder SPI, the initiator should the responder sends a non-zero responder SPI, the initiator should
not reject the response for only that reason. not reject the response for only that reason.
{{ Clarif-2.5 }} When one party receives an IKE_SA_INIT request {{ Clarif-2.5 }} When one party receives an IKE_SA_INIT request
containing a cookie whose contents do not match the value expected, containing a cookie whose contents do not match the value expected,
that party MUST ignore the cookie and process the message as if no that party MUST ignore the cookie and process the message as if no
cookie had been included; usually this means sending a response cookie had been included; usually this means sending a response
containing a new cookie. containing a new cookie. The initiator should limit the number of
cookie exchanges it tries before giving up. An attacker can forge
multiple cookie responses to the initiator's IKE_SA_INIT message, and
each of those forged cookie reply will trigger two packets: one
packet from the initiator to the responder (which will reject those
cookies), and one reply from responder to initiator that includes the
correct cookie.
2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD
{{ This section added by Clarif-2.4 }} {{ This section added by Clarif-2.4 }}
There are two common reasons why the initiator may have to retry the There are two common reasons why the initiator may have to retry the
IKE_SA_INIT exchange: the responder requests a cookie or wants a IKE_SA_INIT exchange: the responder requests a cookie or wants a
different Diffie-Hellman group than was included in the KEi payload. different Diffie-Hellman group than was included in the KEi payload.
If the initiator receives a cookie from the responder, the initiator If the initiator receives a cookie from the responder, the initiator
needs to decide whether or not to include the cookie in only the next needs to decide whether or not to include the cookie in only the next
skipping to change at page 29, line 48 skipping to change at page 31, line 6
well. well.
If the initiator includes the cookie only in the next retry, one If the initiator includes the cookie only in the next retry, one
additional roundtrip may be needed in some cases. An additional additional roundtrip may be needed in some cases. An additional
roundtrip is needed also if the initiator includes the cookie in all roundtrip is needed also if the initiator includes the cookie in all
retries, but the responder does not support this. For instance, if retries, but the responder does not support this. For instance, if
the responder includes the SAi1 and KEi payloads in cookie the responder includes the SAi1 and KEi payloads in cookie
calculation, it will reject the request by sending a new cookie. calculation, it will reject the request by sending a new cookie.
If both peers support including the cookie in all retries, a slightly If both peers support including the cookie in all retries, a slightly
shorter exchange can happen. Implementations SHOULD support this shorter exchange can happen.
shorter exchange, but MUST NOT fail if other implementations do not
support this shorter exchange. Initiator Responder
-----------------------------------------------------------
HDR(A,0), SAi1, KEi, Ni -->
<-- HDR(A,0), N(COOKIE)
HDR(A,0), N(COOKIE), SAi1, KEi, Ni -->
<-- HDR(A,0), N(INVALID_KE_PAYLOAD)
HDR(A,0), N(COOKIE), SAi1, KEi', Ni -->
<-- HDR(A,B), SAr1, KEr, Nr
Implementations SHOULD support this shorter exchange, but MUST NOT
fail if other implementations do not support this shorter exchange.
2.7. Cryptographic Algorithm Negotiation 2.7. Cryptographic Algorithm Negotiation
The payload type known as "SA" indicates a proposal for a set of The payload type known as "SA" indicates a proposal for a set of
choices of IPsec protocols (IKE, ESP, or AH) for the SA as well as choices of IPsec protocols (IKE, ESP, or AH) for the SA as well as
cryptographic algorithms associated with each protocol. cryptographic algorithms associated with each protocol.
An SA payload consists of one or more proposals. {{ Clarif-7.13 }} An SA payload consists of one or more proposals. {{ Clarif-7.13 }}
Each proposal includes one protocol. Each protocol contains one or Each proposal includes one protocol. Each protocol contains one or
more transforms -- each specifying a cryptographic algorithm. Each more transforms -- each specifying a cryptographic algorithm. Each
skipping to change at page 30, line 39 skipping to change at page 32, line 5
Each IPsec protocol proposal contains one or more transforms. Each Each IPsec protocol proposal contains one or more transforms. Each
transform contains a transform type. The accepted cryptographic transform contains a transform type. The accepted cryptographic
suite MUST contain exactly one transform of each type included in the suite MUST contain exactly one transform of each type included in the
proposal. For example: if an ESP proposal includes transforms proposal. For example: if an ESP proposal includes transforms
ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256, ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256,
AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one
of the ENCR_ transforms and one of the AUTH_ transforms. Thus, six of the ENCR_ transforms and one of the AUTH_ transforms. Thus, six
combinations are acceptable. combinations are acceptable.
If an initiator proposes both normal ciphers with integrity
protection as well as combined-mode ciphers, then two proposals are
needed. One of the proposals includes the normal ciphers with the
integrity algoritms for them, and the other proposal includes all the
combined mode ciphers without the integrity algorithms (because
combined mode ciphers are not allowed to have any integrity algorithm
other than "none").
Since the initiator sends its Diffie-Hellman value in the Since the initiator sends its Diffie-Hellman value in the
IKE_SA_INIT, it must guess the Diffie-Hellman group that the IKE_SA_INIT, it must guess the Diffie-Hellman group that the
responder will select from its list of supported groups. If the responder will select from its list of supported groups. If the
initiator guesses wrong, the responder will respond with a Notify initiator guesses wrong, the responder will respond with a Notify
payload of type INVALID_KE_PAYLOAD indicating the selected group. In payload of type INVALID_KE_PAYLOAD indicating the selected group. In
this case, the initiator MUST retry the IKE_SA_INIT with the this case, the initiator MUST retry the IKE_SA_INIT with the
corrected Diffie-Hellman group. The initiator MUST again propose its corrected Diffie-Hellman group. The initiator MUST again propose its
full set of acceptable cryptographic suites because the rejection full set of acceptable cryptographic suites because the rejection
message was unauthenticated and otherwise an active attacker could message was unauthenticated and otherwise an active attacker could
trick the endpoints into negotiating a weaker suite than a stronger trick the endpoints into negotiating a weaker suite than a stronger
one that they both prefer. one that they both prefer.
{{ Clarif-2.1 }} When the IKE_SA_INIT exchange does not result in the {{ Clarif-2.1 }} 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. or COOKIE (see Section 2.6), the responder's SPI will be zero.
However, if the responder sends a non-zero responder SPI, the However, if the responder sends a non-zero responder SPI, the
initiator should not reject the response for only that reason. initiator should not reject the response for only that reason.
2.8. Rekeying 2.8. Rekeying
{{ Demoted the SHOULD }} IKE, ESP, and AH security associations use {{ Demoted the SHOULD }} IKE, ESP, and AH security associations use
secret keys that should be used only for a limited amount of time and secret keys that should be used only for a limited amount of time and
to protect a limited amount of data. This limits the lifetime of the to protect a limited amount of data. This limits the lifetime of the
entire security association. When the lifetime of a security entire security association. When the lifetime of a security
association expires, the security association MUST NOT be used. If association expires, the security association MUST NOT be used. If
there is demand, new security associations MAY be established. there is demand, new security associations MAY be established.
Reestablishment of security associations to take the place of ones Reestablishment of security associations to take the place of ones
that expire is referred to as "rekeying". that expire is referred to as "rekeying".
To allow for minimal IPsec implementations, the ability to rekey SAs To allow for minimal IPsec implementations, the ability to rekey SAs
without restarting the entire IKE_SA is optional. An implementation without restarting the entire IKE SA is optional. An implementation
MAY refuse all CREATE_CHILD_SA requests within an IKE_SA. If an SA MAY refuse all CREATE_CHILD_SA requests within an IKE SA. If an SA
has expired or is about to expire and rekeying attempts using the has expired or is about to expire and rekeying attempts using the
mechanisms described here fail, an implementation MUST close the mechanisms described here fail, an implementation MUST close the IKE
IKE_SA and any associated CHILD_SAs and then MAY start new ones. {{ SA and any associated Child SAs and then MAY start new ones. {{
Demoted the SHOULD }} Implementations may wish to support in-place Demoted the SHOULD }} Implementations may wish to support in-place
rekeying of SAs, since doing so offers better performance and is rekeying of SAs, since doing so offers better performance and is
likely to reduce the number of packets lost during the transition. likely to reduce the number of packets lost during the transition.
To rekey a CHILD_SA within an existing IKE_SA, create a new, To rekey a Child SA within an existing IKE SA, create a new,
equivalent SA (see Section 2.17 below), and when the new one is equivalent SA (see Section 2.17 below), and when the new one is
established, delete the old one. To rekey an IKE_SA, establish a new established, delete the old one. To rekey an IKE SA, establish a new
equivalent IKE_SA (see Section 2.18 below) with the peer to whom the equivalent IKE SA (see Section 2.18 below) with the peer to whom the
old IKE_SA is shared using a CREATE_CHILD_SA within the existing old IKE SA is shared using a CREATE_CHILD_SA within the existing IKE
IKE_SA. An IKE_SA so created inherits all of the original IKE_SA's SA. An IKE SA so created inherits all of the original IKE SA's Child
CHILD_SAs, and the new IKE_SA is used for all control messages needed SAs, and the new IKE SA is used for all control messages needed to
to maintain those CHILD_SAs. The old IKE_SA is then deleted, and the maintain those Child SAs. The old IKE SA is then deleted, and the
Delete payload to delete itself MUST be the last request sent over Delete payload to delete itself MUST be the last request sent over
the old IKE_SA. the old IKE SA. Note that, when rekeying, the new Child SA MAY have
different traffic selectors and algorithms than the old one.
{{ Demoted the SHOULD }} SAs should be rekeyed proactively, i.e., the {{ Demoted the SHOULD }} SAs should be rekeyed proactively, i.e., the
new SA should be established before the old one expires and becomes new SA should be established before the old one expires and becomes
unusable. Enough time should elapse between the time the new SA is unusable. Enough time should elapse between the time the new SA is
established and the old one becomes unusable so that traffic can be established and the old one becomes unusable so that traffic can be
switched over to the new SA. switched over to the new SA.
A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes
were negotiated. In IKEv2, each end of the SA is responsible for were negotiated. In IKEv2, each end of the SA is responsible for
enforcing its own lifetime policy on the SA and rekeying the SA when enforcing its own lifetime policy on the SA and rekeying the SA when
skipping to change at page 33, line 5 skipping to change at page 34, line 28
traffic on the old SA until one of those events occurs. When traffic on the old SA until one of those events occurs. When
establishing a new SA, the responder MAY defer sending messages on a establishing a new SA, the responder MAY defer sending messages on a
new SA until either it receives one or a timeout has occurred. {{ new SA until either it receives one or a timeout has occurred. {{
Demoted the SHOULD }} If an initiator receives a message on an SA for Demoted the SHOULD }} If an initiator receives a message on an SA for
which it has not received a response to its CREATE_CHILD_SA request, which it has not received a response to its CREATE_CHILD_SA request,
it interprets that as a likely packet loss and retransmits the it interprets that as a likely packet loss and retransmits the
CREATE_CHILD_SA request. An initiator MAY send a dummy message on a CREATE_CHILD_SA request. An initiator MAY send a dummy message on a
newly created SA if it has no messages queued in order to assure the newly created SA if it has no messages queued in order to assure the
responder that the initiator is ready to receive messages. responder that the initiator is ready to receive messages.
{{ Clarif-5.9 }} Throughout this document, "initiator" refers to the 2.8.1. Simultaneous Child SA rekeying
party who initiated the exchange being described, and "original
initiator" refers to the party who initiated the whole IKE_SA. The
"original initiator" always refers to the party who initiated the
exchange which resulted in the current IKE_SA. In other words, if
the "original responder" starts rekeying the IKE_SA, that party
becomes the "original initiator" of the new IKE_SA.
2.8.1. Simultaneous CHILD_SA rekeying
{{ The first two paragraphs were moved, and the rest was added, based {{ The first two paragraphs were moved, and the rest was added, based
on Clarif-5.11 }} on Clarif-5.11 }}
If the two ends have the same lifetime policies, it is possible that If the two ends have the same lifetime policies, it is possible that
both will initiate a rekeying at the same time (which will result in both will initiate a rekeying at the same time (which will result in
redundant SAs). To reduce the probability of this happening, the redundant SAs). To reduce the probability of this happening, the
timing of rekeying requests SHOULD be jittered (delayed by a random timing of rekeying requests SHOULD be jittered (delayed by a random
amount of time after the need for rekeying is noticed). amount of time after the need for rekeying is noticed).
skipping to change at page 34, line 17 skipping to change at page 35, line 33
--> recv req1 --> recv req1
Now B also knows that simultaneous rekeying is going on. It responds Now B also knows that simultaneous rekeying is going on. It responds
as usual. as usual.
<-- send resp1: SA(..,SPIb3,..), <-- send resp1: SA(..,SPIb3,..),
Nr2,.. Nr2,..
recv resp1 <-- recv resp1 <--
--> recv resp2 --> recv resp2
At this point, there are three CHILD_SA pairs between A and B (the At this point, there are three Child SA pairs between A and B (the
old one and two new ones). A and B can now compare the nonces. old one and two new ones). A and B can now compare the nonces.
Suppose that the lowest nonce was Nr1 in message resp2; in this case, Suppose that the lowest nonce was Nr1 in message resp2; in this case,
B (the sender of req2) deletes the redundant new SA, and A (the node B (the sender of req2) deletes the redundant new SA, and A (the node
that initiated the surviving rekeyed SA), deletes the old one. that initiated the surviving rekeyed SA), deletes the old one.
send req3: D(SPIa1) --> send req3: D(SPIa1) -->
<-- send req4: D(SPIb2) <-- send req4: D(SPIb2)
--> recv req3 --> recv req3
<-- send resp3: D(SPIb1) <-- send resp3: D(SPIb1)
recv req4 <-- recv req4 <--
skipping to change at page 35, line 22 skipping to change at page 36, line 39
To B, it looks like A is trying to rekey an SA that no longer exists; To B, it looks like A is trying to rekey an SA that no longer exists;
thus, B responds to the request with something non-fatal such as thus, B responds to the request with something non-fatal such as
NO_PROPOSAL_CHOSEN. NO_PROPOSAL_CHOSEN.
<-- send resp1: N(NO_PROPOSAL_CHOSEN) <-- send resp1: N(NO_PROPOSAL_CHOSEN)
recv resp1 <-- recv resp1 <--
When A receives this error, it already knows there was simultaneous When A receives this error, it already knows there was simultaneous
rekeying, so it can ignore the error message. rekeying, so it can ignore the error message.
2.8.2. Rekeying the IKE_SA Versus Reauthentication 2.8.2. Rekeying the IKE SA Versus Reauthentication
{{ Added this section from Clarif-5.2 }} {{ Added this section from Clarif-5.2 }}
Rekeying the IKE_SA and reauthentication are different concepts in Rekeying the IKE SA and reauthentication are different concepts in
IKEv2. Rekeying the IKE_SA establishes new keys for the IKE_SA and IKEv2. Rekeying the IKE SA establishes new keys for the IKE SA and
resets the Message ID counters, but it does not authenticate the resets the Message ID counters, but it does not authenticate the
parties again (no AUTH or EAP payloads are involved). parties again (no AUTH or EAP payloads are involved).
Although rekeying the IKE_SA may be important in some environments, Although rekeying the IKE SA may be important in some environments,
reauthentication (the verification that the parties still have access reauthentication (the verification that the parties still have access
to the long-term credentials) is often more important. to the long-term credentials) is often more important.
IKEv2 does not have any special support for reauthentication. IKEv2 does not have any special support for reauthentication.
Reauthentication is done by creating a new IKE_SA from scratch (using
Reauthentication is done by creating a new IKE SA from scratch (using
IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify
payloads), creating new CHILD_SAs within the new IKE_SA (without payloads), creating new Child SAs within the new IKE SA (without
REKEY_SA notify payloads), and finally deleting the old IKE_SA (which REKEY_SA notify payloads), and finally deleting the old IKE SA (which
deletes the old CHILD_SAs as well). deletes the old Child SAs as well).
This means that reauthentication also establishes new keys for the This means that reauthentication also establishes new keys for the
IKE_SA and CHILD_SAs. Therefore, while rekeying can be performed IKE SA and Child SAs. Therefore, while rekeying can be performed
more often than reauthentication, the situation where "authentication more often than reauthentication, the situation where "authentication
lifetime" is shorter than "key lifetime" does not make sense. lifetime" is shorter than "key lifetime" does not make sense.
While creation of a new IKE_SA can be initiated by either party While creation of a new IKE SA can be initiated by either party
(initiator or responder in the original IKE_SA), the use of EAP (initiator or responder in the original IKE SA), the use of EAP
authentication and/or configuration payloads means in practice that authentication and/or configuration payloads means in practice that
reauthentication has to be initiated by the same party as the reauthentication has to be initiated by the same party as the
original IKE_SA. IKEv2 does not currently allow the responder to original IKE SA. IKEv2 does not currently allow the responder to
request reauthentication in this case; however, there are extensions request reauthentication in this case; however, there are extensions
that add this functionality such as [REAUTH]. that add this functionality such as [REAUTH].
2.9. Traffic Selector Negotiation 2.9. Traffic Selector Negotiation
{{ Clarif-7.2 }} When an RFC4301-compliant IPsec subsystem receives {{ Clarif-7.2 }} When an RFC4301-compliant IPsec subsystem receives
an IP packet and matches a "protect" selector in its Security Policy an IP packet that matches a "protect" selector in its Security Policy
Database (SPD), the subsystem protects that packet with IPsec. When Database (SPD), the subsystem protects that packet with IPsec. When
no SA exists yet, it is the task of IKE to create it. Maintenance of no SA exists yet, it is the task of IKE to create it. Maintenance of
a system's SPD is outside the scope of IKE (see [PFKEY] for an a system's SPD is outside the scope of IKE (see [PFKEY] for an
example protocol), though some implementations might update their SPD example protocol, although it only applies to IKEv1), though some
in connection with the running of IKE (for an example scenario, see implementations might update their SPD in connection with the running
Section 1.1.3). of IKE (for an example scenario, see Section 1.1.3).
Traffic Selector (TS) payloads allow endpoints to communicate some of Traffic Selector (TS) payloads allow endpoints to communicate some of
the information from their SPD to their peers. TS payloads specify the information from their SPD to their peers. TS payloads specify
the selection criteria for packets that will be forwarded over the the selection criteria for packets that will be forwarded over the
newly set up SA. This can serve as a consistency check in some newly set up SA. This can serve as a consistency check in some
scenarios to assure that the SPDs are consistent. In others, it scenarios to assure that the SPDs are consistent. In others, it
guides the dynamic update of the SPD. guides the dynamic update of the SPD.
Two TS payloads appear in each of the messages in the exchange that Two TS payloads appear in each of the messages in the exchange that
creates a CHILD_SA pair. Each TS payload contains one or more creates a Child SA pair. Each TS payload contains one or more
Traffic Selectors. Each Traffic Selector consists of an address Traffic Selectors. Each Traffic Selector consists of an address
range (IPv4 or IPv6), a port range, and an IP protocol ID. range (IPv4 or IPv6), a port range, and an IP protocol ID.
The first of the two TS payloads is known as TSi (Traffic Selector- The first of the two TS payloads is known as TSi (Traffic Selector-
initiator). The second is known as TSr (Traffic Selector-responder). initiator). The second is known as TSr (Traffic Selector-responder).
TSi specifies the source address of traffic forwarded from (or the TSi specifies the source address of traffic forwarded from (or the
destination address of traffic forwarded to) the initiator of the destination address of traffic forwarded to) the initiator of the
CHILD_SA pair. TSr specifies the destination address of the traffic Child SA pair. TSr specifies the destination address of the traffic
forwarded to (or the source address of the traffic forwarded from) forwarded to (or the source address of the traffic forwarded from)
the responder of the CHILD_SA pair. For example, if the original the responder of the Child SA pair. For example, if the original
initiator requests the creation of a CHILD_SA pair, and wishes to initiator requests the creation of a Child SA pair, and wishes to
tunnel all traffic from subnet 192.0.1.* on the initiator's side to tunnel all traffic from subnet 192.0.1.* on the initiator's side to
subnet 192.0.2.* on the responder's side, the initiator would include subnet 192.0.2.* on the responder's side, the initiator would include
a single traffic selector in each TS payload. TSi would specify the a single traffic selector in each TS payload. TSi would specify the
address range (192.0.1.0 - 192.0.1.255) and TSr would specify the address range (192.0.1.0 - 192.0.1.255) and TSr would specify the
address range (192.0.2.0 - 192.0.2.255). Assuming that proposal was address range (192.0.2.0 - 192.0.2.255). Assuming that proposal was
acceptable to the responder, it would send identical TS payloads acceptable to the responder, it would send identical TS payloads
back. (Note: The IP address range 192.0.2.* has been reserved for back. (Note: The IP address range 192.0.2.* has been reserved for
use in examples in RFCs and similar documents. This document needed use in examples in RFCs and similar documents. This document needed
two such ranges, and so also used 192.0.1.*. This should not be two such ranges, and so also used 192.0.1.*. This should not be
confused with any actual address.) confused with any actual address.)
skipping to change at page 37, line 13 skipping to change at page 38, line 29
two endpoints are being updated but only one end has received the new two endpoints are being updated but only one end has received the new
information. Since the two endpoints may be configured by different information. Since the two endpoints may be configured by different
people, the incompatibility may persist for an extended period even people, the incompatibility may persist for an extended period even
in the absence of errors. It also allows for intentionally different in the absence of errors. It also allows for intentionally different
configurations, as when one end is configured to tunnel all addresses configurations, as when one end is configured to tunnel all addresses
and depends on the other end to have the up-to-date list. and depends on the other end to have the up-to-date list.
When the responder chooses a subset of the traffic proposed by the When the responder chooses a subset of the traffic proposed by the
initiator, it narrows the traffic selectors to some subset of the initiator, it narrows the traffic selectors to some subset of the
initiator's proposal (provided the set does not become the null set). initiator's proposal (provided the set does not become the null set).
If the type of traffic selector proposed is unknown, the responder
ignores that traffic selector, so that the unknown type is not be
returned in the narrowed set.
To enable the responder to choose the appropriate range in this case, To enable the responder to choose the appropriate range in this case,
if the initiator has requested the SA due to a data packet, the if the initiator has requested the SA due to a data packet, the
initiator SHOULD include as the first traffic selector in each of TSi initiator SHOULD include as the first traffic selector in each of TSi
and TSr a very specific traffic selector including the addresses in and TSr a very specific traffic selector including the addresses in
the packet triggering the request. In the example, the initiator the packet triggering the request. In the example, the initiator
would include in TSi two traffic selectors: the first containing the would include in TSi two traffic selectors: the first containing the
address range (192.0.1.43 - 192.0.1.43) and the source port and IP address range (192.0.1.43 - 192.0.1.43) and the source port and IP
protocol from the packet and the second containing (192.0.1.0 - protocol from the packet and the second containing (192.0.1.0 -
192.0.1.255) with all ports and IP protocols. The initiator would 192.0.1.255) with all ports and IP protocols. The initiator would
similarly include two traffic selectors in TSr. If the initiator similarly include two traffic selectors in TSr. If the initiator
creates the CHILD_SA pair not in response to an arriving packet, but creates the Child SA pair not in response to an arriving packet, but
rather, say, upon startup, then there may be no specific addresses rather, say, upon startup, then there may be no specific addresses
the initiator prefers for the initial tunnel over any other. In that the initiator prefers for the initial tunnel over any other. In that
case, the first values in TSi and TSr can be ranges rather than case, the first values in TSi and TSr can be ranges rather than
specific values. specific values.
The responder performs the narrowing as follows: {{ Clarif-4.10 }} The responder performs the narrowing as follows: {{ Clarif-4.10 }}
o If the responder's policy does not allow it to accept any part of o If the responder's policy does not allow it to accept any part of
the proposed traffic selectors, it responds with TS_UNACCEPTABLE. the proposed traffic selectors, it responds with TS_UNACCEPTABLE.
o If the responder's policy allows the entire set of traffic covered o If the responder's policy allows the entire set of traffic covered
by TSi and TSr, no narrowing is necessary, and the responder can by TSi and TSr, no narrowing is necessary, and the responder can
return the same TSi and TSr values. return the same TSi and TSr values.
o If the responder's policy allows it to accept the first selector o If the responder's policy allows it to accept the first selector
of TSi and TSr, then the responder MUST narrow the traffic of TSi and TSr, then the responder MUST narrow the traffic
selectors to a subset that includes the initiator's first choices. selectors to a subset that includes the initiator's first choices.
skipping to change at page 38, line 21 skipping to change at page 39, line 41
on the granularity of tunnels, the initiator will never request a on the granularity of tunnels, the initiator will never request a
tunnel wider than the responder will accept. {{ Demoted the SHOULD }} tunnel wider than the responder will accept. {{ Demoted the SHOULD }}
Such misconfigurations should be recorded in error logs. Such misconfigurations should be recorded in error logs.
It is possible for the responder's policy to contain multiple smaller It is possible for the responder's policy to contain multiple smaller
ranges, all encompassed by the initiator's traffic selector, and with ranges, all encompassed by the initiator's traffic selector, and with
the responder's policy being that each of those ranges should be sent the responder's policy being that each of those ranges should be sent
over a different SA. Continuing the example above, the responder over a different SA. Continuing the example above, the responder
might have a policy of being willing to tunnel those addresses to and might have a policy of being willing to tunnel those addresses to and
from the initiator, but might require that each address pair be on a from the initiator, but might require that each address pair be on a
separately negotiated CHILD_SA. If the initiator generated its separately negotiated Child SA. If the initiator generated its
request in response to an incoming packet from 192.0.1.43 to request in response to an incoming packet from 192.0.1.43 to
192.0.2.123, there would be no way for the responder to determine 192.0.2.123, there would be no way for the responder to determine
which pair of addresses should be included in this tunnel, and it which pair of addresses should be included in this tunnel, and it
would have to make a guess or reject the request with a status of would have to make a guess or reject the request with a status of
SINGLE_PAIR_REQUIRED. SINGLE_PAIR_REQUIRED.
{{ 3.10.1-34 }} The SINGLE_PAIR_REQUIRED error indicates that a {{ 3.10.1-34 }} The SINGLE_PAIR_REQUIRED error indicates that a
CREATE_CHILD_SA request is unacceptable because its sender is only CREATE_CHILD_SA request is unacceptable because its sender is only
willing to accept traffic selectors specifying a single pair of willing to accept traffic selectors specifying a single pair of
addresses. The requestor is expected to respond by requesting an SA addresses. The requestor is expected to respond by requesting an SA
skipping to change at page 38, line 46 skipping to change at page 40, line 18
parts of the TSi and TSr proposed by the initiator are acceptable to parts of the TSi and TSr proposed by the initiator are acceptable to
the responder, responders SHOULD narrow the selectors to an the responder, responders SHOULD narrow the selectors to an
acceptable subset rather than use SINGLE_PAIR_REQUIRED. acceptable subset rather than use SINGLE_PAIR_REQUIRED.
2.9.1. Traffic Selectors Violating Own Policy 2.9.1. Traffic Selectors Violating Own Policy
{{ Clarif-4.12 }} {{ Clarif-4.12 }}
When creating a new SA, the initiator needs to avoid proposing When creating a new SA, the initiator needs to avoid proposing
traffic selectors that violate its own policy. If this rule is not traffic selectors that violate its own policy. If this rule is not
followed, valid traffic may be dropped. followed, valid traffic may be dropped. If you use decorrelated
policies from [IPSECARCH], this kind of policy violations cannot
happen.
This is best illustrated by an example. Suppose that host A has a This is best illustrated by an example. Suppose that host A has a
policy whose effect is that traffic to 192.0.1.66 is sent via host B policy whose effect is that traffic to 192.0.1.66 is sent via host B
encrypted using AES, and traffic to all other hosts in 192.0.1.0/24 encrypted using AES, and traffic to all other hosts in 192.0.1.0/24
is also sent via B, but must use 3DES. Suppose also that host B is also sent via B, but must use 3DES. Suppose also that host B
accepts any combination of AES and 3DES. accepts any combination of AES and 3DES.
If host A now proposes an SA that uses 3DES, and includes TSr If host A now proposes an SA that uses 3DES, and includes TSr
containing (192.0.1.0-192.0.1.255), this will be accepted by host B. containing (192.0.1.0-192.0.1.255), this will be accepted by host B.
Now, host B can also use this SA to send traffic from 192.0.1.66, but Now, host B can also use this SA to send traffic from 192.0.1.66, but
skipping to change at page 39, line 29 skipping to change at page 40, line 51
would be willing to accept traffic X' with some SA' (!=SA), valid would be willing to accept traffic X' with some SA' (!=SA), valid
traffic can be unnecessarily dropped since the responder can apply traffic can be unnecessarily dropped since the responder can apply
either SA or SA' to traffic X'. either SA or SA' to traffic X'.
2.10. Nonces 2.10. Nonces
The IKE_SA_INIT messages each contain a nonce. These nonces are used The IKE_SA_INIT messages each contain a nonce. These nonces are used
as inputs to cryptographic functions. The CREATE_CHILD_SA request as inputs to cryptographic functions. The CREATE_CHILD_SA request
and the CREATE_CHILD_SA response also contain nonces. These nonces and the CREATE_CHILD_SA response also contain nonces. These nonces
are used to add freshness to the key derivation technique used to are used to add freshness to the key derivation technique used to
obtain keys for CHILD_SA, and to ensure creation of strong pseudo- obtain keys for Child SA, and to ensure creation of strong pseudo-
random bits from the Diffie-Hellman key. Nonces used in IKEv2 MUST random bits from the Diffie-Hellman key. Nonces used in IKEv2 MUST
be randomly chosen, MUST be at least 128 bits in size, and MUST be at be randomly chosen, MUST be at least 128 bits in size, and MUST be at
least half the key size of the negotiated prf. ("prf" refers to least half the key size of the negotiated prf. ("prf" refers to
"pseudo-random function", one of the cryptographic algorithms "pseudo-random function", one of the cryptographic algorithms
negotiated in the IKE exchange.) {{ Clarif-7.4 }} However, the negotiated in the IKE exchange.) {{ Clarif-7.4 }} However, the
initiator chooses the nonce before the outcome of the negotiation is initiator chooses the nonce before the outcome of the negotiation is
known. Because of that, the nonce has to be long enough for all the known. Because of that, the nonce has to be long enough for all the
PRFs being proposed. If the same random number source is used for PRFs being proposed. If the same random number source is used for
both keys and nonces, care must be taken to ensure that the latter both keys and nonces, care must be taken to ensure that the latter
use does not compromise the former. use does not compromise the former.
skipping to change at page 40, line 20 skipping to change at page 41, line 42
This means that once a connection is closed and its corresponding This means that once a connection is closed and its corresponding
keys are forgotten, even someone who has recorded all of the data keys are forgotten, even someone who has recorded all of the data
from the connection and gets access to all of the long-term keys of from the connection and gets access to all of the long-term keys of
the two endpoints cannot reconstruct the keys used to protect the the two endpoints cannot reconstruct the keys used to protect the
conversation without doing a brute force search of the session key conversation without doing a brute force search of the session key
space. space.
Achieving perfect forward secrecy requires that when a connection is Achieving perfect forward secrecy requires that when a connection is
closed, each endpoint MUST forget not only the keys used by the closed, each endpoint MUST forget not only the keys used by the
connection but also any information that could be used to recompute connection but also any information that could be used to recompute
those keys. In particular, it MUST forget the secrets used in the those keys.
Diffie-Hellman calculation and any state that may persist in the
state of a pseudo-random number generator that could be used to
recompute the Diffie-Hellman secrets.
Since the computing of Diffie-Hellman exponentials is computationally Since the computing of Diffie-Hellman exponentials is computationally
expensive, an endpoint may find it advantageous to reuse those expensive, an endpoint may find it advantageous to reuse those
exponentials for multiple connection setups. There are several exponentials for multiple connection setups. There are several
reasonable strategies for doing this. An endpoint could choose a new reasonable strategies for doing this. An endpoint could choose a new
exponential only periodically though this could result in less-than- exponential only periodically though this could result in less-than-
perfect forward secrecy if some connection lasts for less than the perfect forward secrecy if some connection lasts for less than the
lifetime of the exponential. Or it could keep track of which lifetime of the exponential. Or it could keep track of which
exponential was used for each connection and delete the information exponential was used for each connection and delete the information
associated with the exponential only when some corresponding associated with the exponential only when some corresponding
skipping to change at page 40, line 47 skipping to change at page 42, line 18
Decisions as to whether and when to reuse Diffie-Hellman exponentials Decisions as to whether and when to reuse Diffie-Hellman exponentials
is a private decision in the sense that it will not affect is a private decision in the sense that it will not affect
interoperability. An implementation that reuses exponentials MAY interoperability. An implementation that reuses exponentials MAY
choose to remember the exponential used by the other endpoint on past choose to remember the exponential used by the other endpoint on past
exchanges and if one is reused to avoid the second half of the exchanges and if one is reused to avoid the second half of the
calculation. calculation.
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 pseudo-random function algorithm, a Diffie-Hellman group, and a pseudo-random function
(prf). The pseudo-random function is used for the construction of (prf). The pseudo-random function is used for the construction of
keying material for all of the cryptographic algorithms used in both keying material for all of the cryptographic algorithms used in both
the IKE_SA and the CHILD_SAs. the IKE SA and the Child SAs.
We assume that each encryption algorithm and integrity protection We assume that each encryption algorithm and integrity protection
algorithm uses a fixed-size key and that any randomly chosen value of algorithm uses a fixed-size key and that any randomly chosen value of
that fixed size can serve as an appropriate key. For algorithms that that fixed size can serve as an appropriate key. For algorithms that
accept a variable length key, a fixed key size MUST be specified as accept a variable length key, a fixed key size MUST be specified as
part of the cryptographic transform negotiated (see Section 3.3.5 for part of the cryptographic transform negotiated (see Section 3.3.5 for
the defintion of the Key Length transform attribute). For algorithms the defintion of the Key Length transform attribute). For algorithms
for which not all values are valid keys (such as DES or 3DES with key for which not all values are valid keys (such as DES or 3DES with key
parity), the algorithm by which keys are derived from arbitrary parity), the algorithm by which keys are derived from arbitrary
values MUST be specified by the cryptographic transform. For values MUST be specified by the cryptographic transform. For
skipping to change at page 42, line 5 skipping to change at page 43, line 23
taken from the output string without regard to boundaries (e.g., if taken from the output string without regard to boundaries (e.g., if
the required keys are a 256-bit Advanced Encryption Standard (AES) the required keys are a 256-bit Advanced Encryption Standard (AES)
key and a 160-bit HMAC key, and the prf function generates 160 bits, key and a 160-bit HMAC key, and the prf function generates 160 bits,
the AES key will come from T1 and the beginning of T2, while the HMAC the AES key will come from T1 and the beginning of T2, while the HMAC
key will come from the rest of T2 and the beginning of T3). key will come from the rest of T2 and the beginning of T3).
The constant concatenated to the end of each string feeding the prf The constant concatenated to the end of each string feeding the prf
is a single octet. prf+ in this document is not defined beyond 255 is a single octet. prf+ in this document is not defined beyond 255
times the size of the prf output. times the size of the prf output.
2.14. Generating Keying Material for the IKE_SA 2.14. Generating Keying Material for the IKE SA
The shared keys are computed as follows. A quantity called SKEYSEED The shared keys are computed as follows. A quantity called SKEYSEED
is calculated from the nonces exchanged during the IKE_SA_INIT is calculated from the nonces exchanged during the IKE_SA_INIT
exchange and the Diffie-Hellman shared secret established during that exchange and the Diffie-Hellman shared secret established during that
exchange. SKEYSEED is used to calculate seven other secrets: SK_d exchange. SKEYSEED is used to calculate seven other secrets: SK_d
used for deriving new keys for the CHILD_SAs established with this used for deriving new keys for the Child SAs established with this
IKE_SA; SK_ai and SK_ar used as a key to the integrity protection IKE SA; SK_ai and SK_ar used as a key to the integrity protection
algorithm for authenticating the component messages of subsequent algorithm for authenticating the component messages of subsequent
exchanges; SK_ei and SK_er used for encrypting (and of course exchanges; SK_ei and SK_er used for encrypting (and of course
decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are
used when generating an AUTH payload. The lengths of SK_d, SK_pi, used when generating an AUTH payload. The lengths of SK_d, SK_pi,
and SK_pr are the preferred key length of the agreed-to PRF. and SK_pr are the preferred key length of the agreed-to PRF.
SKEYSEED and its derivatives are computed as follows: SKEYSEED and its derivatives are computed as follows:
SKEYSEED = prf(Ni | Nr, g^ir) SKEYSEED = prf(Ni | Nr, g^ir)
skipping to change at page 42, line 43 skipping to change at page 44, line 13
are treated specially in this calculation. If the negotiated PRF is are treated specially in this calculation. If the negotiated PRF is
AES-XCBC-PRF-128 [RFC4434] or AES-CMAC-PRF-128 [RFC4615], only the AES-XCBC-PRF-128 [RFC4434] or AES-CMAC-PRF-128 [RFC4615], only the
first 64 bits of Ni and the first 64 bits of Nr are used in the first 64 bits of Ni and the first 64 bits of Nr are used in the
calculation. calculation.
The two directions of traffic flow use different keys. The keys used The two directions of traffic flow use different keys. The keys used
to protect messages from the original initiator are SK_ai and SK_ei. to protect messages from the original initiator are SK_ai and SK_ei.
The keys used to protect messages in the other direction are SK_ar The keys used to protect messages in the other direction are SK_ar
and SK_er. and SK_er.
2.15. Authentication of the IKE_SA 2.15. Authentication of the IKE SA
When not using extensible authentication (see Section 2.16), the When not using extensible authentication (see Section 2.16), the
peers are authenticated by having each sign (or MAC using a shared peers are authenticated by having each sign (or MAC using a shared
secret as the key) a block of data. For the responder, the octets to secret as the key) a block of data. For the responder, the octets to
be signed start with the first octet of the first SPI in the header be signed start with the first octet of the first SPI in the header
of the second message (IKE_SA_INIT response) and end with the last of the second message (IKE_SA_INIT response) and end with the last
octet of the last payload in the second message. Appended to this octet of the last payload in the second message. Appended to this
(for purposes of computing the signature) are the initiator's nonce (for purposes of computing the signature) are the initiator's nonce
Ni (just the value, not the payload containing it), and the value Ni (just the value, not the payload containing it), and the value
prf(SK_pr,IDr') where IDr' is the responder's ID payload excluding prf(SK_pr,IDr') where IDr' is the responder's ID payload excluding
skipping to change at page 43, line 41 skipping to change at page 45, line 16
GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
RealIKEHDR = SPIi | SPIr | . . . | Length RealIKEHDR = SPIi | SPIr | . . . | Length
RealMessage2 = RealIKEHDR | RestOfMessage2 RealMessage2 = RealIKEHDR | RestOfMessage2
NonceIPayload = PayloadHeader | NonceIData NonceIPayload = PayloadHeader | NonceIData
ResponderIDPayload = PayloadHeader | RestOfIDPayload ResponderIDPayload = PayloadHeader | RestOfIDPayload
RestOfRespIDPayload = IDType | RESERVED | RespIDData RestOfRespIDPayload = IDType | RESERVED | RespIDData
MACedIDForR = prf(SK_pr, RestOfRespIDPayload) MACedIDForR = prf(SK_pr, RestOfRespIDPayload)
Note that all of the payloads are included under the signature, Note that all of the payloads are included under the signature,
including any payload types not defined in this document. If the including any payload types not defined in this document. If the
first message of the exchange is sent twice (the second time with a first message of the exchange is sent multiple times (such as with a
responder cookie and/or a different Diffie-Hellman group), it is the responder cookie and/or a different Diffie-Hellman group), it is the
second version of the message that is signed. latest version of the message that is signed.
Optionally, messages 3 and 4 MAY include a certificate, or Optionally, messages 3 and 4 MAY include a certificate, or
certificate chain providing evidence that the key used to compute a certificate chain providing evidence that the key used to compute a
digital signature belongs to the name in the ID payload. The digital signature belongs to the name in the ID payload. The
signature or MAC will be computed using algorithms dictated by the signature or MAC will be computed using algorithms dictated by the
type of key used by the signer, and specified by the Auth Method type of key used by the signer, and specified by the Auth Method
field in the Authentication payload. There is no requirement that field in the Authentication payload. There is no requirement that
the initiator and responder sign with the same cryptographic the initiator and responder sign with the same cryptographic
algorithms. The choice of cryptographic algorithms depends on the algorithms. The choice of cryptographic algorithms depends on the
type of key each has. In particular, the initiator may be using a type of key each has. In particular, the initiator may be using a
skipping to change at page 44, line 18 skipping to change at page 45, line 41
that if a shared secret is used for authentication that the same key that if a shared secret is used for authentication that the same key
is used in both directions. is used in both directions.
Note that it is a common but typically insecure practice to have a Note that it is a common but typically insecure practice to have a
shared key derived solely from a user-chosen password without shared key derived solely from a user-chosen password without
incorporating another source of randomness. This is typically incorporating another source of randomness. This is typically
insecure because user-chosen passwords are unlikely to have insecure because user-chosen passwords are unlikely to have
sufficient unpredictability to resist dictionary attacks and these sufficient unpredictability to resist dictionary attacks and these
attacks are not prevented in this authentication method. attacks are not prevented in this authentication method.
(Applications using password-based authentication for bootstrapping (Applications using password-based authentication for bootstrapping
and IKE_SA should use the authentication method in Section 2.16, and IKE SA should use the authentication method in Section 2.16,
which is designed to prevent off-line dictionary attacks.) {{ Demoted which is designed to prevent off-line dictionary attacks.) {{ Demoted
the SHOULD }} The pre-shared key needs to contain as much the SHOULD }} The pre-shared key needs to contain as much
unpredictability as the strongest key being negotiated. In the case unpredictability as the strongest key being negotiated. In the case
of a pre-shared key, the AUTH value is computed as: of a pre-shared key, the AUTH value is computed as:
AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), <msg octets>) AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), <msg octets>)
where the string "Key Pad for IKEv2" is 17 ASCII characters without where the string "Key Pad for IKEv2" is 17 ASCII characters without
null termination. The shared secret can be variable length. The pad null termination. The shared secret can be variable length. The pad
string is added so that if the shared secret is derived from a string is added so that if the shared secret is derived from a
skipping to change at page 45, line 12 skipping to change at page 46, line 34
public key signature based authentication of the responder to the public key signature based authentication of the responder to the
initiator. These methods are often associated with mechanisms initiator. These methods are often associated with mechanisms
referred to as "Legacy Authentication" mechanisms. referred to as "Legacy Authentication" mechanisms.
While this memo references [EAP] with the intent that new methods can While this memo references [EAP] with the intent that new methods can
be added in the future without updating this specification, some be added in the future without updating this specification, some
simpler variations are documented here and in Section 3.16. [EAP] simpler variations are documented here and in Section 3.16. [EAP]
defines an authentication protocol requiring a variable number of defines an authentication protocol requiring a variable number of
messages. Extensible Authentication is implemented in IKE as messages. Extensible Authentication is implemented in IKE as
additional IKE_AUTH exchanges that MUST be completed in order to additional IKE_AUTH exchanges that MUST be completed in order to
initialize the IKE_SA. initialize the IKE SA.
An initiator indicates a desire to use extensible authentication by An initiator indicates a desire to use extensible authentication by
leaving out the AUTH payload from message 3. By including an IDi leaving out the AUTH payload from message 3. By including an IDi
payload but not an AUTH payload, the initiator has declared an payload but not an AUTH payload, the initiator has declared an
identity but has not proven it. If the responder is willing to use identity but has not proven it. If the responder is willing to use
an extensible authentication method, it will place an Extensible an extensible authentication method, it will place an Extensible
Authentication Protocol (EAP) payload in message 4 and defer sending Authentication Protocol (EAP) payload in message 4 and defer sending
SAr2, TSi, and TSr until initiator authentication is complete in a SAr2, TSi, and TSr until initiator authentication is complete in a
subsequent IKE_AUTH exchange. In the case of a minimal extensible subsequent IKE_AUTH exchange. In the case of a minimal extensible
authentication, the initial SA establishment will appear as follows: authentication, the initial SA establishment will appear as follows:
skipping to change at page 45, line 39 skipping to change at page 47, line 20
[IDr,] SAi2, [IDr,] SAi2,
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 }
{{ Clarif-3.10 }} As described in Section 2.2, when EAP is used, each {{ Clarif-3.10 }} As described in Section 2.2, when EAP is used, each
pair of IKE_SA initial setup messages will have their message numbers pair of IKE SA initial setup messages will have their message numbers
incremented; the first pair of AUTH messages will have an ID of 1, incremented; the first pair of AUTH messages will have an ID of 1,
the second will be 2, and so on. the second 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. The 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
they are subject to a number of man-in-the-middle attacks [EAPMITM] they are subject to a number of man-in-the-middle attacks [EAPMITM]
if these EAP methods are used in other protocols that do not use a if these EAP methods are used in other protocols that do not use a
server-authenticated tunnel. Please see the Security Considerations server-authenticated tunnel. Please see the Security Considerations
section for more details. If EAP methods that do not generate a section for more details. If EAP methods that do not generate a
shared key are used, the AUTH payloads in messages 7 and 8 MUST be shared key are used, the AUTH payloads in messages 7 and 8 MUST be
generated using SK_pi and SK_pr, respectively. generated using SK_pi and SK_pr, respectively.
{{ Demoted the SHOULD }} The initiator of an IKE_SA using EAP needs {{ Demoted the SHOULD }} The initiator of an IKE SA using EAP needs
to be capable of extending the initial protocol exchange to at least to be capable of extending the initial protocol exchange to at least
ten IKE_AUTH exchanges in the event the responder sends notification ten IKE_AUTH exchanges in the event the responder sends notification
messages and/or retries the authentication prompt. Once the protocol messages and/or retries the authentication prompt. Once the protocol
exchange defined by the chosen EAP authentication method has exchange defined by the chosen EAP authentication method has
successfully terminated, the responder MUST send an EAP payload successfully terminated, the responder MUST send an EAP payload
containing the Success message. Similarly, if the authentication containing the Success message. Similarly, if the authentication
method has failed, the responder MUST send an EAP payload containing method has failed, the responder MUST send an EAP payload containing
the Failure message. The responder MAY at any time terminate the IKE the Failure message. The responder MAY at any time terminate the IKE
exchange by sending an EAP payload containing the Failure message. exchange by sending an EAP payload containing the Failure message.
skipping to change at page 46, line 36 skipping to change at page 48, line 16
{{ Clarif-3.5 }} When the initiator authentication uses EAP, it is {{ Clarif-3.5 }} When the initiator authentication uses EAP, it is
possible that the contents of the IDi payload is used only for AAA possible that the contents of the IDi payload is used only for AAA
routing purposes and selecting which EAP method to use. This value routing purposes and selecting which EAP method to use. This value
may be different from the identity authenticated by the EAP method. may be different from the identity authenticated by the EAP method.
It is important that policy lookups and access control decisions use It is important that policy lookups and access control decisions use
the actual authenticated identity. Often the EAP server is the actual authenticated identity. Often the EAP server is
implemented in a separate AAA server that communicates with the IKEv2 implemented in a separate AAA server that communicates with the IKEv2
responder. In this case, the authenticated identity has to be sent responder. In this case, the authenticated identity has to be sent
from the AAA server to the IKEv2 responder. from the AAA server to the IKEv2 responder.
2.17. Generating Keying Material for CHILD_SAs 2.17. Generating Keying Material for Child SAs
A single CHILD_SA is created by the IKE_AUTH exchange, and additional A single Child SA is created by the IKE_AUTH exchange, and additional
CHILD_SAs can optionally be created in CREATE_CHILD_SA exchanges. Child SAs can optionally be created in CREATE_CHILD_SA exchanges.
Keying material for them is generated as follows: Keying material for them is generated as follows:
KEYMAT = prf+(SK_d, Ni | Nr) KEYMAT = prf+(SK_d, Ni | Nr)
Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this
request is the first CHILD_SA created or the fresh Ni and Nr from the request is the first Child SA created or the fresh Ni and Nr from the
CREATE_CHILD_SA exchange if this is a subsequent creation. CREATE_CHILD_SA exchange if this is a subsequent creation.
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).
For ESP and AH, a single CHILD_SA negotiation results in two security For ESP and AH, a single Child SA negotiation results in two security
associations (one in each direction). Keying material MUST be taken associations (one in each direction). Keying material MUST be taken
from the expanded KEYMAT in the following order: from the expanded KEYMAT in the following order:
o The encryption key (if any) for the SA carrying data from the o The encryption key (if any) for the SA carrying data from the
initiator to the responder. initiator to the responder.
o The authentication key (if any) for the SA carrying data from the o The authentication key (if any) for the SA carrying data from the
initiator to the responder. initiator to the responder.
o The encryption key (if any) for the SA carrying data from the o The encryption key (if any) for the SA carrying data from the
skipping to change at page 47, line 31 skipping to change at page 49, line 14
o The authentication key (if any) for the SA carrying data from the o The authentication key (if any) for the SA carrying data from the
responder to the initiator. responder to the initiator.
Each cryptographic algorithm takes a fixed number of bits of keying Each cryptographic algorithm takes a fixed number of bits of keying
material specified as part of the algorithm, or negotiated in SA material specified as part of the algorithm, or negotiated in SA
payloads (see Section 2.13 for description of key lengths, and payloads (see Section 2.13 for description of key lengths, and
Section 3.3.5 for the definition of the Key Length transform Section 3.3.5 for the definition of the Key Length transform
attribute). attribute).
2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA Exchange 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange
The CREATE_CHILD_SA exchange can be used to rekey an existing IKE_SA The CREATE_CHILD_SA exchange can be used to rekey an existing IKE SA
(see Section 2.8). {{ Clarif-5.3 }} New initiator and responder SPIs (see Section 2.8). {{ Clarif-5.3 }} New initiator and responder SPIs
are supplied in the SPI fields in the Proposal structures inside the are supplied in the SPI fields in the Proposal structures inside the
Security Association (SA) payloads (not the SPI fields in the IKE Security Association (SA) payloads (not the SPI fields in the IKE
header). The TS payloads are omitted when rekeying an IKE_SA. header). The TS payloads are omitted when rekeying an IKE SA.
SKEYSEED for the new IKE_SA is computed using SK_d from the existing SKEYSEED for the new IKE SA is computed using SK_d from the existing
IKE_SA as follows: IKE SA as follows:
SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr) SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr)
where g^ir (new) is the shared secret from the ephemeral Diffie- 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 if necessary to octet string in big endian order padded with zeros if necessary to
make it the length of the modulus) and Ni and Nr are the two nonces make it the length of the modulus) and Ni and Nr are the two nonces
stripped of any headers. stripped of any headers.
{{ Clarif-5.5 }} The old and new IKE_SA may have selected a different {{ Clarif-5.5 }} The old and new IKE SA may have selected a different
PRF. Because the rekeying exchange belongs to the old IKE_SA, it is PRF. Because the rekeying exchange belongs to the old IKE SA, it is
the old IKE_SA's PRF that is used. the old IKE SA's PRF that is used.
{{ Clarif-5.12}} The main purpose of rekeying the IKE_SA is to ensure {{ Clarif-5.12}} The main rekeying the IKE SA is to ensure that the
that the compromise of old keying material does not provide compromise of old keying material does not provide information about
information about the current keys, or vice versa. Therefore, the current keys, or vice versa. Therefore, implementations SHOULD
implementations SHOULD perform a new Diffie-Hellman exchange when perform a new Diffie-Hellman exchange when rekeying the IKE SA. In
rekeying the IKE_SA. In other words, an initiator SHOULD NOT propose other words, an initiator SHOULD NOT propose the value "NONE" for the
the value "NONE" for the D-H transform, and a responder SHOULD NOT D-H transform, and a responder SHOULD NOT accept such a proposal.
accept such a proposal. This means that a succesful exchange This means that a succesful exchange rekeying the IKE SA always
rekeying the IKE_SA always includes the KEi/KEr payloads. includes the KEi/KEr payloads.
The new IKE_SA MUST reset its message counters to 0. The new IKE SA MUST reset its message counters to 0.
SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as
specified in Section 2.14. specified in Section 2.14.
2.19. Requesting an Internal Address on a Remote Network 2.19. Requesting an Internal Address on a Remote Network
Most commonly occurring in the endpoint-to-security-gateway scenario, Most commonly occurring in the endpoint-to-security-gateway scenario,
an endpoint may need an IP address in the network protected by the an endpoint may need an IP address in the network protected by the
security gateway and may need to have that address dynamically security gateway and may need to have that address dynamically
assigned. A request for such a temporary address can be included in assigned. A request for such a temporary address can be included in
any request to create a CHILD_SA (including the implicit request in any request to create a Child SA (including the implicit request in
message 3) by including a CP payload. message 3) by including a CP payload.
This function provides address allocation to an IPsec Remote Access This function provides address allocation to an IPsec Remote Access
Client (IRAC) trying to tunnel into a network protected by an IPsec Client (IRAC) trying to tunnel into a network protected by an IPsec
Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an
IKE_SA and a CHILD_SA, the IRAC MUST request the IRAS-controlled IKE SA and a Child SA, the IRAC MUST request the IRAS-controlled
address (and optionally other information concerning the protected address (and optionally other information concerning the protected
network) in the IKE_AUTH exchange. The IRAS may procure an address network) in the IKE_AUTH exchange. The IRAS may procure an address
for the IRAC from any number of sources such as a DHCP/BOOTP server for the IRAC from any number of sources such as a DHCP/BOOTP server
or its own address pool. or its own address pool.
Initiator Responder Initiator Responder
------------------------------------------------------------------- -------------------------------------------------------------------
HDR, SK {IDi, [CERT,] HDR, SK {IDi, [CERT,]
[CERTREQ,] [IDr,] AUTH, [CERTREQ,] [IDr,] AUTH,
CP(CFG_REQUEST), SAi2, CP(CFG_REQUEST), SAi2,
skipping to change at page 49, line 7 skipping to change at page 50, line 42
In all cases, the CP payload MUST be inserted before the SA payload. In all cases, the CP payload MUST be inserted before the SA payload.
In variations of the protocol where there are multiple IKE_AUTH In variations of the protocol where there are multiple IKE_AUTH
exchanges, the CP payloads MUST be inserted in the messages exchanges, the CP payloads MUST be inserted in the messages
containing the SA payloads. containing the SA payloads.
CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute
(either IPv4 or IPv6) but MAY contain any number of additional (either IPv4 or IPv6) but MAY contain any number of additional
attributes the initiator wants returned in the response. attributes the initiator wants returned in the response.
{{ 3.10.1-37 }} The FAILED_CP_REQUIRED notification is sent by
responder in the case where CP(CFG_REQUEST) was expected but not
received, and so is a conflict with locally configured policy. There
is no associated data.
For example, message from initiator to responder: For example, message from initiator to responder:
CP(CFG_REQUEST)= CP(CFG_REQUEST)=
INTERNAL_ADDRESS() INTERNAL_ADDRESS()
TSi = (0, 0-65535,0.0.0.0-255.255.255.255) TSi = (0, 0-65535,0.0.0.0-255.255.255.255)
TSr = (0, 0-65535,0.0.0.0-255.255.255.255) TSr = (0, 0-65535,0.0.0.0-255.255.255.255)
NOTE: Traffic Selectors contain (protocol, port range, address NOTE: Traffic Selectors contain (protocol, port range, address
range). range).
skipping to change at page 49, line 36 skipping to change at page 51, line 17
INTERNAL_NETMASK(255.255.255.0) INTERNAL_NETMASK(255.255.255.0)
INTERNAL_SUBNET(192.0.2.0/255.255.255.0) INTERNAL_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535,192.0.2.202-192.0.2.202) TSi = (0, 0-65535,192.0.2.202-192.0.2.202)
TSr = (0, 0-65535,192.0.2.0-192.0.2.255) TSr = (0, 0-65535,192.0.2.0-192.0.2.255)
All returned values will be implementation dependent. As can be seen All returned values will be implementation dependent. As can be seen
in the above example, the IRAS MAY also send other attributes that in the above example, the IRAS MAY also send other attributes that
were not included in CP(CFG_REQUEST) and MAY ignore the non- were not included in CP(CFG_REQUEST) and MAY ignore the non-
mandatory attributes that it does not support. mandatory attributes that it does not support.
{{ 3.10.1-37 }} The FAILED_CP_REQUIRED notification is sent by
responder in the case where CP(CFG_REQUEST) was expected but not
received, and so is a conflict with locally configured policy. There
is no associated data.
The responder MUST NOT send a CFG_REPLY without having first received The responder MUST NOT send a CFG_REPLY without having first received
a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS
to perform an unnecessary configuration lookup if the IRAC cannot to perform an unnecessary configuration lookup if the IRAC cannot
process the REPLY. In the case where the IRAS's configuration process the REPLY. In the case where the IRAS's configuration
requires that CP be used for a given identity IDi, but IRAC has requires that CP be used for a given identity IDi, but IRAC has
failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and
terminate the IKE exchange with a FAILED_CP_REQUIRED error. terminate the IKE exchange with a FAILED_CP_REQUIRED error. The
FAILED_CP_REQUIRED is not fatal to the IKE SA; it simply causes the
Child SA creation fail. The initiator can fix this by later starting
a new configuration payload request.
2.19.1. Configuration Payloads 2.19.1. Configuration Payloads
Editor's note: some of this sub-section is redundant and will go away Editor's note: some of this sub-section is redundant and will go away
in the next version of the document. in the next version of the document.
In support of the scenario described in Section 1.1.3, an initiator In support of the scenario described in Section 1.1.3, an initiator
may request that the responder assign an IP address and tell the may request that the responder assign an IP address and tell the
initiator what it is. {{ Clarif-6.1 }} That request is done using initiator what it is. {{ Clarif-6.1 }} That request is done using
configuration payloads, not traffic selectors. An address in a TSi configuration payloads, not traffic selectors. An address in a TSi
skipping to change at page 51, line 23 skipping to change at page 53, line 11
information between some Security Gateways (SGW) or small networks, information between some Security Gateways (SGW) or small networks,
existing management protocols such as DHCP [DHCP], RADIUS [RADIUS], existing management protocols such as DHCP [DHCP], RADIUS [RADIUS],
SNMP, or LDAP [LDAP] should be preferred for enterprise management as SNMP, or LDAP [LDAP] should be preferred for enterprise management as
well as subsequent information exchanges. well as subsequent information exchanges.
2.20. Requesting the Peer's Version 2.20. Requesting the Peer's Version
An IKE peer wishing to inquire about the other peer's IKE software An IKE peer wishing to inquire about the other peer's IKE software
version information MAY use the method below. This is an example of version information MAY use the method below. This is an example of
a configuration request within an INFORMATIONAL exchange, after the a configuration request within an INFORMATIONAL exchange, after the
IKE_SA and first CHILD_SA have been created. IKE SA and first Child SA have been created.
An IKE implementation MAY decline to give out version information An IKE implementation MAY decline to give out version information
prior to authentication or even after authentication to prevent prior to authentication or even after authentication to prevent
trolling in case some implementation is known to have some security trolling in case some implementation is known to have some security
weakness. In that case, it MUST either return an empty string or no weakness. In that case, it MUST either return an empty string or no
CP payload if CP is not supported. CP payload if CP is not supported.
Initiator Responder Initiator Responder
------------------------------------------------------------------- -------------------------------------------------------------------
HDR, SK{CP(CFG_REQUEST)} --> HDR, SK{CP(CFG_REQUEST)} -->
skipping to change at page 52, line 5 skipping to change at page 53, line 41
There are many kinds of errors that can occur during IKE processing. There are many kinds of errors that can occur during IKE processing.
If a request is received that is badly formatted or unacceptable for If a request is received that is badly formatted or unacceptable for
reasons of policy (e.g., no matching cryptographic algorithms), the reasons of policy (e.g., no matching cryptographic algorithms), the
response MUST contain a Notify payload indicating the error. If an response MUST contain a Notify payload indicating the error. If an
error occurs outside the context of an IKE request (e.g., the node is error occurs outside the context of an IKE request (e.g., the node is
getting ESP messages on a nonexistent SPI), the node SHOULD initiate getting ESP messages on a nonexistent SPI), the node SHOULD initiate
an INFORMATIONAL exchange with a Notify payload describing the an INFORMATIONAL exchange with a Notify payload describing the
problem. problem.
Errors that occur before a cryptographically protected IKE_SA is Errors that occur before a cryptographically protected IKE SA is
established must be handled very carefully. There is a trade-off established must be handled very carefully. There is a trade-off
between wanting to be helpful in diagnosing a problem and responding between wanting to be helpful in diagnosing a problem and responding
to it and wanting to avoid being a dupe in a denial of service attack to it and wanting to avoid being a dupe in a denial of service attack
based on forged messages. based on forged messages.
If a node receives a message on UDP port 500 or 4500 outside the If a node receives a message on UDP port 500 or 4500 outside the
context of an IKE_SA known to it (and not a request to start one), it context of an IKE SA known to it (and not a request to start one), it
may be the result of a recent crash of the node. If the message is may be the result of a recent crash of the node. If the message is
marked as a response, the node MAY audit the suspicious event but marked as a response, the node MAY audit the suspicious event but
MUST NOT respond. If the message is marked as a request, the node MUST NOT respond. If the message is marked as a request, the node
MAY audit the suspicious event and MAY send a response. If a MAY audit the suspicious event and MAY send a response. If a
response is sent, the response MUST be sent to the IP address and response is sent, the response MUST be sent to the IP address and
port from whence it came with the same IKE SPIs and the Message ID port from whence it came with the same IKE SPIs and the Message ID
copied. The response MUST NOT be cryptographically protected and copied. The response MUST NOT be cryptographically protected and
MUST contain a Notify payload indicating INVALID_IKE_SPI. {{ 3.10.1-4 MUST contain a Notify payload indicating INVALID_IKE_SPI. {{ 3.10.1-4
}} The INVALID_IKE_SPI notification indicates an IKE message was }} The INVALID_IKE_SPI notification indicates an IKE message was
received with an unrecognized destination SPI; this usually indicates received with an unrecognized destination SPI; this usually indicates
that the recipient has rebooted and forgotten the existence of an that the recipient has rebooted and forgotten the existence of an IKE
IKE_SA. SA.
A node receiving such an unprotected Notify payload MUST NOT respond A node receiving such an unprotected Notify payload MUST NOT respond
and MUST NOT change the state of any existing SAs. The message might and MUST NOT change the state of any existing SAs. The message might
be a forgery or might be a response the genuine correspondent was be a forgery or might be a response the genuine correspondent was
tricked into sending. {{ Demoted two SHOULDs }} A node should treat tricked into sending. {{ Demoted two SHOULDs }} A node should treat
such a message (and also a network message like ICMP destination such a message (and also a network message like ICMP destination
unreachable) as a hint that there might be problems with SAs to that unreachable) as a hint that there might be problems with SAs to that
IP address and should initiate a liveness test for any such IKE_SA. IP address and should initiate a liveness test for any such IKE SA.
An implementation SHOULD limit the frequency of such tests to avoid An implementation SHOULD limit the frequency of such tests to avoid
being tricked into participating in a denial of service attack. being tricked into participating in a denial of service attack.
A node receiving a suspicious message from an IP address with which A node receiving a suspicious message from an IP address with which
it has an IKE_SA MAY send an IKE Notify payload in an IKE it has an IKE SA MAY send an IKE Notify payload in an IKE
INFORMATIONAL exchange over that SA. {{ Demoted the SHOULD }} The INFORMATIONAL exchange over that SA. {{ Demoted the SHOULD }} The
recipient MUST NOT change the state of any SAs as a result, but may recipient MUST NOT change the state of any SAs as a result, but may
wish to audit the event to aid in diagnosing malfunctions. A node wish to audit the event to aid in diagnosing malfunctions. A node
MUST limit the rate at which it will send messages in response to MUST limit the rate at which it will send messages in response to
unprotected messages. unprotected messages.
2.22. IPComp 2.22. IPComp
Use of IP compression [IPCOMP] can be negotiated as part of the setup Use of IP compression [IP-COMP] can be negotiated as part of the
of a CHILD_SA. While IP compression involves an extra header in each setup of a Child SA. While IP compression involves an extra header
packet and a compression parameter index (CPI), the virtual in each packet and a compression parameter index (CPI), the virtual
"compression association" has no life outside the ESP or AH SA that "compression association" has no life outside the ESP or AH SA that
contains it. Compression associations disappear when the contains it. Compression associations disappear when the
corresponding ESP or AH SA goes away. It is not explicitly mentioned corresponding ESP or AH SA goes away. It is not explicitly mentioned
in any DELETE payload. in any DELETE payload.
Negotiation of IP compression is separate from the negotiation of Negotiation of IP compression is separate from the negotiation of
cryptographic parameters associated with a CHILD_SA. A node cryptographic parameters associated with a Child SA. A node
requesting a CHILD_SA MAY advertise its support for one or more requesting a Child SA MAY advertise its support for one or more
compression algorithms through one or more Notify payloads of type compression algorithms through one or more Notify payloads of type
IPCOMP_SUPPORTED. This notification may be included only in a IPCOMP_SUPPORTED. This notification may be included only in a
message containing an SA payload negotiating a CHILD_SA and indicates message containing an SA payload negotiating a Child SA and indicates
a willingness by its sender to use IPComp on this SA. The response a willingness by its sender to use IPComp on this SA. The response
MAY indicate acceptance of a single compression algorithm with a MAY indicate acceptance of a single compression algorithm with a
Notify payload of type IPCOMP_SUPPORTED. These payloads MUST NOT Notify payload of type IPCOMP_SUPPORTED. These payloads MUST NOT
occur in messages that do not contain SA payloads. occur in messages that do not contain SA payloads.
{{ 3.10.1-16387 }}The data associated with this notification includes {{ 3.10.1-16387 }}The data associated with this notification includes
a two-octet IPComp CPI followed by a one-octet transform ID a two-octet IPComp CPI followed by a one-octet transform ID
optionally followed by attributes whose length and format are defined optionally followed by attributes whose length and format are defined
by that transform ID. A message proposing an SA may contain multiple by that transform ID. A message proposing an SA may contain multiple
IPCOMP_SUPPORTED notifications to indicate multiple supported IPCOMP_SUPPORTED notifications to indicate multiple supported
skipping to change at page 53, line 37 skipping to change at page 55, line 26
RESERVED 0 RESERVED 0
IPCOMP_OUI 1 IPCOMP_OUI 1
IPCOMP_DEFLATE 2 RFC 2394 IPCOMP_DEFLATE 2 RFC 2394
IPCOMP_LZS 3 RFC 2395 IPCOMP_LZS 3 RFC 2395
IPCOMP_LZJH 4 RFC 3051 IPCOMP_LZJH 4 RFC 3051
RESERVED TO IANA 5-240 RESERVED TO IANA 5-240
PRIVATE USE 241-255 PRIVATE USE 241-255
Although there has been discussion of allowing multiple compression Although there has been discussion of allowing multiple compression
algorithms to be accepted and to have different compression algorithms to be accepted and to have different compression
algorithms available for the two directions of a CHILD_SA, algorithms available for the two directions of a Child SA,
implementations of this specification MUST NOT accept an IPComp implementations of this specification MUST NOT accept an IPComp
algorithm that was not proposed, MUST NOT accept more than one, and algorithm that was not proposed, MUST NOT accept more than one, and
MUST NOT compress using an algorithm other than one proposed and MUST NOT compress using an algorithm other than one proposed and
accepted in the setup of the CHILD_SA. accepted in the setup of the Child SA.
A side effect of separating the negotiation of IPComp from A side effect of separating the negotiation of IPComp from
cryptographic parameters is that it is not possible to propose cryptographic parameters is that it is not possible to propose
multiple cryptographic suites and propose IP compression with some of multiple cryptographic suites and propose IP compression with some of
them but not others. them but not others.
In some cases, Robust Header Compression (ROHC) may be more
appropriate than IP Compression. [ROHCV2] defines the use of ROHC
with IKEv2 and IPsec.
2.23. NAT Traversal 2.23. NAT Traversal
Network Address Translation (NAT) gateways are a controversial Network Address Translation (NAT) gateways are a controversial
subject. This section briefly describes what they are and how they subject. This section briefly describes what they are and how they
are likely to act on IKE traffic. Many people believe that NATs are are likely to act on IKE traffic. Many people believe that NATs are
evil and that we should not design our protocols so as to make them evil and that we should not design our protocols so as to make them
work better. IKEv2 does specify some unintuitive processing rules in work better. IKEv2 does specify some unintuitive processing rules in
order that NATs are more likely to work. order that NATs are more likely to work.
NATs exist primarily because of the shortage of IPv4 addresses, NATs exist primarily because of the shortage of IPv4 addresses,
skipping to change at page 54, line 39 skipping to change at page 56, line 32
the headers. Such knowledge is inherently unreliable, is a network the headers. Such knowledge is inherently unreliable, is a network
layer violation, and often results in subtle problems. layer violation, and often results in subtle problems.
Opening an IPsec connection through a NAT introduces special Opening an IPsec connection through a NAT introduces special
problems. If the connection runs in transport mode, changing the IP problems. If the connection runs in transport mode, changing the IP
addresses on packets will cause the checksums to fail and the NAT addresses on packets will cause the checksums to fail and the NAT
cannot correct the checksums because they are cryptographically cannot correct the checksums because they are cryptographically
protected. Even in tunnel mode, there are routing problems because protected. Even in tunnel mode, there are routing problems because
transparently translating the addresses of AH and ESP packets transparently translating the addresses of AH and ESP packets
requires special logic in the NAT and that logic is heuristic and requires special logic in the NAT and that logic is heuristic and
unreliable in nature. For that reason, IKEv2 can negotiate UDP unreliable in nature. For that reason, IKEv2 will use UDP
encapsulation of IKE and ESP packets. This encoding is slightly less encapsulation of IKE and ESP packets. This encoding is slightly less
efficient but is easier for NATs to process. In addition, firewalls efficient but is easier for NATs to process. In addition, firewalls
may be configured to pass IPsec traffic over UDP but not ESP/AH or may be configured to pass IPsec traffic over UDP but not ESP/AH or
vice versa. vice versa.
It is a common practice of NATs to translate TCP and UDP port numbers It is a common practice of NATs to translate TCP and UDP port numbers
as well as addresses and use the port numbers of inbound packets to as well as addresses and use the port numbers of inbound packets to
decide which internal node should get a given packet. For this decide which internal node should get a given packet. For this
reason, even though IKE packets MUST be sent from and to UDP port reason, even though IKE packets MUST be sent from and to UDP port 500
500, they MUST be accepted coming from any port and responses MUST be or 4500, they MUST be accepted coming from any port and responses
sent to the port from whence they came. This is because the ports MUST be sent to the port from whence they came. This is because the
may be modified as the packets pass through NATs. Similarly, IP ports may be modified as the packets pass through NATs. Similarly,
addresses of the IKE endpoints are generally not included in the IKE IP addresses of the IKE endpoints are generally not included in the
payloads because the payloads are cryptographically protected and IKE payloads because the payloads are cryptographically protected and
could not be transparently modified by NATs. could not be transparently modified by NATs.
Port 4500 is reserved for UDP-encapsulated ESP and IKE. When working Port 4500 is reserved for UDP-encapsulated ESP and IKE. {{ Clarif-7.6
through a NAT, it is generally better to pass IKE packets over port }} An IPsec endpoint that discovers a NAT between it and its
4500 because some older NATs handle IKE traffic on port 500 cleverly correspondent MUST send all subsequent traffic from port 4500, which
in an attempt to transparently establish IPsec connections between NATs should not treat specially (as they might with port 500).
endpoints that don't handle NAT traversal themselves. Such NATs may
interfere with the straightforward NAT traversal envisioned by this
document. {{ Clarif-7.6 }} An IPsec endpoint that discovers a NAT
between it and its correspondent MUST send all subsequent traffic
from port 4500, which NATs should not treat specially (as they might
with port 500).
The specific requirements for supporting NAT traversal [NATREQ] are The specific requirements for supporting NAT traversal [NATREQ] are
listed below. Support for NAT traversal is optional. In this listed below. Support for NAT traversal is optional. In this
section only, requirements listed as MUST apply only to section only, requirements listed as MUST apply only to
implementations supporting NAT traversal. implementations supporting NAT traversal.
o IKE MUST listen on port 4500 as well as port 500. IKE MUST o IKE MUST listen on port 4500 as well as port 500. IKE MUST
respond to the IP address and port from which packets arrived. respond to the IP address and port from which packets arrived.
o Both IKE initiator and responder MUST include in their IKE_SA_INIT o Both IKE initiator and responder MUST include in their IKE_SA_INIT
packets Notify payloads of type NAT_DETECTION_SOURCE_IP and packets Notify payloads of type NAT_DETECTION_SOURCE_IP and
NAT_DETECTION_DESTINATION_IP. Those payloads can be used to NAT_DETECTION_DESTINATION_IP. Those payloads can be used to
detect if there is NAT between the hosts, and which end is behind detect if there is NAT between the hosts, and which end is behind
the NAT. The location of the payloads in the IKE_SA_INIT packets the NAT. The location of the payloads in the IKE_SA_INIT packets
are just after the Ni and Nr payloads (before the optional CERTREQ is just after the Ni and Nr payloads (before the optional CERTREQ
payload). payload).
o {{ 3.10.1-16388 }} The data associated with the o {{ 3.10.1-16388 }} The data associated with the
NAT_DETECTION_SOURCE_IP notification is a SHA-1 digest of the SPIs NAT_DETECTION_SOURCE_IP notification is a SHA-1 digest of the SPIs
(in the order they appear in the header), IP address, and port on (in the order they appear in the header), IP address, and port on
which this packet was sent. There MAY be multiple which this packet was sent. There MAY be multiple
NAT_DETECTION_SOURCE_IP payloads in a message if the sender does NAT_DETECTION_SOURCE_IP payloads in a message if the sender does
not know which of several network attachments will be used to send not know which of several network attachments will be used to send
the packet. the packet.
skipping to change at page 56, line 31 skipping to change at page 58, line 18
o If the NAT_DETECTION_DESTINATION_IP payload received does not o If the NAT_DETECTION_DESTINATION_IP payload received does not
match the hash of the destination IP and port found from the IP match the hash of the destination IP and port found from the IP
header of the packet containing the payload, it means that the header of the packet containing the payload, it means that the
system receiving the NAT_DETECTION_DESTINATION_IP payload is system receiving the NAT_DETECTION_DESTINATION_IP payload is
behind a NAT. In this case, that system SHOULD start sending behind a NAT. In this case, that system SHOULD start sending
keepalive packets as explained in [UDPENCAPS]. keepalive packets as explained in [UDPENCAPS].
o The IKE initiator MUST check these payloads if present and if they o The IKE initiator MUST check these payloads if present and if they
do not match the addresses in the outer packet MUST tunnel all do not match the addresses in the outer packet MUST tunnel all
future IKE and ESP packets associated with this IKE_SA over UDP future IKE and ESP packets associated with this IKE SA over UDP
port 4500. port 4500.
o To tunnel IKE packets over UDP port 4500, the IKE header has four o To tunnel IKE packets over UDP port 4500, the IKE header has four
octets of zero prepended and the result immediately follows the octets of zero prepended and the result immediately follows the
UDP header. To tunnel ESP packets over UDP port 4500, the ESP UDP header. To tunnel ESP packets over UDP port 4500, the ESP
header immediately follows the UDP header. Since the first four header immediately follows the UDP header. Since the first four
octets of the ESP header contain the SPI, and the SPI cannot octets of the ESP header contain the SPI, and the SPI cannot
validly be zero, it is always possible to distinguish ESP and IKE validly be zero, it is always possible to distinguish ESP and IKE
messages. messages.
skipping to change at page 57, line 16 skipping to change at page 59, line 5
are still alive (for example, the keepalive interval is too long, are still alive (for example, the keepalive interval is too long,
or the NAT box is rebooted). To recover in these cases, hosts or the NAT box is rebooted). To recover in these cases, hosts
that are not behind a NAT SHOULD send all packets (including that are not behind a NAT SHOULD send all packets (including
retransmission packets) to the IP address and port from the last retransmission packets) to the IP address and port from the last
valid authenticated packet from the other end (i.e., dynamically valid authenticated packet from the other end (i.e., dynamically
update the address). A host behind a NAT SHOULD NOT do this update the address). A host behind a NAT SHOULD NOT do this
because it opens a DoS attack possibility. Any authenticated IKE because it opens a DoS attack possibility. Any authenticated IKE
packet or any authenticated UDP-encapsulated ESP packet can be packet or any authenticated UDP-encapsulated ESP packet can be
used to detect that the IP address or the port has changed. used to detect that the IP address or the port has changed.
Note that similar but probably not identical actions will likely be
needed to make IKE work with Mobile IP, but such processing is not
addressed by this document.
2.24. Explicit Congestion Notification (ECN) 2.24. Explicit Congestion Notification (ECN)
When IPsec tunnels behave as originally specified in [IPSECARCH-OLD], When IPsec tunnels behave as originally specified in [IPSECARCH-OLD],
ECN usage is not appropriate for the outer IP headers because tunnel ECN usage is not appropriate for the outer IP headers because tunnel
decapsulation processing discards ECN congestion indications to the decapsulation processing discards ECN congestion indications to the
detriment of the network. ECN support for IPsec tunnels for IKEv1- detriment of the network. ECN support for IPsec tunnels for IKEv1-
based IPsec requires multiple operating modes and negotiation (see based IPsec requires multiple operating modes and negotiation (see
[ECN]). IKEv2 simplifies this situation by requiring that ECN be [ECN]). IKEv2 simplifies this situation by requiring that ECN be
usable in the outer IP headers of all tunnel-mode IPsec SAs created usable in the outer IP headers of all tunnel-mode IPsec SAs created
by IKEv2. Specifically, tunnel encapsulators and decapsulators for by IKEv2. Specifically, tunnel encapsulators and decapsulators for
skipping to change at page 58, line 35 skipping to change at page 60, line 19
All multi-octet fields representing integers are laid out in big All multi-octet fields representing integers are laid out in big
endian order (also known as "most significant byte first", or endian order (also known as "most significant byte first", or
"network byte order"). "network byte order").
The format of the IKE header is shown in Figure 4. The format of the IKE header is shown in Figure 4.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IKE_SA Initiator's SPI | | IKE SA Initiator's SPI |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IKE_SA Responder's SPI | | IKE SA Responder's SPI |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload | MjVer | MnVer | Exchange Type | Flags | | Next Payload | MjVer | MnVer | Exchange Type | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID | | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IKE Header Format Figure 4: IKE Header Format
skipping to change at page 59, line 20 skipping to change at page 61, line 5
o Next Payload (1 octet) - Indicates the type of payload that o Next Payload (1 octet) - Indicates the type of payload that
immediately follows the header. The format and value of each immediately follows the header. The format and value of each
payload are defined below. payload are defined below.
o Major Version (4 bits) - Indicates the major version of the IKE o Major Version (4 bits) - Indicates the major version of the IKE
protocol in use. Implementations based on this version of IKE protocol in use. Implementations based on this version of IKE
MUST set the Major Version to 2. Implementations based on MUST set the Major Version to 2. Implementations based on
previous versions of IKE and ISAKMP MUST set the Major Version to previous versions of IKE and ISAKMP MUST set the Major Version to
1. Implementations based on this version of IKE MUST reject or 1. Implementations based on this version of IKE MUST reject or
ignore messages containing a version number greater than 2. ignore messages containing a version number greater than 2 with an
INVALID_MAJOR_VERSION notification message as described in Section
2.5.
o Minor Version (4 bits) - Indicates the minor version of the IKE o Minor Version (4 bits) - Indicates the minor version of the IKE
protocol in use. Implementations based on this version of IKE protocol in use. Implementations based on this version of IKE
MUST set the Minor Version to 0. They MUST ignore the minor MUST set the Minor Version to 0. They MUST ignore the minor
version number of received messages. version number of received messages.
o Exchange Type (1 octet) - Indicates the type of exchange being o Exchange Type (1 octet) - Indicates the type of exchange being
used. This constrains the payloads sent in each message and used. This constrains the payloads sent in each message in an
orderings of messages in an exchange. exchange.
Exchange Type Value Exchange Type Value
---------------------------------- ----------------------------------
RESERVED 0-33 RESERVED 0-33
IKE_SA_INIT 34 IKE_SA_INIT 34
IKE_AUTH 35 IKE_AUTH 35
CREATE_CHILD_SA 36 CREATE_CHILD_SA 36
INFORMATIONAL 37 INFORMATIONAL 37
RESERVED TO IANA 38-239 RESERVED TO IANA 38-239
PRIVATE USE 240-255 PRIVATE USE 240-255
o Flags (1 octet) - Indicates specific options that are set for the o Flags (1 octet) - Indicates specific options that are set for the
message. Presence of options are indicated by the appropriate bit message. Presence of options is indicated by the appropriate bit
in the flags field being set. The bits are defined LSB first, so in the flags field being set. The bits are defined LSB first, so
bit 0 would be the least significant bit of the Flags octet. In bit 0 would be the least significant bit of the Flags octet. In
the description below, a bit being 'set' means its value is '1', the description below, a bit being 'set' means its value is '1',
while 'cleared' means its value is '0'. while 'cleared' means its value is '0'.
* X(reserved) (bits 0-2) - These bits MUST be cleared when * X(reserved) (bits 0-2) - These bits MUST be cleared when
sending and MUST be ignored on receipt. sending and MUST be ignored on receipt.
* I(nitiator) (bit 3 of Flags) - This bit MUST be set in messages * I(nitiator) (bit 3 of Flags) - This bit MUST be set in messages
sent by the original initiator of the IKE_SA and MUST be sent by the original initiator of the IKE SA and MUST be
cleared in messages sent by the original responder. It is used cleared in messages sent by the original responder. It is used
by the recipient to determine which eight octets of the SPI by the recipient to determine which eight octets of the SPI
were generated by the recipient. were generated by the recipient. This bit changes to reflect
who initiated the last rekey of the IKE SA.
* V(ersion) (bit 4 of Flags) - This bit indicates that the * V(ersion) (bit 4 of Flags) - This bit indicates that the
transmitter is capable of speaking a higher major version transmitter is capable of speaking a higher major version
number of the protocol than the one indicated in the major number of the protocol than the one indicated in the major
version number field. Implementations of IKEv2 must clear this version number field. Implementations of IKEv2 must clear this
bit when sending and MUST ignore it in incoming messages. bit when sending and MUST ignore it in incoming messages.
* R(esponse) (bit 5 of Flags) - This bit indicates that this * R(esponse) (bit 5 of Flags) - This bit indicates that this
message is a response to a message containing the same message message is a response to a message containing the same message
ID. This bit MUST be cleared in all request messages and MUST ID. This bit MUST be cleared in all request messages and MUST
skipping to change at page 63, line 6 skipping to change at page 64, line 44
example, an initiator might want to propose using ESP with either example, an initiator might want to propose using ESP with either
(3DES and HMAC_MD5) or (AES and HMAC_SHA1). (3DES and HMAC_MD5) or (AES and HMAC_SHA1).
One of the reasons the semantics of the SA payload has changed from One of the reasons the semantics of the SA payload has changed from
ISAKMP and IKEv1 is to make the encodings more compact in common ISAKMP and IKEv1 is to make the encodings more compact in common
cases. cases.
The Proposal structure contains within it a Proposal # and an IPsec The Proposal structure contains within it a Proposal # and an IPsec
protocol ID. Each structure MUST have a proposal number one (1) protocol ID. Each structure MUST have a proposal number one (1)
greater than the previous structure. The first Proposal in the greater than the previous structure. The first Proposal in the
initiator's SA payload MUST have a Proposal # of one (1). A proposal initiator's SA payload MUST have a Proposal # of one (1). One reason
of AH or ESP would have two proposal structures, one for AH with to use multiple proposals is to propose both standard crypto ciphers
Proposal #1 and one for ESP with Proposal #2. and combined-mode ciphers. Combined-mode ciphers include both
integrity and encryption in a single encryption algorithm, and are
not allowed to be offered with a separate integrity algorithm other
than "none". If an initiator wants to propose both combined-mode
ciphers and normal ciphers, it must include two proposals: one will
have all the combined-mode ciphers, and the other will have all the
normal ciphers with the integrity algorithms. For example, one such
proposal would have two proposal structures: ESP with ENCR_AES-CCM_8,
ENCR_AES-CCM_12, and ENCR_AES-CCM_16 as Proposal #1, and ESP with
ENCR_AES_CBC, ENCR_3DES, AUTH_AES_XCBC_96, and AUTH_HMAC_SHA1_96 as
Proposal #2.
Each Proposal/Protocol structure is followed by one or more transform Each Proposal/Protocol structure is followed by one or more transform
structures. The number of different transforms is generally structures. The number of different transforms is generally
determined by the Protocol. AH generally has two transforms: determined by the Protocol. AH generally has two transforms:
Extended Sequence Numbers (ESN) and an integrity check algorithm. Extended Sequence Numbers (ESN) and an integrity check algorithm.
ESP generally has three: ESN, an encryption algorithm and an ESP generally has three: ESN, an encryption algorithm and an
integrity check algorithm. IKE generally has four transforms: a integrity check algorithm. IKE generally has four transforms: a
Diffie-Hellman group, an integrity check algorithm, a prf algorithm, Diffie-Hellman group, an integrity check algorithm, a prf algorithm,
and an encryption algorithm. If an algorithm that combines and an encryption algorithm. If an algorithm that combines
encryption and integrity protection is proposed, it MUST be proposed encryption and integrity protection is proposed, it MUST be proposed
skipping to change at page 65, line 24 skipping to change at page 67, line 24
Protocol Protocol ID Protocol Protocol ID
----------------------------------- -----------------------------------
RESERVED 0 RESERVED 0
IKE 1 IKE 1
AH 2 AH 2
ESP 3 ESP 3
RESERVED TO IANA 4-200 RESERVED TO IANA 4-200
PRIVATE USE 201-255 PRIVATE USE 201-255
o SPI Size (1 octet) - For an initial IKE_SA negotiation, this field o SPI Size (1 octet) - For an initial IKE SA negotiation, this field
MUST be zero; the SPI is obtained from the outer header. During MUST be zero; the SPI is obtained from the outer header. During
subsequent negotiations, it is equal to the size, in octets, of subsequent negotiations, it is equal to the size, in octets, of
the SPI of the corresponding protocol (8 for IKE, 4 for ESP and the SPI of the corresponding protocol (8 for IKE, 4 for ESP and
AH). AH).
o # of Transforms (1 octet) - Specifies the number of transforms in o # of Transforms (1 octet) - Specifies the number of transforms in
this proposal. this proposal.
o SPI (variable) - The sending entity's SPI. Even if the SPI Size o SPI (variable) - The sending entity's SPI. Even if the SPI Size
is not a multiple of 4 octets, there is no padding applied to the is not a multiple of 4 octets, there is no padding applied to the
skipping to change at page 66, line 24 skipping to change at page 68, line 24
| | | |
~ 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 0 (last) or 3 (more) (1 octet) - Specifies whether this is the
last Transform Substructure in the Proposal. This syntax is last Transform Substructure in the Proposal. This syntax is
inherited from ISAKMP, but is unnecessary because the last inherited from ISAKMP, but is unnecessary because the last
Proposal could be identified from the length of the SA. The value transform could be identified from the length of the proposal.
(3) corresponds to a Payload Type of Transform in IKEv1, and the The value (3) corresponds to a Payload Type of Transform in IKEv1,
first four octets of the Transform structure are designed to look and the first four octets of the Transform structure are designed
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.
o Transform Type (1 octet) - The type of transform being specified o Transform Type (1 octet) - The type of transform being specified
in this transform. Different protocols support different in this transform. Different protocols support different
transform types. For some protocols, some of the transforms may transform types. For some protocols, some of the transforms may
be optional. If a transform is optional and the initiator wishes be optional. If a transform is optional and the initiator wishes
to propose that the transform be omitted, no transform of the to propose that the transform be omitted, no transform of the
given type is included in the proposal. If the initiator wishes given type is included in the proposal. If the initiator wishes
to make use of the transform optional to the responder, it to make use of the transform optional to the responder, it
includes a transform substructure with transform ID = 0 as one of includes a transform substructure with transform ID = 0 as one of
the options. the options.
o Transform ID (2 octets) - The specific instance of the transform o Transform ID (2 octets) - The specific instance of the transform
type being proposed. type being proposed.
The tranform type values are: The transform type values are:
Description Trans. Used In Description Trans. Used In
Type Type
------------------------------------------------------------------ ------------------------------------------------------------------
RESERVED 0 RESERVED 0
Encryption Algorithm (ENCR) 1 IKE and ESP Encryption Algorithm (ENCR) 1 IKE and ESP
Pseudo-random Function (PRF) 2 IKE Pseudo-random Function (PRF) 2 IKE
Integrity Algorithm (INTEG) 3 IKE*, AH, optional in ESP Integrity Algorithm (INTEG) 3 IKE*, AH, optional in ESP
Diffie-Hellman Group (D-H) 4 IKE, optional in AH & ESP Diffie-Hellman Group (D-H) 4 IKE, optional in AH & ESP
Extended Sequence Numbers (ESN) 5 AH and ESP Extended Sequence Numbers (ESN) 5 AH and ESP
RESERVED TO IANA 6-240 RESERVED TO IANA 6-240
PRIVATE USE 241-255 PRIVATE USE 241-255
(*) Negotiating an integrity algorithm is mandatory for the (*) Negotiating an integrity algorithm is mandatory for the
Encrypted payload format specified in this document. Future Encrypted payload format specified in this document. For example,
documents may specify additional formats based on authenticated [AEAD] specifies additional formats based on authenticated
encryption, in which case a separate integrity algorithm is not encryption, in which a separate integrity algorithm is not
negotiated. negotiated.
For Transform Type 1 (Encryption Algorithm), defined Transform IDs For Transform Type 1 (Encryption Algorithm), defined Transform IDs
are: are:
Name Number Defined In Name Number Defined In
--------------------------------------------------- ---------------------------------------------------
RESERVED 0 RESERVED 0
ENCR_DES_IV64 1 (UNSPECIFIED) ENCR_DES_IV64 1 (UNSPECIFIED)
ENCR_DES 2 (RFC2405), [DES] ENCR_DES 2 (RFC2405), [DES]
skipping to change at page 68, line 10 skipping to change at page 70, line 10
PRIVATE USE 1024-65535 PRIVATE USE 1024-65535
For Transform Type 2 (Pseudo-random Function), defined Transform IDs For Transform Type 2 (Pseudo-random Function), defined Transform IDs
are: are:
Name Number Defined In Name Number Defined In
------------------------------------------------------ ------------------------------------------------------
RESERVED 0 RESERVED 0
PRF_HMAC_MD5 1 (RFC2104), [MD5] PRF_HMAC_MD5 1 (RFC2104), [MD5]
PRF_HMAC_SHA1 2 (RFC2104), [SHA] PRF_HMAC_SHA1 2 (RFC2104), [SHA]
PRF_HMAC_TIGER 3 (UNSPECIFIED) PRF_HMAC_TIGER 3 (RFC2104)
PRF_AES128_XCBC 4 (RFC4434) PRF_AES128_XCBC 4 (RFC4434)
RESERVED TO IANA 5-1023 RESERVED TO IANA 5-1023
PRIVATE USE 1024-65535 PRIVATE USE 1024-65535
For Transform Type 3 (Integrity Algorithm), defined Transform IDs For Transform Type 3 (Integrity Algorithm), defined Transform IDs
are: are:
Name Number Defined In Name Number Defined In
---------------------------------------- ----------------------------------------
NONE 0 NONE 0
skipping to change at page 69, line 17 skipping to change at page 71, line 17
No Extended Sequence Numbers 0 No Extended Sequence Numbers 0
Extended Sequence Numbers 1 Extended Sequence Numbers 1
RESERVED 2 - 65535 RESERVED 2 - 65535
{{ Clarif-4.4 }} Note that an initiator who supports ESNs will {{ Clarif-4.4 }} Note that an initiator who supports ESNs will
usually include two ESN transforms, with values "0" and "1", in its usually include two ESN transforms, with values "0" and "1", in its
proposals. A proposal containing a single ESN transform with value proposals. A proposal containing a single ESN transform with value
"1" means that using normal (non-extended) sequence numbers is not "1" means that using normal (non-extended) sequence numbers is not
acceptable. acceptable.
Numerous additional transform types have been defined since the
publication of RFC 4306. Please refer to the IANA IKEv2 registry for
details.
3.3.3. Valid Transform Types by Protocol 3.3.3. Valid Transform Types by Protocol
The number and type of transforms that accompany an SA payload are The number and type of transforms that accompany an SA payload are
dependent on the protocol in the SA itself. An SA payload proposing dependent on the protocol in the SA itself. An SA payload proposing
the establishment of an SA has the following mandatory and optional the establishment of an SA has the following mandatory and optional
transform types. A compliant implementation MUST understand all transform types. A compliant implementation MUST understand all
mandatory and optional types for each protocol it supports (though it mandatory and optional types for each protocol it supports (though it
need not accept proposals with unacceptable suites). A proposal MAY need not accept proposals with unacceptable suites). A proposal MAY
omit the optional types if the only value for them it will accept is omit the optional types if the only value for them it will accept is
NONE. NONE.
Protocol Mandatory Types Optional Types Protocol Mandatory Types Optional Types
--------------------------------------------------- ---------------------------------------------------
IKE ENCR, PRF, INTEG*, D-H IKE ENCR, PRF, INTEG*, D-H
ESP ENCR, ESN INTEG, D-H ESP ENCR, ESN INTEG, D-H
AH INTEG, ESN D-H AH INTEG, ESN D-H
(*) Negotiating an integrity algorithm is mandatory for the (*) Negotiating an integrity algorithm is mandatory for the
Encrypted payload format specified in this document. Future Encrypted payload format specified in this document. For example,
documents may specify additional formats based on authenticated [AEAD] specifies additional formats based on authenticated
encryption, in which case a separate integrity algorithm is not encryption, in which a separate integrity algorithm is not
negotiated. negotiated.
3.3.4. Mandatory Transform IDs 3.3.4. Mandatory Transform IDs
The specification of suites that MUST and SHOULD be supported for The specification of suites that MUST and SHOULD be supported for
interoperability has been removed from this document because they are interoperability has been removed from this document because they are
likely to change more rapidly than this document evolves. likely to change more rapidly than this document evolves.
An important lesson learned from IKEv1 is that no system should only An important lesson learned from IKEv1 is that no system should only
implement the mandatory algorithms and expect them to be the best implement the mandatory algorithms and expect them to be the best
choice for all customers. For example, at the time that this choice for all customers.
document was written, many IKEv1 implementers were starting to
migrate to AES in Cipher Block Chaining (CBC) mode for Virtual
Private Network (VPN) applications. Many IPsec systems based on
IKEv2 will implement AES, additional Diffie-Hellman groups, and
additional hash algorithms, and some IPsec customers already require
these algorithms in addition to the ones listed above.
It is likely that IANA will add additional transforms in the future, It is likely that IANA will add additional transforms in the future,
and some users may want to use private suites, especially for IKE and some users may want to use private suites, especially for IKE
where implementations should be capable of supporting different where implementations should be capable of supporting different
parameters, up to certain size limits. In support of this goal, all parameters, up to certain size limits. In support of this goal, all
implementations of IKEv2 SHOULD include a management facility that implementations of IKEv2 SHOULD include a management facility that
allows specification (by a user or system administrator) of Diffie- allows specification (by a user or system administrator) of Diffie-
Hellman (DH) parameters (the generator, modulus, and exponent lengths Hellman (DH) parameters (the generator, modulus, and exponent lengths
and values) for new DH groups. Implementations SHOULD provide a and values) for new DH groups. Implementations SHOULD provide a
management interface through which these parameters and the management interface through which these parameters and the
skipping to change at page 76, line 22 skipping to change at page 77, line 22
ID_FQDN 2 ID_FQDN 2
A fully-qualified domain name string. An example of a ID_FQDN A fully-qualified domain name string. An example of a ID_FQDN
is, "example.com". The string MUST not contain any terminators is, "example.com". The string MUST not contain any terminators
(e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII; (e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII;
for an "internationalized domain name", the syntax is as defined for an "internationalized domain name", the syntax is as defined
in [IDNA], for example "xn--tmonesimerkki-bfbb.example.net". in [IDNA], for example "xn--tmonesimerkki-bfbb.example.net".
ID_RFC822_ADDR 3 ID_RFC822_ADDR 3
A fully-qualified RFC822 email address string, An example of a A fully-qualified RFC822 email address string, An example of a
ID_RFC822_ADDR is, "jsmith@example.com". The string MUST not ID_RFC822_ADDR is, "jsmith@example.com". The string MUST not
contain any terminators. contain any terminators. Because of [EAI], implementations would
be wise to treat this field as UTF-8 encoded text, not as
pure ASCII.
RESERVED TO IANA 4 RESERVED TO IANA 4
ID_IPV6_ADDR 5 ID_IPV6_ADDR 5
A single sixteen (16) octet IPv6 address. A single sixteen (16) octet IPv6 address.
RESERVED TO IANA 6 - 8 RESERVED TO IANA 6 - 8
ID_DER_ASN1_DN 9 ID_DER_ASN1_DN 9
The binary Distinguished Encoding Rules (DER) encoding of an The binary Distinguished Encoding Rules (DER) encoding of an
skipping to change at page 78, line 14 skipping to change at page 79, line 14
Certificate Encoding Value Certificate Encoding Value
---------------------------------------------------- ----------------------------------------------------
RESERVED 0 RESERVED 0
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 Authority Revocation List (ARL) 8 UNSPECIFIED
SPKI Certificate 9 UNSPECIFIED SPKI Certificate 9 UNSPECIFIED
X.509 Certificate - Attribute 10 X.509 Certificate - Attribute 10 UNSPECIFIED
Raw RSA Key 11 Raw RSA Key 11
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
RESERVED to IANA 14 - 200 RESERVED to IANA 14 - 200
PRIVATE USE 201 - 255 PRIVATE USE 201 - 255
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.
skipping to change at page 79, line 46 skipping to change at page 80, line 46
the public key used to sign the AUTH payload. The other certificates the public key used to sign the AUTH payload. The other certificates
may be sent in any order. may be sent in any order.
3.7. Certificate Request Payload 3.7. Certificate Request Payload
The Certificate Request Payload, denoted CERTREQ in this memo, The Certificate Request Payload, denoted CERTREQ in this memo,
provides a means to request preferred certificates via IKE and can provides a means to request preferred certificates via IKE and can
appear in the IKE_INIT_SA response and/or the IKE_AUTH request. appear in the IKE_INIT_SA response and/or the IKE_AUTH request.
Certificate Request payloads MAY be included in an exchange when the Certificate Request payloads MAY be included in an exchange when the
sender needs to get the certificate of the receiver. If multiple CAs sender needs to get the certificate of the receiver. If multiple CAs
are trusted and the cert encoding does not allow a list, then are trusted and the certificate encoding does not allow a list, then
multiple Certificate Request payloads SHOULD be transmitted. multiple Certificate Request payloads would need to be transmitted.
The Certificate Request Payload is defined as follows: The Certificate Request Payload is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert Encoding | | | Cert Encoding | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
skipping to change at page 84, line 35 skipping to change at page 85, line 35
of that SA. For notifications concerning IPsec SAs this field of that SA. For notifications concerning IPsec SAs this field
MUST contain either (2) to indicate AH or (3) to indicate ESP. {{ MUST contain either (2) to indicate AH or (3) to indicate ESP. {{
Clarif-7.8 }} Of the notifications defined in this document, the Clarif-7.8 }} Of the notifications defined in this document, the
SPI is included only with INVALID_SELECTORS and REKEY_SA. If the SPI is included only with INVALID_SELECTORS and REKEY_SA. If the
SPI field is empty, this field MUST be sent as zero and MUST be SPI field is empty, this field MUST be sent as zero and MUST be
ignored on receipt. All other values for this field are reserved ignored on receipt. All other values for this field are reserved
to IANA for future assignment. to IANA for future assignment.
o SPI Size (1 octet) - Length in octets of the SPI as defined by the o SPI Size (1 octet) - Length in octets of the SPI as defined by the
IPsec protocol ID or zero if no SPI is applicable. For a IPsec protocol ID or zero if no SPI is applicable. For a
notification concerning the IKE_SA, the SPI Size MUST be zero and notification concerning the IKE SA, the SPI Size MUST be zero and
the field must be empty. the field must be empty.
o Notify Message Type (2 octets) - Specifies the type of o Notify Message Type (2 octets) - Specifies the type of
notification message. notification message.
o SPI (variable length) - Security Parameter Index. o SPI (variable length) - Security Parameter Index.
o Notification Data (variable length) - Informational or error data o Notification Data (variable length) - Informational or error data
transmitted in addition to the Notify Message Type. Values for transmitted in addition to the Notify Message Type. Values for
this field are type specific (see below). this field are type specific (see below).
skipping to change at page 88, line 11 skipping to change at page 89, line 11
The Delete Payload, denoted D in this memo, contains a protocol The Delete Payload, denoted D in this memo, contains a protocol
specific security association identifier that the sender has removed specific security association identifier that the sender has removed
from its security association database and is, therefore, no longer from its security association database and is, therefore, no longer
valid. Figure 17 shows the format of the Delete Payload. It is valid. Figure 17 shows the format of the Delete Payload. It is
possible to send multiple SPIs in a Delete payload; however, each SPI possible to send multiple SPIs in a Delete payload; however, each SPI
MUST be for the same protocol. Mixing of protocol identifiers MUST MUST be for the same protocol. Mixing of protocol identifiers MUST
NOT be performed in the Delete payload. It is permitted, however, to NOT be performed in the Delete payload. It is permitted, however, to
include multiple Delete payloads in a single INFORMATIONAL exchange include multiple Delete payloads in a single INFORMATIONAL exchange
where each Delete payload lists SPIs for a different protocol. where each Delete payload lists SPIs for a different protocol.
Deletion of the IKE_SA is indicated by a protocol ID of 1 (IKE) but Deletion of the IKE SA is indicated by a protocol ID of 1 (IKE) but
no SPIs. Deletion of a CHILD_SA, such as ESP or AH, will contain the no SPIs. Deletion of a Child SA, such as ESP or AH, will contain the
IPsec protocol ID of that protocol (2 for AH, 3 for ESP), and the SPI IPsec protocol ID of that protocol (2 for AH, 3 for ESP), and the SPI
is the SPI the sending endpoint would expect in inbound ESP or AH is the SPI the sending endpoint would expect in inbound ESP or AH
packets. packets.
The Delete Payload is defined as follows: The Delete Payload is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | # of SPIs | | Protocol ID | SPI Size | # of SPIs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Security Parameter Index(es) (SPI) ~ ~ Security Parameter Index(es) (SPI) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Delete Payload Format Figure 17: Delete Payload Format
o Protocol ID (1 octet) - Must be 1 for an IKE_SA, 2 for AH, or 3 o Protocol ID (1 octet) - Must be 1 for an IKE SA, 2 for AH, or 3
for ESP. for ESP.
o SPI Size (1 octet) - Length in octets of the SPI as defined by the o SPI Size (1 octet) - Length in octets of the SPI as defined by the
protocol ID. It MUST be zero for IKE (SPI is in message header) protocol ID. It MUST be zero for IKE (SPI is in message header)
or four for AH and ESP. or four for AH and ESP.
o # of SPIs (2 octets) - The number of SPIs contained in the Delete o # of SPIs (2 octets) - The number of SPIs contained in the Delete
payload. The size of each SPI is defined by the SPI Size field. payload. The size of each SPI is defined by the SPI Size field.
o Security Parameter Index(es) (variable length) - Identifies the o Security Parameter Index(es) (variable length) - Identifies the
skipping to change at page 91, line 16 skipping to change at page 92, line 16
TSi = ((17, 100, 192.0.1.66-192.0.1.66), TSi = ((17, 100, 192.0.1.66-192.0.1.66),
(17, 200, 192.0.1.66-192.0.1.66)) (17, 200, 192.0.1.66-192.0.1.66))
TSr = ((17, 300, 0.0.0.0-255.255.255.255), TSr = ((17, 300, 0.0.0.0-255.255.255.255),
(17, 400, 0.0.0.0-255.255.255.255)) (17, 400, 0.0.0.0-255.255.255.255))
would match UDP packets from 192.0.1.66 to anywhere, with any of the would match UDP packets from 192.0.1.66 to anywhere, with any of the
four combinations of source/destination ports (100,300), (100,400), four combinations of source/destination ports (100,300), (100,400),
(200,300), and (200, 400). (200,300), and (200, 400).
Thus, some types of policies may require several CHILD_SA pairs. For Thus, some types of policies may require several Child SA pairs. For
instance, a policy matching only source/destination ports (100,300) instance, a policy matching only source/destination ports (100,300)
and (200,400), but not the other two combinations, cannot be and (200,400), but not the other two combinations, cannot be
negotiated as a single CHILD_SA pair. negotiated as a single Child SA pair.
3.13.1. Traffic Selector 3.13.1. Traffic Selector
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS Type |IP Protocol ID*| Selector Length | | TS Type |IP Protocol ID*| Selector Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Port* | End Port* | | Start Port* | End Port* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 92, line 10 skipping to change at page 93, line 10
o IP protocol ID (1 octet) - Value specifying an associated IP o IP protocol ID (1 octet) - Value specifying an associated IP
protocol ID (e.g., UDP/TCP/ICMP). A value of zero means that the protocol ID (e.g., UDP/TCP/ICMP). A value of zero means that the
protocol ID is not relevant to this traffic selector-- the SA can protocol ID is not relevant to this traffic selector-- the SA can
carry all protocols. carry all protocols.
o Selector Length - Specifies the length of this Traffic Selector o Selector Length - Specifies the length of this Traffic Selector
Substructure including the header. Substructure including the header.
o Start Port (2 octets) - Value specifying the smallest port number o Start Port (2 octets) - Value specifying the smallest port number
allowed by this Traffic Selector. For protocols for which port is allowed by this Traffic Selector. For protocols for which port is
undefined, or if all ports are allowed, this field MUST be zero. undefined (including protocol 0), or if all ports are allowed,
For the ICMP protocol, the two one-octet fields Type and Code are this field MUST be zero. For the ICMP protocol, the two one-octet
treated as a single 16-bit integer (with Type in the most fields Type and Code are treated as a single 16-bit integer (with
significant eight bits and Code in the least significant eight Type in the most significant eight bits and Code in the least
bits) port number for the purposes of filtering based on this significant eight bits) port number for the purposes of filtering
field. based on this field.
o End Port (2 octets) - Value specifying the largest port number o End Port (2 octets) - Value specifying the largest port number
allowed by this Traffic Selector. For protocols for which port is allowed by this Traffic Selector. For protocols for which port is
undefined, or if all ports are allowed, this field MUST be 65535. undefined (including protocol 0), or if all ports are allowed,
For the ICMP protocol, the two one-octet fields Type and Code are this field MUST be 65535. For the ICMP protocol, the two one-
treated as a single 16-bit integer (with Type in the most octet fields Type and Code are treated as a single 16-bit integer
significant eight bits and Code in the least significant eight (with Type in the most significant eight bits and Code in the
bits) port number for the purposed of filtering based on this least significant eight bits) port number for the purposed of
field. filtering based on this field.
o Starting Address - The smallest address included in this Traffic o Starting Address - The smallest address included in this Traffic
Selector (length determined by TS type). Selector (length determined by TS type).
o Ending Address - The largest address included in this Traffic o Ending Address - The largest address included in this Traffic
Selector (length determined by TS type). Selector (length determined by TS type).
Systems that are complying with [IPSECARCH] that wish to indicate Systems that are complying with [IPSECARCH] that wish to indicate
"ANY" ports MUST set the start port to 0 and the end port to 65535; "ANY" ports MUST set the start port to 0 and the end port to 65535;
note that according to [IPSECARCH], "ANY" includes "OPAQUE". Systems note that according to [IPSECARCH], "ANY" includes "OPAQUE". Systems
skipping to change at page 93, line 39 skipping to change at page 94, line 39
PRIVATE USE 241-255 PRIVATE USE 241-255
3.14. Encrypted Payload 3.14. Encrypted Payload
The Encrypted Payload, denoted SK{...} or E in this memo, contains The Encrypted Payload, denoted SK{...} or E in this memo, contains
other payloads in encrypted form. The Encrypted Payload, if present other payloads in encrypted form. The Encrypted Payload, if present
in a message, MUST be the last payload in the message. Often, it is in a message, MUST be the last payload in the message. Often, it is
the only payload in the message. the only payload in the message.
The algorithms for encryption and integrity protection are negotiated The algorithms for encryption and integrity protection are negotiated
during IKE_SA setup, and the keys are computed as specified in during IKE SA setup, and the keys are computed as specified in
Section 2.14 and Section 2.18. Section 2.14 and Section 2.18.
This document specifies the cryptographic processing of Encrypted This document specifies the cryptographic processing of Encrypted
payloads using a block cipher in CBC mode and an integrity check payloads using a block cipher in CBC mode and an integrity check
algorithm that computes a fixed-length checksum over a variable size algorithm that computes a fixed-length checksum over a variable size
message. The design is modeled after the ESP algorithms described in message. The design is modeled after the ESP algorithms described in
RFCs 2104 [HMAC], 4303 [ESP], and 2451 [ESPCBC]. This document RFCs 2104 [HMAC], 4303 [ESP], and 2451 [ESPCBC]. This document
completely specifies the cryptographic processing of IKE data, but completely specifies the cryptographic processing of IKE data, but
those documents should be consulted for design rationale. Future those documents should be consulted for design rationale. Future
documents may specify the processing of Encrypted payloads for other documents may specify the processing of Encrypted payloads for other
skipping to change at page 94, line 39 skipping to change at page 95, line 39
Note that this is an exception in the standard header format, Note that this is an exception in the standard header format,
since the Encrypted payload is the last payload in the message and since the Encrypted payload is the last payload in the message and
therefore the Next Payload field would normally be zero. But therefore the Next Payload field would normally be zero. But
because the content of this payload is embedded payloads and there because the content of this payload is embedded payloads and there
was no natural place to put the type of the first one, that type was no natural place to put the type of the first one, that type
is placed here. is placed here.
o Payload Length - Includes the lengths of the header, IV, Encrypted o Payload Length - Includes the lengths of the header, IV, Encrypted
IKE Payloads, Padding, Pad Length, and Integrity Checksum Data. IKE Payloads, Padding, Pad Length, and Integrity Checksum Data.
o Initialization Vector - The length of the initialization vector o Initialization Vector - For CBC mode ciphers, the length of the
(IV) is equal to the block length of the underlying encryption initialization vector (IV) is equal to the block length of the
algorithm. Senders MUST select a new unpredictable IV for every underlying encryption algorithm. Senders MUST select a new
message; recipients MUST accept any value. The reader is unpredictable IV for every message; recipients MUST accept any
encouraged to consult [MODES] for advice on IV generation. In value. For other modes than CBC, the IV format and processing is
particular, using the final ciphertext block of the previous specified in the document specifying the encryption algorithm and
message is not considered unpredictable. mode. The reader is encouraged to consult [MODES] for advice on
IV generation. In particular, using the final ciphertext block of
the previous message is not considered unpredictable.
o IKE Payloads are as specified earlier in this section. This field o IKE Payloads are as specified earlier in this section. This field
is encrypted with the negotiated cipher. is encrypted with the negotiated cipher.
o Padding MAY contain any value chosen by the sender, and MUST have o Padding MAY contain any value chosen by the sender, and MUST have
a length that makes the combination of the Payloads, the Padding, a length that makes the combination of the Payloads, the Padding,
and the Pad Length to be a multiple of the encryption block size. and the Pad Length to be a multiple of the encryption block size.
This field is encrypted with the negotiated cipher. This field is encrypted with the negotiated cipher.
o Pad Length is the length of the Padding field. The sender SHOULD o Pad Length is the length of the Padding field. The sender SHOULD
set the Pad Length to the minimum value that makes the combination set the Pad Length to the minimum value that makes the combination
of the Payloads, the Padding, and the Pad Length a multiple of the of the Payloads, the Padding, and the Pad Length a multiple of the
block size, but the recipient MUST accept any length that results block size, but the recipient MUST accept any length that results
in proper alignment. This field is encrypted with the negotiated in proper alignment. This field is encrypted with the negotiated
cipher. cipher.
o Integrity Checksum Data is the cryptographic checksum of the o Integrity Checksum Data is the cryptographic checksum of the
skipping to change at page 97, line 44 skipping to change at page 98, line 44
requested address (or a zero-length address if no specific address requested address (or a zero-length address if no specific address
is requested). If a specific address is requested, it likely is requested). If a specific address is requested, it likely
indicates that a previous connection existed with this address and indicates that a previous connection existed with this address and
the requestor would like to reuse that address. With IPv6, a the requestor would like to reuse that address. With IPv6, a
requestor MAY supply the low-order address octets it wants to use. requestor MAY supply the low-order address octets it wants to use.
Multiple internal addresses MAY be requested by requesting Multiple internal addresses MAY be requested by requesting
multiple internal address attributes. The responder MAY only send multiple internal address attributes. The responder MAY only send
up to the number of addresses requested. The INTERNAL_IP6_ADDRESS up to the number of addresses requested. The INTERNAL_IP6_ADDRESS
is made up of two fields: the first is a 16-octet IPv6 address, is made up of two fields: the first is a 16-octet IPv6 address,
and the second is a one-octet prefix-length as defined in and the second is a one-octet prefix-length as defined in
[ADDRIPV6]. The requested address is valid until there are no [ADDRIPV6]. The requested address is valid until there are no IKE
IKE_SAs between the peers. SAs between the peers. This is described in more detail in
Section 3.15.3.
o INTERNAL_IP4_NETMASK - The internal network's netmask. Only one o INTERNAL_IP4_NETMASK - The internal network's netmask. Only one
netmask is allowed in the request and reply messages (e.g., netmask is allowed in the request and reply messages (e.g.,
255.255.255.0), and it MUST be used only with an 255.255.255.0), and it MUST be used only with an
INTERNAL_IP4_ADDRESS attribute. {{ Clarif-6.4 }} INTERNAL_IP4_ADDRESS attribute. {{ Clarif-6.4 }}
INTERNAL_IP4_NETMASK in a CFG_REPLY means roughly the same thing INTERNAL_IP4_NETMASK in a CFG_REPLY means roughly the same thing
as INTERNAL_IP4_SUBNET containing the same information ("send as INTERNAL_IP4_SUBNET containing the same information ("send
traffic to these addresses through me"), but also implies a link traffic to these addresses through me"), but also implies a link
boundary. For instance, the client could use its own address and boundary. For instance, the client could use its own address and
the netmask to calculate the broadcast address of the link. An the netmask to calculate the broadcast address of the link. An
skipping to change at page 98, line 39 skipping to change at page 99, line 40
MAY respond with zero or more DHCP server attributes. MAY respond with zero or more DHCP server attributes.
o APPLICATION_VERSION - The version or application information of o APPLICATION_VERSION - The version or application information of
the IPsec host. This is a string of printable ASCII characters the IPsec host. This is a string of printable ASCII characters
that is NOT null terminated. that is NOT null terminated.
o INTERNAL_IP4_SUBNET - The protected sub-networks that this edge- o INTERNAL_IP4_SUBNET - The protected sub-networks that this edge-
device protects. This attribute is made up of two fields: the device protects. This attribute is made up of two fields: the
first being an IP address and the second being a netmask. first being an IP address and the second being a netmask.
Multiple sub-networks MAY be requested. The responder MAY respond Multiple sub-networks MAY be requested. The responder MAY respond
with zero or more sub-network attributes. with zero or more sub-network attributes. This is discussed in
more detail in Section 3.15.2.
o SUPPORTED_ATTRIBUTES - When used within a Request, this attribute o SUPPORTED_ATTRIBUTES - When used within a Request, this attribute
MUST be zero-length and specifies a query to the responder to MUST be zero-length and specifies a query to the responder to
reply back with all of the attributes that it supports. The reply back with all of the attributes that it supports. The
response contains an attribute that contains a set of attribute response contains an attribute that contains a set of attribute
identifiers each in 2 octets. The length divided by 2 (octets) identifiers each in 2 octets. The length divided by 2 (octets)
would state the number of supported attributes contained in the would state the number of supported attributes contained in the
response. response.
o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge- o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge-
device protects. This attribute is made up of two fields: the device protects. This attribute is made up of two fields: the
first is a 16-octet IPv6 address, and the second is a one-octet first is a 16-octet IPv6 address, and the second is a one-octet
prefix-length as defined in [ADDRIPV6]. Multiple sub-networks MAY prefix-length as defined in [ADDRIPV6]. Multiple sub-networks MAY
be requested. The responder MAY respond with zero or more sub- be requested. The responder MAY respond with zero or more sub-
network attributes. network attributes. This is discussed in more detail in Section
3.15.2.
Note that no recommendations are made in this document as to how an Note that no recommendations are made in this document as to how an
implementation actually figures out what information to send in a implementation actually figures out what information to send in a
reply. That is, we do not recommend any specific method of an IRAS reply. That is, we do not recommend any specific method of an IRAS
determining which DNS server should be returned to a requesting IRAC. determining which DNS server should be returned to a requesting IRAC.
3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET
{{ Section added based on Clarif-6.3 }} {{ Section added based on Clarif-6.3 }}
skipping to change at page 102, line 4 skipping to change at page 103, line 8
Although this approach to configuring IPv6 addresses is reasonably Although this approach to configuring IPv6 addresses is reasonably
simple, it has some limitations. IPsec tunnels configured using simple, it has some limitations. IPsec tunnels configured using
IKEv2 are not fully-featured "interfaces" in the IPv6 addressing IKEv2 are not fully-featured "interfaces" in the IPv6 addressing
architecture sense [IPV6ADDR]. In particular, they do not architecture sense [IPV6ADDR]. In particular, they do not
necessarily have link-local addresses, and this may complicate the necessarily have link-local addresses, and this may complicate the
use of protocols that assume them, such as [MLDV2]. use of protocols that assume them, such as [MLDV2].
3.15.4. Address Assignment Failures 3.15.4. Address Assignment Failures
{{ Added this section from Clarif-6.8 }} {{ Added this section from Clarif-6.8 }}
If the responder encounters an error while attempting to assign an IP If the responder encounters an error while attempting to assign an IP
address to the initiator during the processing of a Configuration address to the initiator during the processing of a Configuration
Payload, it responds with an INTERNAL_ADDRESS_FAILURE notification. Payload, it responds with an INTERNAL_ADDRESS_FAILURE notification.
{{ 3.10.1-36 }} If this error is generated within an IKE_AUTH The IKE SA is still created even if the initial Child SA cannot be
exchange, no CHILD_SA will be created. However, there are some more created because of this failure. {{ 3.10.1-36 }} If this error is
complex error cases. generated within an IKE_AUTH exchange, no Child SA will be created.
However, there are some more complex error cases.
If the responder does not support configuration payloads at all, it If the responder does not support configuration payloads at all, it
can simply ignore all configuration payloads. This type of can simply ignore all configuration payloads. This type of
implementation never sends INTERNAL_ADDRESS_FAILURE notifications. implementation never sends INTERNAL_ADDRESS_FAILURE notifications.
If the initiator requires the assignment of an IP address, it will If the initiator requires the assignment of an IP address, it will
treat a response without CFG_REPLY as an error. treat a response without CFG_REPLY as an error.
The initiator may request a particular type of address (IPv4 or IPv6) The initiator may request a particular type of address (IPv4 or IPv6)
that the responder does not support, even though the responder that the responder does not support, even though the responder
supports configuration payloads. In this case, the responder simply supports configuration payloads. In this case, the responder simply
skipping to change at page 102, line 31 skipping to change at page 103, line 37
rest of the request as usual. rest of the request as usual.
If the initiator requests multiple addresses of a type that the If the initiator requests multiple addresses of a type that the
responder supports, and some (but not all) of the requests fail, the responder supports, and some (but not all) of the requests fail, the
responder replies with the successful addresses only. The responder responder replies with the successful addresses only. The responder
sends INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned. sends INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned.
3.16. Extensible Authentication Protocol (EAP) Payload 3.16. Extensible Authentication Protocol (EAP) Payload
The Extensible Authentication Protocol Payload, denoted EAP in this The Extensible Authentication Protocol Payload, denoted EAP in this
memo, allows IKE_SAs to be authenticated using the protocol defined memo, allows IKE SAs to be authenticated using the protocol defined
in RFC 3748 [EAP] and subsequent extensions to that protocol. The in RFC 3748 [EAP] and subsequent extensions to that protocol. The
full set of acceptable values for the payload is defined elsewhere, full set of acceptable values for the payload is defined elsewhere,
but a short summary of RFC 3748 is included here to make this but a short summary of RFC 3748 is included here to make this
document stand alone in the common cases. document stand alone in the common cases.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 104, line 32 skipping to change at page 105, line 34
o Ability to negotiate SAs through a NAT and tunnel the resulting o Ability to negotiate SAs through a NAT and tunnel the resulting
ESP SA over UDP. ESP SA over UDP.
o Ability to request (and respond to a request for) a temporary IP o Ability to request (and respond to a request for) a temporary IP
address on the remote end of a tunnel. address on the remote end of a tunnel.
o Ability to support various types of legacy authentication. o Ability to support various types of legacy authentication.
o Ability to support window sizes greater than one. o Ability to support window sizes greater than one.
o Ability to establish multiple ESP or AH SAs within a single o Ability to establish multiple ESP or AH SAs within a single IKE
IKE_SA. SA.
o Ability to rekey SAs. o Ability to rekey SAs.
To assure interoperability, all implementations MUST be capable of To assure interoperability, all implementations MUST be capable of
parsing all payload types (if only to skip over them) and to ignore parsing all payload types (if only to skip over them) and to ignore
payload types that it does not support unless the critical bit is set payload types that it does not support unless the critical bit is set
in the payload header. If the critical bit is set in an unsupported in the payload header. If the critical bit is set in an unsupported
payload header, all implementations MUST reject the messages payload header, all implementations MUST reject the messages
containing those payloads. containing those payloads.
Every implementation MUST be capable of doing four-message Every implementation MUST be capable of doing four-message
IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE,
one for ESP or AH). Implementations MAY be initiate-only or respond- one for ESP or AH). Implementations MAY be initiate-only or respond-
only if appropriate for their platform. Every implementation MUST be only if appropriate for their platform. Every implementation MUST be
capable of responding to an INFORMATIONAL exchange, but a minimal capable of responding to an INFORMATIONAL exchange, but a minimal
implementation MAY respond to any INFORMATIONAL message with an empty implementation MAY respond to any INFORMATIONAL message with an empty
INFORMATIONAL reply (note that within the context of an IKE_SA, an INFORMATIONAL reply (note that within the context of an IKE SA, an
"empty" message consists of an IKE header followed by an Encrypted "empty" message consists of an IKE header followed by an Encrypted
payload with no payloads contained in it). A minimal implementation payload with no payloads contained in it). A minimal implementation
MAY support the CREATE_CHILD_SA exchange only in so far as to MAY support the CREATE_CHILD_SA exchange only in so far as to
recognize requests and reject them with a Notify payload of type recognize requests and reject them with a Notify payload of type
NO_ADDITIONAL_SAS. A minimal implementation need not be able to NO_ADDITIONAL_SAS. A minimal implementation need not be able to
initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA
expires (based on locally configured values of either lifetime or expires (based on locally configured values of either lifetime or
octets passed), and implementation MAY either try to renew it with a octets passed), and implementation MAY either try to renew it with a
CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and
create a new one. If the responder rejects the CREATE_CHILD_SA create a new one. If the responder rejects the CREATE_CHILD_SA
skipping to change at page 107, line 6 skipping to change at page 108, line 11
Note that these limitations are on the Diffie-Hellman groups Note that these limitations are on the Diffie-Hellman groups
themselves. There is nothing in IKE that prohibits using stronger themselves. There is nothing in IKE that prohibits using stronger
groups nor is there anything that will dilute the strength obtained groups nor is there anything that will dilute the strength obtained
from stronger groups (limited by the strength of the other algorithms from stronger groups (limited by the strength of the other algorithms
negotiated including the prf function). In fact, the extensible negotiated including the prf function). In fact, the extensible
framework of IKE encourages the definition of more groups; use of framework of IKE encourages the definition of more groups; use of
elliptical curve groups may greatly increase strength using much elliptical curve groups may greatly increase strength using much
smaller numbers. smaller numbers.
It is assumed that all Diffie-Hellman exponents are erased from It is assumed that all Diffie-Hellman exponents are erased from
memory after use. In particular, these exponents MUST NOT be derived memory after use.
from long-lived secrets like the seed to a pseudo-random generator
that is not erased after use.
The strength of all keys is limited by the size of the output of the The strength of all keys is limited by the size of the output of the
negotiated prf function. For this reason, a prf function whose negotiated prf function. For this reason, a prf function whose
output is less than 128 bits (e.g., 3DES-CBC) MUST NOT be used with output is less than 128 bits (e.g., 3DES-CBC) MUST NOT be used with
this protocol. this protocol.
The security of this protocol is critically dependent on the The security of this protocol is critically dependent on the
randomness of the randomly chosen parameters. These should be randomness of the randomly chosen parameters. These should be
generated by a strong random or properly seeded pseudo-random source generated by a strong random or properly seeded pseudo-random source
(see [RANDOMNESS]). Implementers should take care to ensure that use (see [RANDOMNESS]). Implementers should take care to ensure that use
of random numbers for both keys and nonces is engineered in a fashion of random numbers for both keys and nonces is engineered in a fashion
that does not undermine the security of the keys. that does not undermine the security of the keys.
For information on the rationale of many of the cryptographic design For information on the rationale of many of the cryptographic design
choices in this protocol, see [SIGMA] and [SKEME]. Though the choices in this protocol, see [SIGMA] and [SKEME]. Though the
security of negotiated CHILD_SAs does not depend on the strength of security of negotiated Child SAs does not depend on the strength of
the encryption and integrity protection negotiated in the IKE_SA, the encryption and integrity protection negotiated in the IKE SA,
implementations MUST NOT negotiate NONE as the IKE integrity implementations MUST NOT negotiate NONE as the IKE integrity
protection algorithm or ENCR_NULL as the IKE encryption algorithm. protection algorithm or ENCR_NULL as the IKE encryption algorithm.
When using pre-shared keys, a critical consideration is how to assure When using pre-shared keys, a critical consideration is how to assure
the randomness of these secrets. The strongest practice is to ensure the randomness of these secrets. The strongest practice is to ensure
that any pre-shared key contain as much randomness as the strongest that any pre-shared key contain as much randomness as the strongest
key being negotiated. Deriving a shared secret from a password, key being negotiated. Deriving a shared secret from a password,
name, or other low-entropy source is not secure. These sources are name, or other low-entropy source is not secure. These sources are
subject to dictionary and social engineering attacks, among others. subject to dictionary and social engineering attacks, among others.
skipping to change at page 108, line 20 skipping to change at page 109, line 24
unprotected fashion. Note that this vulnerability is not limited to unprotected fashion. Note that this vulnerability is not limited to
just EAP, but can occur in other scenarios where an authentication just EAP, but can occur in other scenarios where an authentication
infrastructure is reused. For example, if the EAP mechanism used by infrastructure is reused. For example, if the EAP mechanism used by
IKEv2 utilizes a token authenticator, a man-in-the-middle attacker IKEv2 utilizes a token authenticator, a man-in-the-middle attacker
could impersonate the web server, intercept the token authentication could impersonate the web server, intercept the token authentication
exchange, and use it to initiate an IKEv2 connection. For this exchange, and use it to initiate an IKEv2 connection. For this
reason, use of non-key-generating EAP methods SHOULD be avoided where reason, use of non-key-generating EAP methods SHOULD be avoided where
possible. Where they are used, it is extremely important that all possible. Where they are used, it is extremely important that all
usages of these EAP methods SHOULD utilize a protected tunnel, where usages of these EAP methods SHOULD utilize a protected tunnel, where
the initiator validates the responder's certificate before initiating the initiator validates the responder's certificate before initiating
the EAP exchange. {{ Demoted the SHOULD }} Implementers should the EAP authentication. {{ Demoted the SHOULD }} Implementers should
describe the vulnerabilities of using non-key-generating EAP methods describe the vulnerabilities of using non-key-generating EAP methods
in the documentation of their implementations so that the in the documentation of their implementations so that the
administrators deploying IPsec solutions are aware of these dangers. administrators deploying IPsec solutions are aware of these dangers.
An implementation using EAP MUST also use strong authentication of An implementation using EAP MUST also use strong authentication of
the server to the client before the EAP exchange begins, even if the the server to the client before the EAP authentication begins, even
EAP method offers mutual authentication. This avoids having if the EAP method offers mutual authentication. This avoids having
additional IKEv2 protocol variations and protects the EAP data from additional IKEv2 protocol variations and protects the EAP data from
active attackers. active attackers.
If the messages of IKEv2 are long enough that IP-level fragmentation If the messages of IKEv2 are long enough that IP-level fragmentation
is necessary, it is possible that attackers could prevent the is necessary, it is possible that attackers could prevent the
exchange from completing by exhausting the reassembly buffers. The exchange from completing by exhausting the reassembly buffers. The
chances of this can be minimized by using the Hash and URL encodings chances of this can be minimized by using the Hash and URL encodings
instead of sending certificates (see Section 3.6). Additional instead of sending certificates (see Section 3.6). Additional
mitigations are discussed in [DOSUDPPROT]. mitigations are discussed in [DOSUDPPROT].
skipping to change at page 110, line 38 skipping to change at page 111, line 41
Reingold, and Michael Richardson. Many other people contributed to Reingold, and Michael Richardson. Many other people contributed to
the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI, the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI,
each of which has its own list of authors. Hugh Daniel suggested the each of which has its own list of authors. Hugh Daniel suggested the
feature of having the initiator, in message 3, specify a name for the feature of having the initiator, in message 3, specify a name for the
responder, and gave the feature the cute name "You Tarzan, Me Jane". responder, and gave the feature the cute name "You Tarzan, Me Jane".
David Faucher and Valery Smyzlov helped refine the design of the David Faucher and Valery Smyzlov helped refine the design of the
traffic selector negotiation. traffic selector negotiation.
This paragraph lists references that appear only in figures. The This paragraph lists references that appear only in figures. The
section is only here to keep the 'xml2rfc' program happy, and needs section is only here to keep the 'xml2rfc' program happy, and needs
to be removed when the document is published. Feel free to ignore to be removed when the document is published. The RFC Editor will
it. [DES] [IDEA] [MD5] [X.501] [X.509] remove it before publication. [AEAD] [EAI] [DES] [IDEA] [MD5]
[X.501] [X.509]
8. References 8. References
8.1. Normative References 8.1. Normative References
[ADDGROUP] [ADDGROUP]
Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)", Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, May 2003. RFC 3526, May 2003.
skipping to change at page 112, line 7 skipping to change at page 113, line 8
PRF-128) Algorithm for the Internet Key Exchange Protocol PRF-128) Algorithm for the Internet Key Exchange Protocol
(IKE)", RFC 4615, August 2006. (IKE)", RFC 4615, August 2006.
[UDPENCAPS] [UDPENCAPS]
Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005. RFC 3948, January 2005.
8.2. Informative References 8.2. Informative References
[AEAD] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, January 2008.
[AH] Kent, S., "IP Authentication Header", RFC 4302, [AH] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
[ARCHGUIDEPHIL] [ARCHGUIDEPHIL]
Bush, R. and D. Meyer, "Some Internet Architectural Bush, R. and D. Meyer, "Some Internet Architectural
Guidelines and Philosophy", RFC 3439, December 2002. Guidelines and Philosophy", RFC 3439, December 2002.
[ARCHPRINC] [ARCHPRINC]
Carpenter, B., "Architectural Principles of the Internet", Carpenter, B., "Architectural Principles of the Internet",
RFC 1958, June 1996. RFC 1958, June 1996.
skipping to change at page 113, line 8 skipping to change at page 114, line 13
[DOI] Piper, D., "The Internet IP Security Domain of [DOI] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998. Interpretation for ISAKMP", RFC 2407, November 1998.
[DOSUDPPROT] [DOSUDPPROT]
C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection
for UDP-based protocols", ACM Conference on Computer and for UDP-based protocols", ACM Conference on Computer and
Communications Security , October 2003. Communications Security , October 2003.
[DSS] National Institute of Standards and Technology, U.S. [DSS] National Institute of Standards and Technology, U.S.
Department of Commerce, "Digital Signature Standard", Department of Commerce, "Digital Signature Standard",
FIPS 186, May 1994. Draft FIPS 186-3, June 2008.
[EAI] Abel, Y., "Internationalized Email Headers", RFC 5335,
September 2008.
[EAPMITM] N. Asokan, V. Nierni, and K. Nyberg, "Man-in-the-Middle in [EAPMITM] N. Asokan, V. Nierni, and K. Nyberg, "Man-in-the-Middle in
Tunneled Authentication Protocols", November 2002, Tunneled Authentication Protocols", November 2002,
<http://eprint.iacr.org/2002/163>. <http://eprint.iacr.org/2002/163>.
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[EXCHANGEANALYSIS] [EXCHANGEANALYSIS]
R. Perlman and C. Kaufman, "Analysis of the IPsec key R. Perlman and C. Kaufman, "Analysis of the IPsec key
skipping to change at page 113, line 46 skipping to change at page 115, line 6
[IDNA] Faltstrom, P., Hoffman, P., and A. Costello, [IDNA] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)", "Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003. RFC 3490, March 2003.
[IKEV1] Harkins, D. and D. Carrel, "The Internet Key Exchange [IKEV1] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (IKE)", RFC 2409, November 1998.
[IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[IPCOMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP [IP-COMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP
Payload Compression Protocol (IPComp)", RFC 3173, Payload Compression Protocol (IPComp)", RFC 3173,
September 2001. September 2001.
[IPSECARCH-OLD] [IPSECARCH-OLD]
Kent, S. and R. Atkinson, "Security Architecture for the Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[IPV6ADDR] [IPV6ADDR]
Hinden, R. and S. Deering, "Internet Protocol Version 6 Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003. (IPv6) Addressing Architecture", RFC 4291, February 2006.
[ISAKMP] Maughan, D., Schneider, M., and M. Schertler, "Internet [ISAKMP] Maughan, D., Schneider, M., and M. Schertler, "Internet
Security Association and Key Management Protocol Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998. (ISAKMP)", RFC 2408, November 1998.
[LDAP] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory [LDAP] Sermersheim, J., "Lightweight Directory Access Protocol
Access Protocol (v3)", RFC 2251, December 1997. (v3)", RFC 4511, June 2006.
[MAILFORMAT] [MAILFORMAT]
Resnick, P., "Internet Message Format", RFC 2822, Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[MIPV6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [MIPV6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[MLDV2] Vida, R. and L. Costa, "Multicast Listener Discovery [MLDV2] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[MODES] National Institute of Standards and Technology, U.S. [MODES] National Institute of Standards and Technology, U.S.
Department of Commerce, "Recommendation for Block Cipher Department of Commerce, "Recommendation for Block Cipher
Modes of Operation", SP 800-38A, 2001. Modes of Operation", SP 800-38A, 2001.
[NAI] Aboba, B. and M. Beadles, "The Network Access Identifier", [NAI] Aboba, B., Beadles, M., Eronen, P., and J. Arkko, "The
RFC 2486, January 1999. Network Access Identifier", RFC 4282, December 2005.
[NATREQ] Aboba, B. and W. Dixon, "IPsec-Network Address Translation [NATREQ] Aboba, B. and W. Dixon, "IPsec-Network Address Translation
(NAT) Compatibility Requirements", RFC 3715, March 2004. (NAT) Compatibility Requirements", RFC 3715, March 2004.
[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol",
RFC 2412, November 1998. RFC 2412, November 1998.
[PFKEY] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key [PFKEY] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
Management API, Version 2", RFC 2367, July 1998. Management API, Version 2", RFC 2367, July 1998.
skipping to change at page 115, line 13 skipping to change at page 116, line 21
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2138, April 1997. RFC 2138, April 1997.
[RANDOMNESS] [RANDOMNESS]
Eastlake, D., Schiller, J., and S. Crocker, "Randomness Eastlake, D., Schiller, J., and S. Crocker, "Randomness
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.
[ROHCV2] Ertekin, et. al., E., "IKEv2 Extensions to Support Robust
Header Compression over IPsec (ROHCoIPsec)",
draft-ietf-rohc-ikev2-extensions-hcoipsec (work in
progress), October 2008.
[RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for [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",
FIPS 180-1, May 1994. FIPS 180-3, October 2008.
[SIGMA] H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to [SIGMA] H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to
Authenticated Diffie-Hellman and its Use in the IKE Authenticated Diffie-Hellman and its Use in the IKE
Protocols", Advances in Cryptography - CRYPTO 2003 Protocols", Advances in Cryptography - CRYPTO 2003
Proceedings LNCS 2729, 2003, <http:// Proceedings LNCS 2729, 2003, <http://
www.informatik.uni-trier.de/~ley/db/conf/crypto/ www.informatik.uni-trier.de/~ley/db/conf/crypto/
crypto2003.html>. crypto2003.html>.
[SKEME] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange [SKEME] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange
Mechanism for Internet", IEEE Proceedings of the 1996 Mechanism for Internet", IEEE Proceedings of the 1996
skipping to change at page 116, line 22 skipping to change at page 117, line 31
authentication mechanisms affecting only a single AUTH payload authentication mechanisms affecting only a single AUTH payload
rather than restructuring the entire exchange) see rather than restructuring the entire exchange) see
[EXCHANGEANALYSIS]; [EXCHANGEANALYSIS];
3. To remove the Domain of Interpretation (DOI), Situation (SIT), 3. To remove the Domain of Interpretation (DOI), Situation (SIT),
and Labeled Domain Identifier fields, and the Commit and and Labeled Domain Identifier fields, and the Commit and
Authentication only bits; Authentication only bits;
4. To decrease IKE's latency in the common case by making the 4. To decrease IKE's latency in the common case by making the
initial exchange be 2 round trips (4 messages), and allowing the initial exchange be 2 round trips (4 messages), and allowing the
ability to piggyback setup of a CHILD_SA on that exchange; ability to piggyback setup of a Child SA on that exchange;
5. To replace the cryptographic syntax for protecting the IKE 5. To replace the cryptographic syntax for protecting the IKE
messages themselves with one based closely on ESP to simplify messages themselves with one based closely on ESP to simplify
implementation and security analysis; implementation and security analysis;
6. To reduce the number of possible error states by making the 6. To reduce the number of possible error states by making the
protocol reliable (all messages are acknowledged) and sequenced. protocol reliable (all messages are acknowledged) and sequenced.
This allows shortening CREATE_CHILD_SA exchanges from 3 messages This allows shortening CREATE_CHILD_SA exchanges from 3 messages
to 2; to 2;
skipping to change at page 119, line 5 skipping to change at page 119, line 43
[N(NAT_DETECTION_SOURCE_IP)+, [N(NAT_DETECTION_SOURCE_IP)+,
N(NAT_DETECTION_DESTINATION_IP)], N(NAT_DETECTION_DESTINATION_IP)],
[V+] [V+]
normal response <-- SA, KE, Nr, normal response <-- SA, KE, Nr,
(no cookie) [N(NAT_DETECTION_SOURCE_IP), (no cookie) [N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)], N(NAT_DETECTION_DESTINATION_IP)],
[[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
[V+] [V+]
cookie response <-- N(COOKIE),
[V+]
different D-H <-- N(INVALID_KE_PAYLOAD),
group wanted [V+]
C.2. IKE_AUTH Exchange without EAP C.2. IKE_AUTH Exchange without EAP
request --> IDi, [CERT+], request --> IDi, [CERT+],
[N(INITIAL_CONTACT)], [N(INITIAL_CONTACT)],
[[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
[IDr], [IDr],
AUTH, AUTH,
[CP(CFG_REQUEST)], [CP(CFG_REQUEST)],
[N(IPCOMP_SUPPORTED)+], [N(IPCOMP_SUPPORTED)+],
[N(USE_TRANSPORT_MODE)], [N(USE_TRANSPORT_MODE)],
skipping to change at page 120, line 5 skipping to change at page 120, line 31
AUTH, AUTH,
[CP(CFG_REPLY)], [CP(CFG_REPLY)],
[N(IPCOMP_SUPPORTED)], [N(IPCOMP_SUPPORTED)],
[N(USE_TRANSPORT_MODE)], [N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)], [N(NON_FIRST_FRAGMENTS_ALSO)],
SA, TSi, TSr, SA, TSi, TSr,
[N(ADDITIONAL_TS_POSSIBLE)], [N(ADDITIONAL_TS_POSSIBLE)],
[V+] [V+]
error in Child SA <-- IDr, [CERT+],
creation AUTH,
N(error),
[V+]
C.3. IKE_AUTH Exchange with EAP C.3. IKE_AUTH Exchange with EAP
first request --> IDi, first request --> IDi,
[N(INITIAL_CONTACT)], [N(INITIAL_CONTACT)],
[[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
[IDr], [IDr],
[CP(CFG_REQUEST)], [CP(CFG_REQUEST)],
[N(IPCOMP_SUPPORTED)+], [N(IPCOMP_SUPPORTED)+],
[N(USE_TRANSPORT_MODE)], [N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
skipping to change at page 121, line 5 skipping to change at page 122, line 5
last response <-- AUTH, last response <-- AUTH,
[CP(CFG_REPLY)], [CP(CFG_REPLY)],
[N(IPCOMP_SUPPORTED)], [N(IPCOMP_SUPPORTED)],
[N(USE_TRANSPORT_MODE)], [N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)], [N(NON_FIRST_FRAGMENTS_ALSO)],
SA, TSi, TSr, SA, TSi, TSr,
[N(ADDITIONAL_TS_POSSIBLE)], [N(ADDITIONAL_TS_POSSIBLE)],
[V+] [V+]
C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying CHILD_SAs C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying Child SAs
request --> [N(REKEY_SA)], request --> [N(REKEY_SA)],
[CP(CFG_REQUEST)], [CP(CFG_REQUEST)],
[N(IPCOMP_SUPPORTED)+], [N(IPCOMP_SUPPORTED)+],
[N(USE_TRANSPORT_MODE)], [N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)], [N(NON_FIRST_FRAGMENTS_ALSO)],
SA, Ni, [KEi], TSi, TSr SA, Ni, [KEi], TSi, TSr
[V+]
response <-- [CP(CFG_REPLY)], normal <-- [CP(CFG_REPLY)],
[N(IPCOMP_SUPPORTED)], response [N(IPCOMP_SUPPORTED)],
[N(USE_TRANSPORT_MODE)], [N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)], [N(NON_FIRST_FRAGMENTS_ALSO)],
SA, Nr, [KEr], TSi, TSr, SA, Nr, [KEr], TSi, TSr,
[N(ADDITIONAL_TS_POSSIBLE)] [N(ADDITIONAL_TS_POSSIBLE)]
[V+]
C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA error case <-- N(error)
different D-H <-- N(INVALID_KE_PAYLOAD),
group wanted [V+]
C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA
request --> SA, Ni, [KEi] request --> SA, Ni, [KEi]
[V+]
response <-- SA, Nr, [KEr] response <-- SA, Nr, [KEr]
[V+]
C.6. INFORMATIONAL Exchange C.6. INFORMATIONAL Exchange
request --> [N+], request --> [N+],
[D+], [D+],
[CP(CFG_REQUEST)] [CP(CFG_REQUEST)]
response <-- [N+], response <-- [N+],
[D+], [D+],
[CP(CFG_REPLY)] [CP(CFG_REPLY)]
skipping to change at page 122, line 43 skipping to change at page 124, line 4
Removed the discussion of INTERNAL_ADDRESS_EXPIRY in many places, and Removed the discussion of INTERNAL_ADDRESS_EXPIRY in many places, and
added a paragraph about it in Section 1.7. added a paragraph about it in Section 1.7.
Moved Clarif-7.10 from Section 1.2 to Section 3.2. Moved Clarif-7.10 from Section 1.2 to Section 3.2.
In the figure in Section 1.3.2, made KEi optional, and added text In the figure in Section 1.3.2, made KEi optional, and added text
saying "The KEi payload SHOULD be included." saying "The KEi payload SHOULD be included."
In the figure in Section 1.3.2, maked KEr optional, and removed text In the figure in Section 1.3.2, maked KEr optional, and removed text
saying "KEi and KEr are required for rekeying an IKE_SA." saying "KEi and KEr are required for rekeying an IKE SA."
In Section 1.4, clarified that the half-closed connections being In Section 1.4, clarified that the half-closed connections being
discussed are AH and ESP. discussed are AH and ESP.
Rearranged the end of Section 1.7, and added the new notation for Rearranged the end of Section 1.7, and added the new notation for
moving text out of 3.10.1. moving text out of 3.10.1.
Clarified the wording in the second paragraph of Section 2.2. This Clarified the wording in the second paragraph of Section 2.2. This
allowd the removal of the fourth paragraph, which previously had allowd the removal of the fourth paragraph, which previously had
Clarif-2.2 in it. Clarif-2.2 in it.
In section 2.5, removed "or later" from "version 2.0". In section 2.5, removed "or later" from "version 2.0".
Added the question for implementers about payload order at the end of Added the question for implementers about payload order at the end of
Section 2.5. Section 2.5.
Corrected Section 2.7 based on Clarif-7-13 to say that you can't do Corrected Section 2.7 based on Clarif-7-13 to say that you can't do
ESP and AH at one time. ESP and AH at one time.
In Section 2.8, clarified the wording about how to replace an IKE_SA. In Section 2.8, clarified the wording about how to replace an IKE SA.
Clarified the text in the last many paragraphs in Section 2.9. Also Clarified the text in the last many paragraphs in Section 2.9. Also
moved some text from near the beginning of 2.9 to the beginning of moved some text from near the beginning of 2.9 to the beginning of
2.9.1. 2.9.1.
Removed some redundant text in Section 2.9 concerning creating a Removed some redundant text in Section 2.9 concerning creating a
CHILD_SA pair not in response to an arriving packet. Child SA pair not in response to an arriving packet.
Added the following to the end of the first paragraph of Section Added the following to the end of the first paragraph of Section
2.14: "The lengths of SK_d, SK_pi, and SK_pr are the key length of 2.14: "The lengths of SK_d, SK_pi, and SK_pr are the key length of
the agreed-to PRF." the agreed-to PRF."
Added the restriction in Section 2.15 that all PRFs used with IKEv2 Added the restriction in Section 2.15 that all PRFs used with IKEv2
MUST take variable-sized keys. MUST take variable-sized keys.
In Section 2.17, removed "If multiple IPsec protocols are negotiated, In Section 2.17, removed "If multiple IPsec protocols are negotiated,
keying material is taken in the order in which the protocol headers keying material is taken in the order in which the protocol headers
skipping to change at page 124, line 14 skipping to change at page 125, line 24
domain name" as defined in [IDNA]." domain name" as defined in [IDNA]."
In Section 3.8, shortened and clarified the description of "RSA In Section 3.8, shortened and clarified the description of "RSA
Digital Signature". Digital Signature".
In Section 3.10, shortened and clarified the description of "Protocol In Section 3.10, shortened and clarified the description of "Protocol
ID". ID".
In Section 3.15, "The requested address is valid until the expiry In Section 3.15, "The requested address is valid until the expiry
time defined with the INTERNAL_ADDRESS_EXPIRY attribute or there are time defined with the INTERNAL_ADDRESS_EXPIRY attribute or there are
no IKE_SAs between the peers" is shortened to just "The requested no IKE SAs between the peers" is shortened to just "The requested
address is valid until there are no IKE_SAs between the peers." address is valid until there are no IKE SAs between the peers."
In Section 3.15.1, changed "INTERNAL_IP6_NBNS" to unspecified. In Section 3.15.1, changed "INTERNAL_IP6_NBNS" to unspecified.
Made [ADDRIPV6] an informative reference instead of a normative Made [ADDRIPV6] an informative reference instead of a normative
reference and updated it. reference and updated it.
Made [PKCS1] a normative reference instead of an informative Made [PKCS1] a normative reference instead of an informative
reference and changed the pointer to RFC 3447. reference and changed the pointer to RFC 3447.
D.3. Changes from draft -00 to draft -01 D.3. Changes from draft -00 to draft -01
skipping to change at page 124, line 39 skipping to change at page 125, line 49
unrecognized SPI...". unrecognized SPI...".
In Section 3.3, fifth paragraph, upped the number of transforms for In Section 3.3, fifth paragraph, upped the number of transforms for
AH and ESP by one each to account for ESN, which is now mandatory. AH and ESP by one each to account for ESN, which is now mandatory.
In Section 2.1, added "or equal to" in "The responder MUST remember In Section 2.1, added "or equal to" in "The responder MUST remember
each response until it receives a request whose sequence number is each response until it receives a request whose sequence number is
larger than or equal to the sequence number in the response plus its larger than or equal to the sequence number in the response plus its
window size." window size."
In Section 2.18, removed " Note that this may not work if the new In Section 2.18, removed " Note that this may not work if the new IKE
IKE_SA's PRF has a fixed key size because the output of the PRF may SA's PRF has a fixed key size because the output of the PRF may not
not be of the correct size." because it is no longer relevant. be of the correct size." because it is no longer relevant.
D.4. Changes from draft -01 to draft -02 D.4. Changes from draft -01 to draft -02
Many grammatical fixes. Many grammatical fixes.
In Section 1.2, reworded Clarif-4.3 to be clearer. In Section 1.2, reworded Clarif-4.3 to be clearer.
In Section 1.3.3, reworded 3.10.1-16393 and Clarif-5.4 to remove In Section 1.3.3, reworded 3.10.1-16393 and Clarif-5.4 to remove
redundant text. redundant text.
skipping to change at page 125, line 20 skipping to change at page 126, line 29
In Section 2.14, removed the "half and half" description and replaced In Section 2.14, removed the "half and half" description and replaced
it with exceptions for RFC4434 and RFC4615. it with exceptions for RFC4434 and RFC4615.
Removed the now-redundant "All PRFs used with IKEv2 MUST take Removed the now-redundant "All PRFs used with IKEv2 MUST take
variable-sized keys" from Section 2.15. variable-sized keys" from Section 2.15.
In Section 2.15, added "(IKE_SA_INIT response)" after "of the second In Section 2.15, added "(IKE_SA_INIT response)" after "of the second
message" and "(IKE_SA_INIT request)" after "the first message". message" and "(IKE_SA_INIT request)" after "the first message".
In Section 2.17, simplified because there are no more bundles. "A In Section 2.17, simplified because there are no more bundles. "A
single CHILD_SA negotiation may result in multiple security single Child SA negotiation may result in multiple security
associations. ESP and AH SAs exist in pairs (one in each associations. ESP and AH SAs exist in pairs (one in each
direction)." becomes "For ESP and AH, a single CHILD_SA negotiation direction)." becomes "For ESP and AH, a single Child SA negotiation
results in two security associations (one in each direction)." results in two security associations (one in each direction)."
In section 3.3, made the example of combinations of algorithms and In section 3.3, made the example of combinations of algorithms and
the contents of the first proposal clearer. the contents of the first proposal clearer.
Added Clarif-4.4 to the ned of Section 3.3.2. Added Clarif-4.4 to the end of Section 3.3.2.
Reordered Section 3.3.5 and added Clarif-7.11. Reordered Section 3.3.5 and added Clarif-7.11.
Clarified Section 3.3.6 about choosing a single proposal. Also added Clarified Section 3.3.6 about choosing a single proposal. Also added
second paragraph about transforms not understood, and clarified third second paragraph about transforms not understood, and clarified third
paragraph about picking D-H groups. paragraph about picking D-H groups.
Moved 3.10.1-16392 from Section 3.6 to 3.7. Moved 3.10.1-16392 from Section 3.6 to 3.7.
In Section 3.10, clarified 3.10.1-16394. In Section 3.10, clarified 3.10.1-16394.
skipping to change at page 126, line 11 skipping to change at page 127, line 21
In Section 1.3, changed "If the responder rejects the Diffie-Hellman In Section 1.3, changed "If the responder rejects the Diffie-Hellman
group of the KEi payload, the responder MUST reject the request and group of the KEi payload, the responder MUST reject the request and
indicate its preferred Diffie-Hellman group in the INVALID_KE_PAYLOAD indicate its preferred Diffie-Hellman group in the INVALID_KE_PAYLOAD
Notification payload." to "If the responder selects a proposal using Notification payload." to "If the responder selects a proposal using
a different Diffie-Hellman group (other than NONE), the responder a different Diffie-Hellman group (other than NONE), the responder
MUST reject the request and indicate its preferred Diffie-Hellman MUST reject the request and indicate its preferred Diffie-Hellman
group in the INVALID_KE_PAYLOAD Notification payload. group in the INVALID_KE_PAYLOAD Notification payload.
In Section 2.3, added the last two paragraphs covering why you In Section 2.3, added the last two paragraphs covering why you
initiator's SPI and/or IP to differentiate if this is a "half-open" initiator's SPI and/or IP to differentiate if this is a "half-open"
IKE_SA or a new request. Also removed similar text from Section 2.2. IKE SA or a new request. Also removed similar text from Section 2.2.
In Section 2.5, added "Payloads sent in IKE response messages MUST In Section 2.5, added "Payloads sent in IKE response messages MUST
NOT have the critical flag set. Note that the critical flag applies NOT have the critical flag set. Note that the critical flag applies
only to the payload type, not the contents. If the payload type is only to the payload type, not the contents. If the payload type is
recognized, but the payload contains something which is not (such as recognized, but the payload contains something which is not (such as
an unknown transform inside an SA payload, or an unknown Notify an unknown transform inside an SA payload, or an unknown Notify
Message Type inside a Notify payload), the critical flag is ignored." Message Type inside a Notify payload), the critical flag is ignored."
In Section 2.6, moved the text about {{ 3.10.1-16390 }} later in the In Section 2.6, moved the text about {{ 3.10.1-16390 }} later in the
section. Also reworded the text to make it clearer what the COOKIE section. Also reworded the text to make it clearer what the COOKIE
skipping to change at page 126, line 38 skipping to change at page 127, line 48
In Section 2.17, change the description of the keying material from In Section 2.17, change the description of the keying material from
the list with two bullets to a clearer list. the list with two bullets to a clearer list.
In Section 2.23, added "Implementations MUST process received UDP- In Section 2.23, added "Implementations MUST process received UDP-
encapsulated ESP packets even when no NAT was detected." encapsulated ESP packets even when no NAT was detected."
In Section 3.3, changed "Each proposal may contain a" to "Each In Section 3.3, changed "Each proposal may contain a" to "Each
proposal contains a". proposal contains a".
Added the asterisks to the tranform type table in Section 3.3.2 and Added the asterisks to the transform type table in Section 3.3.2 and
the types table in 3.3.3 to foreshadow future developments. the types table in 3.3.3 to foreshadow future developments.
In Section 3.3.2, changed the following algorithms to (UNSPECIFIED) In Section 3.3.2, changed the following algorithms to (UNSPECIFIED)
because the RFCs listed didn't really specify how to implement them because the RFCs listed didn't really specify how to implement them
in an interoperable fashion: in an interoperable fashion:
Encryption Algorithms Encryption Algorithms
ENCR_DES_IV64 1 (RFC1827) ENCR_DES_IV64 1 (RFC1827)
ENCR_3IDEA 8 (RFC2451) ENCR_3IDEA 8 (RFC2451)
ENCR_DES_IV32 9 ENCR_DES_IV32 9
skipping to change at page 127, line 50 skipping to change at page 129, line 4
In Section 1, clarified that RFC 4306 already replaced IKEv1, and In Section 1, clarified that RFC 4306 already replaced IKEv1, and
that this document replaces RFC 4306. Also fixed Section 2.5 for that this document replaces RFC 4306. Also fixed Section 2.5 for
similar issue. Also updated the Abstract to cover this. similar issue. Also updated the Abstract to cover this.
In Section 2.15, in the responder's signed octets, changed: In Section 2.15, in the responder's signed octets, changed:
RestOfRespIDPayload = IDType | RESERVED | InitIDData RestOfRespIDPayload = IDType | RESERVED | InitIDData
to to
RestOfRespIDPayload = IDType | RESERVED | RespIDData RestOfRespIDPayload = IDType | RESERVED | RespIDData
In 2.16, changed "strong" back to "public key signature based" to In 2.16, changed "strong" back to "public key signature based" to
make it the same as 4306. make it the same as 4306.
In section 3.10, added "and the field must be empty" to make it clear In section 3.10, added "and the field must be empty" to make it clear
that a zero-length SPI is really empty. that a zero-length SPI is really empty.
D.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to
draft-ietf-ipsecme-ikev2bis-01
Throughout, changed "IKE_SA" to "IKE SA", and changed "CHILD_SA" to
"Child SA" (except left "CREATE_CHILD_SA" alone).
Added the middle sentence in the Abstract to say what IKE actually
does.
Added in section 1 "(unless there is failure setting up the AH or ESP
Child SA, in which case the IKE SA is still established without IPsec
SA)".
Clarified the titles of 1.1.1, 1.1.2, and 1.1.3.
In 1.1.2, changed "If there is an inner IP header, the inner
addresses will be the same as the outer addresses." because we are
talking about transport mode here.
Added reference to section 2.14 to setion 1.2 and 1.3.
In 1.2, clarified what is and isn't encrypted in a message.
Added the following to 1.2: "If the IDr proposed by the initiator is
not acceptable to the responder, the responder might use some other
IDr to finish the exchange. If the initiator then does not accept
that fact that responder used different IDr than the one that was
requested, the initiator can close the SA after noticing the fact."
Moved the paragraph beginning "All messages following..." from 1.3 up
to 1.2, and reworded it to apply to all the cases it covers.
At the end of section 1.3.1, clarified that the responder is the one
who controls whether non-first-fragments will be sent, and reworded
the paragraph.
In section 1.3.3, added "The Protocol ID field of the REKEY_SA
notification is set to match the protocol of the SA we are rekeying,
for example, 3 for ESP and 2 for AH." [Issue #10]
In 1.3.2, added "of the SA payload" to "New initiator and responder
SPIs are supplied in the SPI fields."
In 1.3.3, fixed the art.
<-- HDR, SK {SA, Nr, [KEr],
Si, TSr}
becomes
<-- HDR, SK {SA, Nr, [KEr],
TSi, TSr}
In 1.4 and 2.18, changed "replaced for the purpose of rekeying" to
"rekeyed".
Split out the SA deletion material from section 1.4 into its own
subsection, 1.4.1.
Clarified which bits are set at the end of Section 1.5.
In 1.7, added "That is, the version number is *not* changed from RFC
4306.".
In 2.1, added wording about retransmissions needing to be identical.
In 2.2, added "or rekeyed" to "In the unlikely event that Message IDs
grow too large to fit in 32 bits, the IKE SA MUST be closed"
In 2.2, moved the sentence "Rekeying an IKE SA resets the sequence
numbers." up higher so it would be more likely to be seen. [Issue
#15]
Moved the definition of "original initiator" from 2.8 into 2.2
because that is where it is first used.
In 2.4, added "fresh (i.e., not retransmitted)" to "If a
cryptographically protected message has been received from the other
side recently". Also added the sentence saying that liveness checks
are sometimes call dead peer detection.
Removed the question to implementers about payload order in 2.5.
Changed the title of 2.6 to "IKE SA SPIs and Cookies". Also, in the
paragraph that describes how to implement the responder, changed the
lower-case "should" to "can" to emphasize that this is a choice.
Added the second paragraph in 2.6 to make it clear that the SPI is
used for mapping.
In section 2.6, upgraded "needs to choose them so as to be unique
identifiers of an IKE_SA" to a MUST.
Added sentences at the end of 2.6 eplaining wny the initiator should
limit the number of responses it sends out.
In 2.6.1, added the example of the shorter exchange; this is copied
from RFC 4718 but was dropped in early drafts of this document.
Added the paragraph to 2.7 that describes needing two proposals if
you are having both normal ciphers and combined-mode ciphers. [Issue
#20].
In section 2.8, added "Note that, when rekeying, the new Child SA MAY
have different traffic selectors and algorithms than the old one."
Added a note in 2.9 that PFKEY applies only to IKEv1. Also added
that unknown traffic selector types are not returned in narrowed
responses.
Added note in the first paragraph of Setion 2.9.1 about decorrelated
policies preventing the problem mentioned.
In 2.12, removed "In particular, it MUST forget the secrets used in
the Diffie-Hellman calculation and any state that may persist in the
state of a pseudo-random number generator that could be used to
recompute the Diffie-Hellman secrets."
In 2.15, noted that the retry could happen multiple times for
different reasons.
In section 2.16, changed "This shared key generated during an IKE
exchange" to "This key".
At the end of 2.19, added statement that FAILED_CP_REQUIRED is not
fatal to the IKE SA.
Added the reference to ROHCV2 to the end of 2.22.
In 2.23, changed "can negotiate" to "will use". for UDP
encapsulation. Added "or 4500" to "...MUST be sent from and to UDP
port 500". Also removed the text about why not to do NAT-traversal
over port 500 because we later say you can't do that anyway. [Issue
#27] Also removed the last paragraph, which obliquely pointed to
MOBIKE. More will be added later on MOBIKE.
In 3.1, removed "and orderings of messages" from "Exchange type".
[Issue #29]
In 3.1, added "This bit changes to reflect who initiated the last
rekey of the IKE SA." to the description of the Initiator bit.
In 3.3, added a long example of why you might use a Proposal
structure because of combined-mode algorithms. [Issue #42]
In 3.3.2, changed "is unnecessary because the last Proposal could be
identified from the length of the SA" to "is unnecessary because the
last transform could be identified from the length of the proposal."
Added reference to AEAD to 3.3.2 and 3.3.3.
Added the reference to RFC 2104 back for PRF_HMAC_TIGER in 3.3.2.
[Issue #33]
Added note at the bottom of 3.3.2 to see the IANA registry.
In 3.3.4, removed all the "this could happen in the future" stuff
because it already happened.
Added a reference to email address internationalization to 3.5,
making the address binary (not ASCII).
In the table in 3.6, made "Authority Revocation List (ARL) 8" and
"X.509 Certificate - Attribute 10" unspecified.
In 3.7, changed the last sentence of the first paragraph to eliminate
the non-protocol SHOULD.
In 3.13.1, added "(including protocol 0)" for the start port and end
port.
In 3.14, updated the discussion of initialization modes to reflect
that it is only about CBC, and that other specs have to specify their
own IVs.
In 3.15.1, added a pointer to 3.15.3. In the entries for
INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET, added a pointer to
3.15.2.
In 3.15.4, added "The IKE SA is still created even if the initial
Child SA cannot be created because of this failure."
Changed "EAP exchange" to "EAP authentication" in 5.
Removed "In particular, these exponents MUST NOT be derived from
long-lived secrets like the seed to a pseudo-random generator that is
not erased after use." from section 5 because it is not possible in
most implementations to do so.
Updated a bunch of reference to their newer versions.
Added "[V+]" to the end of the exchanges in C.4 and C.5.
Added two more response templates to Appendix C.1. Added another
response template in Appendix C.2. Added two more responses in
Appendix C.4.
Authors' Addresses Authors' Addresses
Charlie Kaufman Charlie Kaufman
Microsoft Microsoft
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
US US
Phone: 1-425-707-3335 Phone: 1-425-707-3335
Email: charliek@microsoft.com Email: charliek@microsoft.com
 End of changes. 258 change blocks. 
555 lines changed or deleted 860 lines changed or added

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