draft-ietf-ipsecme-ikev2bis-03.txt   draft-ietf-ipsecme-ikev2bis-04.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: October 26, 2009 Check Point Expires: January 9, 2010 Check Point
P. Eronen P. Eronen
Nokia Nokia
April 24, 2009 July 8, 2009
Internet Key Exchange Protocol: IKEv2 Internet Key Exchange Protocol: IKEv2
draft-ietf-ipsecme-ikev2bis-03 draft-ietf-ipsecme-ikev2bis-04
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 47 skipping to change at page 1, line 47
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 26, 2009. This Internet-Draft will expire on January 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
skipping to change at page 3, line 9 skipping to change at page 3, line 9
This document describes version 2 of the Internet Key Exchange (IKE) This document describes version 2 of the Internet Key Exchange (IKE)
protocol. IKE is a component of IPsec used for performing mutual protocol. IKE is a component of IPsec used for performing mutual
authentication and establishing and maintaining security associations authentication and establishing and maintaining security associations
(SAs). It replaces and updates RFC 4306, and includes all of the (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 . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 7 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 7
1.1.1. Security Gateway to Security Gateway Tunnel Mode . . 7 1.1.1. Security Gateway to Security Gateway Tunnel Mode . . 8
1.1.2. Endpoint-to-Endpoint Transport Mode . . . . . . . . . 8 1.1.2. Endpoint-to-Endpoint Transport Mode . . . . . . . . . 8
1.1.3. Endpoint to Security Gateway Tunnel Mode . . . . . . 9 1.1.3. Endpoint to Security Gateway Tunnel Mode . . . . . . 9
1.1.4. Other Scenarios . . . . . . . . . . . . . . . . . . . 9 1.1.4. Other Scenarios . . . . . . . . . . . . . . . . . . . 10
1.2. The Initial Exchanges . . . . . . . . . . . . . . . . . . 10 1.2. The Initial Exchanges . . . . . . . . . . . . . . . . . . 10
1.3. The CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 13 1.3. The CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 13
1.3.1. Creating New Child SAs with the CREATE_CHILD_SA 1.3.1. Creating New Child SAs with the CREATE_CHILD_SA
Exchange . . . . . . . . . . . . . . . . . . . . . . 14 Exchange . . . . . . . . . . . . . . . . . . . . . . 14
1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange . 16 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange . 15
1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA
Exchange . . . . . . . . . . . . . . . . . . . . . . 16 Exchange . . . . . . . . . . . . . . . . . . . . . . 16
1.4. The INFORMATIONAL Exchange . . . . . . . . . . . . . . . 17 1.4. The INFORMATIONAL Exchange . . . . . . . . . . . . . . . 17
1.4.1. Deleting an SA with INFORMATIONAL Exchanges . . . . . 18 1.4.1. Deleting an SA with INFORMATIONAL Exchanges . . . . . 17
1.5. Informational Messages outside of an IKE SA . . . . . . . 18 1.5. Informational Messages outside of an IKE SA . . . . . . . 18
1.6. Requirements Terminology . . . . . . . . . . . . . . . . 19 1.6. Requirements Terminology . . . . . . . . . . . . . . . . 19
1.7. Differences Between RFC 4306 and This Document . . . . . 20 1.7. Differences Between RFC 4306 and This Document . . . . . 19
2. IKE Protocol Details and Variations . . . . . . . . . . . . . 21 2. IKE Protocol Details and Variations . . . . . . . . . . . . . 21
2.1. Use of Retransmission Timers . . . . . . . . . . . . . . 22 2.1. Use of Retransmission Timers . . . . . . . . . . . . . . 21
2.2. Use of Sequence Numbers for Message ID . . . . . . . . . 23 2.2. Use of Sequence Numbers for Message ID . . . . . . . . . 23
2.3. Window Size for Overlapping Requests . . . . . . . . . . 24 2.3. Window Size for Overlapping Requests . . . . . . . . . . 23
2.4. State Synchronization and Connection Timeouts . . . . . . 25 2.4. State Synchronization and Connection Timeouts . . . . . . 25
2.5. Version Numbers and Forward Compatibility . . . . . . . . 27 2.5. Version Numbers and Forward Compatibility . . . . . . . . 27
2.6. IKE SA SPIs and Cookies . . . . . . . . . . . . . . . . . 29 2.6. IKE SA SPIs and Cookies . . . . . . . . . . . . . . . . . 28
2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . 32 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . 31
2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 32 2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 32
2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 34 2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 33
2.8.1. Simultaneous Child SA rekeying . . . . . . . . . . . 36 2.8.1. Simultaneous Child SA rekeying . . . . . . . . . . . 35
2.8.2. Simultaneous IKE SA Rekeying . . . . . . . . . . . . 38 2.8.2. Simultaneous IKE SA Rekeying . . . . . . . . . . . . 37
2.8.3. Rekeying the IKE SA Versus Reauthentication . . . . . 39 2.8.3. Rekeying the IKE SA Versus Reauthentication . . . . . 38
2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 39 2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 39
2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 42 2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 41
2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.11. Address and Port Agility . . . . . . . . . . . . . . . . 43 2.11. Address and Port Agility . . . . . . . . . . . . . . . . 42
2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 43 2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 43
2.13. Generating Keying Material . . . . . . . . . . . . . . . 44 2.13. Generating Keying Material . . . . . . . . . . . . . . . 43
2.14. Generating Keying Material for the IKE SA . . . . . . . . 45 2.14. Generating Keying Material for the IKE SA . . . . . . . . 45
2.15. Authentication of the IKE SA . . . . . . . . . . . . . . 46 2.15. Authentication of the IKE SA . . . . . . . . . . . . . . 45
2.16. Extensible Authentication Protocol Methods . . . . . . . 48 2.16. Extensible Authentication Protocol Methods . . . . . . . 47
2.17. Generating Keying Material for Child SAs . . . . . . . . 50 2.17. Generating Keying Material for Child SAs . . . . . . . . 49
2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange . . . . 51 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange . . . . 50
2.19. Requesting an Internal Address on a Remote Network . . . 52 2.19. Requesting an Internal Address on a Remote Network . . . 51
2.19.1. Configuration Payloads . . . . . . . . . . . . . . . 53 2.19.1. Configuration Payloads . . . . . . . . . . . . . . . 53
2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 55 2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 54
2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 55 2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 55
2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 56 2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 58 2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 57
2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 61 2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 61
3. Header and Payload Formats . . . . . . . . . . . . . . . . . 62 3. Header and Payload Formats . . . . . . . . . . . . . . . . . 61
3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 62 3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 61
3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 65 3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 64
3.3. Security Association Payload . . . . . . . . . . . . . . 67 3.3. Security Association Payload . . . . . . . . . . . . . . 66
3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 69 3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 68
3.3.2. Transform Substructure . . . . . . . . . . . . . . . 71 3.3.2. Transform Substructure . . . . . . . . . . . . . . . 70
3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 74 3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 73
3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 74 3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 73
3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 75 3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 74
3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 77 3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 76
3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 78 3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 77
3.5. Identification Payloads . . . . . . . . . . . . . . . . . 79 3.5. Identification Payloads . . . . . . . . . . . . . . . . . 78
3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 81 3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 80
3.7. Certificate Request Payload . . . . . . . . . . . . . . . 83 3.7. Certificate Request Payload . . . . . . . . . . . . . . . 82
3.8. Authentication Payload . . . . . . . . . . . . . . . . . 85 3.8. Authentication Payload . . . . . . . . . . . . . . . . . 84
3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 87 3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 85
3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 87 3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 86
3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 88 3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 87
3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 91 3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 90
3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 93 3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 92
3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 94 3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 93
3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 95 3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 94
3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 97 3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 96
3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 99 3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 98
3.15.1. Configuration Attributes . . . . . . . . . . . . . . 100 3.15.1. Configuration Attributes . . . . . . . . . . . . . . 99
3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 103 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 102
3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 105 3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 104
3.15.4. Address Assignment Failures . . . . . . . . . . . . . 106 3.15.4. Address Assignment Failures . . . . . . . . . . . . . 104
3.16. Extensible Authentication Protocol (EAP) Payload . . . . 106 3.16. Extensible Authentication Protocol (EAP) Payload . . . . 105
4. Conformance Requirements . . . . . . . . . . . . . . . . . . 108 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 107
5. Security Considerations . . . . . . . . . . . . . . . . . . . 110 5. Security Considerations . . . . . . . . . . . . . . . . . . . 109
5.1. Traffic selector authorization . . . . . . . . . . . . . 113 5.1. Traffic selector authorization . . . . . . . . . . . . . 112
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 114 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 113
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 114 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 113
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 115 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 114
8.1. Normative References . . . . . . . . . . . . . . . . . . 115 8.1. Normative References . . . . . . . . . . . . . . . . . . 114
8.2. Informative References . . . . . . . . . . . . . . . . . 116 8.2. Informative References . . . . . . . . . . . . . . . . . 115
Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 120 Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 119
Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 121 Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 120
B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 122 B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 120
B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 122 B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 121
Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 122 Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 121
C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 123 C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 122
C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 124 C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 123
C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 125 C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 124
C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying
Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 126 Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 125
C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA . . . . 126 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA . . . . 125
C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 126 C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 125
Appendix D. Significant Changes from RFC 4306 . . . . . . . . . 126 Appendix D. Significant Changes from RFC 4306 . . . . . . . . . 125
Appendix E. Changes Between Internet Draft Versions . . . . . . 127 Appendix E. Changes Between Internet Draft Versions . . . . . . 126
E.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 127 E.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 126
E.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 127 E.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 126
E.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 129 E.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 128
E.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 130 E.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 129
E.5. Changes from draft -02 to draft -03 . . . . . . . . . . . 131 E.5. Changes from draft -02 to draft -03 . . . . . . . . . . . 130
E.6. Changes from draft -03 to E.6. Changes from draft -03 to
draft-ietf-ipsecme-ikev2bis-00 . . . . . . . . . . . . . 132 draft-ietf-ipsecme-ikev2bis-00 . . . . . . . . . . . . . 131
E.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to E.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to
draft-ietf-ipsecme-ikev2bis-01 . . . . . . . . . . . . . 133 draft-ietf-ipsecme-ikev2bis-01 . . . . . . . . . . . . . 132
E.8. Changes from draft-ietf-ipsecme-ikev2bis-01 to E.8. Changes from draft-ietf-ipsecme-ikev2bis-01 to
draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 137 draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 136
E.9. Changes from draft-ietf-ipsecme-ikev2bis-01 to E.9. Changes from draft-ietf-ipsecme-ikev2bis-01 to
draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 139 draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 138
E.10. Changes from draft-ietf-ipsecme-ikev2bis-02 to E.10. Changes from draft-ietf-ipsecme-ikev2bis-02 to
draft-ietf-ipsecme-ikev2bis-03 . . . . . . . . . . . . . 140 draft-ietf-ipsecme-ikev2bis-03 . . . . . . . . . . . . . 139
E.11. Changes from draft-ietf-ipsecme-ikev2bis-03 to
draft-ietf-ipsecme-ikev2bis-04 . . . . . . . . . . . . . 139
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 140 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 140
1. Introduction 1. Introduction
{{ An introduction to the differences between RFC 4306 [IKEV2] and {{ An introduction to the differences between RFC 4306 [IKEV2] and
this document is given at the end of Section 1. It is put there this document is given at the end of Section 1. It is put there
(instead of here) to preserve the section numbering of RFC 4306. }} (instead of here) to preserve the section numbering of RFC 4306. }}
IP Security (IPsec) provides confidentiality, data integrity, access IP Security (IPsec) provides confidentiality, data integrity, access
control, and data source authentication to IP datagrams. These control, and data source authentication to IP datagrams. These
skipping to change at page 6, line 26 skipping to change at page 6, line 26
cryptographic algorithms will be used to provide the services, and cryptographic algorithms will be used to provide the services, and
the keys used as input to the cryptographic algorithms. the keys used as input to the cryptographic algorithms.
Establishing this shared state in a manual fashion does not scale Establishing this shared state in a manual fashion does not scale
well. Therefore, a protocol to establish this state dynamically is well. Therefore, a protocol to establish this state dynamically is
needed. This memo describes such a protocol -- the Internet Key needed. This memo describes such a protocol -- the Internet Key
Exchange (IKE). Version 1 of IKE was defined in RFCs 2407 [DOI], Exchange (IKE). Version 1 of IKE was defined in RFCs 2407 [DOI],
2408 [ISAKMP], and 2409 [IKEV1]. IKEv2 replaced all of those RFCs. 2408 [ISAKMP], and 2409 [IKEV1]. IKEv2 replaced all of those RFCs.
IKEv2 was defined in [IKEV2] (RFC 4306) and was clarified in [Clarif] IKEv2 was defined in [IKEV2] (RFC 4306) and was clarified in [Clarif]
(RFC 4718). This document replaces and updates RFC 4306 and RFC (RFC 4718). This document replaces and updates RFC 4306 and RFC
4718. 4718. IKEv2 was a change to the IKE protocol that was not backward
compatible. In contrast, the current document not only provides a
clarification of IKEv2, but makes minimum changes to the IKE
protocol.
IKE performs mutual authentication between two parties and IKE performs mutual authentication between two parties and
establishes an IKE security association (SA) that includes shared establishes an IKE security association (SA) that includes shared
secret information that can be used to efficiently establish SAs for secret information that can be used to efficiently establish SAs for
Encapsulating Security Payload (ESP) [ESP] or Authentication Header Encapsulating Security Payload (ESP) [ESP] or Authentication Header
(AH) [AH] and a set of cryptographic algorithms to be used by the SAs (AH) [AH] and a set of cryptographic algorithms to be used by the SAs
to protect the traffic that they carry. In this document, the term to protect the traffic that they carry. In this document, the term
"suite" or "cryptographic suite" refers to a complete set of "suite" or "cryptographic suite" refers to a complete set of
algorithms used to protect an SA. An initiator proposes one or more algorithms used to protect an SA. An initiator proposes one or more
suites by listing supported algorithms that can be combined into suites by listing supported algorithms that can be combined into
skipping to change at page 9, line 26 skipping to change at page 9, line 28
In this scenario, a protected endpoint (typically a portable roaming In this scenario, a protected endpoint (typically a portable roaming
computer) connects back to its corporate network through an IPsec- computer) connects back to its corporate network through an IPsec-
protected tunnel. It might use this tunnel only to access protected tunnel. It might use this tunnel only to access
information on the corporate network, or it might tunnel all of its information on the corporate network, or it might tunnel all of its
traffic back through the corporate network in order to take advantage traffic back through the corporate network in order to take advantage
of protection provided by a corporate firewall against Internet-based of protection provided by a corporate firewall against Internet-based
attacks. In either case, the protected endpoint will want an IP attacks. In either case, the protected endpoint will want an IP
address associated with the security gateway so that packets returned address associated with the security gateway so that packets returned
to it will go to the security gateway and be tunneled back. This IP to it will go to the security gateway and be tunneled back. This IP
address may be static or may be dynamically allocated by the security address may be static or may be dynamically allocated by the security
gateway. {{ Clarif-6.1 }} In support of the latter case, IKEv2 gateway. In support of the latter case, IKEv2 includes a mechanism
includes a mechanism (namely, configuration payloads) for the (namely, configuration payloads) for the initiator to request an IP
initiator to request an IP address owned by the security gateway for address owned by the security gateway for use for the duration of its
use for the duration of its SA. SA.
In this scenario, packets will use tunnel mode. On each packet from In this scenario, packets will use tunnel mode. On each packet from
the protected endpoint, the outer IP header will contain the source the protected endpoint, the outer IP header will contain the source
IP address associated with its current location (i.e., the address IP address associated with its current location (i.e., the address
that will get traffic routed to the endpoint directly), while the that will get traffic routed to the endpoint directly), while the
inner IP header will contain the source IP address assigned by the inner IP header will contain the source IP address assigned by the
security gateway (i.e., the address that will get traffic routed to security gateway (i.e., the address that will get traffic routed to
the security gateway for forwarding to the endpoint). The outer the security gateway for forwarding to the endpoint). The outer
destination address will always be that of the security gateway, destination address will always be that of the security gateway,
while the inner destination address will be the ultimate destination while the inner destination address will be the ultimate destination
skipping to change at page 10, line 29 skipping to change at page 10, line 35
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. (See Section 2.14 for information on the messages are authenticated. (See Section 2.14 for information on
how the encyrption keys are generated.) how the encryption keys are generated.)
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 the IKE_SA_INIT exchange. These subsequent messages use the the the IKE_SA_INIT exchange. These subsequent messages use the
syntax of the Encrypted Payload described in Section 3.14, encrypted syntax of the Encrypted Payload described in Section 3.14, encrypted
with keys that are derived as described in Section 2.14. All with keys that are derived as described in Section 2.14. All
subsequent messages include an Encrypted Payload, even if they are subsequent messages include an Encrypted Payload, even if they are
referred to in the text as "empty". For the CREATE_CHILD_SA, referred to in the text as "empty". For the CREATE_CHILD_SA,
IKE_AUTH, or IKE_INFORMATIONAL exchanges, the message following the IKE_AUTH, or IKE_INFORMATIONAL exchanges, the message following the
header is encrypted and the message including the header is integrity header is encrypted and the message including the header is integrity
skipping to change at page 13, line 5 skipping to change at page 13, line 5
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 If creating the Child SA during the IKE_AUTH exchange fails for some
fails for some reason, the IKE SA is still created as usual. The reason, the IKE SA is still created as usual. The list of responses
list of responses in the IKE_AUTH exchange that do not prevent an IKE in the IKE_AUTH exchange that do not prevent an IKE SA from being set
SA from being set up include at least the following: up include at least the following: NO_PROPOSAL_CHOSEN,
NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, and
INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED. FAILED_CP_REQUIRED.
{{ Clarif-4.3 }} Note that IKE_AUTH messages do not contain KEi/KEr Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads.
or Ni/Nr payloads. Thus, the SA payloads in the IKE_AUTH exchange Thus, the SA payloads in the IKE_AUTH exchange cannot contain
cannot contain Transform Type 4 (Diffie-Hellman Group) with any value Transform Type 4 (Diffie-Hellman Group) with any value other than
other than NONE. Implementations SHOULD omit the whole transform NONE. Implementations SHOULD omit the whole transform substructure
substructure instead of sending value NONE. 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
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
skipping to change at page 14, line 20 skipping to change at page 14, line 16
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. There are two octets of
are two octets of data associated with this notification: the data associated with this notification: the accepted D-H Group number
accepted D-H Group number in big endian order. In the case of such a in big endian order. In the case of such a rejection, the
rejection, the CREATE_CHILD_SA exchange fails, and the initiator will CREATE_CHILD_SA exchange fails, and the initiator will probably retry
probably retry the exchange with a Diffie-Hellman proposal and KEi in the exchange with a Diffie-Hellman proposal and KEi in the group that
the group that the responder gave in the INVALID_KE_PAYLOAD. the responder gave in the INVALID_KE_PAYLOAD.
{{ 3.10.1-35 }} The responder sends a NO_ADDITIONAL_SAS notification The responder sends a NO_ADDITIONAL_SAS notification to indicate that
to indicate that a CREATE_CHILD_SA request is unacceptable because a CREATE_CHILD_SA request is unacceptable because the responder is
the responder is unwilling to accept any more Child SAs on this IKE unwilling to accept any more Child SAs on this IKE SA. Some minimal
SA. Some minimal implementations may only accept a single Child SA implementations may only accept a single Child SA setup in the
setup in the context of an initial IKE exchange and reject any context of an initial IKE exchange and reject any subsequent attempts
subsequent attempts to add more. 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} -->
skipping to change at page 15, line 4 skipping to change at page 14, line 49
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 The USE_TRANSPORT_MODE notification MAY be included in a request
included in a request message that also includes an SA payload message that also includes an SA payload requesting a Child SA. It
requesting a Child SA. It requests that the Child SA use transport requests that the Child SA use transport mode rather than tunnel mode
mode rather than tunnel mode for the SA created. If the request is for the SA created. If the request is accepted, the response MUST
accepted, the response MUST also include a notification of type also include a notification of type USE_TRANSPORT_MODE. If the
USE_TRANSPORT_MODE. If the responder declines the request, the Child responder declines the request, the Child SA will be established in
SA will be established in tunnel mode. If this is unacceptable to tunnel mode. If this is unacceptable to the initiator, the initiator
the initiator, the initiator MUST delete the SA. Note: Except when MUST delete the SA. Note: Except when using this option to negotiate
using this option to negotiate transport mode, all Child SAs will use transport mode, all Child SAs will use tunnel mode.
tunnel mode.
{{ 3.10.1-16394 }} The ESP_TFC_PADDING_NOT_SUPPORTED notification The ESP_TFC_PADDING_NOT_SUPPORTED notification asserts that the
asserts that the sending endpoint will NOT accept packets that sending endpoint will NOT accept packets that contain Traffic Flow
contain Traffic Flow Confidentiality (TFC) padding over the Child SA Confidentiality (TFC) padding over the Child SA being negotiated. If
being negotiated. {{ Clarif-4.5 }} If neither endpoint accepts TFC neither endpoint accepts TFC padding, this notification is included
padding, this notification is included in both the request and the in both the request and the response. If this notification is
response. If this notification is included in only one of the included in only one of the messages, TFC padding can still be sent
messages, TFC padding can still be sent in the other direction. in the other direction.
{{ 3.10.1-16395 }} The NON_FIRST_FRAGMENTS_ALSO notification is used The NON_FIRST_FRAGMENTS_ALSO notification is used for fragmentation
for fragmentation control. See [IPSECARCH] for a fuller explanation. control. See [IPSECARCH] for a fuller explanation. Both parties
{{ Clarif-4.6 }} Both parties need to agree to sending non-first need to agree to sending non-first fragments before either party does
fragments before either party does so. It is enabled only if so. It is enabled only if NON_FIRST_FRAGMENTS_ALSO notification is
NON_FIRST_FRAGMENTS_ALSO notification is included in both the request included in both the request proposing an SA and the response
proposing an SA and the response accepting it. If the responder does accepting it. If the responder does not want to send or receive non-
not want to send or receive non-first fragments, it only omits first fragments, it only omits NON_FIRST_FRAGMENTS_ALSO notification
NON_FIRST_FRAGMENTS_ALSO notification from its response, but does not from its response, but does not reject the whole Child SA creation.
reject the whole Child SA creation.
Failure of an attempt to create a CHILD SA SHOULD NOT tear down the Failure of an attempt to create a CHILD SA SHOULD NOT tear down the
IKE SA: there is no reason to lose the work done to set up the IKE IKE SA: there is no reason to lose the work done to set up the IKE
SA. When an IKE SA is not created, the error message return SHOULD SA. When an IKE SA is not created, the error message return SHOULD
NOT be encrypted because the other party will not be able to NOT be encrypted because the other party will not be able to
authenticate that message. [[ Note: this text may be changed in the authenticate that message. [[ Note: this text may be changed in the
future. ]] future. ]]
1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange
skipping to change at page 16, line 48 skipping to change at page 16, line 39
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 The REKEY_SA notification MUST be included in a CREATE_CHILD_SA
CREATE_CHILD_SA exchange if the purpose of the exchange is to replace exchange if the purpose of the exchange is to replace an existing ESP
an existing ESP or AH SA. {{ Clarif-5.4 }} The SA being rekeyed is or AH SA. The SA being rekeyed is identified by the SPI field in the
identified by the SPI field in the Notify payload; this is the SPI Notify payload; this is the SPI the exchange initiator would expect
the exchange initiator would expect in inbound ESP or AH packets. in inbound ESP or AH packets. There is no data associated with this
Notify type. The Protocol ID field of the REKEY_SA notification is
There is no data associated with this Notify type. The Protocol ID set to match the protocol of the SA we are rekeying, for example, 3
field of the REKEY_SA notification is set to match the protocol of for ESP and 2 for AH.
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],
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.
1.4. The INFORMATIONAL Exchange 1.4. The INFORMATIONAL Exchange
skipping to change at page 18, line 11 skipping to change at page 17, line 50
HDR, SK {[N,] [D,] HDR, SK {[N,] [D,]
[CP,] ...} --> [CP,] ...} -->
<-- HDR, SK {[N,] [D,] <-- HDR, SK {[N,] [D,]
[CP], ...} [CP], ...}
The processing of an INFORMATIONAL exchange is determined by its The processing of an INFORMATIONAL exchange is determined by its
component payloads. component payloads.
1.4.1. Deleting an SA with INFORMATIONAL Exchanges 1.4.1. Deleting an SA with INFORMATIONAL Exchanges
{{ Clarif-5.6 }} ESP and AH SAs always exist in pairs, with one SA in ESP and AH SAs always exist in pairs, with one SA in each direction.
each direction. When an SA is closed, both members of the pair MUST When an SA is closed, both members of the pair MUST be closed (that
be closed (that is, deleted). Each endpoint MUST close its incoming is, deleted). Each endpoint MUST close its incoming SAs and allow
SAs and allow the other endpoint to close the other SA in each pair. the other endpoint to close the other SA in each pair. To delete an
To delete an SA, an INFORMATIONAL exchange with one or more delete SA, an INFORMATIONAL exchange with one or more delete payloads is
payloads is sent listing the SPIs (as they would be expected in the sent listing the SPIs (as they would be expected in the headers of
headers of inbound packets) of the SAs to be deleted. The recipient inbound packets) of the SAs to be deleted. The recipient MUST close
MUST close the designated SAs. {{ Clarif-5.7 }} Note that one never the designated SAs. Note that one never sends delete payloads for
sends delete payloads for the two sides of an SA in a single message. the two sides of an SA in a single message. If there are many SAs to
If there are many SAs to delete at the same time, one includes delete delete at the same time, one includes delete payloads for the inbound
payloads for the inbound half of each SA pair in your Informational 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
responses MUST NOT include delete payloads for the deleted SAs, since responses MUST NOT include delete payloads for the deleted SAs, since
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 Half-closed ESP or AH connections are anomalous, and a node with
anomalous, and a node with auditing capability should probably audit auditing capability should probably audit their existence if they
their existence if they persist. Note that this specification persist. Note that this specification nowhere specifies time
nowhere specifies time periods, so it is up to individual endpoints periods, so it is up to individual endpoints to decide how long to
to decide how long to wait. A node MAY refuse to accept incoming wait. A node MAY refuse to accept incoming data on half-closed
data on half-closed connections but MUST NOT unilaterally close them connections but MUST NOT unilaterally close them and reuse the SPIs.
and reuse the SPIs. If connection state becomes sufficiently messed If connection state becomes sufficiently messed up, a node MAY close
up, a node MAY close the IKE SA; doing so will implicitly close all the IKE SA; doing so will implicitly close all SAs negotiated under
SAs negotiated under it. It can then rebuild the SAs it needs on a it. It can then rebuild the SAs it needs on a clean base under a new
clean base under a new IKE SA. {{ Clarif-5.8 }} The response to a IKE SA. The response to a request that deletes the IKE SA is an
request that deletes the IKE SA is an empty Informational response. empty Informational response.
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 The INVALID_SPI notification MAY be sent in an IKE INFORMATIONAL
INFORMATIONAL exchange when a node receives an ESP or AH packet with exchange when a node receives an ESP or AH packet with an invalid
an invalid SPI. The Notification Data contains the SPI of the SPI. The Notification Data contains the SPI of the invalid packet.
invalid packet. This usually indicates a node has rebooted and This usually indicates a node has rebooted and forgotten an SA. If
forgotten an SA. If this Informational Message is sent outside the this Informational Message is sent outside the context of an IKE SA,
context of an IKE SA, it should only be used by the recipient as a it should only be used by the recipient as a "hint" that something
"hint" that something might be wrong (because it could easily be might be wrong (because it could easily be forged). The recipient of
forged). this notification cannot tell whether the SPI is for AH or ESP, but
this is not important because the SPIs are supposed to be different
for the two.
{{ Clarif-7.7 }} There are two cases when such a one-way notification There are two cases when such a one-way notification is sent:
is sent: INVALID_IKE_SPI and INVALID_SPI. These notifications are INVALID_IKE_SPI and INVALID_SPI. These notifications are sent
sent outside of an IKE SA. Note that such notifications are outside of an IKE SA. Note that such notifications are explicitly
explicitly not Informational exchanges; these are one-way messages not Informational exchanges; these are one-way messages that must not
that must not be responded to. be responded to. (INVALID_MAJOR_VERSION is also a one-way message
which is sent outside of an IKE SA, although it is sent as a response
to the incoming IKE SA creation.)
In case of INVALID_IKE_SPI, the message sent is a response message, In case of INVALID_IKE_SPI, the message sent is a response message,
and thus it is sent to the IP address and port from whence it came and thus it is sent to the IP address and port from whence it came
with the same IKE SPIs and the Message ID is copied. The Response with the same IKE SPIs and the Message ID is copied. The Response
bit is set to 1, and the version flags are set in the normal fashion. bit is set to 1, and the version flags are set in the normal fashion.
For a one-way INVALID_IKE_SPI notification for an unrecognized SPI, For a one-way INVALID_IKE_SPI notification for an unrecognized SPI,
the responder SHOULD copy the Exchange Type from the request. the responder SHOULD copy the Exchange Type from the request.
In case of INVALID_SPI, however, there are no IKE SPI values that In case of INVALID_SPI, however, there are no IKE SPI values that
would be meaningful to the recipient of such a notification. Using would be meaningful to the recipient of such a notification. Using
zero values or random values are both acceptable. The Initiator flag 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 is set, the Response bit is set to 0, and the version flags are set
in the normal fashion. 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]. It should be noted
should be noted that parts of IKEv2 rely on some of the processing that parts of IKEv2 rely on some of the processing rules in
rules in [IPSECARCH], as described in various sections of this [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
"MAY" that appear in this document are to be interpreted as described "MAY" that appear in this document are to be interpreted as described
in [MUSTSHOULD]. in [MUSTSHOULD].
1.7. Differences Between RFC 4306 and This Document 1.7. Differences Between RFC 4306 and This Document
{{ Added this entire section, including this recursive remark. }} {{ Added this entire section, including this recursive remark. }}
This document contains clarifications and amplifications to IKEv2 This document contains clarifications and amplifications to IKEv2
skipping to change at page 20, line 39 skipping to change at page 20, line 32
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 document. 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
braces {{ such as this }} point out changes from IKEv2. Changes that
come from [Clarif] are marked with the section from that document,
such as "{{ Clarif-2.10 }}". Changes that come from moving
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 "{{
3.10.1-16384 }}".
This document removes discussion of nesting AH and ESP. This was a This document removes discussion of nesting AH and ESP. This was a
mistake in RFC 4306 caused by the lag between finishing RFC 4306 and mistake in RFC 4306 caused by the lag between finishing RFC 4306 and
RFC 4301. Basically, IKEv2 is based on RFC 4301, which does not RFC 4301. Basically, IKEv2 is based on RFC 4301, which does not
include "SA bundles" that were part of RFC 2401. While a single include "SA bundles" that were part of RFC 2401. While a single
packet can go through IPsec processing multiple times, each of these packet can go through IPsec processing multiple times, each of these
passes uses a separate SA, and the passes are coordinated by the passes uses a separate SA, and the passes are coordinated by the
forwarding tables. In IKEv2, each of these SAs has to be created forwarding tables. In IKEv2, each of these SAs has to be created
using a separate CREATE_CHILD_SA exchange. using a separate CREATE_CHILD_SA exchange.
This document removes discussion of the INTERNAL_ADDRESS_EXPIRY This document removes discussion of the INTERNAL_ADDRESS_EXPIRY
configuration attribute because its implementation was very configuration attribute because its implementation was very
problematic. Implementations that conform to this document MUST problematic. Implementations that conform to this document MUST
ignore proposals that have configuration attribute type 5, the old ignore proposals that have configuration attribute type 5, the old
value for INTERNAL_ADDRESS_EXPIRY. value for INTERNAL_ADDRESS_EXPIRY.
This document adds the restriction in Section 2.13 that all PRFs used This document adds the restriction in Section 2.13 that all PRFs used
with IKEv2 MUST take variable-sized keys. This should not affect any with IKEv2 MUST take variable-sized keys. This should not affect any
implementations because there were no standardized PRFs that have implementations because there were no standardized PRFs that have
fixed-size keys. fixed-size keys.
A later version of this document may have all the {{ }} comments
removed from the body of the document and instead appear in an
appendix.
2. IKE Protocol Details and Variations 2. IKE Protocol Details and Variations
IKE normally listens and sends on UDP port 500, though IKE messages IKE normally listens and sends on UDP port 500, though IKE messages
may also be received on UDP port 4500 with a slightly different may also be received on UDP port 4500 with a slightly different
format (see Section 2.23). Since UDP is a datagram (unreliable) format (see Section 2.23). Since UDP is a datagram (unreliable)
protocol, IKE includes in its definition recovery from transmission protocol, IKE includes in its definition recovery from transmission
errors, including packet loss, packet replay, and packet forgery. errors, including packet loss, packet replay, and packet forgery.
IKE is designed to function so long as (1) at least one of a series IKE is designed to function so long as (1) at least one of a series
of retransmitted packets reaches its destination before timing out; of retransmitted packets reaches its destination before timing out;
and (2) the channel is not so full of forged and replayed packets so and (2) the channel is not so full of forged and replayed packets so
skipping to change at page 21, line 50 skipping to change at page 21, line 32
fragmenting large messages. IP defines a mechanism for fragmentation fragmenting large messages. IP defines a mechanism for fragmentation
of oversize UDP messages, but implementations vary in the maximum of oversize UDP messages, but implementations vary in the maximum
message size supported. Furthermore, use of IP fragmentation opens message size supported. Furthermore, use of IP fragmentation opens
an implementation to denial of service attacks [DOSUDPPROT]. an implementation to denial of service attacks [DOSUDPPROT].
Finally, some NAT and/or firewall implementations may block IP Finally, some NAT and/or firewall implementations may block IP
fragments. fragments.
All IKEv2 implementations MUST be able to send, receive, and process All IKEv2 implementations MUST be able to send, receive, and process
IKE messages that are up to 1280 octets long, and they SHOULD be able IKE messages that are up to 1280 octets long, and they SHOULD be able
to send, receive, and process messages that are up to 3000 octets to send, receive, and process messages that are up to 3000 octets
long. {{ Demoted the SHOULD }} IKEv2 implementations need to be aware long. IKEv2 implementations need to be aware of the maximum UDP
of the maximum UDP message size supported and MAY shorten messages by message size supported and MAY shorten messages by leaving out some
leaving out some certificates or cryptographic suite proposals if certificates or cryptographic suite proposals if that will keep
that will keep messages below the maximum. Use of the "Hash and URL" messages below the maximum. Use of the "Hash and URL" formats rather
formats rather than including certificates in exchanges where than including certificates in exchanges where possible can avoid
possible can avoid most problems. {{ Demoted the SHOULD }} most problems. Implementations and configuration need to keep in
Implementations and configuration need to keep in mind, however, that mind, however, that if the URL lookups are possible only after the
if the URL lookups are possible only after the IPsec SA is IPsec SA is established, recursion issues could prevent this
established, recursion issues could prevent this technique from technique from working.
working.
{{ Clarif-7.5 }} The UDP payload of all packets containing IKE The UDP payload of all packets containing IKE messages sent on port
messages sent on port 4500 MUST begin with the prefix of four zeros; 4500 MUST begin with the prefix of four zeros; otherwise, the
otherwise, the receiver won't know how to handle them. 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
skipping to change at page 23, line 7 skipping to change at page 22, line 34
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. A retransmission from the initiator negotiated using that IKE SA. A retransmission from the initiator
MUST be bitwise identical to the original request. That is, MUST be bitwise identical to the original request. That is,
everything starting from the IKE Header (the IKE SA Initiator's SPI everything starting from the IKE Header (the IKE SA Initiator's SPI
onwards) must be bitwise identical; items before it (such as the IP 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 and UDP headers, and the zero non-ESP marker) do not have to be
identical. identical.
{{ Clarif-2.3 }} Retransmissions of the IKE_SA_INIT request require Retransmissions of the IKE_SA_INIT request require some special
some special handling. When a responder receives an IKE_SA_INIT handling. When a responder receives an IKE_SA_INIT request, it has
request, it has to determine whether the packet is a retransmission to determine whether the packet is a retransmission belonging to an
belonging to an existing "half-open" IKE SA (in which case the existing "half-open" IKE SA (in which case the responder retransmits
responder retransmits the same response), or a new request (in which the same response), or a new request (in which case the responder
case the responder creates a new IKE SA and sends a fresh response), creates a new IKE SA and sends a fresh response), or it belongs to an
or it belongs to an existing IKE SA where the IKE_AUTH request has existing IKE SA where the IKE_AUTH request has been already received
been already received (in which case the responder ignores it). (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), and incremented for
and incremented for each subsequent exchange. Rekeying an IKE SA each subsequent exchange. The Message ID is reset to zero in the new
resets the sequence numbers. Thus, the first pair of IKE_AUTH IKE SA after the IKE SA is rekeyed. Rekeying an IKE SA resets the
messages will have ID of 1, the second (when EAP is used) will be 2, sequence numbers. Thus, the first pair of IKE_AUTH messages will
and so on. {{ Clarif-3.10 }} have ID of 1, the second (when EAP is used) will be 2, and so on.
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 Throughout this document, "initiator" refers to the party who
party who initiated the exchange being described, and "original initiated the exchange being described, and "original initiator"
initiator" refers to the party who initiated the whole IKE SA. The refers to the party who initiated the whole IKE SA. The "original
"original initiator" always refers to the party who initiated the initiator" always refers to the party who initiated the exchange
exchange which resulted in the current IKE SA. In other words, if which resulted in the current IKE SA. In other words, if the
the "original responder" starts rekeying the IKE SA, that party "original responder" starts rekeying the IKE SA, that party becomes
becomes the "original initiator" of the new IKE SA. the "original initiator" of the new IKE SA.
Note that Message IDs are cryptographically protected and provide Note that Message IDs are cryptographically protected and provide
protection against message replays. In the unlikely event that protection against message replays. In the unlikely event that
Message IDs grow too large to fit in 32 bits, the IKE SA MUST be Message IDs grow too large to fit in 32 bits, the IKE SA MUST be
closed or rekeyed. closed or rekeyed.
2.3. Window Size for Overlapping Requests 2.3. Window Size for Overlapping Requests
{{ 3.10.1-16385 }} The SET_WINDOW_SIZE notification asserts that the The SET_WINDOW_SIZE notification asserts that the sending endpoint is
sending endpoint is capable of keeping state for multiple outstanding capable of keeping state for multiple outstanding exchanges,
exchanges, permitting the recipient to send multiple requests before permitting the recipient to send multiple requests before getting a
getting a response to the first. The data associated with a response to the first. The data associated with a SET_WINDOW_SIZE
SET_WINDOW_SIZE notification MUST be 4 octets long and contain the notification MUST be 4 octets long and contain the big endian
big endian representation of the number of messages the sender representation of the number of messages the sender promises to keep.
promises to keep. The window size is always one until the initial The window size is always one until the initial exchanges complete.
exchanges complete.
An IKE endpoint MUST wait for a response to each of its messages An IKE endpoint MUST wait for a response to each of its messages
before sending a subsequent message unless it has received a before sending a subsequent message unless it has received a
SET_WINDOW_SIZE Notify message from its peer informing it that the SET_WINDOW_SIZE Notify message from its peer informing it that the
peer is prepared to maintain state for multiple outstanding messages peer is prepared to maintain state for multiple outstanding messages
in order to allow greater throughput. in order to allow greater throughput.
After an IKE SA is set up, in order to maximize IKE throughput, an After an IKE SA is set up, in order to maximize IKE throughput, an
IKE endpoint MAY issue multiple requests before getting a response to IKE endpoint MAY issue multiple requests before getting a response to
any of them, up to the limit set by its peer's SET_WINDOW_SIZE. any of them, up to the limit set by its peer's SET_WINDOW_SIZE.
These requests may pass one another over the network. An IKE These requests may pass one another over the network. An IKE
endpoint MUST be prepared to accept and process a request while it endpoint MUST be prepared to accept and process a request while it
has a request outstanding in order to avoid a deadlock in this has a request outstanding in order to avoid a deadlock in this
situation. {{ Downgraded the SHOULD }} An IKE endpoint may also situation. An IKE endpoint may also accept and process multiple
accept and process multiple requests while it has a request requests while it has a request outstanding.
outstanding.
An IKE endpoint MUST NOT exceed the peer's stated window size for An IKE endpoint MUST NOT exceed the peer's stated window size for
transmitted IKE requests. In other words, if the responder stated transmitted IKE requests. In other words, if the responder stated
its window size is N, then when the initiator needs to make a request its window size is N, then when the initiator needs to make a request
X, it MUST wait until it has received responses to all requests up X, it MUST wait until it has received responses to all requests up
through request X-N. An IKE endpoint MUST keep a copy of (or be able through request X-N. An IKE endpoint MUST keep a copy of (or be able
to regenerate exactly) each request it has sent until it receives the to regenerate exactly) each request it has sent until it receives the
corresponding response. An IKE endpoint MUST keep a copy of (or be corresponding response. An IKE endpoint MUST keep a copy of (or be
able to regenerate exactly) the number of previous responses equal to able to regenerate exactly) the number of previous responses equal to
its declared window size in case its response was lost and the its declared window size in case its response was lost and the
initiator requests its retransmission by retransmitting the request. initiator requests its retransmission by retransmitting the request.
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 The window size is normally a (possibly configurable) property of a
configurable) property of a particular implementation, and is not particular implementation, and is not related to congestion control
related to congestion control (unlike the window size in TCP, for (unlike the window size in TCP, for example). In particular, it is
example). In particular, it is not defined what the responder should not defined what the responder should do when it receives a
do when it receives a SET_WINDOW_SIZE notification containing a SET_WINDOW_SIZE notification containing a smaller value than is
smaller value than is currently in effect. Thus, there is currently currently in effect. Thus, there is currently no way to reduce the
no way to reduce the window size of an existing IKE SA; you can only window size of an existing IKE SA; you can only increase it. When
increase it. When rekeying an IKE SA, the new IKE SA starts with rekeying an IKE SA, the new IKE SA starts with window size 1 until it
window size 1 until it is explicitly increased by sending a new is explicitly increased by sending a new SET_WINDOW_SIZE
SET_WINDOW_SIZE notification. notification.
{{ 3.10.1-9 }}The INVALID_MESSAGE_ID notification is sent when an IKE The INVALID_MESSAGE_ID notification is sent when an IKE message ID
message ID outside the supported window is received. This Notify outside the supported window is received. This Notify MUST NOT be
MUST NOT be sent in a response; the invalid request MUST NOT be sent in a response; the invalid request MUST NOT be acknowledged.
acknowledged. Instead, inform the other side by initiating an
INFORMATIONAL exchange with Notification data containing the four Instead, inform the other side by initiating an INFORMATIONAL
octet invalid message ID. Sending this notification is optional, and exchange with Notification data containing the four octet invalid
notifications of this type MUST be rate limited. message ID. Sending this notification is optional, and 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 The INITIAL_CONTACT notification asserts that this IKE SA is the only
IKE SA is the only IKE SA currently active between the authenticated IKE SA currently active between the authenticated identities. It MAY
identities. It MAY be sent when an IKE SA is established after a be sent when an IKE SA is established after a crash, and the
crash, and the recipient MAY use this information to delete any other recipient MAY use this information to delete any other IKE SAs it has
IKE SAs it has to the same authenticated identity without waiting for to the same authenticated identity without waiting for a timeout.
a timeout. This notification MUST NOT be sent by an entity that may This notification MUST NOT be sent by an entity that may be
be replicated (e.g., a roaming user's credentials where the user is 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). The INITIAL_CONTACT notification, if sent, MUST
if sent, MUST be in the first IKE_AUTH request or response, not as a be in the first IKE_AUTH request or response, not as a separate
separate exchange afterwards; however, receiving parties MAY ignore exchange afterwards; however, receiving parties MAY ignore it in
it in other messages. other messages.
Since IKE is designed to operate in spite of Denial of Service (DoS) Since IKE is designed to operate in spite of Denial of Service (DoS)
attacks from the network, an endpoint MUST NOT conclude that the attacks from the network, an endpoint MUST NOT conclude that the
other endpoint has failed based on any routing information (e.g., other endpoint has failed based on any routing information (e.g.,
ICMP messages) or IKE messages that arrive without cryptographic ICMP messages) or IKE messages that arrive without cryptographic
protection (e.g., Notify messages complaining about unknown SPIs). protection (e.g., Notify messages complaining about unknown SPIs).
An endpoint MUST conclude that the other endpoint has failed only An endpoint MUST conclude that the other endpoint has failed only
when repeated attempts to contact it have gone unanswered for a when repeated attempts to contact it have gone unanswered for a
timeout period or when a cryptographically protected INITIAL_CONTACT timeout period or when a cryptographically protected INITIAL_CONTACT
notification is received on a different IKE SA to the same notification is received on a different IKE SA to the same
authenticated identity. {{ Demoted the SHOULD }} An endpoint should authenticated identity. An endpoint should suspect that the other
suspect that the other endpoint has failed based on routing endpoint has failed based on routing information and initiate a
information and initiate a request to see whether the other endpoint request to see whether the other endpoint is alive. To check whether
is alive. To check whether the other side is alive, IKE specifies an the other side is alive, IKE specifies an empty INFORMATIONAL message
empty INFORMATIONAL message that (like all IKE requests) requires an that (like all IKE requests) requires an acknowledgement (note that
acknowledgement (note that within the context of an IKE SA, an within the context of an IKE SA, an "empty" message consists of an
"empty" message consists of an IKE header followed by an Encrypted IKE header followed by an Encrypted payload that contains no
payload that contains no payloads). If a cryptographically protected payloads). If a cryptographically protected (fresh, i.e. not
(fresh, i.e. not retransmitted) message has been received from the retransmitted) message has been received from the other side
other side recently, unprotected notifications MAY be ignored. recently, unprotected notifications MAY be ignored. Implementations
Implementations MUST limit the rate at which they take actions based MUST limit the rate at which they take actions based on unprotected
on unprotected messages. 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
skipping to change at page 27, line 24 skipping to change at page 27, line 4
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
associated Child SAs. In this case, an IKE endpoint SHOULD send a Closing the IKE SA implicitly closes all associated Child SAs. In
Delete payload indicating that it has closed the IKE SA unless the this case, an IKE endpoint SHOULD send a Delete payload indicating
other endpoint is no longer responding. that it has closed the IKE SA unless the 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. This document is a
relationship to RFC 4306 }} This document is a replacement for replacement for [IKEV2]. It is likely that some implementations will
[IKEV2]. It is likely that some implementations will want to support want to support version 1.0 and version 2.0, and in the future, other
version 1.0 and version 2.0, and in the future, other versions. versions.
The major version number should be incremented only if the packet The major version number should be incremented only if the packet
formats or required actions have changed so dramatically that an formats or required actions have changed so dramatically that an
older version node would not be able to interoperate with a newer older version node would not be able to interoperate with a newer
version node if it simply ignored the fields it did not understand version node if it simply ignored the fields it did not understand
and took the actions specified in the older specification. The minor and took the actions specified in the older specification. The minor
version number indicates new capabilities, and MUST be ignored by a version number indicates new capabilities, and MUST be ignored by a
node with a smaller minor version number, but used for informational node with a smaller minor version number, but used for informational
purposes by the node with the larger minor version number. For purposes by the node with the larger minor version number. For
example, it might indicate the ability to process a newly defined example, it might indicate the ability to process a newly defined
notification message. The node with the larger minor version number notification message. The node with the larger minor version number
would simply note that its correspondent would not be able to would simply note that its correspondent would not be able to
understand that message and therefore would not send it. understand that message and therefore would not send it.
{{ 3.10.1-5 }} If an endpoint receives a message with a higher major If an endpoint receives a message with a higher major version number,
version number, it MUST drop the message and SHOULD send an it MUST drop the message and SHOULD send an unauthenticated
unauthenticated notification message of type INVALID_MAJOR_VERSION notification message of type INVALID_MAJOR_VERSION containing the
containing the highest (closest) version number it supports. If an highest (closest) version number it supports. If an endpoint
endpoint supports major version n, and major version m, it MUST supports major version n, and major version m, it MUST support all
support all versions between n and m. If it receives a message with versions between n and m. If it receives a message with a major
a major version that it supports, it MUST respond with that version version that it supports, it MUST respond with that version number.
number. In order to prevent two nodes from being tricked into In order to prevent two nodes from being tricked into corresponding
corresponding with a lower major version number than the maximum that with a lower major version number than the maximum that they both
they both support, IKE has a flag that indicates that the node is support, IKE has a flag that indicates that the node is capable of
capable of speaking a higher major version number. speaking a higher major version number.
Thus, the major version number in the IKE header indicates the Thus, the major version number in the IKE header indicates the
version number of the message, not the highest version number that version number of the message, not the highest version number that
the transmitter supports. If the initiator is capable of speaking the transmitter supports. If the initiator is capable of speaking
versions n, n+1, and n+2, and the responder is capable of speaking versions n, n+1, and n+2, and the responder is capable of speaking
versions n and n+1, then they will negotiate speaking n+1, where the versions n and n+1, then they will negotiate speaking n+1, where the
initiator will set a flag indicating its ability to speak a higher initiator will set a flag indicating its ability to speak a higher
version. If they mistakenly (perhaps through an active attacker version. If they mistakenly (perhaps through an active attacker
sending error messages) negotiate to version n, then both will notice sending error messages) negotiate to version n, then both will notice
that the other side can support a higher version number, and they that the other side can support a higher version number, and they
MUST break the connection and reconnect using version n+1. MUST break the connection and reconnect using version n+1.
Note that IKEv1 does not follow these rules, because there is no way Note that IKEv1 does not follow these rules, because there is no way
in v1 of noting that you are capable of speaking a higher version in v1 of noting that you are capable of speaking a higher version
number. So an active attacker can trick two v2-capable nodes into number. So an active attacker can trick two v2-capable nodes into
speaking v1. {{ Demoted the SHOULD }} When a v2-capable node speaking v1. When a v2-capable node negotiates down to v1, it should
negotiates down to v1, it should note that fact in its logs. note that fact in its logs.
Also for forward compatibility, all fields marked RESERVED MUST be Also for forward compatibility, all fields marked RESERVED MUST be
set to zero by an implementation running version 2.0, and their set to zero by an implementation running version 2.0, and their
content MUST be ignored by an implementation running version 2.0 ("Be content MUST be ignored by an implementation running version 2.0 ("Be
conservative in what you send and liberal in what you receive"). In conservative in what you send and liberal in what you receive"). In
this way, future versions of the protocol can use those fields in a this way, future versions of the protocol can use those fields in a
way that is guaranteed to be ignored by implementations that do not way that is guaranteed to be ignored by implementations that do not
understand them. Similarly, payload types that are not defined are understand them. Similarly, payload types that are not defined are
reserved for future use; implementations of a version where they are reserved for future use; implementations of a version where they are
undefined MUST skip over those payloads and ignore their contents. undefined MUST skip over those payloads and ignore their contents.
IKEv2 adds a "critical" flag to each payload header for further IKEv2 adds a "critical" flag to each payload header for further
flexibility for forward compatibility. If the critical flag is set flexibility for forward compatibility. If the critical flag is set
and the payload type is unrecognized, the message MUST be rejected and the payload type is unrecognized, the message MUST be rejected
and the response to the IKE request containing that payload MUST and the response to the IKE request containing that payload MUST
include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an
unsupported critical payload was included. {{ 3.10.1-1 }} In that unsupported critical payload was included. In that Notify payload,
Notify payload, the notification data contains the one-octet payload the notification data contains the one-octet payload type. If the
type. If the critical flag is not set and the payload type is critical flag is not set and the payload type is unsupported, that
unsupported, that payload MUST be ignored. Payloads sent in IKE payload MUST be ignored. Payloads sent in IKE response messages MUST
response messages MUST NOT have the critical flag set. Note that the NOT have the critical flag set. Note that the critical flag applies
critical flag applies only to the payload type, not the contents. If only to the payload type, not the contents. If the payload type is
the payload type is recognized, but the payload contains something recognized, but the payload contains something which is not (such as
which is not (such as an unknown transform inside an SA payload, or an unknown transform inside an SA payload, or an unknown Notify
an unknown Notify Message Type inside a Notify payload), the critical Message Type inside a Notify payload), the critical flag is ignored.
flag is ignored.
{{ Demoted the SHOULD in the second clause }}Although new payload Although new payload types may be added in the future and may appear
types may be added in the future and may appear interleaved with the interleaved with the fields defined in this specification,
fields defined in this specification, implementations MUST send the implementations SHOULD send the payloads defined in this
payloads defined in this specification in the order shown in the specification in the order shown in the figures in Section 2;
figures in Section 2; implementations are explicitly allowed to implementations MUST NOT reject as invalid a message with those
reject as invalid a message with those payloads in any other order. payloads in any other order.
2.6. IKE SA SPIs and 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
skipping to change at page 30, line 7 skipping to change at page 29, line 33
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. The data associated with this notification MUST
notification MUST be between 1 and 64 octets in length (inclusive), be between 1 and 64 octets in length (inclusive), and its generation
and its generation is described later in this section. If the is described later in this section. If the IKE_SA_INIT response
IKE_SA_INIT response includes the COOKIE notification, the initiator includes the COOKIE notification, the initiator MUST then retry the
MUST then retry the IKE_SA_INIT request, and include the COOKIE IKE_SA_INIT request, and include the COOKIE notification containing
notification containing the received data as the first payload, and the received data as the first payload, and all other payloads
all other payloads unchanged. The initial exchange will then be as unchanged. The initial exchange will then be as follows:
follows:
Initiator Responder Initiator Responder
------------------------------------------------------------------- -------------------------------------------------------------------
HDR(A,0), SAi1, KEi, Ni --> HDR(A,0), SAi1, KEi, Ni -->
<-- HDR(A,0), N(COOKIE) <-- HDR(A,0), N(COOKIE)
HDR(A,0), N(COOKIE), SAi1, HDR(A,0), N(COOKIE), SAi1,
KEi, Ni --> KEi, Ni -->
<-- HDR(A,B), SAr1, KEr, <-- HDR(A,B), SAr1, KEr,
Nr, [CERTREQ] Nr, [CERTREQ]
HDR(A,B), SK {IDi, [CERT,] HDR(A,B), SK {IDi, [CERT,]
skipping to change at page 30, line 37 skipping to change at page 30, 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 can implement its An IKE implementation can implement its responder cookie generation
responder cookie generation in such a way as to not require any saved in such a way as to not require any saved state to recognize its
state to recognize its valid cookie when the second IKE_SA_INIT valid cookie when the second IKE_SA_INIT message arrives. The exact
message arrives. The exact algorithms and syntax they use to algorithms and syntax they use to generate cookies do not affect
generate cookies do not affect interoperability and hence are not interoperability and hence are not specified here. The following is
specified here. The following is an example of how an endpoint could an example of how an endpoint could use cookies to implement limited
use cookies to implement limited DOS protection. 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
skipping to change at page 31, line 24 skipping to change at page 31, line 13
initiating many IKE_SA_INIT exchanges all with different initiator initiating many IKE_SA_INIT exchanges all with different initiator
SPIs (and perhaps port numbers) so that the responder thinks that SPIs (and perhaps port numbers) so that the responder thinks that
there are lots of machines behind one NAT box who are all trying to there are lots of machines behind one NAT box who are all trying to
connect. connect.
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. The
the SHOULD NOT }} The responder should not accept cookies responder should not accept cookies indefinitely after <secret> is
indefinitely after <secret> is changed, since that would defeat part changed, since that would defeat part of the denial of service
of the denial of service protection. {{ Demoted the SHOULD }} The protection. The responder should change the value of <secret>
responder should change the value of <secret> frequently, especially frequently, especially if under attack.
if under attack.
{{ Clarif-2.1 }} In addition to cookies, there are several cases In addition to cookies, there are several cases where the IKE_SA_INIT
where the IKE_SA_INIT exchange does not result in the creation of an exchange does not result in the creation of an IKE SA (such as
IKE SA (such as INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). In such a INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). In such a case, sending a
case, sending a zero value for the Responder's SPI is correct. If zero value for the Responder's SPI is correct. If the responder
the responder sends a non-zero responder SPI, the initiator should sends a non-zero responder SPI, the initiator should not reject the
not reject the response for only that reason. response for only that reason.
{{ Clarif-2.5 }} When one party receives an IKE_SA_INIT request When one party receives an IKE_SA_INIT request containing a cookie
containing a cookie whose contents do not match the value expected, whose contents do not match the value expected, that party MUST
that party MUST ignore the cookie and process the message as if no ignore the cookie and process the message as if no cookie had been
cookie had been included; usually this means sending a response included; usually this means sending a response containing a new
containing a new cookie. The initiator should limit the number of cookie. The initiator should limit the number of cookie exchanges it
cookie exchanges it tries before giving up. An attacker can forge tries before giving up. An attacker can forge multiple cookie
multiple cookie responses to the initiator's IKE_SA_INIT message, and responses to the initiator's IKE_SA_INIT message, and each of those
each of those forged cookie reply will trigger two packets: one forged cookie reply will trigger two packets: one packet from the
packet from the initiator to the responder (which will reject those initiator to the responder (which will reject those cookies), and one
cookies), and one reply from responder to initiator that includes the reply from responder to initiator that includes the correct cookie.
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 }}
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
retry of the IKE_SA_INIT request, or in all subsequent retries as retry of the IKE_SA_INIT request, or in all subsequent retries as
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
skipping to change at page 32, line 45 skipping to change at page 32, line 27
Implementations SHOULD support this shorter exchange, but MUST NOT Implementations SHOULD support this shorter exchange, but MUST NOT
fail if other implementations do not support this shorter exchange. 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. Each proposal
Each proposal includes one protocol. Each protocol contains one or includes one protocol. Each protocol contains one or more transforms
more transforms -- each specifying a cryptographic algorithm. Each -- each specifying a cryptographic algorithm. Each transform
transform contains zero or more attributes (attributes are needed contains zero or more attributes (attributes are needed only if the
only if the transform identifier does not completely specify the transform identifier does not completely specify the cryptographic
cryptographic algorithm). algorithm).
This hierarchical structure was designed to efficiently encode This hierarchical structure was designed to efficiently encode
proposals for cryptographic suites when the number of supported proposals for cryptographic suites when the number of supported
suites is large because multiple values are acceptable for multiple suites is large because multiple values are acceptable for multiple
transforms. The responder MUST choose a single suite, which may be transforms. The responder MUST choose a single suite, which may be
any subset of the SA proposal following the rules below: any subset of the SA proposal following the rules below:
{{ Clarif-7.13 }} Each proposal contains one protocol. If a proposal Each proposal contains one protocol. If a proposal is accepted, the
is accepted, the SA response MUST contain the same protocol. The SA response MUST contain the same protocol. The responder MUST
responder MUST accept a single proposal or reject them all and return accept a single proposal or reject them all and return an error. The
an error. {{ 3.10.1-14 }} The error is given in a notification of error is given in a notification of type NO_PROPOSAL_CHOSEN.
type NO_PROPOSAL_CHOSEN.
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.
skipping to change at page 33, line 44 skipping to change at page 33, line 26
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 When the IKE_SA_INIT exchange does not result in the creation of an
creation of an IKE SA due to INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN, IKE SA due to INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN, or COOKIE (see
or COOKIE (see Section 2.6), the responder's SPI will be zero. Section 2.6), the responder's SPI will be zero. However, if the
However, if the responder sends a non-zero responder SPI, the responder sends a non-zero responder SPI, the initiator should not
initiator should not reject the response for only that reason. reject the response for only that reason.
2.8. Rekeying 2.8. Rekeying
{{ Demoted the SHOULD }} IKE, ESP, and AH security associations use IKE, ESP, and AH security associations use secret keys that should be
secret keys that should be used only for a limited amount of time and used only for a limited amount of time and to protect a limited
to protect a limited amount of data. This limits the lifetime of the amount of data. This limits the lifetime of the entire security
entire security association. When the lifetime of a security association. When the lifetime of a security association expires,
association expires, the security association MUST NOT be used. If the security association MUST NOT be used. If there is demand, new
there is demand, new security associations MAY be established. security associations MAY be established. Reestablishment of
Reestablishment of security associations to take the place of ones security associations to take the place of ones that expire is
that expire is referred to as "rekeying". 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 IKE mechanisms described here fail, an implementation MUST close the 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 Implementations may wish to support in-place rekeying of SAs, since
rekeying of SAs, since doing so offers better performance and is doing so offers better performance and is likely to reduce the number
likely to reduce the number of packets lost during the transition. 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 IKE old IKE SA is shared using a CREATE_CHILD_SA within the existing IKE
SA. An IKE SA so created inherits all of the original IKE SA's Child SA. An IKE SA so created inherits all of the original IKE SA's Child
SAs, and the new IKE SA is used for all control messages needed to SAs, and the new IKE SA is used for all control messages needed 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. Note that, when rekeying, the new Child SA MAY have the old IKE SA. Note that, when rekeying, the new Child SA MAY have
different traffic selectors and algorithms than the old one. different traffic selectors and algorithms than the old one.
{{ Demoted the SHOULD }} SAs should be rekeyed proactively, i.e., the SAs should be rekeyed proactively, i.e., the new SA should be
new SA should be established before the old one expires and becomes established before the old one expires and becomes unusable. Enough
unusable. Enough time should elapse between the time the new SA is time should elapse between the time the new SA is established and the
established and the old one becomes unusable so that traffic can be old one becomes unusable so that traffic can be switched over to the
switched over to the new SA. 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
necessary. If the two ends have different lifetime policies, the end necessary. If the two ends have different lifetime policies, the end
with the shorter lifetime will end up always being the one to request with the shorter lifetime will end up always being the one to request
the rekeying. If an SA has been inactive for a long time and if an the rekeying. If an SA has been inactive for a long time and if an
endpoint would not initiate the SA in the absence of traffic, the endpoint would not initiate the SA in the absence of traffic, the
endpoint MAY choose to close the SA instead of rekeying it when its endpoint MAY choose to close the SA instead of rekeying it when its
lifetime expires. {{ Demoted the SHOULD }} It should do so if there lifetime expires. It should do so if there has been no traffic since
has been no traffic since the last time the SA was rekeyed. the last time the SA was rekeyed.
Note that IKEv2 deliberately allows parallel SAs with the same Note that IKEv2 deliberately allows parallel SAs with the same
traffic selectors between common endpoints. One of the purposes of traffic selectors between common endpoints. One of the purposes of
this is to support traffic quality of service (QoS) differences among this is to support traffic quality of service (QoS) differences among
the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and section 4.1 of the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and section 4.1 of
[DIFFTUNNEL]). Hence unlike IKEv1, the combination of the endpoints [DIFFTUNNEL]). Hence unlike IKEv1, the combination of the endpoints
and the traffic selectors may not uniquely identify an SA between and the traffic selectors may not uniquely identify an SA between
those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on
the basis of duplicate traffic selectors SHOULD NOT be used. the basis of duplicate traffic selectors SHOULD NOT be used.
{{ Demoted the SHOULD }} The node that initiated the surviving The node that initiated the surviving rekeyed SA should delete the
rekeyed SA should delete the replaced SA after the new one is replaced SA after the new one is established.
established.
There are timing windows -- particularly in the presence of lost There are timing windows -- particularly in the presence of lost
packets -- where endpoints may not agree on the state of an SA. The packets -- where endpoints may not agree on the state of an SA. The
responder to a CREATE_CHILD_SA MUST be prepared to accept messages on responder to a CREATE_CHILD_SA MUST be prepared to accept messages on
an SA before sending its response to the creation request, so there an SA before sending its response to the creation request, so there
is no ambiguity for the initiator. The initiator MAY begin sending is no ambiguity for the initiator. The initiator MAY begin sending
on an SA as soon as it processes the response. The initiator, on an SA as soon as it processes the response. The initiator,
however, cannot receive on a newly created SA until it receives and however, cannot receive on a newly created SA until it receives and
processes the response to its CREATE_CHILD_SA request. How, then, is processes the response to its CREATE_CHILD_SA request. How, then, is
the responder to know when it is OK to send on the newly created SA? the responder to know when it is OK to send on the newly created SA?
skipping to change at page 35, line 42 skipping to change at page 35, line 20
could result in packets unnecessarily being dropped, so an could result in packets unnecessarily being dropped, so an
implementation MAY defer such sending. implementation MAY defer such sending.
The responder can be assured that the initiator is prepared to The responder can be assured that the initiator is prepared to
receive messages on an SA if either (1) it has received a receive messages on an SA if either (1) it has received a
cryptographically valid message on the new SA, or (2) the new SA cryptographically valid message on the new SA, or (2) the new SA
rekeys an existing SA and it receives an IKE request to close the rekeys an existing SA and it receives an IKE request to close the
replaced SA. When rekeying an SA, the responder continues to send replaced SA. When rekeying an SA, the responder continues to send
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. If an
Demoted the SHOULD }} If an initiator receives a message on an SA for initiator receives a message on an SA for which it has not received a
which it has not received a response to its CREATE_CHILD_SA request, response to its CREATE_CHILD_SA request, it interprets that as a
it interprets that as a likely packet loss and retransmits the likely packet loss and retransmits the CREATE_CHILD_SA request. An
CREATE_CHILD_SA request. An initiator MAY send a dummy message on a initiator MAY send a dummy message on a newly created SA if it has no
newly created SA if it has no messages queued in order to assure the messages queued in order to assure the responder that the initiator
responder that the initiator is ready to receive messages. is ready to receive messages.
2.8.1. Simultaneous Child SA rekeying 2.8.1. Simultaneous Child SA rekeying
{{ The first two paragraphs were moved, and the rest was added, based
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).
This form of rekeying may temporarily result in multiple similar SAs This form of rekeying may temporarily result in multiple similar SAs
between the same pairs of nodes. When there are two SAs eligible to between the same pairs of nodes. When there are two SAs eligible to
receive packets, a node MUST accept incoming packets through either receive packets, a node MUST accept incoming packets through either
SA. If redundant SAs are created though such a collision, the SA SA. If redundant SAs are created though such a collision, the SA
created with the lowest of the four nonces used in the two exchanges created with the lowest of the four nonces used in the two exchanges
SHOULD be closed by the endpoint that created it. {{ Clarif-5.10 }} SHOULD be closed by the endpoint that created it. "Lowest" means an
"Lowest" means an octet-by-octet, lexicographical comparison (instead octet-by-octet, lexicographical comparison (instead of, for instance,
of, for instance, comparing the nonces as large integers). In other comparing the nonces as large integers). In other words, start by
words, start by comparing the first octet; if they're equal, move to comparing the first octet; if they're equal, move to the next octet,
the next octet, and so on. If you reach the end of one nonce, that and so on. If you reach the end of one nonce, that nonce is the
nonce is the lower one. lower one.
The following is an explanation on the impact this has on The following is an explanation on the impact this has on
implementations. Assume that hosts A and B have an existing IPsec SA implementations. Assume that hosts A and B have an existing IPsec SA
pair with SPIs (SPIa1,SPIb1), and both start rekeying it at the same pair with SPIs (SPIa1,SPIb1), and both start rekeying it at the same
time: time:
Host A Host B Host A Host B
------------------------------------------------------------------- -------------------------------------------------------------------
send req1: N(REKEY_SA,SPIa1), send req1: N(REKEY_SA,SPIa1),
SA(..,SPIa2,..),Ni1,.. --> SA(..,SPIa2,..),Ni1,.. -->
skipping to change at page 39, line 7 skipping to change at page 38, line 26
At this point, host B sees a request to close the IKE_SA. There's At this point, host B sees a request to close the IKE_SA. There's
not much more to do than to reply as usual. However, at this point not much more to do than to reply as usual. However, at this point
host B should stop retransmitting req2, since once host A receives host B should stop retransmitting req2, since once host A receives
resp3, it will delete all the state associated with the old IKE_SA resp3, it will delete all the state associated with the old IKE_SA
and will not be able to reply to it. and will not be able to reply to it.
<-- send resp3: () <-- send resp3: ()
2.8.3. Rekeying the IKE SA Versus Reauthentication 2.8.3. Rekeying the IKE SA Versus Reauthentication
{{ 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.
skipping to change at page 39, line 40 skipping to change at page 39, line 8
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 When an RFC4301-compliant IPsec subsystem receives an IP packet that
an IP packet that matches a "protect" selector in its Security Policy matches a "protect" selector in its Security Policy Database (SPD),
Database (SPD), the subsystem protects that packet with IPsec. When the subsystem protects that packet with IPsec. When no SA exists
no SA exists yet, it is the task of IKE to create it. Maintenance of yet, it is the task of IKE to create it. Maintenance of a system's
a system's SPD is outside the scope of IKE (see [PFKEY] for an SPD is outside the scope of IKE (see [PFKEY] for an example
example protocol, although it only applies to IKEv1), though some programming interface, although it only applies to IKEv1), though
implementations might update their SPD in connection with the running some implementations might update their SPD in connection with the
of IKE (for an example scenario, see Section 1.1.3). running 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
skipping to change at page 41, line 15 skipping to change at page 40, line 32
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:
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
skipping to change at page 41, line 37 skipping to change at page 41, line 6
In this example above, the responder might respond with TSi being In this example above, the responder might respond with TSi being
(192.0.1.43 - 192.0.1.43) with all ports and IP protocols. (192.0.1.43 - 192.0.1.43) with all ports and IP protocols.
o If the responder's policy does not allow it to accept the first o If the responder's policy does not allow it to accept the first
selector of TSi and TSr, the responder narrows to an acceptable selector of TSi and TSr, the responder narrows to an acceptable
subset of TSi and TSr. subset of TSi and TSr.
When narrowing is done, there may be several subsets that are When narrowing is done, there may be several subsets that are
acceptable but their union is not. In this case, the responder acceptable but their union is not. In this case, the responder
arbitrarily chooses one of them, and MAY include an arbitrarily chooses one of them, and MAY include an
ADDITIONAL_TS_POSSIBLE notification in the response. {{ 3.10.1-16386 ADDITIONAL_TS_POSSIBLE notification in the response. The
}} The ADDITIONAL_TS_POSSIBLE notification asserts that the responder ADDITIONAL_TS_POSSIBLE notification asserts that the responder
narrowed the proposed traffic selectors but that other traffic narrowed the proposed traffic selectors but that other traffic
selectors would also have been acceptable, though only in a separate selectors would also have been acceptable, though only in a separate
SA. There is no data associated with this Notify type. This case SA. There is no data associated with this Notify type. This case
will occur only when the initiator and responder are configured will occur only when the initiator and responder are configured
differently from one another. If the initiator and responder agree differently from one another. If the initiator and responder agree
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. Such misconfigurations
Such misconfigurations should be recorded in error logs. 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 The SINGLE_PAIR_REQUIRED error indicates that a CREATE_CHILD_SA
CREATE_CHILD_SA request is unacceptable because its sender is only request is unacceptable because its sender is only willing to accept
willing to accept traffic selectors specifying a single pair of traffic selectors specifying a single pair of addresses. The
addresses. The requestor is expected to respond by requesting an SA requestor is expected to respond by requesting an SA for only the
for only the specific traffic it is trying to forward. specific traffic it is trying to forward.
{{ Clarif-4.11 }} Few implementations will have policies that require Few implementations will have policies that require separate SAs for
separate SAs for each address pair. Because of this, if only some each address pair. Because of this, if only some parts of the TSi
parts of the TSi and TSr proposed by the initiator are acceptable to and TSr proposed by the initiator are acceptable to the responder,
the responder, responders SHOULD narrow the selectors to an responders SHOULD narrow the selectors to an acceptable subset rather
acceptable subset rather than use SINGLE_PAIR_REQUIRED. than use SINGLE_PAIR_REQUIRED.
2.9.1. Traffic Selectors Violating Own Policy 2.9.1. Traffic Selectors Violating Own Policy
{{ 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. If you use decorrelated followed, valid traffic may be dropped. If you use decorrelated
policies from [IPSECARCH], this kind of policy violations cannot policies from [IPSECARCH], this kind of policy violations cannot
happen. 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
skipping to change at page 43, line 21 skipping to change at page 42, line 36
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.) However, the initiator chooses the
initiator chooses the nonce before the outcome of the negotiation is nonce before the outcome of the negotiation is known. Because of
known. Because of that, the nonce has to be long enough for all the that, the nonce has to be long enough for all the PRFs being
PRFs being proposed. If the same random number source is used for proposed. If the same random number source is used for both keys and
both keys and nonces, care must be taken to ensure that the latter nonces, care must be taken to ensure that the latter use does not
use does not compromise the former. compromise the former.
2.11. Address and Port Agility 2.11. Address and Port Agility
IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and
AH associations for the same IP addresses it runs over. The IP AH associations for the same IP addresses it runs over. The IP
addresses and ports in the outer header are, however, not themselves addresses and ports in the outer header are, however, not themselves
cryptographically protected, and IKE is designed to work even through cryptographically protected, and IKE is designed to work even through
Network Address Translation (NAT) boxes. An implementation MUST Network Address Translation (NAT) boxes. An implementation MUST
accept incoming requests even if the source port is not 500 or 4500, accept incoming requests even if the source port is not 500 or 4500,
and MUST respond to the address and port from which the request was and MUST respond to the address and port from which the request was
skipping to change at page 46, line 48 skipping to change at page 46, line 15
the fixed header. Note that neither the nonce Ni nor the value the fixed header. Note that neither the nonce Ni nor the value
prf(SK_pr,IDr') are transmitted. Similarly, the initiator signs the prf(SK_pr,IDr') are transmitted. Similarly, the initiator signs the
first message (IKE_SA_INIT request), starting with the first octet of first message (IKE_SA_INIT request), starting with the first octet of
the first SPI in the header and ending with the last octet of the the first SPI in the header and ending with the last octet of the
last payload. Appended to this (for purposes of computing the last payload. Appended to this (for purposes of computing the
signature) are the responder's nonce Nr, and the value signature) are the responder's nonce Nr, and the value
prf(SK_pi,IDi'). In the above calculation, IDi' and IDr' are the prf(SK_pi,IDi'). In the above calculation, IDi' and IDr' are the
entire ID payloads excluding the fixed header. It is critical to the entire ID payloads excluding the fixed header. It is critical to the
security of the exchange that each side sign the other side's nonce. security of the exchange that each side sign the other side's nonce.
{{ Clarif-3.1 }}
The initiator's signed octets can be described as: The initiator's signed octets can be described as:
InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI
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
RealMessage1 = RealIKEHDR | RestOfMessage1 RealMessage1 = RealIKEHDR | RestOfMessage1
NonceRPayload = PayloadHeader | NonceRData NonceRPayload = PayloadHeader | NonceRData
InitiatorIDPayload = PayloadHeader | RestOfIDPayload InitiatorIDPayload = PayloadHeader | RestOfIDPayload
RestOfInitIDPayload = IDType | RESERVED | InitIDData RestOfInitIDPayload = IDType | RESERVED | InitIDData
MACedIDForI = prf(SK_pi, RestOfInitIDPayload) MACedIDForI = prf(SK_pi, RestOfInitIDPayload)
skipping to change at page 48, line 4 skipping to change at page 47, line 17
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.) The pre-
the SHOULD }} The pre-shared key needs to contain as much shared key needs to contain as much unpredictability as the strongest
unpredictability as the strongest key being negotiated. In the case key being negotiated. In the case of a pre-shared key, the AUTH
of a pre-shared key, the AUTH value is computed as: value is computed as:
For the initiator: For the initiator:
AUTH = prf( prf( Shared Secret,"Key Pad for IKEv2"), AUTH = prf( prf( Shared Secret,"Key Pad for IKEv2"),
<InitiatorSignedOctets>) <InitiatorSignedOctets>)
For the responder: For the responder:
AUTH = prf( prf( Shared Secret,"Key Pad for IKEv2"), AUTH = prf( prf( Shared Secret,"Key Pad for IKEv2"),
<ResponderSignedOctets>) <ResponderSignedOctets>)
where the string "Key Pad for IKEv2" is 17 ASCII characters without where the string "Key Pad for IKEv2" is 17 ASCII characters without
null termination. The shared secret can be variable length. The pad null termination. The shared secret can be variable length. The pad
skipping to change at page 49, line 29 skipping to change at page 48, line 41
HDR, SK {IDi, [CERTREQ,] HDR, SK {IDi, [CERTREQ,]
[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 As described in Section 2.2, when EAP is used, each pair of IKE SA
pair of IKE SA initial setup messages will have their message numbers initial setup messages will have their message numbers incremented;
incremented; the first pair of AUTH messages will have an ID of 1, the first pair of AUTH messages will have an ID of 1, the second will
the second will be 2, and so on. be 2, and so on.
For EAP methods that create a shared key as a side effect of For EAP methods that create a shared key as a side effect of
authentication, that shared key MUST be used by both the initiator authentication, that shared key MUST be used by both the initiator
and responder to generate AUTH payloads in messages 7 and 8 using the and responder to generate AUTH payloads in messages 7 and 8 using the
syntax for shared secrets specified in Section 2.15. The shared key syntax for shared secrets specified in Section 2.15. The shared key
from EAP is the field from the EAP specification named MSK. This from EAP is the field from the EAP specification named MSK. This
shared key generated during an IKE exchange MUST NOT be used for any shared key generated during an IKE exchange MUST NOT be used for any
other purpose. other purpose.
EAP methods that do not establish a shared key SHOULD NOT be used, as EAP methods that do not establish a shared key SHOULD NOT be used, as
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 The initiator of an IKE SA using EAP needs to be capable of extending
to be capable of extending the initial protocol exchange to at least the initial protocol exchange to at least ten IKE_AUTH exchanges in
ten IKE_AUTH exchanges in the event the responder sends notification the event the responder sends notification messages and/or retries
messages and/or retries the authentication prompt. Once the protocol the authentication prompt. Once the protocol exchange defined by the
exchange defined by the chosen EAP authentication method has chosen EAP authentication method has successfully terminated, the
successfully terminated, the responder MUST send an EAP payload responder MUST send an EAP payload containing the Success message.
containing the Success message. Similarly, if the authentication Similarly, if the authentication method has failed, the responder
method has failed, the responder MUST send an EAP payload containing MUST send an EAP payload containing the Failure message. The
the Failure message. The responder MAY at any time terminate the IKE responder MAY at any time terminate the IKE exchange by sending an
exchange by sending an EAP payload containing the Failure message. EAP payload containing the Failure message.
Following such an extended exchange, the EAP AUTH payloads MUST be Following such an extended exchange, the EAP AUTH payloads MUST be
included in the two messages following the one containing the EAP included in the two messages following the one containing the EAP
Success message. Success message.
{{ Clarif-3.5 }} When the initiator authentication uses EAP, it is When the initiator authentication uses EAP, it is possible that the
possible that the contents of the IDi payload is used only for AAA contents of the IDi payload is used only for AAA routing purposes and
routing purposes and selecting which EAP method to use. This value selecting which EAP method to use. This value may be different from
may be different from the identity authenticated by the EAP method. the identity authenticated by the EAP method. It is important that
It is important that policy lookups and access control decisions use policy lookups and access control decisions use the actual
the actual authenticated identity. Often the EAP server is authenticated identity. Often the EAP server is implemented in a
implemented in a separate AAA server that communicates with the IKEv2 separate AAA server that communicates with the IKEv2 responder. In
responder. In this case, the authenticated identity has to be sent this case, the authenticated identity has to be sent from the AAA
from the AAA server to the IKEv2 responder. 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
skipping to change at page 51, line 26 skipping to change at page 50, line 38
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). New initiator and responder SPIs are supplied in
are supplied in the SPI fields in the Proposal structures inside the the SPI fields in the Proposal structures inside the Security
Security Association (SA) payloads (not the SPI fields in the IKE Association (SA) payloads (not the SPI fields in the IKE header).
header). The TS payloads are omitted when rekeying an IKE SA. The TS payloads are omitted when rekeying an IKE SA. SKEYSEED for
SKEYSEED for the new IKE SA is computed using SK_d from the existing the new IKE SA is computed using SK_d from the existing IKE SA as
IKE SA as follows: 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 The old and new IKE SA may have selected a different PRF. Because
PRF. Because the rekeying exchange belongs to the old IKE SA, it is the rekeying exchange belongs to the old IKE SA, it is the old IKE
the old IKE SA's PRF that is used. SA's PRF that is used.
{{ Clarif-5.12}} The main reason for rekeying the IKE SA is to ensure The main reason for 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 MUST
implementations MUST 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 MUST NOT propose other words, an initiator MUST NOT propose the value "NONE" for the
the value "NONE" for the D-H transform, and a responder MUST NOT D-H transform, and a responder MUST NOT accept such a proposal. This
accept such a proposal. This means that a succesful exchange means that a succesful exchange rekeying the IKE SA always includes
rekeying the IKE SA always includes the KEi/KEr payloads. 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, using SPIi, SPIr, Ni, and Nr from the new
exchange.
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. Note, however, it is usual to message 3) by including a CP payload. Note, however, it is usual to
only assign one IP address during the IKE_AUTH exchange. That only assign one IP address during the IKE_AUTH exchange. That
skipping to change at page 53, line 27 skipping to change at page 52, line 37
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 The FAILED_CP_REQUIRED notification is sent by responder in the case
responder in the case where CP(CFG_REQUEST) was expected but not where CP(CFG_REQUEST) was expected but not received, and so is a
received, and so is a conflict with locally configured policy. There conflict with locally configured policy. There is no associated
is no associated data. 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. The 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 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 Child SA creation fail. The initiator can fix this by later starting
a new configuration payload request. 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. That request is done using configuration
configuration payloads, not traffic selectors. An address in a TSi payloads, not traffic selectors. An address in a TSi payload in a
payload in a response does not mean that the responder has assigned response does not mean that the responder has assigned that address
that address to the initiator: it only means that if packets matching to the initiator: it only means that if packets matching these
these traffic selectors are sent by the initiator, IPsec processing traffic selectors are sent by the initiator, IPsec processing can be
can be performed as agreed for this SA. performed as agreed for this SA.
Configuration payloads are of type CFG_REQUEST/CFG_REPLY or CFG_SET/ Configuration payloads are of type CFG_REQUEST/CFG_REPLY or CFG_SET/
CFG_ACK (see CFG Type in the payload description below). CFG_REQUEST CFG_ACK (see CFG Type in the payload description below). CFG_REQUEST
and CFG_SET payloads may optionally be added to any IKE request. The and CFG_SET payloads may optionally be added to any IKE request. The
IKE response MUST include either a corresponding CFG_REPLY or CFG_ACK IKE response MUST include either a corresponding CFG_REPLY or CFG_ACK
or a Notify payload with an error type indicating why the request or a Notify payload with an error type indicating why the request
could not be honored. An exception is that a minimal implementation could not be honored. An exception is that a minimal implementation
MAY ignore all CFG_REQUEST and CFG_SET payloads, so a response MAY ignore all CFG_REQUEST and CFG_SET payloads, so a response
message without a corresponding CFG_REPLY or CFG_ACK MUST be accepted message without a corresponding CFG_REPLY or CFG_ACK MUST be accepted
as an indication that the request was not supported. as an indication that the request was not supported.
skipping to change at page 55, line 7 skipping to change at page 54, line 17
the configuration data and it MUST contain the attributes that the the configuration data and it MUST contain the attributes that the
responder accepted with zero-length data. Those attributes that it responder accepted with zero-length data. Those attributes that it
did not accept MUST NOT be in the CFG_ACK Configuration Payload. If did not accept MUST NOT be in the CFG_ACK Configuration Payload. If
no attributes were accepted, the responder MUST return either an no attributes were accepted, the responder MUST return either an
empty CFG_ACK payload or a response message without a CFG_ACK empty CFG_ACK payload or a response message without a CFG_ACK
payload. There are currently no defined uses for the CFG_SET/CFG_ACK payload. There are currently no defined uses for the CFG_SET/CFG_ACK
exchange, though they may be used in connection with extensions based exchange, though they may be used in connection with extensions based
on Vendor IDs. An minimal implementation of this specification MAY on Vendor IDs. An minimal implementation of this specification MAY
ignore CFG_SET payloads. ignore CFG_SET payloads.
{{ Demoted the SHOULD }} Extensions via the CP payload should not be Extensions via the CP payload should not be used for general purpose
used for general purpose management. Its main intent is to provide a management. Its main intent is to provide a bootstrap mechanism to
bootstrap mechanism to exchange information within IPsec from IRAS to exchange information within IPsec from IRAS to IRAC. While it MAY be
IRAC. While it MAY be useful to use such a method to exchange useful to use such a method to exchange information between some
information between some Security Gateways (SGW) or small networks, Security Gateways (SGW) or small networks, existing management
existing management protocols such as DHCP [DHCP], RADIUS [RADIUS], protocols such as DHCP [DHCP], RADIUS [RADIUS], SNMP, or LDAP [LDAP]
SNMP, or LDAP [LDAP] should be preferred for enterprise management as should be preferred for enterprise management as well as subsequent
well as subsequent information exchanges. 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
skipping to change at page 56, line 18 skipping to change at page 55, line 31
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. The
}} The INVALID_IKE_SPI notification indicates an IKE message was INVALID_IKE_SPI notification indicates an IKE message was received
received with an unrecognized destination SPI; this usually indicates with an unrecognized destination SPI; this usually indicates that the
that the recipient has rebooted and forgotten the existence of an IKE recipient has rebooted and forgotten the existence of an 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. A node should treat such a message (and also a
such a message (and also a network message like ICMP destination network message like ICMP destination unreachable) as a hint that
unreachable) as a hint that there might be problems with SAs to that there might be problems with SAs to that IP address and should
IP address and should initiate a liveness test for any such IKE SA. initiate a liveness test for any such IKE SA. An implementation
An implementation SHOULD limit the frequency of such tests to avoid SHOULD limit the frequency of such tests to avoid being tricked into
being tricked into participating in a denial of service attack. 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. The recipient MUST NOT change
recipient MUST NOT change the state of any SAs as a result, but may the state of any SAs as a result, but may wish to audit the event to
wish to audit the event to aid in diagnosing malfunctions. A node aid in diagnosing malfunctions. A node MUST limit the rate at which
MUST limit the rate at which it will send messages in response to it will send messages in response to unprotected messages.
unprotected messages.
2.22. IPComp 2.22. IPComp
Use of IP compression [IP-COMP] can be negotiated as part of the Use of IP compression [IP-COMP] can be negotiated as part of the
setup of a Child SA. While IP compression involves an extra header setup of a Child SA. While IP compression involves an extra header
in each 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.
skipping to change at page 57, line 16 skipping to change at page 56, line 26
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 The data associated with this notification includes a two-octet
a two-octet IPComp CPI followed by a one-octet transform ID IPComp CPI followed by a one-octet transform ID optionally followed
optionally followed by attributes whose length and format are defined by attributes whose length and format are defined by that transform
by that transform ID. A message proposing an SA may contain multiple ID. A message proposing an SA may contain multiple IPCOMP_SUPPORTED
IPCOMP_SUPPORTED notifications to indicate multiple supported notifications to indicate multiple supported algorithms. A message
algorithms. A message accepting an SA may contain at most one. accepting an SA may contain at most one.
The transform IDs currently defined are: The transform IDs currently defined are:
Name Number Defined In Name Number Defined In
------------------------------------- -------------------------------------
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
skipping to change at page 59, line 13 skipping to change at page 58, line 22
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 500 reason, even though IKE packets MUST be sent from and to UDP port 500
or 4500, they MUST be accepted coming from any port and responses or 4500, they MUST be accepted coming from any port and responses
MUST be sent to the port from whence they came. This is because the MUST be sent to the port from whence they came. This is because the
ports may be modified as the packets pass through NATs. Similarly, ports may be modified as the packets pass through NATs. Similarly,
IP addresses of the IKE endpoints are generally not included in the IP addresses of the IKE endpoints are generally not included in the
IKE 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. {{ Clarif-7.6 Port 4500 is reserved for UDP-encapsulated ESP and IKE. An IPsec
}} An IPsec endpoint that discovers a NAT between it and its endpoint that discovers a NAT between it and its correspondent MUST
correspondent MUST send all subsequent traffic from port 4500, which send all subsequent traffic from port 4500, which NATs should not
NATs should not treat specially (as they might with port 500). treat specially (as they might with port 500).
An initiator can float to port 4500, regardless whether or not there An initiator can float to port 4500, regardless whether or not there
is NAT, even at the beginning of IKE. When either side is using port is NAT, even at the beginning of IKE. When either side is using port
4500, sending with UDP encapsulation is not required, but 4500, sending with UDP encapsulation is not required, but
understanding received packets with UDP encapsulation is required. understanding received packets with UDP encapsulation is required.
UDP encapsulation MUST NOT be done on port 500. If NAT-T is UDP encapsulation MUST NOT be done on port 500. If NAT-T is
supported (that is, if NAT_DETECTION_*_IP payloads were exchanged supported (that is, if NAT_DETECTION_*_IP payloads were exchanged
during IKE_SA_INIT), all devices MUST be able to receive and process during IKE_SA_INIT), all devices MUST be able to receive and process
both UDP encapsulated and non-UDP encapsulated packets at any time. both UDP encapsulated and non-UDP encapsulated packets at any time.
Either side can decide whether or not to use UDP encapsulation Either side can decide whether or not to use UDP encapsulation
skipping to change at page 59, line 46 skipping to change at page 59, line 7
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
is 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 The data associated with the NAT_DETECTION_SOURCE_IP notification
NAT_DETECTION_SOURCE_IP notification is a SHA-1 digest of the SPIs is a SHA-1 digest of the SPIs (in the order they appear in the
(in the order they appear in the header), IP address, and port on header), IP address, and port on which this packet was sent.
which this packet was sent. There MAY be multiple There MAY be multiple NAT_DETECTION_SOURCE_IP payloads in a
NAT_DETECTION_SOURCE_IP payloads in a message if the sender does message if the sender does not know which of several network
not know which of several network attachments will be used to send attachments will be used to send the packet.
the packet.
o {{ 3.10.1-16389 }} The data associated with the o The data associated with the NAT_DETECTION_DESTINATION_IP
NAT_DETECTION_DESTINATION_IP notification is a SHA-1 digest of the notification is a SHA-1 digest of the SPIs (in the order they
SPIs (in the order they appear in the header), IP address, and appear in the header), IP address, and port to which this packet
port to which this packet was sent. was sent.
o {{ 3.10.1-16388 }} {{ 3.10.1-16389 }} The recipient of either the o The recipient of either the NAT_DETECTION_SOURCE_IP or
NAT_DETECTION_SOURCE_IP or NAT_DETECTION_DESTINATION_IP NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied
notification MAY compare the supplied value to a SHA-1 hash of the value to a SHA-1 hash of the SPIs, source IP address, and port,
SPIs, source IP address, and port, and if they don't match it and if they don't match it SHOULD enable NAT traversal. In the
SHOULD enable NAT traversal. In the case of a mismatching case of a mismatching NAT_DETECTION_SOURCE_IP hash, the recipient
NAT_DETECTION_SOURCE_IP hash, the recipient MAY reject the MAY reject the connection attempt if NAT traversal is not
connection attempt if NAT traversal is not supported. In the case supported. In the case of a mismatching
of a mismatching NAT_DETECTION_DESTINATION_IP hash, it means that NAT_DETECTION_DESTINATION_IP hash, it means that the system
the system receiving the NAT_DETECTION_DESTINATION_IP payload is receiving the NAT_DETECTION_DESTINATION_IP payload is behind a NAT
behind a NAT and that system SHOULD start sending keepalive and that system SHOULD start sending keepalive packets as defined
packets as defined in [UDPENCAPS]; alternately, it MAY reject the in [UDPENCAPS]; alternately, it MAY reject the connection attempt
connection attempt if NAT traversal is not supported. if NAT traversal is not supported.
o If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches o If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches
the expected value of the source IP and port found from the IP the expected value of the source 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 sending those payloads is behind NAT (i.e., someone along system sending those payloads is behind NAT (i.e., someone along
the route changed the source address of the original packet to the route changed the source address of the original packet to
match the address of the NAT box). In this case, the system match the address of the NAT box). In this case, the system
receiving the payloads should allow dynamic update of the other receiving the payloads should allow dynamic update of the other
systems' IP address, as described later. systems' IP address, as described later.
skipping to change at page 63, line 32 skipping to change at page 62, line 41
Figure 4: IKE Header Format Figure 4: IKE Header Format
o Initiator's SPI (8 octets) - A value chosen by the initiator to o Initiator's SPI (8 octets) - A value chosen by the initiator to
identify a unique IKE security association. This value MUST NOT identify a unique IKE security association. This value MUST NOT
be zero. be zero.
o Responder's SPI (8 octets) - A value chosen by the responder to o Responder's SPI (8 octets) - A value chosen by the responder to
identify a unique IKE security association. This value MUST be identify a unique IKE security association. This value MUST be
zero in the first message of an IKE Initial Exchange (including zero in the first message of an IKE Initial Exchange (including
repeats of that message including a cookie). {{ The phrase "and repeats of that message including a cookie).
MUST NOT be zero in any other message" was removed; Clarif-2.1 }}
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
skipping to change at page 67, line 5 skipping to change at page 66, line 5
defined in this document and therefore must ignore the Critical defined in this document and therefore must ignore the Critical
bit's value. Skipped payloads are expected to have valid Next bit's value. Skipped payloads are expected to have valid Next
Payload and Payload Length fields. Payload and Payload Length fields.
o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on
receipt. receipt.
o Payload Length (2 octets) - Length in octets of the current o Payload Length (2 octets) - Length in octets of the current
payload, including the generic payload header. payload, including the generic payload header.
{{ Clarif-7.10 }} Many payloads contain fields marked as "RESERVED". Many payloads contain fields marked as "RESERVED". Some payloads in
Some payloads in IKEv2 (and historically in IKEv1) are not aligned to IKEv2 (and historically in IKEv1) are not aligned to 4-octet
4-octet boundaries. boundaries.
3.3. Security Association Payload 3.3. Security Association Payload
The Security Association Payload, denoted SA in this memo, is used to The Security Association Payload, denoted SA in this memo, is used to
negotiate attributes of a security association. Assembly of Security negotiate attributes of a security association. Assembly of Security
Association Payloads requires great peace of mind. An SA payload MAY Association Payloads requires great peace of mind. An SA payload MAY
contain multiple proposals. If there is more than one, they MUST be contain multiple proposals. If there is more than one, they MUST be
ordered from most preferred to least preferred. Each proposal ordered from most preferred to least preferred. Each proposal
contains a single IPsec protocol (where a protocol is IKE, ESP, or contains a single IPsec protocol (where a protocol is IKE, ESP, or
AH), each protocol MAY contain multiple transforms, and each AH), each protocol MAY contain multiple transforms, and each
skipping to change at page 74, line 11 skipping to change at page 73, line 11
For Transform Type 5 (Extended Sequence Numbers), defined Transform For Transform Type 5 (Extended Sequence Numbers), defined Transform
IDs are: IDs are:
Name Number Name Number
-------------------------------------------- --------------------------------------------
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 Note that an initiator who supports ESNs will usually include two ESN
usually include two ESN transforms, with values "0" and "1", in its transforms, with values "0" and "1", in its proposals. A proposal
proposals. A proposal containing a single ESN transform with value containing a single ESN transform with value "1" means that using
"1" means that using normal (non-extended) sequence numbers is not normal (non-extended) sequence numbers is not acceptable.
acceptable.
Numerous additional transform types have been defined since the Numerous additional transform types have been defined since the
publication of RFC 4306. Please refer to the IANA IKEv2 registry for publication of RFC 4306. Please refer to the IANA IKEv2 registry for
details. 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
skipping to change at page 76, line 40 skipping to change at page 75, line 40
RESERVED 0-13 RESERVED 0-13
Key Length (in bits) 14 TV Key Length (in bits) 14 TV
RESERVED 15-17 RESERVED 15-17
RESERVED TO IANA 18-16383 RESERVED TO IANA 18-16383
PRIVATE USE 16384-32767 PRIVATE USE 16384-32767
Values 0-13 and 15-17 were used in a similar context in IKEv1, and Values 0-13 and 15-17 were used in a similar context in IKEv1, and
should not be assigned except to matching values. should not be assigned except to matching values.
The Key Length attribute specifies the key length in bits (MUST use The Key Length attribute specifies the key length in bits (MUST use
network byte order) for certain transforms as follows: {{ Clarif-7.11 network byte order) for certain transforms as follows:
}}
o The Key Length attribute MUST NOT be used with transforms that use o The Key Length attribute MUST NOT be used with transforms that use
a fixed length key. This includes, e.g., ENCR_DES, ENCR_IDEA, and a fixed length key. This includes, e.g., ENCR_DES, ENCR_IDEA, and
all the Type 2 (Pseudo-random function) and Type 3 (Integrity all the Type 2 (Pseudo-random function) and Type 3 (Integrity
Algorithm) transforms specified in this document. It is Algorithm) transforms specified in this document. It is
recommended that future Type 2 or 3 transforms do not use this recommended that future Type 2 or 3 transforms do not use this
attribute. attribute.
o Some transforms specify that the Key Length attribute MUST be o Some transforms specify that the Key Length attribute MUST be
always included (omitting the attribute is not allowed, and always included (omitting the attribute is not allowed, and
skipping to change at page 79, line 14 skipping to change at page 78, line 13
with a Notify payload of type INVALID_KE_PAYLOAD. with a Notify payload of type INVALID_KE_PAYLOAD.
The payload type for the Key Exchange payload is thirty four (34). The payload type for the Key Exchange payload is thirty four (34).
3.5. Identification Payloads 3.5. Identification Payloads
The Identification Payloads, denoted IDi and IDr in this memo, allow The Identification Payloads, denoted IDi and IDr in this memo, allow
peers to assert an identity to one another. This identity may be peers to assert an identity to one another. This identity may be
used for policy lookup, but does not necessarily have to match used for policy lookup, but does not necessarily have to match
anything in the CERT payload; both fields may be used by an anything in the CERT payload; both fields may be used by an
implementation to perform access control decisions. {{ Clarif-7.1 }} implementation to perform access control decisions. When using the
When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2
payloads, IKEv2 does not require this address to match the address in does not require this address to match the address in the IP header
the IP header of IKEv2 packets, or anything in the TSi/TSr payloads. of IKEv2 packets, or anything in the TSi/TSr payloads. The contents
The contents of IDi/IDr is used purely to fetch the policy and of IDi/IDr is used purely to fetch the policy and authentication data
authentication data related to the other party. related to the other party.
NOTE: In IKEv1, two ID payloads were used in each direction to hold NOTE: In IKEv1, two ID payloads were used in each direction to hold
Traffic Selector (TS) information for data passing over the SA. In Traffic Selector (TS) information for data passing over the SA. In
IKEv2, this information is carried in TS payloads (see Section 3.13). IKEv2, this information is carried in TS payloads (see Section 3.13).
The Identification Payload consists of the IKE generic payload header The Identification Payload consists of the IKE generic payload header
followed by identification fields as follows: followed by identification fields 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
skipping to change at page 81, line 14 skipping to change at page 80, line 13
Two implementations will interoperate only if each can generate a Two implementations will interoperate only if each can generate a
type of ID acceptable to the other. To assure maximum type of ID acceptable to the other. To assure maximum
interoperability, implementations MUST be configurable to send at interoperability, implementations MUST be configurable to send at
least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and
MUST be configurable to accept all of these types. Implementations MUST be configurable to accept all of these types. Implementations
SHOULD be capable of generating and accepting all of these types. SHOULD be capable of generating and accepting all of these types.
IPv6-capable implementations MUST additionally be configurable to IPv6-capable implementations MUST additionally be configurable to
accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable
to send only ID_IPV6_ADDR. to send only ID_IPV6_ADDR.
{{ Clarif-3.4 }} EAP [EAP] does not mandate the use of any particular EAP [EAP] does not mandate the use of any particular type of
type of identifier, but often EAP is used with Network Access identifier, but often EAP is used with Network Access Identifiers
Identifiers (NAIs) defined in [NAI]. Although NAIs look a bit like (NAIs) defined in [NAI]. Although NAIs look a bit like email
email addresses (e.g., "joe@example.com"), the syntax is not exactly addresses (e.g., "joe@example.com"), the syntax is not exactly the
the same as the syntax of email address in [MAILFORMAT]. For those same as the syntax of email address in [MAILFORMAT]. For those NAIs
NAIs that include the realm component, the ID_RFC822_ADDR that include the realm component, the ID_RFC822_ADDR identification
identification type SHOULD be used. Responder implementations should type SHOULD be used. Responder implementations should not attempt to
not attempt to verify that the contents actually conform to the exact verify that the contents actually conform to the exact syntax given
syntax given in [MAILFORMAT], but instead should accept any in [MAILFORMAT], but instead should accept any reasonable-looking
reasonable-looking NAI. For NAIs that do not include the realm NAI. For NAIs that do not include the realm component,the ID_KEY_ID
component,the ID_KEY_ID identification type SHOULD be used. identification type SHOULD be used.
3.6. Certificate Payload 3.6. Certificate Payload
The Certificate Payload, denoted CERT in this memo, provides a means The Certificate Payload, denoted CERT in this memo, provides a means
to transport certificates or other authentication-related information to transport certificates or other authentication-related information
via IKE. Certificate payloads SHOULD be included in an exchange if via IKE. Certificate payloads SHOULD be included in an exchange if
certificates are available to the sender unless the peer has certificates are available to the sender unless the peer has
indicated an ability to retrieve this information from elsewhere indicated an ability to retrieve this information from elsewhere
using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note that the using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note that the
term "Certificate Payload" is somewhat misleading, because not all term "Certificate Payload" is somewhat misleading, because not all
skipping to change at page 82, line 43 skipping to change at page 81, line 43
defined in this document. The types whose syntax is defined in this defined in this document. The types whose syntax is defined in this
document are: document are:
o X.509 Certificate - Signature (4) contains a DER encoded X.509 o X.509 Certificate - Signature (4) contains a DER encoded X.509
certificate whose public key is used to validate the sender's AUTH certificate whose public key is used to validate the sender's AUTH
payload. payload.
o Certificate Revocation List (7) contains a DER encoded X.509 o Certificate Revocation List (7) contains a DER encoded X.509
certificate revocation list. certificate revocation list.
o {{ Added "DER-encoded RSAPublicKey structure" from Clarif-3.6 }} o Raw RSA Key (11) contains a PKCS #1 encoded RSA key, that is, a
Raw RSA Key (11) contains a PKCS #1 encoded RSA key, that is, a
DER-encoded RSAPublicKey structure (see [RSA] and [PKCS1]). DER-encoded RSAPublicKey structure (see [RSA] and [PKCS1]).
o Hash and URL encodings (12-13) allow IKE messages to remain short o Hash and URL encodings (12-13) allow IKE messages to remain short
by replacing long data structures with a 20 octet SHA-1 hash (see by replacing long data structures with a 20 octet SHA-1 hash (see
[SHA]) of the replaced value followed by a variable-length URL [SHA]) of the replaced value followed by a variable-length URL
that resolves to the DER encoded data structure itself. This that resolves to the DER encoded data structure itself. This
improves efficiency when the endpoints have certificate data improves efficiency when the endpoints have certificate data
cached and makes IKE less subject to denial of service attacks cached and makes IKE less subject to denial of service attacks
that become easier to mount when IKE messages are large enough to that become easier to mount when IKE messages are large enough to
require IP fragmentation [DOSUDPPROT]. require IP fragmentation [DOSUDPPROT].
skipping to change at page 84, line 41 skipping to change at page 83, line 39
The Certificate Encoding field has the same values as those defined The Certificate Encoding field has the same values as those defined
in Section 3.6. The Certification Authority field contains an in Section 3.6. The Certification Authority field contains an
indicator of trusted authorities for this certificate type. The indicator of trusted authorities for this certificate type. The
Certification Authority value is a concatenated list of SHA-1 hashes Certification Authority value is a concatenated list of SHA-1 hashes
of the public keys of trusted Certification Authorities (CAs). Each of the public keys of trusted Certification Authorities (CAs). Each
is encoded as the SHA-1 hash of the Subject Public Key Info element is encoded as the SHA-1 hash of the Subject Public Key Info element
(see section 4.1.2.7 of [PKIX]) from each Trust Anchor certificate. (see section 4.1.2.7 of [PKIX]) from each Trust Anchor certificate.
The twenty-octet hashes are concatenated and included with no other The twenty-octet hashes are concatenated and included with no other
formatting. formatting.
{{ Clarif-3.6 }} The contents of the "Certification Authority" field The contents of the "Certification Authority" field are defined only
are defined only for X.509 certificates, which are types 4, 10, 12, for X.509 certificates, which are types 4, 10, 12, and 13. Other
and 13. Other values SHOULD NOT be used until standards-track values SHOULD NOT be used until standards-track specifications that
specifications that specify their use are published. specify their use are published.
Note that the term "Certificate Request" is somewhat misleading, in Note that the term "Certificate Request" is somewhat misleading, in
that values other than certificates are defined in a "Certificate" that values other than certificates are defined in a "Certificate"
payload and requests for those values can be present in a Certificate payload and requests for those values can be present in a Certificate
Request Payload. The syntax of the Certificate Request payload in Request Payload. The syntax of the Certificate Request payload in
such cases is not defined in this document. such cases is not defined in this document.
The Certificate Request Payload is processed by inspecting the "Cert The Certificate Request Payload is processed by inspecting the "Cert
Encoding" field to determine whether the processor has any Encoding" field to determine whether the processor has any
certificates of this type. If so, the "Certification Authority" certificates of this type. If so, the "Certification Authority"
skipping to change at page 85, line 42 skipping to change at page 84, line 40
alternate certificate could be selected by the sender that would alternate certificate could be selected by the sender that would
still enable the recipient to successfully validate and trust it still enable the recipient to successfully validate and trust it
through trust conveyed by cross-certification, CRLs, or other out-of- through trust conveyed by cross-certification, CRLs, or other out-of-
band configured means. Thus, the processing of a CERTREQ should be band configured means. Thus, the processing of a CERTREQ should be
seen as a suggestion for a certificate to select, not a mandated one. seen as a suggestion for a certificate to select, not a mandated one.
If no certificates exist, then the CERTREQ is ignored. This is not If no certificates exist, then the CERTREQ is ignored. This is not
an error condition of the protocol. There may be cases where there an error condition of the protocol. There may be cases where there
is a preferred CA sent in the CERTREQ, but an alternate might be is a preferred CA sent in the CERTREQ, but an alternate might be
acceptable (perhaps after prompting a human operator). acceptable (perhaps after prompting a human operator).
{{ 3.10.1-16392 }} The HTTP_CERT_LOOKUP_SUPPORTED notification MAY be The HTTP_CERT_LOOKUP_SUPPORTED notification MAY be included in any
included in any message that can include a CERTREQ payload and message that can include a CERTREQ payload and indicates that the
indicates that the sender is capable of looking up certificates based sender is capable of looking up certificates based on an HTTP-based
on an HTTP-based URL (and hence presumably would prefer to receive URL (and hence presumably would prefer to receive certificate
certificate specifications in that format). specifications in that format).
3.8. Authentication Payload 3.8. Authentication Payload
The Authentication Payload, denoted AUTH in this memo, contains data The Authentication Payload, denoted AUTH in this memo, contains data
used for authentication purposes. The syntax of the Authentication used for authentication purposes. The syntax of the Authentication
data varies according to the Auth Method as specified below. data varies according to the Auth Method as specified below.
The Authentication Payload is defined as follows: The Authentication Payload is defined as follows:
1 2 3 1 2 3
skipping to change at page 86, line 28 skipping to change at page 85, line 27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Authentication Payload Format Figure 14: Authentication Payload Format
o Auth Method (1 octet) - Specifies the method of authentication o Auth Method (1 octet) - Specifies the method of authentication
used. Values defined are: used. Values defined are:
* RSA Digital Signature (1) - Computed as specified in * RSA Digital Signature (1) - Computed as specified in
Section 2.15 using an RSA private key with RSASSA-PKCS1-v1_5 Section 2.15 using an RSA private key with RSASSA-PKCS1-v1_5
signature scheme specified in [PKCS1] (implementors should note signature scheme specified in [PKCS1] (implementors should note
that IKEv1 used a different method for RSA signatures) {{ that IKEv1 used a different method for RSA signatures). To
Clarif-3.3 }}. {{ Clarif-3.2 }} To promote interoperability, promote interoperability, implementations that support this
implementations that support this type SHOULD support type SHOULD support signatures that use SHA-1 as the hash
signatures that use SHA-1 as the hash function and SHOULD use function and SHOULD use SHA-1 as the default hash function when
SHA-1 as the default hash function when generating signatures. generating signatures.
* Shared Key Message Integrity Code (2) - Computed as specified * Shared Key Message Integrity Code (2) - Computed as specified
in Section 2.15 using the shared key associated with the in Section 2.15 using the shared key associated with the
identity in the ID payload and the negotiated prf function identity in the ID payload and the negotiated prf function
* DSS Digital Signature (3) - Computed as specified in * DSS Digital Signature (3) - Computed as specified in
Section 2.15 using a DSS private key (see [DSS]) over a SHA-1 Section 2.15 using a DSS private key (see [DSS]) over a SHA-1
hash. hash.
* The values 0 and 4-200 are reserved to IANA. The values 201- * The values 0 and 4-200 are reserved to IANA. The values 201-
skipping to change at page 88, line 26 skipping to change at page 87, line 26
| | | |
~ Notification Data ~ ~ Notification Data ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Notify Payload Format Figure 16: Notify Payload Format
o Protocol ID (1 octet) - If this notification concerns an existing o Protocol ID (1 octet) - If this notification concerns an existing
SA whose SPI is given the SPI field, this field indicates the type SA whose SPI is given the SPI field, this field indicates the type
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. Of
Clarif-7.8 }} Of the notifications defined in this document, the the notifications defined in this document, the SPI is included
SPI is included only with INVALID_SELECTORS and REKEY_SA. If the only with INVALID_SELECTORS and REKEY_SA. If the SPI field is
SPI field is empty, this field MUST be sent as zero and MUST be empty, this field MUST be sent as zero and MUST be ignored on
ignored on receipt. All other values for this field are reserved receipt. All other values for this field are reserved to IANA for
to IANA for future assignment. 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.
skipping to change at page 89, line 13 skipping to change at page 88, line 13
could not be established. It can also be status data that a process could not be established. It can also be status data that a process
managing an SA database wishes to communicate with a peer process. managing an SA database wishes to communicate with a peer process.
The table below lists the Notification messages and their The table below lists the Notification messages and their
corresponding values. The number of different error statuses was corresponding values. The number of different error statuses was
greatly reduced from IKEv1 both for simplification and to avoid greatly reduced from IKEv1 both for simplification and to avoid
giving configuration information to probers. giving configuration information to probers.
Types in the range 0 - 16383 are intended for reporting errors. An Types in the range 0 - 16383 are intended for reporting errors. An
implementation receiving a Notify payload with one of these types implementation receiving a Notify payload with one of these types
that it does not recognize in a response MUST assume that the that it does not recognize in a response MUST assume that the
corresponding request has failed entirely. {{ Demoted the SHOULD }} corresponding request has failed entirely. Unrecognized error types
Unrecognized error types in a request and status types in a request in a request and status types in a request or response MUST be
or response MUST be ignored, and they should be logged. ignored, and they should be logged.
Notify payloads with status types MAY be added to any message and Notify payloads with status types MAY be added to any message and
MUST be ignored if not recognized. They are intended to indicate MUST be ignored if not recognized. They are intended to indicate
capabilities, and as part of SA negotiation are used to negotiate capabilities, and as part of SA negotiation are used to negotiate
non-cryptographic parameters. non-cryptographic parameters.
NOTIFY messages: error types Value NOTIFY messages: error types Value
------------------------------------------------------------------- -------------------------------------------------------------------
RESERVED 0 RESERVED 0
skipping to change at page 94, line 47 skipping to change at page 93, line 47
o Traffic Selectors (variable length) - One or more individual o Traffic Selectors (variable length) - One or more individual
traffic selectors. traffic selectors.
The length of the Traffic Selector payload includes the TS header and The length of the Traffic Selector payload includes the TS header and
all the traffic selectors. all the traffic selectors.
The payload type for the Traffic Selector payload is forty four (44) The payload type for the Traffic Selector payload is forty four (44)
for addresses at the initiator's end of the SA and forty five (45) for addresses at the initiator's end of the SA and forty five (45)
for addresses at the responder's end. for addresses at the responder's end.
{{ Clarif-4.7 }} There is no requirement that TSi and TSr contain the There is no requirement that TSi and TSr contain the same number of
same number of individual traffic selectors. Thus, they are individual traffic selectors. Thus, they are interpreted as follows:
interpreted as follows: a packet matches a given TSi/TSr if it a packet matches a given TSi/TSr if it matches at least one of the
matches at least one of the individual selectors in TSi, and at least individual selectors in TSi, and at least one of the individual
one of the individual selectors in TSr. selectors in TSr.
For instance, the following traffic selectors: For instance, the following traffic selectors:
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),
skipping to change at page 96, line 39 skipping to change at page 95, line 39
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
working with [IPSECARCH] that wish to indicate "OPAQUE" ports, but working with [IPSECARCH] that wish to indicate "OPAQUE" ports, but
not "ANY" ports, MUST set the start port to 65535 and the end port to not "ANY" ports, MUST set the start port to 65535 and the end port to
0. 0.
{{ Added from Clarif-4.8 }} The traffic selector types 7 and 8 can The traffic selector types 7 and 8 can also refer to ICMP type and
also refer to ICMP type and code fields. Note, however, that ICMP code fields. Note, however, that ICMP packets do not have separate
packets do not have separate source and destination port fields. The source and destination port fields. The method for specifying the
method for specifying the traffic selectors for ICMP is shown by traffic selectors for ICMP is shown by example in Section 4.4.1.3 of
example in Section 4.4.1.3 of [IPSECARCH]. [IPSECARCH].
{{ Added from Clarif-4.9 }} Traffic selectors can use IP Protocol ID Traffic selectors can use IP Protocol ID 135 to match the IPv6
135 to match the IPv6 mobility header [MIPV6]. This document does mobility header [MIPV6]. This document does not specify how to
not specify how to represent the "MH Type" field in traffic represent the "MH Type" field in traffic selectors, although it is
selectors, although it is likely that a different document will likely that a different document will specify this in the future.
specify this in the future. Note that [IPSECARCH] says that the IPv6 Note that [IPSECARCH] says that the IPv6 mobility header (MH) message
mobility header (MH) message type is placed in the most significant type is placed in the most significant eight bits of the 16-bit local
eight bits of the 16-bit local port selector. The direction port selector. The direction semantics of TSi/TSr port fields are
semantics of TSi/TSr port fields are the same as for ICMP. the same as for ICMP.
The following table lists the assigned values for the Traffic The following table lists the assigned values for the Traffic
Selector Type field and the corresponding Address Selector Data. Selector Type field and the corresponding Address Selector Data.
TS Type Value TS Type Value
------------------------------------------------------------------- -------------------------------------------------------------------
RESERVED 0-6 RESERVED 0-6
TS_IPV4_ADDR_RANGE 7 TS_IPV4_ADDR_RANGE 7
skipping to change at page 101, line 19 skipping to change at page 100, line 19
INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets
INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets
INTERNAL_IP4_DNS 3 YES 0 or 4 octets INTERNAL_IP4_DNS 3 YES 0 or 4 octets
INTERNAL_IP4_NBNS 4 YES 0 or 4 octets INTERNAL_IP4_NBNS 4 YES 0 or 4 octets
RESERVED 5 RESERVED 5
INTERNAL_IP4_DHCP 6 YES 0 or 4 octets INTERNAL_IP4_DHCP 6 YES 0 or 4 octets
APPLICATION_VERSION 7 NO 0 or more APPLICATION_VERSION 7 NO 0 or more
INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets
RESERVED 9 RESERVED 9
INTERNAL_IP6_DNS 10 YES 0 or 16 octets INTERNAL_IP6_DNS 10 YES 0 or 16 octets
INTERNAL_IP6_NBNS 11 YES 0 or 16 octets RESERVED
INTERNAL_IP6_DHCP 12 YES 0 or 16 octets INTERNAL_IP6_DHCP 12 YES 0 or 16 octets
INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets
SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 SUPPORTED_ATTRIBUTES 14 NO Multiple of 2
INTERNAL_IP6_SUBNET 15 YES 17 octets INTERNAL_IP6_SUBNET 15 YES 17 octets
RESERVED TO IANA 16-16383 RESERVED TO IANA 16-16383
PRIVATE USE 16384-32767 PRIVATE USE 16384-32767
* These attributes may be multi-valued on return only if * These attributes may be multi-valued on return only if
multiple values were requested. multiple values were requested.
o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the
internal network, sometimes called a red node address or private internal network, sometimes called a red node address or private
address and MAY be a private address on the Internet. {{ address and MAY be a private address on the Internet. In a
Clarif-6.2}} In a request message, the address specified is a request message, the address specified is a requested address (or
requested address (or a zero-length address if no specific address a zero-length address if no specific address is requested). If a
is requested). If a specific address is requested, it likely specific address is requested, it likely indicates that a previous
indicates that a previous connection existed with this address and connection existed with this address and the requestor would like
the requestor would like to reuse that address. With IPv6, a to reuse that address. With IPv6, a requestor MAY supply the low-
requestor MAY supply the low-order address octets it wants to use. order address octets it wants to use. Multiple internal addresses
Multiple internal addresses MAY be requested by requesting MAY be requested by requesting multiple internal address
multiple internal address attributes. The responder MAY only send attributes. The responder MAY only send up to the number of
up to the number of addresses requested. The INTERNAL_IP6_ADDRESS addresses requested. The INTERNAL_IP6_ADDRESS is made up of two
is made up of two fields: the first is a 16-octet IPv6 address, fields: the first is a 16-octet IPv6 address, and the second is a
and the second is a one-octet prefix-length as defined in one-octet prefix-length as defined in [ADDRIPV6]. The requested
[ADDRIPV6]. The requested address is valid until there are no IKE address is valid as long as this IKE SA (or its rekeyed
SAs between the peers. This is described in more detail in successors) requesting the address is valid. This is described in
Section 3.15.3. 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. INTERNAL_IP4_NETMASK in a
INTERNAL_IP4_NETMASK in a CFG_REPLY means roughly the same thing CFG_REPLY means roughly the same thing as INTERNAL_IP4_SUBNET
as INTERNAL_IP4_SUBNET containing the same information ("send containing the same information ("send traffic to these addresses
traffic to these addresses through me"), but also implies a link through me"), but also implies a link boundary. For instance, the
boundary. For instance, the client could use its own address and client could use its own address and the netmask to calculate the
the netmask to calculate the broadcast address of the link. An broadcast address of the link. An empty INTERNAL_IP4_NETMASK
empty INTERNAL_IP4_NETMASK attribute can be included in a attribute can be included in a CFG_REQUEST to request this
CFG_REQUEST to request this information (although the gateway can information (although the gateway can send the information even
send the information even when not requested). Non-empty values when not requested). Non-empty values for this attribute in a
for this attribute in a CFG_REQUEST do not make sense and thus CFG_REQUEST do not make sense and thus MUST NOT be included.
MUST NOT be included.
o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a DNS o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a DNS
server within the network. Multiple DNS servers MAY be requested. server within the network. Multiple DNS servers MAY be requested.
The responder MAY respond with zero or more DNS server attributes. The responder MAY respond with zero or more DNS server attributes.
o INTERNAL_IP4_NBNS - Specifies an address of a NetBios Name Server o INTERNAL_IP4_NBNS - Specifies an address of a NetBios Name Server
(WINS) within the network. Multiple NBNS servers MAY be (WINS) within the network. Multiple NBNS servers MAY be
requested. The responder MAY respond with zero or more NBNS requested. The responder MAY respond with zero or more NBNS
server attributes. server attributes.
o INTERNAL_IP6_NBNS - {{ Clarif-6.6 }} NetBIOS is not defined for
IPv6; therefore, INTERNAL_IP6_NBNS is also unspecified and is only
retained for compatibility with RFC 4306.
o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to send o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to send
any internal DHCP requests to the address contained within the any internal DHCP requests to the address contained within the
attribute. Multiple DHCP servers MAY be requested. The responder attribute. Multiple DHCP servers MAY be requested. The responder
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-
skipping to change at page 103, line 20 skipping to change at page 102, line 13
network attributes. This is discussed in more detail in Section network attributes. This is discussed in more detail in Section
3.15.2. 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 }}
INTERNAL_IP4/6_SUBNET attributes can indicate additional subnets, INTERNAL_IP4/6_SUBNET attributes can indicate additional subnets,
ones that need one or more separate SAs, that can be reached through ones that need one or more separate SAs, that can be reached through
the gateway that announces the attributes. INTERNAL_IP4/6_SUBNET the gateway that announces the attributes. INTERNAL_IP4/6_SUBNET
attributes may also express the gateway's policy about what traffic attributes may also express the gateway's policy about what traffic
should be sent through the gateway; the client can choose whether should be sent through the gateway; the client can choose whether
other traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is other traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is
sent through the gateway or directly to the destination. Thus, sent through the gateway or directly to the destination. Thus,
traffic to the addresses listed in the INTERNAL_IP4/6_SUBNET traffic to the addresses listed in the INTERNAL_IP4/6_SUBNET
attributes should be sent through the gateway that announces the attributes should be sent through the gateway that announces the
attributes. If there are no existing IPsec SAs whose traffic attributes. If there are no existing IPsec SAs whose traffic
skipping to change at page 105, line 4 skipping to change at page 103, line 47
TSr = (0, 0-65535, 192.0.2.155-192.0.2.155) TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)
then the gateway's reply might be: then the gateway's reply might be:
CP(CFG_REPLY) = CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(192.0.1.234) INTERNAL_IP4_ADDRESS(192.0.1.234)
INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
TSr = (0, 0-65535, 192.0.2.155-192.0.2.155) TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)
Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET is in Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET is in
CFG_REQUESTs is unclear, they cannot be used reliably in CFG_REQUESTs is unclear, they cannot be used reliably in
CFG_REQUESTs. CFG_REQUESTs.
3.15.3. Configuration payloads for IPv6 3.15.3. Configuration payloads for IPv6
{{ Added this section from Clarif-6.5 }}
The configuration payloads for IPv6 are based on the corresponding The configuration payloads for IPv6 are based on the corresponding
IPv4 payloads, and do not fully follow the "normal IPv6 way of doing IPv4 payloads, and do not fully follow the "normal IPv6 way of doing
things". In particular, IPv6 stateless autoconfiguration or router things". In particular, IPv6 stateless autoconfiguration or router
advertisement messages are not used; neither is neighbor discovery. advertisement messages are not used; neither is neighbor discovery.
A client can be assigned an IPv6 address using the A client can be assigned an IPv6 address using the
INTERNAL_IP6_ADDRESS configuration payload. A minimal exchange might INTERNAL_IP6_ADDRESS configuration payload. A minimal exchange might
look like this: look like this:
CP(CFG_REQUEST) = CP(CFG_REQUEST) =
skipping to change at page 106, line 7 skipping to change at page 104, line 49
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 }}
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.
The IKE SA is still created even if the initial Child SA cannot be The IKE SA is still created even if the initial Child SA cannot be
created because of this failure. {{ 3.10.1-36 }} If this error is created because of this failure. If this error is generated within
generated within an IKE_AUTH exchange, no Child SA will be created. an IKE_AUTH exchange, no Child SA will be created. However, there
However, there are some more complex error cases. 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 107, line 50 skipping to change at page 106, line 47
2 Notification 2 Notification
3 Nak (Response Only) 3 Nak (Response Only)
4 MD5-Challenge 4 MD5-Challenge
5 One-Time Password (OTP) 5 One-Time Password (OTP)
6 Generic Token Card 6 Generic Token Card
o Type_Data (Variable Length) varies with the Type of Request and o Type_Data (Variable Length) varies with the Type of Request and
the associated Response. For the documentation of the EAP the associated Response. For the documentation of the EAP
methods, see [EAP]. methods, see [EAP].
{{ Demoted the SHOULD NOT and SHOULD }} Note that since IKE passes an Note that since IKE passes an indication of initiator identity in
indication of initiator identity in message 3 of the protocol, the message 3 of the protocol, the responder should not send EAP Identity
responder should not send EAP Identity requests. The initiator may, requests. The initiator may, however, respond to such requests if it
however, respond to such requests if it receives them. receives them.
4. Conformance Requirements 4. Conformance Requirements
In order to assure that all implementations of IKEv2 can In order to assure that all implementations of IKEv2 can
interoperate, there are "MUST support" requirements in addition to interoperate, there are "MUST support" requirements in addition to
those listed elsewhere. Of course, IKEv2 is a security protocol, and those listed elsewhere. Of course, IKEv2 is a security protocol, and
one of its major functions is to allow only authorized parties to one of its major functions is to allow only authorized parties to
successfully complete establishment of SAs. So a particular successfully complete establishment of SAs. So a particular
implementation may be configured with any of a number of restrictions implementation may be configured with any of a number of restrictions
concerning algorithms and trusted authorities that will prevent concerning algorithms and trusted authorities that will prevent
skipping to change at page 109, line 30 skipping to change at page 108, line 26
Implementations are not required to support requesting temporary IP Implementations are not required to support requesting temporary IP
addresses or responding to such requests. If an implementation does addresses or responding to such requests. If an implementation does
support issuing such requests, it MUST include a CP payload in support issuing such requests, it MUST include a CP payload in
message 3 containing at least a field of type INTERNAL_IP4_ADDRESS or message 3 containing at least a field of type INTERNAL_IP4_ADDRESS or
INTERNAL_IP6_ADDRESS. All other fields are optional. If an INTERNAL_IP6_ADDRESS. All other fields are optional. If an
implementation supports responding to such requests, it MUST parse implementation supports responding to such requests, it MUST parse
the CP payload of type CFG_REQUEST in message 3 and recognize a field the CP payload of type CFG_REQUEST in message 3 and recognize a field
of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports
leasing an address of the appropriate type, it MUST return a CP leasing an address of the appropriate type, it MUST return a CP
payload of type CFG_REPLY containing an address of the requested payload of type CFG_REPLY containing an address of the requested
type. {{ Demoted the SHOULD }} The responder may include any other type. The responder may include any other related attributes.
related attributes.
A minimal IPv4 responder implementation will ignore the contents of A minimal IPv4 responder implementation will ignore the contents of
the CP payload except to determine that it includes an the CP payload except to determine that it includes an
INTERNAL_IP4_ADDRESS attribute and will respond with the address and INTERNAL_IP4_ADDRESS attribute and will respond with the address and
other related attributes regardless of whether the initiator other related attributes regardless of whether the initiator
requested them. requested them.
A minimal IPv4 initiator will generate a CP payload containing only A minimal IPv4 initiator will generate a CP payload containing only
an INTERNAL_IP4_ADDRESS attribute and will parse the response an INTERNAL_IP4_ADDRESS attribute and will parse the response
ignoring attributes it does not know how to use. ignoring attributes it does not know how to use.
skipping to change at page 112, line 32 skipping to change at page 111, line 26
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 authentication. {{ Demoted the SHOULD }} Implementers should the EAP authentication. Implementers should describe the
describe the vulnerabilities of using non-key-generating EAP methods vulnerabilities of using non-key-generating EAP methods in the
in the documentation of their implementations so that the documentation of their implementations so that the administrators
administrators deploying IPsec solutions are aware of these dangers. 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 authentication begins, even the server to the client before the EAP authentication begins, even
if the 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
skipping to change at page 113, line 13 skipping to change at page 112, line 7
example, trust anchors used for identifying IKE peers should probably example, trust anchors used for identifying IKE peers should probably
be different than those used for other forms of trust, such as those be different than those used for other forms of trust, such as those
used to identify public web servers. Moreover, although IKE provides used to identify public web servers. Moreover, although IKE provides
a great deal of leeway in defining the security policy for a trusted a great deal of leeway in defining the security policy for a trusted
peer's identity, credentials, and the correlation between them, peer's identity, credentials, and the correlation between them,
having such security policy defined explicitly is essential to a having such security policy defined explicitly is essential to a
secure implementation. secure implementation.
5.1. Traffic selector authorization 5.1. Traffic selector authorization
{{ Added this section from Clarif-4.13 }}
IKEv2 relies on information in the Peer Authorization Database (PAD) IKEv2 relies on information in the Peer Authorization Database (PAD)
when determining what kind of IPsec SAs a peer is allowed to create. when determining what kind of IPsec SAs a peer is allowed to create.
This process is described in [IPSECARCH] Section 4.4.3. When a peer This process is described in [IPSECARCH] Section 4.4.3. When a peer
requests the creation of an IPsec SA with some traffic selectors, the requests the creation of an IPsec SA with some traffic selectors, the
PAD must contain "Child SA Authorization Data" linking the identity PAD must contain "Child SA Authorization Data" linking the identity
authenticated by IKEv2 and the addresses permitted for traffic authenticated by IKEv2 and the addresses permitted for traffic
selectors. selectors.
For example, the PAD might be configured so that authenticated For example, the PAD might be configured so that authenticated
identity "sgw23.example.com" is allowed to create IPsec SAs for identity "sgw23.example.com" is allowed to create IPsec SAs for
skipping to change at page 114, line 23 skipping to change at page 113, line 14
traffic selectors containing the same address that was used for the traffic selectors containing the same address that was used for the
IKEv2 packets. In environments where IP spoofing is possible (i.e., IKEv2 packets. In environments where IP spoofing is possible (i.e.,
almost everywhere) this essentially allows any peer to create IPsec almost everywhere) this essentially allows any peer to create IPsec
SAs with any traffic selectors. This is not an appropriate or secure SAs with any traffic selectors. This is not an appropriate or secure
configuration in most circumstances. See [H2HIPSEC] for an extensive configuration in most circumstances. See [H2HIPSEC] for an extensive
discussion about this issue, and the limitations of host-to-host discussion about this issue, and the limitations of host-to-host
IPsec in general. IPsec in general.
6. IANA Considerations 6. IANA Considerations
{{ This section was changed to not re-define any new IANA registries.
}}
[IKEV2] defined many field types and values. IANA has already [IKEV2] defined many field types and values. IANA has already
registered those types and values, so the are not listed here again. registered those types and values, so the are not listed here again.
No new types or values are registered in this document. However, No new types or values are registered in this document. However,
IANA should update all references to RFC 4306 to point to this IANA should update all references to RFC 4306 to point to this
document. document.
7. Acknowledgements 7. Acknowledgements
The individuals on the IPsec mailing list was very helpful in both The individuals on the IPsec mailing list was very helpful in both
pointing out where clarifications and changes were needed, as well as pointing out where clarifications and changes were needed, as well as
skipping to change at page 122, line 43 skipping to change at page 121, line 33
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
The generator is 2. The generator is 2.
Appendix C. Exchanges and Payloads Appendix C. Exchanges and Payloads
{{ Clarif-AppA }}
This appendix contains a short summary of the IKEv2 exchanges, and This appendix contains a short summary of the IKEv2 exchanges, and
what payloads can appear in which message. This appendix is purely what payloads can appear in which message. This appendix is purely
informative; if it disagrees with the body of this document, the informative; if it disagrees with the body of this document, the
other text is considered correct. other text is considered correct.
Vendor-ID (V) payloads may be included in any place in any message. Vendor-ID (V) payloads may be included in any place in any message.
This sequence here shows what are the most logical places for them. This sequence here shows what are the most logical places for them.
C.1. IKE_SA_INIT Exchange C.1. IKE_SA_INIT Exchange
skipping to change at page 131, line 42 skipping to change at page 130, line 42
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
is for. is for.
Moved text from {{ Clarif-2.1 }} from Section 2.6 to Section 2.7. Moved text from Clarif-2.1 from Section 2.6 to Section 2.7.
In Section 2.13, added "(see Section 3.3.5 for the defintion of the In Section 2.13, added "(see Section 3.3.5 for the defintion of the
Key Length transform attribute)". Key Length transform attribute)".
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
skipping to change at page 141, line 5 skipping to change at page 139, line 45
identifying IKE peers should probably be different than those used identifying IKE peers should probably be different than those used
for other forms of trust, such as those used to identify public web for other forms of trust, such as those used to identify public web
servers. Moreover, although IKE provides a great deal of leeway in servers. Moreover, although IKE provides a great deal of leeway in
defining the security policy for a trusted peer's identity, defining the security policy for a trusted peer's identity,
credentials, and the correlation between them, having such security credentials, and the correlation between them, having such security
policy defined explicitly is essential to a secure implementation." policy defined explicitly is essential to a secure implementation."
[Issue #61] [Issue #61]
Changed "[V+]" to "[V+][N+]" throughout Appendix C. [Issue #63] Changed "[V+]" to "[V+][N+]" throughout Appendix C. [Issue #63]
E.11. Changes from draft-ietf-ipsecme-ikev2bis-03 to
draft-ietf-ipsecme-ikev2bis-04
Throughout, removed the marks that showed where text from the
Clarifications RFC was inserted, or where a "SHOULD" was demoted to
weaker language.
In section 1, added "IKEv2 was a change to the IKE protocol that was
not backward compatible. In contrast, the current document not only
provides a clarification of IKEv2, but makes minimum changes to the
IKE protocol." [Issue #48]
In 1.5, added "The recipient of this notification cannot tell whether
the SPI is for AH or ESP, but this is not important because the SPIs
are supposed to be different for the two." [Issue #35]
In 1.5, added "(INVALID_MAJOR_VERSION is also a one-way message which
is sent outside of an IKE SA, although it is sent as a response to
the incoming IKE SA creation.)" [Issue #13]
Added "The Message ID is reset to zero in the new IKE SA after the
IKE SA is rekeyed" in the first paragraph of 2.2. [Issue #15]
In 2.5, changed "implementations MUST send the payloads defined in
this specification in the order shown in the figures in Section 2;
implementations are explicitly allowed to reject as invalid a message
with those payloads in any other order" to "implementations SHOULD
send the payloads defined in this specification in the order shown in
the figures in Section 2; implementations MUST NOT reject as invalid
a message with those payloads in any other order". [Issue #16]
[Issue #45]
In 2.9, added "Maintenance of a system's SPD is outside the scope of
IKE (see [PFKEY] for an example programming interface, although it
only applies to IKEv1), though some implementations might update
their SPD in connection with the running of IKE (for an example
scenario, see Section 1.1.3)." This was actually done in -03 but not
noted in the change notes. [Issue #64] [Issue #54]
In 2.18, added "using SPIi, SPIr, Ni, and Nr from the new exchange"
to the last sentence.
Removed INTERNAL_IP6_NBNS from 3.15.1. [Issue #44]
Changed "The requested address is valid until there are no IKE_SAs
between the peers" to "The requested address is valid as long as this
IKE SA (or its rekeyed successors) requesting the address is valid."
[Issue #43]
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. 142 change blocks. 
700 lines changed or deleted 696 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/