draft-ietf-ipsecme-ikev2bis-05.txt   draft-ietf-ipsecme-ikev2bis-06.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: April 8, 2010 Check Point Expires: June 12, 2010 Check Point
P. Eronen P. Eronen
Nokia Nokia
October 5, 2009 December 9, 2009
Internet Key Exchange Protocol: IKEv2 Internet Key Exchange Protocol: IKEv2
draft-ietf-ipsecme-ikev2bis-05 draft-ietf-ipsecme-ikev2bis-06
Abstract
This document describes version 2 of the Internet Key Exchange (IKE)
protocol. IKE is a component of IPsec used for performing mutual
authentication and establishing and maintaining security associations
(SAs). It replaces and updates RFC 4306, and includes all of the
clarifications from RFC 4718.
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.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
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 April 8, 2010. This Internet-Draft will expire on June 12, 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
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
This document describes version 2 of the Internet Key Exchange (IKE) This document may contain material from IETF Documents or IETF
protocol. IKE is a component of IPsec used for performing mutual Contributions published or made publicly available before November
authentication and establishing and maintaining security associations 10, 2008. The person(s) controlling the copyright in some of this
(SAs). It replaces and updates RFC 4306, and includes all of the material may not have granted the IETF Trust the right to allow
clarifications from RFC 4718. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 7 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 6
1.1.1. Security Gateway to Security Gateway Tunnel Mode . . 8 1.1.1. Security Gateway to Security Gateway Tunnel Mode . . 7
1.1.2. Endpoint-to-Endpoint Transport Mode . . . . . . . . . 8 1.1.2. Endpoint-to-Endpoint Transport Mode . . . . . . . . . 7
1.1.3. Endpoint to Security Gateway Tunnel Mode . . . . . . 9 1.1.3. Endpoint to Security Gateway Tunnel Mode . . . . . . 8
1.1.4. Other Scenarios . . . . . . . . . . . . . . . . . . . 10 1.1.4. Other Scenarios . . . . . . . . . . . . . . . . . . . 9
1.2. The Initial Exchanges . . . . . . . . . . . . . . . . . . 10 1.2. The Initial Exchanges . . . . . . . . . . . . . . . . . . 9
1.3. The CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 13 1.3. The CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 12
1.3.1. Creating New Child SAs with the CREATE_CHILD_SA 1.3.1. Creating New Child SAs with the CREATE_CHILD_SA
Exchange . . . . . . . . . . . . . . . . . . . . . . 14 Exchange . . . . . . . . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . . . . . . . 15
1.4. The INFORMATIONAL Exchange . . . . . . . . . . . . . . . 17 1.4. The INFORMATIONAL Exchange . . . . . . . . . . . . . . . 16
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 . . . . . . . 19 1.5. Informational Messages outside of an IKE SA . . . . . . . 18
1.6. Requirements Terminology . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . 20
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 . . . . . . . . . 22
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 . . . . . . 24
2.5. Version Numbers and Forward Compatibility . . . . . . . . 27 2.5. Version Numbers and Forward Compatibility . . . . . . . . 26
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 . . . . 31 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . 30
2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 32 2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 31
2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 33 2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 32
2.8.1. Simultaneous Child SA rekeying . . . . . . . . . . . 35 2.8.1. Simultaneous Child SA rekeying . . . . . . . . . . . 34
2.8.2. Simultaneous IKE SA Rekeying . . . . . . . . . . . . 37 2.8.2. Simultaneous IKE SA Rekeying . . . . . . . . . . . . 36
2.8.3. Rekeying the IKE SA Versus Reauthentication . . . . . 38 2.8.3. Rekeying the IKE SA Versus Reauthentication . . . . . 37
2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 39 2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 38
2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 41 2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 41
2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.11. Address and Port Agility . . . . . . . . . . . . . . . . 42 2.11. Address and Port Agility . . . . . . . . . . . . . . . . 42
2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 43 2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 42
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 . . . . . . . . 44
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 . . . . . . . . 49 2.17. Generating Keying Material for Child SAs . . . . . . . . 49
2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange . . . . 50 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange . . . . 50
2.19. Requesting an Internal Address on a Remote Network . . . 51 2.19. Requesting an Internal Address on a Remote Network . . . 51
2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 53 2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 52
2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 53 2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 53
2.21.1. Error Handling in IKE_SA_INIT . . . . . . . . . . . . 54 2.21.1. Error Handling in IKE_SA_INIT . . . . . . . . . . . . 53
2.21.2. Error Handling in IKE_AUTH . . . . . . . . . . . . . 54 2.21.2. Error Handling in IKE_AUTH . . . . . . . . . . . . . 54
2.21.3. Error Handling after IKE SA is Authenticated . . . . 55 2.21.3. Error Handling after IKE SA is Authenticated . . . . 55
2.21.4. Error Handling Outside IKE SA . . . . . . . . . . . . 56 2.21.4. Error Handling Outside IKE SA . . . . . . . . . . . . 55
2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 56 2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 58 2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 57
2.23.1. Transport Mode NAT Traversal . . . . . . . . . . . . 61 2.23.1. Transport Mode NAT Traversal . . . . . . . . . . . . 61
2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 65 2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 65
3. Header and Payload Formats . . . . . . . . . . . . . . . . . 65 2.25. Exchange Collisions . . . . . . . . . . . . . . . . . . . 65
3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 66 2.25.1. Collisions While Rekeying or Closing Child SAs . . . 66
3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 69 2.25.2. Collisions While Rekeying or Closing IKE SAs . . . . 67
3.3. Security Association Payload . . . . . . . . . . . . . . 71 3. Header and Payload Formats . . . . . . . . . . . . . . . . . 67
3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 73 3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 67
3.3.2. Transform Substructure . . . . . . . . . . . . . . . 75 3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 70
3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 78 3.3. Security Association Payload . . . . . . . . . . . . . . 72
3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 78 3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 74
3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 79 3.3.2. Transform Substructure . . . . . . . . . . . . . . . 76
3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 81 3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 79
3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 82 3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 79
3.5. Identification Payloads . . . . . . . . . . . . . . . . . 83 3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 80
3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 86 3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 82
3.7. Certificate Request Payload . . . . . . . . . . . . . . . 88 3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 83
3.8. Authentication Payload . . . . . . . . . . . . . . . . . 90 3.5. Identification Payloads . . . . . . . . . . . . . . . . . 84
3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 91 3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 87
3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 92 3.7. Certificate Request Payload . . . . . . . . . . . . . . . 89
3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 93 3.8. Authentication Payload . . . . . . . . . . . . . . . . . 91
3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 96 3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 93
3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 93
3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 94
3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 97
3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 98 3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 98
3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 99 3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 100
3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 100 3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 101
3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 102 3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 103
3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 104 3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 105
3.15.1. Configuration Attributes . . . . . . . . . . . . . . 105 3.15.1. Configuration Attributes . . . . . . . . . . . . . . 106
3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 108 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 109
3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 110 3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 111
3.15.4. Address Assignment Failures . . . . . . . . . . . . . 111 3.15.4. Address Assignment Failures . . . . . . . . . . . . . 112
3.16. Extensible Authentication Protocol (EAP) Payload . . . . 112 3.16. Extensible Authentication Protocol (EAP) Payload . . . . 112
4. Conformance Requirements . . . . . . . . . . . . . . . . . . 113 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 114
5. Security Considerations . . . . . . . . . . . . . . . . . . . 115 5. Security Considerations . . . . . . . . . . . . . . . . . . . 116
5.1. Traffic selector authorization . . . . . . . . . . . . . 118 5.1. Traffic selector authorization . . . . . . . . . . . . . 119
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 119 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 120
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 119 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 121
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 120 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 121
8.1. Normative References . . . . . . . . . . . . . . . . . . 120 8.1. Normative References . . . . . . . . . . . . . . . . . . 121
8.2. Informative References . . . . . . . . . . . . . . . . . 121 8.2. Informative References . . . . . . . . . . . . . . . . . 122
Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 126 Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 127
Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 127 Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 128
B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 127 B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 128
B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 127 B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 128
Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 129
Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 128 C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 129
C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 128 C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 130
C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 129 C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 131
C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 130
C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying
Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 131 Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 132
C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA . . . . 131 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA . . . . 132
C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 131 C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 132
Appendix D. Significant Changes from RFC 4306 . . . . . . . . . 131 Appendix D. Significant Changes from RFC 4306 . . . . . . . . . 132
Appendix E. Changes Between Internet Draft Versions . . . . . . 132 Appendix E. Changes Between Internet Draft Versions . . . . . . 133
E.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 132 E.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 133
E.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 132 E.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 133
E.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 134 E.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 135
E.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 135 E.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 136
E.5. Changes from draft -02 to draft -03 . . . . . . . . . . . 136 E.5. Changes from draft -02 to draft -03 . . . . . . . . . . . 137
E.6. Changes from draft -03 to E.6. Changes from draft -03 to
draft-ietf-ipsecme-ikev2bis-00 . . . . . . . . . . . . . 137 draft-ietf-ipsecme-ikev2bis-00 . . . . . . . . . . . . . 138
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 . . . . . . . . . . . . . 138 draft-ietf-ipsecme-ikev2bis-01 . . . . . . . . . . . . . 139
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 . . . . . . . . . . . . . 142 draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 143
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 . . . . . . . . . . . . . 144 draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 145
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 . . . . . . . . . . . . . 145 draft-ietf-ipsecme-ikev2bis-03 . . . . . . . . . . . . . 146
E.11. Changes from draft-ietf-ipsecme-ikev2bis-03 to E.11. Changes from draft-ietf-ipsecme-ikev2bis-03 to
draft-ietf-ipsecme-ikev2bis-04 . . . . . . . . . . . . . 145 draft-ietf-ipsecme-ikev2bis-04 . . . . . . . . . . . . . 146
E.12. Changes from draft-ietf-ipsecme-ikev2bis-04 to E.12. Changes from draft-ietf-ipsecme-ikev2bis-04 to
draft-ietf-ipsecme-ikev2bis-05 . . . . . . . . . . . . . 146 draft-ietf-ipsecme-ikev2bis-05 . . . . . . . . . . . . . 147
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 148 E.13. Changes from draft-ietf-ipsecme-ikev2bis-05 to
draft-ietf-ipsecme-ikev2bis-06 . . . . . . . . . . . . . 149
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 151
1. Introduction 1. Introduction
{{ An introduction to the differences between RFC 4306 [IKEV2] and [[ An introduction to the differences between RFC 4306 [IKEV2] and
this document is given at the end of Section 1. It is put there this document is given at the end of Section 1. It is put there
(instead of here) to preserve the section numbering of RFC 4306. }} (instead of here) to preserve the section numbering of RFC 4306. ]]
IP Security (IPsec) provides confidentiality, data integrity, access IP Security (IPsec) provides confidentiality, data integrity, access
control, and data source authentication to IP datagrams. These control, and data source authentication to IP datagrams. These
services are provided by maintaining shared state between the source services are provided by maintaining shared state between the source
and the sink of an IP datagram. This state defines, among other and the sink of an IP datagram. This state defines, among other
things, the specific services provided to the datagram, which things, the specific services provided to the datagram, which
cryptographic algorithms will be used to provide the services, and cryptographic algorithms will be used to provide the services, and
the keys used as input to the cryptographic algorithms. the keys used as input to the cryptographic algorithms.
Establishing this shared state in a manual fashion does not scale Establishing this shared state in a manual fashion does not scale
skipping to change at page 7, line 26 skipping to change at page 7, line 26
needs to retransmit the request (or abandon the connection). needs to retransmit the request (or abandon the connection).
The first request/response of an IKE session (IKE_SA_INIT) negotiates The first request/response of an IKE session (IKE_SA_INIT) negotiates
security parameters for the IKE SA, sends nonces, and sends Diffie- security parameters for the IKE SA, sends nonces, and sends Diffie-
Hellman values. Hellman values.
The second request/response (IKE_AUTH) transmits identities, proves The second request/response (IKE_AUTH) transmits identities, proves
knowledge of the secrets corresponding to the two identities, and knowledge of the secrets corresponding to the two identities, and
sets up an SA for the first (and often only) AH or ESP Child SA sets up an SA for the first (and often only) AH or ESP Child SA
(unless there is failure setting up the AH or ESP Child SA, in which (unless there is failure setting up the AH or ESP Child SA, in which
case the IKE SA is still established without IPsec SA). case the IKE SA is still established without the IPsec SA).
The types of subsequent exchanges are CREATE_CHILD_SA (which creates The types of subsequent exchanges are CREATE_CHILD_SA (which creates
a Child SA) and INFORMATIONAL (which deletes an SA, reports error a Child SA) and INFORMATIONAL (which deletes an SA, reports error
conditions, or does other housekeeping). Every request requires a conditions, or does other housekeeping). Every request requires a
response. An INFORMATIONAL request with no payloads (other than the response. An INFORMATIONAL request with no payloads (other than the
empty Encrypted payload required by the syntax) is commonly used as a empty Encrypted payload required by the syntax) is commonly used as a
check for liveness. These subsequent exchanges cannot be used until check for liveness. These subsequent exchanges cannot be used until
the initial exchanges have completed. the initial exchanges have completed.
In the description that follows, we assume that no errors occur. In the description that follows, we assume that no errors occur.
skipping to change at page 10, line 39 skipping to change at page 10, line 39
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 encryption 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 IKE_SA_INIT exchange. These subsequent messages use the syntax
syntax of the Encrypted Payload described in Section 3.14, encrypted of the Encrypted Payload described in Section 3.14, encrypted with
with keys that are derived as described in Section 2.14. All keys that are derived as described in Section 2.14. All subsequent
subsequent messages include an Encrypted Payload, even if they are messages include an Encrypted Payload, even if they are referred to
referred to in the text as "empty". For the CREATE_CHILD_SA, in the text as "empty". For the CREATE_CHILD_SA, IKE_AUTH, or
IKE_AUTH, or IKE_INFORMATIONAL exchanges, the message following the IKE_INFORMATIONAL exchanges, the message following the header is
header is encrypted and the message including the header is integrity encrypted and the message including the header is integrity protected
protected using the cryptographic algorithms negotiated for the IKE using the cryptographic algorithms negotiated for the IKE SA.
SA.
In the following descriptions, the payloads contained in the message In the following descriptions, the payloads contained in the message
are indicated by names as listed below. are indicated by names as listed below.
Notation Payload Notation Payload
----------------------------------------- -----------------------------------------
AUTH Authentication AUTH Authentication
CERT Certificate CERT Certificate
CERTREQ Certificate Request CERTREQ Certificate Request
CP Configuration CP Configuration
skipping to change at page 12, line 31 skipping to change at page 12, line 31
payload(s) and a list of its trust anchors in CERTREQ payload(s). If payload(s) and a list of its trust anchors in CERTREQ payload(s). If
any CERT payloads are included, the first certificate provided MUST any CERT payloads are included, the first certificate provided MUST
contain the public key used to verify the AUTH field. contain the public key used to verify the AUTH field.
The optional payload IDr enables the initiator to specify which of The optional payload IDr enables the initiator to specify which of
the responder's identities it wants to talk to. This is useful when the responder's identities it wants to talk to. This is useful when
the machine on which the responder is running is hosting multiple the machine on which the responder is running is hosting multiple
identities at the same IP address. If the IDr proposed by the identities at the same IP address. If the IDr proposed by the
initiator is not acceptable to the responder, the responder might use initiator is not acceptable to the responder, the responder might use
some other IDr to finish the exchange. If the initiator then does some other IDr to finish the exchange. If the initiator then does
not accept that fact that responder used different IDr than the one not accept the fact that responder used an IDr different than the one
that was requested, the initiator can close the SA after noticing the that was requested, the initiator can close the SA after noticing the
fact. fact.
The initiator begins negotiation of a Child SA using the SAi2 The initiator begins negotiation of a Child SA using the SAi2
payload. The final fields (starting with SAi2) are described in the payload. The final fields (starting with SAi2) are described in the
description of the CREATE_CHILD_SA exchange. description of the CREATE_CHILD_SA exchange.
<-- HDR, SK {IDr, [CERT,] AUTH, <-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr} SAr2, TSi, TSr}
skipping to change at page 15, line 48 skipping to change at page 15, line 48
The NON_FIRST_FRAGMENTS_ALSO notification is used for fragmentation The NON_FIRST_FRAGMENTS_ALSO notification is used for fragmentation
control. See [IPSECARCH] for a fuller explanation. Both parties control. See [IPSECARCH] for a fuller explanation. Both parties
need to agree to sending non-first fragments before either party does need to agree to sending non-first fragments before either party does
so. It is enabled only if NON_FIRST_FRAGMENTS_ALSO notification is so. It is enabled only if NON_FIRST_FRAGMENTS_ALSO notification is
included in both the request proposing an SA and the response included in both the request proposing an SA and the response
accepting it. If the responder does not want to send or receive non- accepting it. If the responder does not want to send or receive non-
first fragments, it only omits NON_FIRST_FRAGMENTS_ALSO notification first fragments, it only omits NON_FIRST_FRAGMENTS_ALSO notification
from its response, but does not reject the whole Child SA creation. from its response, but does not 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. See Section 2.21 for a list of error
future. ]] messages that might occur if creating a Child SA fails.
1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange
The CREATE_CHILD_SA request for rekeying an IKE SA is: The CREATE_CHILD_SA request for rekeying an IKE SA is:
Initiator Responder Initiator Responder
------------------------------------------------------------------- -------------------------------------------------------------------
HDR, SK {SA, Ni, KEi} --> HDR, SK {SA, Ni, KEi} -->
The initiator sends SA offer(s) in the SA payload, a nonce in the Ni The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
payload, and a Diffie-Hellman value in the KEi payload. The KEi payload, and a Diffie-Hellman value in the KEi payload. The KEi
payload MUST be included. New initiator and responder SPIs are payload MUST be included. New initiator and responder SPIs are
supplied in the SPI fields of the SA payload. supplied in the SPI fields of the SA payload. Once a peer receives a
request to rekey an IKE SA or sends a request to rekey an IKE SA, it
SHOULD NOT start any new CREATE_CHILD_SA exchanges on the IKE SA that
is being rekeyed.
The CREATE_CHILD_SA response for rekeying an IKE SA is: The CREATE_CHILD_SA response for rekeying an IKE SA is:
<-- HDR, SK {SA, Nr,[KEr]} <-- HDR, SK {SA, Nr, KEr}
The responder replies (using the same Message ID to respond) with the The responder replies (using the same Message ID to respond) with the
accepted offer in an SA payload, and a Diffie-Hellman value in the accepted offer in an SA payload, and a Diffie-Hellman value in the
KEr payload if the selected cryptographic suite includes that group. KEr payload if the selected cryptographic suite includes that group.
The new IKE SA has its message counters set to 0, regardless of what The new IKE SA has its message counters set to 0, regardless of what
they were in the earlier IKE SA. The first IKE requests from both they were in the earlier IKE SA. The first IKE requests from both
sides on the new IKE SA will have message ID 0. The old IKE SA sides on the new IKE SA will have message ID 0. The old IKE SA
retains its numbering, so any further requests (for example, to retains its numbering, so any further requests (for example, to
delete the IKE SA) will have consecutive numbering. The new IKE SA delete the IKE SA) will have consecutive numbering. The new IKE SA
skipping to change at page 20, line 18 skipping to change at page 20, line 18
Association or SA) can be found in [IPSECARCH]. It should be noted Association or SA) can be found in [IPSECARCH]. It should be noted
that parts of IKEv2 rely on some of the processing rules in that parts of IKEv2 rely on some of the processing rules in
[IPSECARCH], as described in various sections of this document. [IPSECARCH], as described in various sections of this document.
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. }}
This document contains clarifications and amplifications to IKEv2 This document contains clarifications and amplifications to IKEv2
[IKEV2]. The clarifications are mostly based on [Clarif]. The [IKEV2]. The clarifications are mostly based on [Clarif]. The
changes listed in that document were discussed in the IPsec Working changes listed in that document were discussed in the IPsec Working
Group and, after the Working Group was disbanded, on the IPsec Group and, after the Working Group was disbanded, on the IPsec
mailing list. That document contains detailed explanations of areas mailing list. That document contains detailed explanations of areas
that were unclear in IKEv2, and is thus useful to implementers of that were unclear in IKEv2, and is thus useful to implementers of
IKEv2. IKEv2.
The protocol described in this document retains the same major The protocol described in this document retains the same major
version number (2) and minor version number (0) as was used in RFC version number (2) and minor version number (0) as was used in RFC
skipping to change at page 21, line 24 skipping to change at page 21, line 22
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.
Section 2.21 has been greatly expanded to cover the different cases Section 2.21 has been greatly expanded to cover the different cases
where error responses are needed and the appropriate responses to where error responses are needed and the appropriate responses to
them. them.
All of Section 2.25 was added to explain how to act when there are
timing collisions when deleting and/or rekeying SAs.
2. IKE Protocol Details and Variations 2. IKE Protocol Details and Variations
IKE normally listens and sends on UDP port 500, though IKE messages IKE normally listens and sends on UDP port 500, though IKE messages
may also be received on UDP port 4500 with a slightly different may also be received on UDP port 4500 with a slightly different
format (see Section 2.23). Since UDP is a datagram (unreliable) format (see Section 2.23). Since UDP is a datagram (unreliable)
protocol, IKE includes in its definition recovery from transmission protocol, IKE includes in its definition recovery from transmission
errors, including packet loss, packet replay, and packet forgery. errors, including packet loss, packet replay, and packet forgery.
IKE is designed to function so long as (1) at least one of a series IKE is designed to function so long as (1) at least one of a series
of retransmitted packets reaches its destination before timing out; of retransmitted packets reaches its destination before timing out;
and (2) the channel is not so full of forged and replayed packets so and (2) the channel is not so full of forged and replayed packets so
skipping to change at page 31, line 10 skipping to change at page 31, line 10
regenerated. The cookie can be recomputed when the IKE_SA_INIT regenerated. The cookie can be recomputed when the IKE_SA_INIT
arrives the second time and compared to the cookie in the received arrives the second time and compared to the cookie in the received
message. If it matches, the responder knows that the cookie was message. If it matches, the responder knows that the cookie was
generated since the last change to <secret> and that IPi must be the generated since the last change to <secret> and that IPi must be the
same as the source address it saw the first time. Incorporating SPIi same as the source address it saw the first time. Incorporating SPIi
into the calculation ensures that if multiple IKE SAs are being set into the calculation ensures that if multiple IKE SAs are being set
up in parallel they will all get different cookies (assuming the up in parallel they will all get different cookies (assuming the
initiator chooses unique SPIi's). Incorporating Ni in the hash initiator chooses unique SPIi's). Incorporating Ni in the hash
ensures that an attacker who sees only message 2 can't successfully ensures that an attacker who sees only message 2 can't successfully
forge a message 3. Also, incorporating Ni in the hash prevents an forge a message 3. Also, incorporating Ni in the hash prevents an
attacker from fetching one one cookie from the other end, and then attacker from fetching one cookie from the other end, and then
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
skipping to change at page 31, line 41 skipping to change at page 31, line 41
sends a non-zero responder SPI, the initiator should not reject the sends a non-zero responder SPI, the initiator should not reject the
response for only that reason. response for only that reason.
When one party receives an IKE_SA_INIT request containing a cookie When one party receives an IKE_SA_INIT request containing a cookie
whose contents do not match the value expected, that party MUST whose contents do not match the value expected, that party MUST
ignore the cookie and process the message as if no cookie had been ignore the cookie and process the message as if no cookie had been
included; usually this means sending a response containing a new included; usually this means sending a response containing a new
cookie. The initiator should limit the number of cookie exchanges it cookie. The initiator should limit the number of cookie exchanges it
tries before giving up. An attacker can forge multiple cookie tries before giving up. An attacker can forge multiple cookie
responses to the initiator's IKE_SA_INIT message, and each of those responses to the initiator's IKE_SA_INIT message, and each of those
forged cookie reply will trigger two packets: one packet from the forged cookie replies will trigger two packets: one packet from the
initiator to the responder (which will reject those cookies), and one initiator to the responder (which will reject those cookies), and one
reply from responder to initiator that includes the correct cookie. reply from responder to initiator that includes the correct cookie.
2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD
There are two common reasons why the initiator may have to retry the There are two common reasons why the initiator may have to retry the
IKE_SA_INIT exchange: the responder requests a cookie or wants a IKE_SA_INIT exchange: the responder requests a cookie or wants a
different Diffie-Hellman group than was included in the KEi payload. different Diffie-Hellman group than was included in the KEi payload.
If the initiator receives a cookie from the responder, the initiator If the initiator receives a cookie from the responder, the initiator
needs to decide whether or not to include the cookie in only the next needs to decide whether or not to include the cookie in only the next
skipping to change at page 34, line 14 skipping to change at page 34, line 14
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.
Implementations may wish to support in-place rekeying of SAs, since Implementations may wish to support in-place rekeying of SAs, since
doing so offers better performance and is likely to reduce the number doing so offers better performance and is 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.
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 To rekey an IKE SA, establish a new equivalent IKE SA (see
SA. An IKE SA so created inherits all of the original IKE SA's Child Section 2.18 below) with the peer to whom the old IKE SA is shared
SAs, and the new IKE SA is used for all control messages needed to using a CREATE_CHILD_SA within the existing IKE SA. An IKE SA so
maintain those Child SAs. The old IKE SA is then deleted, and the created inherits all of the original IKE SA's Child SAs, and the new
Delete payload to delete itself MUST be the last request sent over IKE SA is used for all control messages needed to maintain those
the old IKE SA. Note that, when rekeying, the new Child SA SHOULD Child SAs. After the new equivalent IKE SA is created, the initiator
NOT have different traffic selectors and algorithms than the old one. deletes the old IKE SA, and the Delete payload to delete itself MUST
be the last request sent over the old IKE SA. Note that, when
rekeying, the new Child SA SHOULD NOT have different traffic
selectors and algorithms than the old one.
SAs should be rekeyed proactively, i.e., the new SA should be SAs should be rekeyed proactively, i.e., the new SA should be
established before the old one expires and becomes unusable. Enough established before the old one expires and becomes unusable. Enough
time should elapse between the time the new SA is established and the time should elapse between the time the new SA is established and the
old one becomes unusable so that traffic can be switched over to the old one becomes unusable so that traffic can be 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
skipping to change at page 37, line 52 skipping to change at page 38, line 6
rekeying, so it can ignore the error message. rekeying, so it can ignore the error message.
2.8.2. Simultaneous IKE SA Rekeying 2.8.2. Simultaneous IKE SA Rekeying
Probably the most complex case occurs when both peers try to rekey Probably the most complex case occurs when both peers try to rekey
the IKE_SA at the same time. Basically, the text in Section 2.8 the IKE_SA at the same time. Basically, the text in Section 2.8
applies to this case as well; however, it is important to ensure that applies to this case as well; however, it is important to ensure that
the CHILD_SAs are inherited by the right IKE_SA. the CHILD_SAs are inherited by the right IKE_SA.
The case where both endpoints notice the simultaneous rekeying works The case where both endpoints notice the simultaneous rekeying works
the same way as with CHILD_SAs. After the CREATE_CHILD_SA exchanges, the same way as with Child SAs. After the CREATE_CHILD_SA exchanges,
three IKE_SAs exist between A and B; the one containing the lowest three IKE SAs exist between A and B: the old IKE SA and two new IKE
nonce inherits the CHILD_SAs. SAs. The new IKE SA containing the lowest nonce inherits the Child
SAs. If only one peer detects a simultaneous rekey, redundant SAs
are not created. In this case, when the peer that did not notice the
simultaneous rekey gets the request to rekey the IKE SA that it has
already successfully rekeyed, it MUST return TEMPORARY_FAILURE
because it is an IKE SA that it is currently trying to close (whether
or not it has already sent the delete notification for the SA). If
the peer that did notice the simultaneous rekey gets the delete
request from the other peer for the old IKE SA, it knows that the
other peer did not detect the simultaneous rekey, and the first peer
can forget its own rekey attempt.
However, there is a twist to the other case where one rekeying However, there is a twist to the other case where one rekeying
finishes first: finishes first:
Host A Host B Host A Host B
------------------------------------------------------------------- -------------------------------------------------------------------
send req1: send req1:
SA(..,SPIa1,..),Ni1,.. --> SA(..,SPIa1,..),Ni1,.. -->
<-- send req2: SA(..,SPIb1,..),Ni2,.. <-- send req2: SA(..,SPIb1,..),Ni2,..
--> recv req1 --> recv req1
skipping to change at page 45, line 40 skipping to change at page 46, line 4
= prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )
(indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er,
SK_pi, and SK_pr are taken in order from the generated bits of the SK_pi, and SK_pr are taken in order from the generated bits of the
prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman
exchange. g^ir is represented as a string of octets in big endian exchange. g^ir is represented as a string of octets in big endian
order padded with zeros if necessary to make it the length of the order padded with zeros if necessary to make it the length of the
modulus. Ni and Nr are the nonces, stripped of any headers. For modulus. Ni and Nr are the nonces, stripped of any headers. For
historical backwards-compatibility reasons, there are two PRFs that historical backwards-compatibility reasons, there are two PRFs that
are treated specially in this calculation. If the negotiated PRF is are treated specially in this calculation. If the negotiated PRF is
AES-XCBC-PRF-128 [RFC4434] or AES-CMAC-PRF-128 [RFC4615], only the AES-XCBC-PRF-128 [AESXCBCPRF128] or AES-CMAC-PRF-128 [AESCMACPRF128],
first 64 bits of Ni and the first 64 bits of Nr are used in the only the first 64 bits of Ni and the first 64 bits of Nr are used in
calculation. the calculation.
The two directions of traffic flow use different keys. The keys used The two directions of traffic flow use different keys. The keys used
to protect messages from the original initiator are SK_ai and SK_ei. to protect messages from the original initiator are SK_ai and SK_ei.
The keys used to protect messages in the other direction are SK_ar The keys used to protect messages in the other direction are SK_ar
and SK_er. and SK_er.
2.15. Authentication of the IKE SA 2.15. Authentication of the IKE SA
When not using extensible authentication (see Section 2.16), the When not using extensible authentication (see Section 2.16), the
peers are authenticated by having each sign (or MAC using a shared peers are authenticated by having each sign (or MAC using a padded
secret as the key) a block of data. For the responder, the octets to shared secret as the key, as described later in this section) a block
be signed start with the first octet of the first SPI in the header of data. For the responder, the octets to be signed start with the
of the second message (IKE_SA_INIT response) and end with the last first octet of the first SPI in the header of the second message
octet of the last payload in the second message. Appended to this (IKE_SA_INIT response) and end with the last octet of the last
(for purposes of computing the signature) are the initiator's nonce payload in the second message. Appended to this (for purposes of
Ni (just the value, not the payload containing it), and the value computing the signature) are the initiator's nonce Ni (just the
prf(SK_pr,IDr') where IDr' is the responder's ID payload excluding value, not the payload containing it), and the value prf(SK_pr,IDr')
the fixed header. Note that neither the nonce Ni nor the value where IDr' is the responder's ID payload excluding the fixed header.
prf(SK_pr,IDr') are transmitted. Similarly, the initiator signs the Note that neither the nonce Ni nor the value prf(SK_pr,IDr') are
first message (IKE_SA_INIT request), starting with the first octet of transmitted. Similarly, the initiator signs the first message
the first SPI in the header and ending with the last octet of the (IKE_SA_INIT request), starting with the first octet of the first SPI
last payload. Appended to this (for purposes of computing the in the header and ending with the last octet of the last payload.
signature) are the responder's nonce Nr, and the value Appended to this (for purposes of computing the signature) are the
prf(SK_pi,IDi'). In the above calculation, IDi' and IDr' are the responder's nonce Nr, and the value prf(SK_pi,IDi'). In the above
entire ID payloads excluding the fixed header. It is critical to the calculation, IDi' and IDr' are the entire ID payloads excluding the
security of the exchange that each side sign the other side's nonce. fixed header. It is critical to the security of the exchange that
each side sign the other side's nonce.
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 | RestOfInitIDPayload
RestOfInitIDPayload = IDType | RESERVED | InitIDData RestOfInitIDPayload = IDType | RESERVED | InitIDData
MACedIDForI = prf(SK_pi, RestOfInitIDPayload) MACedIDForI = prf(SK_pi, RestOfInitIDPayload)
The responder's signed octets can be described as: The responder's signed octets can be described as:
ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR
GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
RealIKEHDR = SPIi | SPIr | . . . | Length RealIKEHDR = SPIi | SPIr | . . . | Length
RealMessage2 = RealIKEHDR | RestOfMessage2 RealMessage2 = RealIKEHDR | RestOfMessage2
NonceIPayload = PayloadHeader | NonceIData NonceIPayload = PayloadHeader | NonceIData
ResponderIDPayload = PayloadHeader | RestOfIDPayload ResponderIDPayload = PayloadHeader | RestOfRespIDPayload
RestOfRespIDPayload = IDType | RESERVED | RespIDData RestOfRespIDPayload = IDType | RESERVED | RespIDData
MACedIDForR = prf(SK_pr, RestOfRespIDPayload) MACedIDForR = prf(SK_pr, RestOfRespIDPayload)
Note that all of the payloads are included under the signature, Note that all of the payloads are included under the signature,
including any payload types not defined in this document. If the including any payload types not defined in this document. If the
first message of the exchange is sent multiple times (such as with a first message of the exchange is sent multiple times (such as with a
responder cookie and/or a different Diffie-Hellman group), it is the responder cookie and/or a different Diffie-Hellman group), it is the
latest version of the message that is signed. latest version of the message that is signed.
Optionally, messages 3 and 4 MAY include a certificate, or Optionally, messages 3 and 4 MAY include a certificate, or
skipping to change at page 47, line 33 skipping to change at page 47, line 48
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.) The pre- which is designed to prevent off-line dictionary attacks.) The pre-
shared key needs to contain as much unpredictability as the strongest shared key needs to contain as much unpredictability as the strongest
key being negotiated. In the case of a pre-shared key, the AUTH key being negotiated. In the case 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
string is added so that if the shared secret is derived from a string is added so that if the shared secret is derived from a
password, the IKE implementation need not store the password in password, the IKE implementation need not store the password in
cleartext, but rather can store the value prf(Shared Secret,"Key Pad cleartext, but rather can store the value prf(Shared Secret,"Key Pad
for IKEv2"), which could not be used as a password equivalent for for IKEv2"), which could not be used as a password equivalent for
protocols other than IKEv2. As noted above, deriving the shared protocols other than IKEv2. As noted above, deriving the shared
secret from a password is not secure. This construction is used secret from a password is not secure. This construction is used
skipping to change at page 54, line 46 skipping to change at page 55, line 22
certificate, etc.) SHOULD result in an AUTHENTICATION_FAILED certificate, etc.) SHOULD result in an AUTHENTICATION_FAILED
notification. If the error occurred on the responder, the notification. If the error occurred on the responder, the
notification is returned in the protected response, and is usually notification is returned in the protected response, and is usually
the only payload in that response. Although the IKE_AUTH messages the only payload in that response. Although the IKE_AUTH messages
are encrypted and integrity protected, if the peer receiving this are encrypted and integrity protected, if the peer receiving this
notification has not authenticated the other end yet, that peer needs notification has not authenticated the other end yet, that peer needs
to treat the information with caution. to treat the information with caution.
If the error occurs on the initiator, the notification MAY be If the error occurs on the initiator, the notification MAY be
returned in a separate INFORMATIONAL exchange, usually with no other returned in a separate INFORMATIONAL exchange, usually with no other
payloads. This is exception for the general rule of not starting new payloads. This is an exception for the general rule of not starting
exchanges based on errors in responses. new exchanges based on errors in responses.
Note, however, that request messages that contain an unsupported Note, however, that request messages that contain an unsupported
critical payload, or where the whole message is malformed (rather critical payload, or where the whole message is malformed (rather
than just bad payload contents), MUST be rejected in their entirety, than just bad payload contents), MUST be rejected in their entirety,
and MUST only lead to an UNSUPPORTED_CRITICAL_PAYLOAD or and MUST only lead to an UNSUPPORTED_CRITICAL_PAYLOAD or
INVALID_SYNTAX Notification sent as response. The receiver should INVALID_SYNTAX Notification sent as a response. The receiver should
not verify the payloads related to authentication in this case. not verify the payloads related to authentication in this case.
If authentication has succeeded in the IKE_AUTH exchange, the IKE SA If authentication has succeeded in the IKE_AUTH exchange, the IKE SA
is established; however, establishing the Child SA or requesting is established; however, establishing the Child SA or requesting
configuration information may still fail. This failure does not configuration information may still fail. This failure does not
automatically cause the IKE SA to be deleted. Specifically, a automatically cause the IKE SA to be deleted. Specifically, a
responder may include all the payloads associated with authentication responder may include all the payloads associated with authentication
(IDr, Cert and AUTH) while sending error notifications for the (IDr, Cert and AUTH) while sending error notifications for the
piggybacked exchanges (FAILED_CP_REQUIRED, INVALID_SELECTORS, piggybacked exchanges (FAILED_CP_REQUIRED, INVALID_SELECTORS,
NO_PROPOSAL_CHOSEN, and so on), and the initiator MUST NOT fail the NO_PROPOSAL_CHOSEN, and so on), and the initiator MUST NOT fail the
authentication because of this. The initiator MAY, of course, for authentication because of this. The initiator MAY, of course, for
reasons of policy later delete such an IKE SA. reasons of policy later delete such an IKE SA.
In an IKE_AUTH exchange, or in the INFORMATIONAL exchange immediately In an IKE_AUTH exchange, or in the INFORMATIONAL exchange immediately
following it (in case an error happened in when processing response following it (in case an error happened in when processing a response
to IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and to IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and
AUTHENTICATION_FAILED notifications are the only ones to cause the AUTHENTICATION_FAILED notifications are the only ones to cause the
IKE SA to be deleted or not created, without a DELETE payload. IKE SA to be deleted or not created, without a DELETE payload.
Extension documents may define new error notifications with these Extension documents may define new error notifications with these
semantics, but MUST NOT use them unless the peer has been shown to semantics, but MUST NOT use them unless the peer has been shown to
understand them. understand them.
NOTE FOR WG DISCUSSION: Having other payloads in the message is NOTE FOR WG DISCUSSION: Having other payloads in the message is
allowed but there are none suggested. One WG member mentioned the allowed but there are none suggested. One WG member mentioned the
possibility of adding a DELETE payload when the error is sent in a possibility of adding a DELETE payload when the error is sent in a
skipping to change at page 57, line 26 skipping to change at page 57, line 50
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.
The data associated with this notification includes a two-octet The data associated with this notification includes a two-octet
IPComp CPI followed by a one-octet transform ID optionally followed IPComp CPI followed by a one-octet transform ID optionally followed
by attributes whose length and format are defined by that transform by attributes whose length and format are defined by that transform
ID. A message proposing an SA may contain multiple IPCOMP_SUPPORTED ID. A message proposing an SA may contain multiple IPCOMP_SUPPORTED
notifications to indicate multiple supported algorithms. A message notifications to indicate multiple supported 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 are listed here. The values in the following table
are only current as of the publication date of RFC 4306. Other
values may have been added since then or will be added after the
publication of this document. Readers should refer to [IKEV2IANA]
for the latest values.
Name Number Defined In Name Number Defined In
------------------------------------- -------------------------------------
RESERVED 0
IPCOMP_OUI 1 IPCOMP_OUI 1
IPCOMP_DEFLATE 2 RFC 2394 IPCOMP_DEFLATE 2 RFC 2394
IPCOMP_LZS 3 RFC 2395 IPCOMP_LZS 3 RFC 2395
IPCOMP_LZJH 4 RFC 3051 IPCOMP_LZJH 4 RFC 3051
RESERVED TO IANA 5-240
PRIVATE USE 241-255
Although there has been discussion of allowing multiple compression Although there has been discussion of allowing multiple compression
algorithms to be accepted and to have different compression algorithms to be accepted and to have different compression
algorithms available for the two directions of a Child SA, algorithms available for the two directions of a Child SA,
implementations of this specification MUST NOT accept an IPComp implementations of this specification MUST NOT accept an IPComp
algorithm that was not proposed, MUST NOT accept more than one, and algorithm that was not proposed, MUST NOT accept more than one, and
MUST NOT compress using an algorithm other than one proposed and MUST NOT compress using an algorithm other than one proposed and
accepted in the setup of the Child SA. accepted in the setup of the Child SA.
A side effect of separating the negotiation of IPComp from A side effect of separating the negotiation of IPComp from
skipping to change at page 61, line 19 skipping to change at page 61, line 47
o The original source and destination IP address required for the o The original source and destination IP address required for the
transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS])
are obtained from the Traffic Selectors associated with the are obtained from the Traffic Selectors associated with the
exchange. In the case of NAT traversal, the Traffic Selectors exchange. In the case of NAT traversal, the Traffic Selectors
MUST contain exactly one IP address, which is then used as the MUST contain exactly one IP address, which is then used as the
original IP address. original IP address.
o There are cases where a NAT box decides to remove mappings that o There are cases where a NAT box decides to remove mappings that
are still alive (for example, the keepalive interval is too long, are still alive (for example, the keepalive interval is too long,
or the NAT box is rebooted). To recover in these cases, hosts or the NAT box is rebooted). To recover in these cases, hosts
that are not behind a NAT SHOULD send all packets (including
retransmission packets) to the IP address and port from the last
valid authenticated packet from the other end (i.e., dynamically
update the address). A host behind a NAT SHOULD NOT do this
because it opens a DoS attack possibility. Any authenticated IKE
packet or any authenticated UDP-encapsulated ESP packet can be
used to detect that the IP address or the port has changed.
o There are cases where a NAT box decides to remove mappings that
are still alive (for example, the keepalive interval is too long,
or the NAT box is rebooted). To recover in these cases, hosts
that do not support other methods of recovery such as MOBIKE that do not support other methods of recovery such as MOBIKE
[MOBIKE], and that are not behind a NAT, SHOULD send all packets [MOBIKE], and that are not behind a NAT, SHOULD send all packets
(including retransmission packets) to the IP address and port from (including retransmission packets) to the IP address and port from
the last valid authenticated packet from the other end (that is, the last valid authenticated packet from the other end (that is,
they should dynamically update the address). A host behind a NAT they should dynamically update the address). A host behind a NAT
SHOULD NOT do this because it opens a possible denial-of-service SHOULD NOT do this because it opens a possible denial-of-service
attack. Any authenticated IKE packet or any authenticated UDP- attack. Any authenticated IKE packet or any authenticated UDP-
encapsulated ESP packet can be used to detect that the IP address encapsulated ESP packet can be used to detect that the IP address
or the port has changed. When IKEv2 is used with MOBIKE, or the port has changed. When IKEv2 is used with MOBIKE,
dynamically updating the addresses described above interferes with dynamically updating the addresses described above interferes with
skipping to change at page 65, line 48 skipping to change at page 66, line 48
based IPsec requires multiple operating modes and negotiation (see based IPsec requires multiple operating modes and negotiation (see
[ECN]). IKEv2 simplifies this situation by requiring that ECN be [ECN]). IKEv2 simplifies this situation by requiring that ECN be
usable in the outer IP headers of all tunnel-mode IPsec SAs created usable in the outer IP headers of all tunnel-mode IPsec SAs created
by IKEv2. Specifically, tunnel encapsulators and decapsulators for by IKEv2. Specifically, tunnel encapsulators and decapsulators for
all tunnel-mode SAs created by IKEv2 MUST support the ECN full- all tunnel-mode SAs created by IKEv2 MUST support the ECN full-
functionality option for tunnels specified in [ECN] and MUST functionality option for tunnels specified in [ECN] and MUST
implement the tunnel encapsulation and decapsulation processing implement the tunnel encapsulation and decapsulation processing
specified in [IPSECARCH] to prevent discarding of ECN congestion specified in [IPSECARCH] to prevent discarding of ECN congestion
indications. indications.
2.25. Exchange Collisions
Because IKEv2 exchanges can be initiated by either peer, it is
possible that two exchanges affecting the same SA partly overlap.
This can lead to a situation where the SA state information is
temporarily not synchronized, and a peer can receive a request that
it cannot process in a normal fashion.
Obviously, using a window size greater than 1 leads to more complex
situations, especially if requests are processed out of order. This
section concentrates on problems that can arise even with a window
size of 1, and recommends solutions.
A TEMPORARY_FAILURE notification SHOULD be sent when a peer receives
a request that cannot be completed due to a temporary condition such
as a rekeying operation. When a peer receives a TEMPORARY_FAILURE
notification, it MUST NOT immediately retry the operation; it MUST
wait so that the sender may complete whatever operation caused the
temporary condition. The recipient MAY retry the request one or more
times over a period of several minutes. If a peer continues to
receive TEMPORARY_FAILURE on the same IKE SA after several minutes,
it SHOULD conclude that state information is out-of-sync and close
the IKE SA.
A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives
a request to rekey a Child SA that does not exist. A peer that
receives a CHILD_SA_NOT_FOUND notification SHOULD silently delete the
Child SA and send a request to create a new Child SA from scratch.
2.25.1. Collisions While Rekeying or Closing Child SAs
If a peer receives a request to rekey a Child SA that it is currently
trying to close, it SHOULD reply with TEMPORARY_FAILURE. If a peer
receives a request to rekey a Child SA that it is currently rekeying,
it SHOULD reply as usual, and SHOULD prepare to close redundant SAs
later based on the nonces. If a peer receives a request to rekey a
Child SA that does not exist, it SHOULD reply with
CHILD_SA_NOT_FOUND.
If a peer receives a request to close a Child SA that it is currently
trying to close, it SHOULD reply without Delete payloads. If a peer
receives a request to close a Child SA that it is currently rekeying,
it SHOULD reply as usual, with Delete payload. If a peer receives a
request to close a Child SA that does not exist, it SHOULD reply
without Delete payloads.
If a peer receives a request to rekey the IKE SA, and it is currently
creating, rekeying, or closing a Child SA of that IKE SA, it SHOULD
reply with TEMPORARY_FAILURE.
2.25.2. Collisions While Rekeying or Closing IKE SAs
If a peer receives a request to rekey an IKE SA that it is currently
rekeying, it SHOULD reply as usual, and SHOULD prepare to close
redundant SAs and move inherited Child SAs later based on the nonces.
If a peer receives a request to rekey an IKE SA that it is currently
trying to close, it SHOULD reply with TEMPORARY_FAILURE.
If a peer receives a request to close an IKE SA that it is currently
rekeying, it SHOULD reply as usual, and forget about its own rekeying
request. If a peer receives a request to close an IKE SA that it is
currently trying to close, it SHOULD reply as usual, and forget about
its own close request.
If a peer receives a request to create or rekey a Child SA when it is
currently rekeying the IKE SA, it SHOULD reply with
TEMPORARY_FAILURE. If a peer receives a request to delete a Child SA
when it is currently rekeying the IKE SA, it SHOULD reply as usual,
with a Delete payload.
3. Header and Payload Formats 3. Header and Payload Formats
In the tables in this section, some cryptographic primitives and In the tables in this section, some cryptographic primitives and
configuation attributes are marked as "UNSPECIFIED". These are items configuation attributes are marked as "UNSPECIFIED". These are items
for which there are no known specifications and therefore for which there are no known specifications and therefore
interoperability is currently impossible. A future specification may interoperability is currently impossible. A future specification may
describe their use, but until such specification is made, describe their use, but until such specification is made,
implementations SHOULD NOT attempt to use items marked as implementations SHOULD NOT attempt to use items marked as
"UNSPECIFIED" in implementations that are meant to be interoperable. "UNSPECIFIED" in implementations that are meant to be interoperable.
skipping to change at page 67, line 52 skipping to change at page 70, line 21
INVALID_MAJOR_VERSION notification message as described in Section INVALID_MAJOR_VERSION notification message as described in Section
2.5. 2.5.
o Minor Version (4 bits) - Indicates the minor version of the IKE o Minor Version (4 bits) - Indicates the minor version of the IKE
protocol in use. Implementations based on this version of IKE protocol in use. Implementations based on this version of IKE
MUST set the Minor Version to 0. They MUST ignore the minor MUST set the Minor Version to 0. They MUST ignore the minor
version number of received messages. version number of received messages.
o Exchange Type (1 octet) - Indicates the type of exchange being o Exchange Type (1 octet) - Indicates the type of exchange being
used. This constrains the payloads sent in each message in an used. This constrains the payloads sent in each message in an
exchange. exchange. The values in the following table are only current as
of the publication date of RFC 4306. Other values may have been
added since then or will be added after the publication of this
document. Readers should refer to [IKEV2IANA] for the latest
values.
Exchange Type Value Exchange Type Value
---------------------------------- ----------------------------------
RESERVED 0-33
IKE_SA_INIT 34 IKE_SA_INIT 34
IKE_AUTH 35 IKE_AUTH 35
CREATE_CHILD_SA 36 CREATE_CHILD_SA 36
INFORMATIONAL 37 INFORMATIONAL 37
RESERVED TO IANA 38-239
PRIVATE USE 240-255
o Flags (1 octet) - Indicates specific options that are set for the o Flags (1 octet) - Indicates specific options that are set for the
message. Presence of options is indicated by the appropriate bit message. Presence of options is indicated by the appropriate bit
in the flags field being set. The bits are defined LSB first, so in the flags field being set. The bits are defined LSB first, so
bit 0 would be the least significant bit of the Flags octet. In bit 0 would be the least significant bit of the Flags octet. In
the description below, a bit being 'set' means its value is '1', the description below, a bit being 'set' means its value is '1',
while 'cleared' means its value is '0'. while 'cleared' means its value is '0'.
* X(reserved) (bits 0-2) - These bits MUST be cleared when * X(reserved) (bits 0-2) - These bits MUST be cleared when
sending and MUST be ignored on receipt. sending and MUST be ignored on receipt.
skipping to change at page 69, line 35 skipping to change at page 72, line 5
o Next Payload (1 octet) - Identifier for the payload type of the o Next Payload (1 octet) - Identifier for the payload type of the
next payload in the message. If the current payload is the last next payload in the message. If the current payload is the last
in the message, then this field will be 0. This field provides a in the message, then this field will be 0. This field provides a
"chaining" capability whereby additional payloads can be added to "chaining" capability whereby additional payloads can be added to
a message by appending it to the end of the message and setting a message by appending it to the end of the message and setting
the "Next Payload" field of the preceding payload to indicate the the "Next Payload" field of the preceding payload to indicate the
new payload's type. An Encrypted payload, which must always be new payload's type. An Encrypted payload, which must always be
the last payload of a message, is an exception. It contains data the last payload of a message, is an exception. It contains data
structures in the format of additional payloads. In the header of structures in the format of additional payloads. In the header of
an Encrypted payload, the Next Payload field is set to the payload an Encrypted payload, the Next Payload field is set to the payload
type of the first contained payload (instead of 0). The payload type of the first contained payload (instead of 0).
type values are:
o The payload type values are listed here. The values in the
following table are only current as of the publication date of RFC
4306. Other values may have been added since then or will be
added after the publication of this document. Readers should
refer to [IKEV2IANA] for the latest values.
Next Payload Type Notation Value Next Payload Type Notation Value
-------------------------------------------------- --------------------------------------------------
No Next Payload 0 No Next Payload 0
RESERVED 1-32
Security Association SA 33 Security Association SA 33
Key Exchange KE 34 Key Exchange KE 34
Identification - Initiator IDi 35 Identification - Initiator IDi 35
Identification - Responder IDr 36 Identification - Responder IDr 36
Certificate CERT 37 Certificate CERT 37
Certificate Request CERTREQ 38 Certificate Request CERTREQ 38
Authentication AUTH 39 Authentication AUTH 39
Nonce Ni, Nr 40 Nonce Ni, Nr 40
Notify N 41 Notify N 41
Delete D 42 Delete D 42
Vendor ID V 43 Vendor ID V 43
Traffic Selector - Initiator TSi 44 Traffic Selector - Initiator TSi 44
Traffic Selector - Responder TSr 45 Traffic Selector - Responder TSr 45
Encrypted E 46 Encrypted E 46
Configuration CP 47 Configuration CP 47
Extensible Authentication EAP 48 Extensible Authentication EAP 48
RESERVED TO IANA 49-127
PRIVATE USE 128-255
(Payload type values 1-32 should not be assigned in the (Payload type values 1-32 should not be assigned in the
future so that there is no overlap with the code assignments future so that there is no overlap with the code assignments
for IKEv1.) for IKEv1.)
o Critical (1 bit) - MUST be set to zero if the sender wants the o Critical (1 bit) - MUST be set to zero if the sender wants the
recipient to skip this payload if it does not understand the recipient to skip this payload if it does not understand the
payload type code in the Next Payload field of the previous payload type code in the Next Payload field of the previous
payload. MUST be set to one if the sender wants the recipient to payload. MUST be set to one if the sender wants the recipient to
reject this entire message if it does not understand the payload reject this entire message if it does not understand the payload
skipping to change at page 72, line 44 skipping to change at page 74, line 50
Proposal. Instead, the initiator would have to construct two Proposal. Instead, the initiator would have to construct two
different Proposals, each with two transforms. different Proposals, each with two transforms.
A given transform MAY have one or more Attributes. Attributes are A given transform MAY have one or more Attributes. Attributes are
necessary when the transform can be used in more than one way, as necessary when the transform can be used in more than one way, as
when an encryption algorithm has a variable key size. The transform when an encryption algorithm has a variable key size. The transform
would specify the algorithm and the attribute would specify the key would specify the algorithm and the attribute would specify the key
size. Most transforms do not have attributes. A transform MUST NOT size. Most transforms do not have attributes. A transform MUST NOT
have multiple attributes of the same type. To propose alternate have multiple attributes of the same type. To propose alternate
values for an attribute (for example, multiple key sizes for the AES values for an attribute (for example, multiple key sizes for the AES
encryption algorithm), and implementation MUST include multiple encryption algorithm), an implementation MUST include multiple
Transforms with the same Transform Type each with a single Attribute. Transforms with the same Transform Type each with a single Attribute.
Note that the semantics of Transforms and Attributes are quite Note that the semantics of Transforms and Attributes are quite
different from those in IKEv1. In IKEv1, a single Transform carried different from those in IKEv1. In IKEv1, a single Transform carried
multiple algorithms for a protocol with one carried in the Transform multiple algorithms for a protocol with one carried in the Transform
and the others carried in the Attributes. and the others carried in the Attributes.
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 74, line 13 skipping to change at page 76, line 19
all transforms and attributes that follow. all transforms and attributes that follow.
o Proposal # (1 octet) - When a proposal is made, the first proposal o Proposal # (1 octet) - When a proposal is made, the first proposal
in an SA payload MUST be #1, and subsequent proposals MUST be one in an SA payload MUST be #1, and subsequent proposals MUST be one
more than the previous proposal (indicating an OR of the two more than the previous proposal (indicating an OR of the two
proposals). When a proposal is accepted, the proposal number in proposals). When a proposal is accepted, the proposal number in
the SA payload MUST match the number on the proposal sent that was the SA payload MUST match the number on the proposal sent that was
accepted. accepted.
o Protocol ID (1 octet) - Specifies the IPsec protocol identifier o Protocol ID (1 octet) - Specifies the IPsec protocol identifier
for the current negotiation. The defined values are: for the current negotiation. The values in the following table
are only current as of the publication date of RFC 4306. Other
values may have been added since then or will be added after the
publication of this document. Readers should refer to [IKEV2IANA]
for the latest values.
Protocol Protocol ID Protocol Protocol ID
----------------------------------- -----------------------------------
RESERVED 0
IKE 1 IKE 1
AH 2 AH 2
ESP 3 ESP 3
RESERVED TO IANA 4-200
PRIVATE USE 201-255
o SPI Size (1 octet) - For an initial IKE SA negotiation, this field o SPI Size (1 octet) - For an initial IKE SA negotiation, this field
MUST be zero; the SPI is obtained from the outer header. During MUST be zero; the SPI is obtained from the outer header. During
subsequent negotiations, it is equal to the size, in octets, of subsequent negotiations, it is equal to the size, in octets, of
the SPI of the corresponding protocol (8 for IKE, 4 for ESP and the SPI of the corresponding protocol (8 for IKE, 4 for ESP and
AH). AH).
o # of Transforms (1 octet) - Specifies the number of transforms in o # of Transforms (1 octet) - Specifies the number of transforms in
this proposal. this proposal.
skipping to change at page 75, line 47 skipping to change at page 77, line 47
be optional. If a transform is optional and the initiator wishes be optional. If a transform is optional and the initiator wishes
to propose that the transform be omitted, no transform of the to propose that the transform be omitted, no transform of the
given type is included in the proposal. If the initiator wishes given type is included in the proposal. If the initiator wishes
to make use of the transform optional to the responder, it to make use of the transform optional to the responder, it
includes a transform substructure with transform ID = 0 as one of includes a transform substructure with transform ID = 0 as one of
the options. the options.
o Transform ID (2 octets) - The specific instance of the transform o Transform ID (2 octets) - The specific instance of the transform
type being proposed. type being proposed.
The transform type values are: The transform type values are listed below. The values in the
following table are only current as of the publication date of RFC
4306. Other values may have been added since then or will be added
after the publication of this document. Readers should refer to
[IKEV2IANA] for the latest values.
Description Trans. Used In Description Trans. Used In
Type Type
------------------------------------------------------------------ ------------------------------------------------------------------
RESERVED 0
Encryption Algorithm (ENCR) 1 IKE and ESP Encryption Algorithm (ENCR) 1 IKE and ESP
Pseudo-random Function (PRF) 2 IKE Pseudo-random Function (PRF) 2 IKE
Integrity Algorithm (INTEG) 3 IKE*, AH, optional in ESP Integrity Algorithm (INTEG) 3 IKE*, AH, optional in ESP
Diffie-Hellman Group (D-H) 4 IKE, optional in AH & ESP Diffie-Hellman Group (D-H) 4 IKE, optional in AH & ESP
Extended Sequence Numbers (ESN) 5 AH and ESP Extended Sequence Numbers (ESN) 5 AH and ESP
RESERVED TO IANA 6-240
PRIVATE USE 241-255
(*) Negotiating an integrity algorithm is mandatory for the (*) Negotiating an integrity algorithm is mandatory for the
Encrypted payload format specified in this document. For example, Encrypted payload format specified in this document. For example,
[AEAD] specifies additional formats based on authenticated [AEAD] specifies additional formats based on authenticated
encryption, in which a separate integrity algorithm is not encryption, in which a separate integrity algorithm is not
negotiated. negotiated.
For Transform Type 1 (Encryption Algorithm), defined Transform IDs For Transform Type 1 (Encryption Algorithm), the Transform IDs are
are: listed below. The values in the following table are only current as
of the publication date of RFC 4306. Other values may have been
added since then or will be added after the publication of this
document. Readers should refer to [IKEV2IANA] for the latest values.
Name Number Defined In Name Number Defined In
--------------------------------------------------- ---------------------------------------------------
RESERVED 0
ENCR_DES_IV64 1 (UNSPECIFIED) ENCR_DES_IV64 1 (UNSPECIFIED)
ENCR_DES 2 (RFC2405), [DES] ENCR_DES 2 (RFC2405), [DES]
ENCR_3DES 3 (RFC2451) ENCR_3DES 3 (RFC2451)
ENCR_RC5 4 (RFC2451) ENCR_RC5 4 (RFC2451)
ENCR_IDEA 5 (RFC2451), [IDEA] ENCR_IDEA 5 (RFC2451), [IDEA]
ENCR_CAST 6 (RFC2451) ENCR_CAST 6 (RFC2451)
ENCR_BLOWFISH 7 (RFC2451) ENCR_BLOWFISH 7 (RFC2451)
ENCR_3IDEA 8 (UNSPECIFIED) ENCR_3IDEA 8 (UNSPECIFIED)
ENCR_DES_IV32 9 (UNSPECIFIED) ENCR_DES_IV32 9 (UNSPECIFIED)
RESERVED 10
ENCR_NULL 11 (RFC2410) ENCR_NULL 11 (RFC2410)
ENCR_AES_CBC 12 (RFC3602) ENCR_AES_CBC 12 (RFC3602)
ENCR_AES_CTR 13 (RFC3686) ENCR_AES_CTR 13 (RFC3686)
RESERVED TO IANA 14-1023
PRIVATE USE 1024-65535
For Transform Type 2 (Pseudo-random Function), defined Transform IDs For Transform Type 2 (Pseudo-random Function), the Transform IDs are
are: listed below. The values in the following table are only current as
of the publication date of RFC 4306. Other values may have been
added since then or will be added after the publication of this
document. Readers should refer to [IKEV2IANA] for the latest values.
Name Number Defined In Name Number Defined In
------------------------------------------------------ ------------------------------------------------------
RESERVED 0
PRF_HMAC_MD5 1 (RFC2104), [MD5] PRF_HMAC_MD5 1 (RFC2104), [MD5]
PRF_HMAC_SHA1 2 (RFC2104), [SHA] PRF_HMAC_SHA1 2 (RFC2104), [SHA]
PRF_HMAC_TIGER 3 (RFC2104) PRF_HMAC_TIGER 3 (RFC2104)
PRF_AES128_XCBC 4 (RFC4434) For Transform Type 3 (Integrity Algorithm), defined Transform IDs are
RESERVED TO IANA 5-1023 listed below. The values in the following table are only current as
PRIVATE USE 1024-65535 of the publication date of RFC 4306. Other values may have been
added since then or will be added after the publication of this
For Transform Type 3 (Integrity Algorithm), defined Transform IDs document. Readers should refer to [IKEV2IANA] for the latest values.
are:
Name Number Defined In Name Number Defined In
---------------------------------------- ----------------------------------------
NONE 0 NONE 0
AUTH_HMAC_MD5_96 1 (RFC2403) AUTH_HMAC_MD5_96 1 (RFC2403)
AUTH_HMAC_SHA1_96 2 (RFC2404) AUTH_HMAC_SHA1_96 2 (RFC2404)
AUTH_DES_MAC 3 (UNSPECIFIED) AUTH_DES_MAC 3 (UNSPECIFIED)
AUTH_KPDK_MD5 4 (UNSPECIFIED) AUTH_KPDK_MD5 4 (UNSPECIFIED)
AUTH_AES_XCBC_96 5 (RFC3566) AUTH_AES_XCBC_96 5 (RFC3566)
RESERVED TO IANA 6-1023
PRIVATE USE 1024-65535
For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs
are: are listed below. The values in the following table are only current
as of the publication date of RFC 4306. Other values may have been
added since then or will be added after the publication of this
document. Readers should refer to [IKEV2IANA] for the latest values.
Name Number Defined in Name Number Defined in
---------------------------------------- ----------------------------------------
NONE 0 NONE 0
768 Bit MODP 1 Appendix B 768 Bit MODP 1 Appendix B
1024 Bit MODP 2 Appendix B 1024 Bit MODP 2 Appendix B
RESERVED TO IANA 3-4
1536-bit MODP 5 [ADDGROUP] 1536-bit MODP 5 [ADDGROUP]
RESERVED TO IANA 6-13
2048-bit MODP 14 [ADDGROUP] 2048-bit MODP 14 [ADDGROUP]
3072-bit MODP 15 [ADDGROUP] 3072-bit MODP 15 [ADDGROUP]
4096-bit MODP 16 [ADDGROUP] 4096-bit MODP 16 [ADDGROUP]
6144-bit MODP 17 [ADDGROUP] 6144-bit MODP 17 [ADDGROUP]
8192-bit MODP 18 [ADDGROUP] 8192-bit MODP 18 [ADDGROUP]
RESERVED TO IANA 19-1023
PRIVATE USE 1024-65535
Although ESP and AH do not directly include a Diffie-Hellman Although ESP and AH do not directly include a Diffie-Hellman
exchange, a Diffie-Hellman group MAY be negotiated for the Child SA. exchange, a Diffie-Hellman group MAY be negotiated for the Child SA.
This allows the peers to employ Diffie-Hellman in the CREATE_CHILD_SA This allows the peers to employ Diffie-Hellman in the CREATE_CHILD_SA
exchange, providing perfect forward secrecy for the generated Child exchange, providing perfect forward secrecy for the generated Child
SA keys. SA keys.
For Transform Type 5 (Extended Sequence Numbers), defined Transform For Transform Type 5 (Extended Sequence Numbers), defined Transform
IDs are: IDs are listed below. The values in the following table are only
current as of the publication date of RFC 4306. Other values may
have been added since then or will be added after the publication of
this document. Readers should refer to [IKEV2IANA] for the latest
values.
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
Note that an initiator who supports ESNs will usually include two ESN Note that an initiator who supports ESNs will usually include two ESN
transforms, with values "0" and "1", in its proposals. A proposal transforms, with values "0" and "1", in its proposals. A proposal
containing a single ESN transform with value "1" means that using containing a single ESN transform with value "1" means that using
normal (non-extended) sequence numbers is not acceptable. normal (non-extended) sequence numbers is not 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.
skipping to change at page 80, line 32 skipping to change at page 82, line 20
o Attribute Type (15 bits) - Unique identifier for each type of o Attribute Type (15 bits) - Unique identifier for each type of
attribute (see below). attribute (see below).
o Attribute Value (variable length) - Value of the Attribute o Attribute Value (variable length) - Value of the Attribute
associated with the Attribute Type. If the AF bit is a zero (0), associated with the Attribute Type. If the AF bit is a zero (0),
this field has a variable length defined by the Attribute Length this field has a variable length defined by the Attribute Length
field. If the AF bit is a one (1), the Attribute Value has a field. If the AF bit is a one (1), the Attribute Value has a
length of 2 octets. length of 2 octets.
Note that the only currently defined attribute type (Key Length) is The only currently defined attribute type (Key Length) is fixed
fixed length; the variable-length encoding specification is included length; the variable-length encoding specification is included only
only for future extensions. Attributes described as fixed length for future extensions. Attributes described as fixed length MUST NOT
MUST NOT be encoded using the variable-length encoding. Variable- be encoded using the variable-length encoding. Variable-length
length attributes MUST NOT be encoded as fixed-length even if their attributes MUST NOT be encoded as fixed-length even if their value
value can fit into two octets. NOTE: This is a change from IKEv1, can fit into two octets. NOTE: This is a change from IKEv1, where
where increased flexibility may have simplified the composer of increased flexibility may have simplified the composer of messages
messages but certainly complicated the parser. but certainly complicated the parser.
The values in the following table are only current as of the
publication date of RFC 4306. Other values may have been added since
then or will be added after the publication of this document.
Readers should refer to [IKEV2IANA] for the latest values.
Attribute Type Value Attribute Format Attribute Type Value Attribute Format
------------------------------------------------------------ ------------------------------------------------------------
RESERVED 0-13
Key Length (in bits) 14 TV Key Length (in bits) 14 TV
RESERVED 15-17
RESERVED TO IANA 18-16383
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: 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
skipping to change at page 81, line 35 skipping to change at page 83, line 24
instance, if a peer is configured to accept a variable-length cipher instance, if a peer is configured to accept a variable-length cipher
with a key length of X bits and is offered that cipher with a larger with a key length of X bits and is offered that cipher with a larger
key length, the implementation SHOULD accept the offer if it supports key length, the implementation SHOULD accept the offer if it supports
use of the longer key. use of the longer key.
Support of this capability allows a responder to express a concept of Support of this capability allows a responder to express a concept of
"at least" a certain level of security -- "a key length of _at least_ "at least" a certain level of security -- "a key length of _at least_
X bits for cipher Y". However, as the attribute is always returned X bits for cipher Y". However, as the attribute is always returned
unchanged (see the next section), an initiator willing to accept unchanged (see the next section), an initiator willing to accept
multiple key lengths has to include multiple transforms with the same multiple key lengths has to include multiple transforms with the same
Transform Type, each with different Key Length attribute. Transform Type, each with a different Key Length attribute.
3.3.6. Attribute Negotiation 3.3.6. Attribute Negotiation
During security association negotiation initiators present offers to During security association negotiation initiators present offers to
responders. Responders MUST select a single complete set of responders. Responders MUST select a single complete set of
parameters from the offers (or reject all offers if none are parameters from the offers (or reject all offers if none are
acceptable). If there are multiple proposals, the responder MUST acceptable). If there are multiple proposals, the responder MUST
choose a single proposal. If the selected proposal has multiple choose a single proposal. If the selected proposal has multiple
Transforms with the same type, the responder MUST choose a single Transforms with the same type, the responder MUST choose a single
one. Any attributes of a selected transform MUST be returned one. Any attributes of a selected transform MUST be returned
skipping to change at page 84, line 31 skipping to change at page 86, line 17
o RESERVED - MUST be sent as zero; MUST be ignored on receipt. o RESERVED - MUST be sent as zero; MUST be ignored on receipt.
o Identification Data (variable length) - Value, as indicated by the o Identification Data (variable length) - Value, as indicated by the
Identification Type. The length of the Identification Data is Identification Type. The length of the Identification Data is
computed from the size in the ID payload header. computed from the size in the ID payload header.
The payload types for the Identification Payload are thirty five (35) The payload types for the Identification Payload are thirty five (35)
for IDi and thirty six (36) for IDr. for IDi and thirty six (36) for IDr.
The following table lists the assigned values for the Identification The following table lists the assigned semantics for the
Type field: Identification Type field. The values in the following table are
only current as of the publication date of RFC 4306. Other values
may have been added since then or will be added after the publication
of this document. Readers should refer to [IKEV2IANA] for the latest
values.
ID Type Value ID Type Value
------------------------------------------------------------------- -------------------------------------------------------------------
RESERVED 0
ID_IPV4_ADDR 1 ID_IPV4_ADDR 1
A single four (4) octet IPv4 address. A single four (4) octet IPv4 address.
ID_FQDN 2 ID_FQDN 2
A fully-qualified domain name string. An example of a ID_FQDN A fully-qualified domain name string. An example of a ID_FQDN
is, "example.com". The string MUST not contain any terminators is, "example.com". The string MUST not contain any terminators
(e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII; (e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII;
for an "internationalized domain name", the syntax is as defined for an "internationalized domain name", the syntax is as defined
in [IDNA], for example "xn--tmonesimerkki-bfbb.example.net". in [IDNA], for example "xn--tmonesimerkki-bfbb.example.net".
ID_RFC822_ADDR 3 ID_RFC822_ADDR 3
A fully-qualified RFC822 email address string, An example of a A fully-qualified RFC822 email address string, An example of a
ID_RFC822_ADDR is, "jsmith@example.com". The string MUST not ID_RFC822_ADDR is, "jsmith@example.com". The string MUST not
contain any terminators. Because of [EAI], implementations would contain any terminators. Because of [EAI], implementations would
be wise to treat this field as UTF-8 encoded text, not as be wise to treat this field as UTF-8 encoded text, not as
pure ASCII. pure ASCII.
RESERVED TO IANA 4
ID_IPV6_ADDR 5 ID_IPV6_ADDR 5
A single sixteen (16) octet IPv6 address. A single sixteen (16) octet IPv6 address.
RESERVED TO IANA 6 - 8
ID_DER_ASN1_DN 9 ID_DER_ASN1_DN 9
The binary Distinguished Encoding Rules (DER) encoding of an The binary Distinguished Encoding Rules (DER) encoding of an
ASN.1 X.500 Distinguished Name [X.501]. ASN.1 X.500 Distinguished Name [X.501].
ID_DER_ASN1_GN 10 ID_DER_ASN1_GN 10
The binary DER encoding of an ASN.1 X.500 GeneralName [X.509]. The binary DER encoding of an ASN.1 X.500 GeneralName [X.509].
ID_KEY_ID 11 ID_KEY_ID 11
An opaque octet stream which may be used to pass vendor- An opaque octet stream which may be used to pass vendor-
specific information necessary to do certain proprietary specific information necessary to do certain proprietary
types of identification. types of identification.
RESERVED TO IANA 12-200
PRIVATE USE 201-255
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.
skipping to change at page 86, line 51 skipping to change at page 88, line 41
| Cert Encoding | | | Cert Encoding | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
~ Certificate Data ~ ~ Certificate Data ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Certificate Payload Format Figure 12: Certificate Payload Format
o Certificate Encoding (1 octet) - This field indicates the type of o Certificate Encoding (1 octet) - This field indicates the type of
certificate or certificate-related information contained in the certificate or certificate-related information contained in the
Certificate Data field. Certificate Data field. The values in the following table are
only current as of the publication date of RFC 4306. Other values
may have been added since then or will be added after the
publication of this document. Readers should refer to [IKEV2IANA]
for the latest values.
Certificate Encoding Value Certificate Encoding Value
---------------------------------------------------- ----------------------------------------------------
RESERVED 0
PKCS #7 wrapped X.509 certificate 1 UNSPECIFIED PKCS #7 wrapped X.509 certificate 1 UNSPECIFIED
PGP Certificate 2 UNSPECIFIED PGP Certificate 2 UNSPECIFIED
DNS Signed Key 3 UNSPECIFIED DNS Signed Key 3 UNSPECIFIED
X.509 Certificate - Signature 4 X.509 Certificate - Signature 4
Kerberos Token 6 UNSPECIFIED Kerberos Token 6 UNSPECIFIED
Certificate Revocation List (CRL) 7 Certificate Revocation List (CRL) 7
Authority Revocation List (ARL) 8 UNSPECIFIED Authority Revocation List (ARL) 8 UNSPECIFIED
SPKI Certificate 9 UNSPECIFIED SPKI Certificate 9 UNSPECIFIED
X.509 Certificate - Attribute 10 UNSPECIFIED X.509 Certificate - Attribute 10 UNSPECIFIED
Raw RSA Key 11 Raw RSA Key 11
Hash and URL of X.509 certificate 12 Hash and URL of X.509 certificate 12
Hash and URL of X.509 bundle 13 Hash and URL of X.509 bundle 13
RESERVED to IANA 14 - 200
PRIVATE USE 201 - 255
o Certificate Data (variable length) - Actual encoding of o Certificate Data (variable length) - Actual encoding of
certificate data. The type of certificate is indicated by the certificate data. The type of certificate is indicated by the
Certificate Encoding field. Certificate Encoding field.
The payload type for the Certificate Payload is thirty seven (37). The payload type for the Certificate Payload is thirty seven (37).
Specific syntax for some of the certificate type codes above is not Specific syntax for some of the certificate type codes above is not
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 contains a DER encoded X.509
certificate whose public key is used to validate the sender's AUTH certificate whose public key is used to validate the sender's AUTH
payload. Note that with this encoding, if a chain of certificates payload. Note that with this encoding, if a chain of certificates
needs to be sent, multiple CERT payloads are used, only the first needs to be sent, multiple CERT payloads are used, only the first
of which holds the public key used to validate the sender's AUTH of which holds the public key used to validate the sender's AUTH
payload. payload.
o Certificate Revocation List (7) contains a DER encoded X.509 o Certificate Revocation List contains a DER encoded X.509
certificate revocation list. certificate revocation list.
o Raw RSA Key (11) contains a PKCS #1 encoded RSA key, that is, a o Raw RSA Key contains a PKCS #1 encoded RSA key, that is, a DER-
DER-encoded RSAPublicKey structure (see [RSA] and [PKCS1]). 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 allow IKE messages to remain short by
by replacing long data structures with a 20 octet SHA-1 hash (see replacing long data structures with a 20 octet SHA-1 hash (see
[SHA]) of the replaced value followed by a variable-length URL [SHA]) of the replaced value followed by a variable-length URL
that resolves to the DER encoded data structure itself. This that resolves to the DER encoded data structure itself. This
improves efficiency when the endpoints have certificate data improves efficiency when the endpoints have certificate data
cached and makes IKE less subject to 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].
Use the following ASN.1 definition for an X.509 bundle: Use the following ASN.1 definition for an X.509 bundle:
CertBundle CertBundle
skipping to change at page 88, line 40 skipping to change at page 90, line 37
Implementations MUST be capable of being configured to send and Implementations MUST be capable of being configured to send and
accept up to four X.509 certificates in support of authentication, accept up to four X.509 certificates in support of authentication,
and also MUST be capable of being configured to send and accept the and also MUST be capable of being configured to send and accept the
two Hash and URL formats (with HTTP URLs). Implementations SHOULD be two Hash and URL formats (with HTTP URLs). Implementations SHOULD be
capable of being configured to send and accept Raw RSA keys. If capable of being configured to send and accept Raw RSA keys. If
multiple certificates are sent, the first certificate MUST contain multiple certificates are sent, the first certificate MUST contain
the public key used to sign the AUTH payload. The other certificates the public key used to sign the AUTH payload. The other certificates
may be sent in any order. may be sent in any order.
Implementations MUST support the HTTP method for hash-and-URL lookup.
The behavior of other URL methods is not currently specified, and
such methods SHOULD NOT be used in the absence of a document
specifying them.
3.7. Certificate Request Payload 3.7. Certificate Request Payload
The Certificate Request Payload, denoted CERTREQ in this memo, The Certificate Request Payload, denoted CERTREQ in this memo,
provides a means to request preferred certificates via IKE and can provides a means to request preferred certificates via IKE and can
appear in the IKE_INIT_SA response and/or the IKE_AUTH request. appear in the IKE_INIT_SA response and/or the IKE_AUTH request.
Certificate Request payloads MAY be included in an exchange when the Certificate Request payloads MAY be included in an exchange when the
sender needs to get the certificate of the receiver. If multiple CAs sender needs to get the certificate of the receiver. If multiple CAs
are trusted and the certificate encoding does not allow a list, then are trusted and the certificate encoding does not allow a list, then
multiple Certificate Request payloads would need to be transmitted. multiple Certificate Request payloads would need to be transmitted.
skipping to change at page 89, line 40 skipping to change at page 91, line 40
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.
The contents of the "Certification Authority" field are defined only The contents of the "Certification Authority" field are defined only
for X.509 certificates, which are types 4, 10, 12, and 13. Other for X.509 certificates, which are types 4, 12, and 13. Other values
values SHOULD NOT be used until standards-track specifications that SHOULD NOT be used until standards-track specifications that specify
specify their use are published. 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 91, line 22 skipping to change at page 93, line 22
| Auth Method | RESERVED | | Auth Method | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Authentication Data ~ ~ Authentication Data ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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. The types of signatures are listed here. The values in the
following table are only current as of the publication date of RFC
* RSA Digital Signature (1) - Computed as specified in 4306. Other values may have been added since then or will be
Section 2.15 using an RSA private key with RSASSA-PKCS1-v1_5 added after the publication of this document. Readers should
signature scheme specified in [PKCS1] (implementors should note refer to [IKEV2IANA] for the latest values.
that IKEv1 used a different method for RSA signatures). To
promote interoperability, implementations that support this
type SHOULD support signatures that use SHA-1 as the hash
function and SHOULD use SHA-1 as the default hash function when
generating signatures.
* Shared Key Message Integrity Code (2) - Computed as specified Mechanism Value
in Section 2.15 using the shared key associated with the -----------------------------------------------------------------
identity in the ID payload and the negotiated prf function RSA Digital Signature 1
Computed as specified in Section 2.15 using an RSA private key
with RSASSA-PKCS1-v1_5 signature scheme specified in [PKCS1]
(implementors should note that IKEv1 used a different method for
RSA signatures). To promote interoperability, implementations
that support this type SHOULD support signatures that use SHA-1
as the hash function and SHOULD use SHA-1 as the default hash
function when generating signatures. Implementations can use the
certificates received from a given peer as a hint for selecting a
mutually-understood hash function for the AUTH payload signature.
Note, however, that the hash algorithm used in the AUTH payload
signature doesn't have to be the same as any hash algorithm(s)
used in the certificate(s).
* DSS Digital Signature (3) - Computed as specified in Shared Key Message Integrity Code 2
Section 2.15 using a DSS private key (see [DSS]) over a SHA-1 Computed as specified in Section 2.15 using the shared key
hash. associated with the identity in the ID payload and the negotiated
prf function.
* The values 0 and 4-200 are reserved to IANA. The values 201- DSS Digital Signature 3
255 are available for private use. Computed as specified in Section 2.15 using a DSS private key
(see [DSS]) over a SHA-1 hash.
o Authentication Data (variable length) - see Section 2.15. o Authentication Data (variable length) - see Section 2.15.
The payload type for the Authentication Payload is thirty nine (39). The payload type for the Authentication Payload is thirty nine (39).
3.9. Nonce Payload 3.9. Nonce Payload
The Nonce Payload, denoted Ni and Nr in this memo for the initiator's The Nonce Payload, denoted Ni and Nr in this memo for the initiator's
and responder's nonce respectively, contains random data used to and responder's nonce respectively, contains random data used to
guarantee liveness during an exchange and protect against replay guarantee liveness during an exchange and protect against replay
skipping to change at page 93, line 24 skipping to change at page 95, line 24
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ 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 in the SPI field, this field indicates the
of that SA. For notifications concerning IPsec SAs this field type of that SA. For notifications concerning IPsec SAs this
MUST contain either (2) to indicate AH or (3) to indicate ESP. Of field MUST contain either (2) to indicate AH or (3) to indicate
the notifications defined in this document, the SPI is included ESP. Of the notifications defined in this document, the SPI is
only with INVALID_SELECTORS and REKEY_SA. If the SPI field is included only with INVALID_SELECTORS and REKEY_SA. If the SPI
empty, this field MUST be sent as zero and MUST be ignored on field is empty, this field MUST be sent as zero and MUST be
receipt. All other values for this field are reserved to IANA for ignored on receipt.
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 94, line 22 skipping to change at page 96, line 22
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. Unrecognized error types corresponding request has failed entirely. Unrecognized error types
in a request and status types in a request or response MUST be in a request and status types in a request 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.
The values in the following table are only current as of the
publication date of RFC 4306. Other values may have been added since
then or will be added after the publication of this document.
Readers should refer to [IKEV2IANA] for the latest values.
NOTIFY messages: error types Value NOTIFY messages: error types Value
------------------------------------------------------------------- -------------------------------------------------------------------
RESERVED 0
UNSUPPORTED_CRITICAL_PAYLOAD 1 UNSUPPORTED_CRITICAL_PAYLOAD 1
See Section 2.5. See Section 2.5.
INVALID_IKE_SPI 4 INVALID_IKE_SPI 4
See Section 2.21. See Section 2.21.
INVALID_MAJOR_VERSION 5 INVALID_MAJOR_VERSION 5
See Section 2.5. See Section 2.5.
INVALID_SYNTAX 7 INVALID_SYNTAX 7
skipping to change at page 95, line 44 skipping to change at page 98, line 5
See Section 2.9. See Section 2.9.
INVALID_SELECTORS 39 INVALID_SELECTORS 39
MAY be sent in an IKE INFORMATIONAL exchange when a node receives MAY be sent in an IKE INFORMATIONAL exchange when a node receives
an ESP or AH packet whose selectors do not match those of the SA an ESP or AH packet whose selectors do not match those of the SA
on which it was delivered (and that caused the packet to be on which it was delivered (and that caused the packet to be
dropped). The Notification Data contains the start of the dropped). The Notification Data contains the start of the
offending packet (as in ICMP messages) and the SPI field of the offending packet (as in ICMP messages) and the SPI field of the
notification is set to match the SPI of the IPsec SA. notification is set to match the SPI of the IPsec SA.
RESERVED TO IANA 40-8191
PRIVATE USE 8192-16383
NOTIFY messages: status types Value NOTIFY messages: status types Value
------------------------------------------------------------------- -------------------------------------------------------------------
INITIAL_CONTACT 16384 INITIAL_CONTACT 16384
See Section 2.4. See Section 2.4.
SET_WINDOW_SIZE 16385 SET_WINDOW_SIZE 16385
See Section 2.3. See Section 2.3.
ADDITIONAL_TS_POSSIBLE 16386 ADDITIONAL_TS_POSSIBLE 16386
See Section 2.9. See Section 2.9.
IPCOMP_SUPPORTED 16387 IPCOMP_SUPPORTED 16387
skipping to change at page 96, line 43 skipping to change at page 98, line 43
REKEY_SA 16393 REKEY_SA 16393
See Section 1.3.3. See Section 1.3.3.
ESP_TFC_PADDING_NOT_SUPPORTED 16394 ESP_TFC_PADDING_NOT_SUPPORTED 16394
See Section 1.3.1. See Section 1.3.1.
NON_FIRST_FRAGMENTS_ALSO 16395 NON_FIRST_FRAGMENTS_ALSO 16395
See Section 1.3.1. See Section 1.3.1.
RESERVED TO IANA 16396-40959
PRIVATE USE 40960-65535
3.11. Delete Payload 3.11. Delete Payload
The Delete Payload, denoted D in this memo, contains a protocol The Delete Payload, denoted D in this memo, contains a protocol
specific security association identifier that the sender has removed specific security association identifier that the sender has removed
from its security association database and is, therefore, no longer from its security association database and is, therefore, no longer
valid. Figure 17 shows the format of the Delete Payload. It is valid. Figure 17 shows the format of the Delete Payload. It is
possible to send multiple SPIs in a Delete payload; however, each SPI possible to send multiple SPIs in a Delete payload; however, each SPI
MUST be for the same protocol. Mixing of protocol identifiers MUST MUST be for the same protocol. Mixing of protocol identifiers MUST
NOT be performed in the Delete payload. It is permitted, however, to NOT be performed in the Delete payload. It is permitted, however, to
include multiple Delete payloads in a single INFORMATIONAL exchange include multiple Delete payloads in a single INFORMATIONAL exchange
skipping to change at page 102, line 5 skipping to change at page 103, line 47
Traffic selectors can use IP Protocol ID 135 to match the IPv6 Traffic selectors can use IP Protocol ID 135 to match the IPv6
mobility header [MIPV6]. This document does not specify how to mobility header [MIPV6]. This document does not specify how to
represent the "MH Type" field in traffic selectors, although it is represent the "MH Type" field in traffic selectors, although it is
likely that a different document will specify this in the future. likely that a different document will specify this in the future.
Note that [IPSECARCH] says that the IPv6 mobility header (MH) message Note that [IPSECARCH] says that the IPv6 mobility header (MH) message
type is placed in the most significant eight bits of the 16-bit local type is placed in the most significant eight bits of the 16-bit local
port selector. The direction semantics of TSi/TSr port fields are port selector. The direction 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 values for the Traffic Selector Type field
Selector Type field and the corresponding Address Selector Data. and the corresponding Address Selector Data. The values in the
following table are only current as of the publication date of RFC
4306. Other values may have been added since then or will be added
after the publication of this document. Readers should refer to
[IKEV2IANA] for the latest values.
TS Type Value TS Type Value
------------------------------------------------------------------- -------------------------------------------------------------------
RESERVED 0-6
TS_IPV4_ADDR_RANGE 7 TS_IPV4_ADDR_RANGE 7
A range of IPv4 addresses, represented by two four-octet A range of IPv4 addresses, represented by two four-octet
values. The first value is the beginning IPv4 address values. The first value is the beginning IPv4 address
(inclusive) and the second value is the ending IPv4 address (inclusive) and the second value is the ending IPv4 address
(inclusive). All addresses falling between the two specified (inclusive). All addresses falling between the two specified
addresses are considered to be within the list. addresses are considered to be within the list.
TS_IPV6_ADDR_RANGE 8 TS_IPV6_ADDR_RANGE 8
A range of IPv6 addresses, represented by two sixteen-octet A range of IPv6 addresses, represented by two sixteen-octet
values. The first value is the beginning IPv6 address values. The first value is the beginning IPv6 address
(inclusive) and the second value is the ending IPv6 address (inclusive) and the second value is the ending IPv6 address
(inclusive). All addresses falling between the two specified (inclusive). All addresses falling between the two specified
addresses are considered to be within the list. addresses are considered to be within the list.
RESERVED TO IANA 9-240
PRIVATE USE 241-255
3.14. Encrypted Payload 3.14. Encrypted Payload
The Encrypted Payload, denoted SK{...} or E in this memo, contains The Encrypted Payload, denoted SK{...} or E in this memo, contains
other payloads in encrypted form. The Encrypted Payload, if present other payloads in encrypted form. The Encrypted Payload, if present
in a message, MUST be the last payload in the message. Often, it is in a message, MUST be the last payload in the message. Often, it is
the only payload in the message. the only payload in the message.
The algorithms for encryption and integrity protection are negotiated The algorithms for encryption and integrity protection are negotiated
during IKE SA setup, and the keys are computed as specified in during IKE SA setup, and the keys are computed as specified in
Section 2.14 and Section 2.18. Section 2.14 and Section 2.18.
skipping to change at page 103, line 6 skipping to change at page 104, line 49
message. The design is modeled after the ESP algorithms described in message. The design is modeled after the ESP algorithms described in
RFCs 2104 [HMAC], 4303 [ESP], and 2451 [ESPCBC]. This document RFCs 2104 [HMAC], 4303 [ESP], and 2451 [ESPCBC]. This document
completely specifies the cryptographic processing of IKE data, but completely specifies the cryptographic processing of IKE data, but
those documents should be consulted for design rationale. Future those documents should be consulted for design rationale. Future
documents may specify the processing of Encrypted payloads for other documents may specify the processing of Encrypted payloads for other
types of transforms, such as counter mode encryption and types of transforms, such as counter mode encryption and
authenticated encryption algorithms. Peers MUST NOT negotiate authenticated encryption algorithms. Peers MUST NOT negotiate
transforms for which no such specification exists. transforms for which no such specification exists.
When an authenticated encryption algorithm is used to protect the IKE When an authenticated encryption algorithm is used to protect the IKE
SA, the construction of the encrypted payload is different that what SA, the construction of the encrypted payload is different than what
is described here. See [RFC5282] for more information on is described here. See [AEAD] for more information on authenticated
authenticated encryption algorithms and their use in ESP. encryption algorithms and their use in ESP.
The payload type for an Encrypted payload is forty six (46). The The payload type for an Encrypted payload is forty six (46). The
Encrypted Payload consists of the IKE generic payload header followed Encrypted Payload consists of the IKE generic payload header followed
by individual fields as follows: by individual 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 105, line 6 skipping to change at page 106, line 50
| | | |
~ Configuration Attributes ~ ~ Configuration Attributes ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: Configuration Payload Format Figure 22: Configuration Payload Format
The payload type for the Configuration Payload is forty seven (47). The payload type for the Configuration Payload is forty seven (47).
o CFG Type (1 octet) - The type of exchange represented by the o CFG Type (1 octet) - The type of exchange represented by the
Configuration Attributes. Configuration Attributes. The values in the following table are
only current as of the publication date of RFC 4306. Other values
may have been added since then or will be added after the
publication of this document. Readers should refer to [IKEV2IANA]
for the latest values.
CFG Type Value CFG Type Value
-------------------------- --------------------------
RESERVED 0
CFG_REQUEST 1 CFG_REQUEST 1
CFG_REPLY 2 CFG_REPLY 2
CFG_SET 3 CFG_SET 3
CFG_ACK 4 CFG_ACK 4
RESERVED TO IANA 5-127
PRIVATE USE 128-255
o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on
receipt. receipt.
o Configuration Attributes (variable length) - These are type length o Configuration Attributes (variable length) - These are type length
values specific to the Configuration Payload and are defined values specific to the Configuration Payload and are defined
below. There may be zero or more Configuration Attributes in this below. There may be zero or more Configuration Attributes in this
payload. payload.
3.15.1. Configuration Attributes 3.15.1. Configuration Attributes
skipping to change at page 105, line 49 skipping to change at page 107, line 45
o Reserved (1 bit) - This bit MUST be set to zero and MUST be o Reserved (1 bit) - This bit MUST be set to zero and MUST be
ignored on receipt. ignored on receipt.
o Attribute Type (15 bits) - A unique identifier for each of the o Attribute Type (15 bits) - A unique identifier for each of the
Configuration Attribute Types. Configuration Attribute Types.
o Length (2 octets) - Length in octets of Value. o Length (2 octets) - Length in octets of Value.
o Value (0 or more octets) - The variable-length value of this o Value (0 or more octets) - The variable-length value of this
Configuration Attribute. The following attribute types have been Configuration Attribute. The following lists the attribute types.
defined: The values in the following table are only current as of the
publication date of RFC 4306. Other values may have been added
since then or will be added after the publication of this
document. Readers should refer to [IKEV2IANA] for the latest
values.
Multi-
Attribute Type Value Valued Length Attribute Type Value Valued Length
------------------------------------------------------- -------------------------------------------------------
RESERVED 0
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
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
INTERNAL_IP6_DNS 10 YES 0 or 16 octets INTERNAL_IP6_DNS 10 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
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. In a address and MAY be a private address on the Internet. In a
request message, the address specified is a requested address (or request message, the address specified is a requested address (or
a zero-length address if no specific address is requested). If a a zero-length address if no specific address is requested). If a
specific address is requested, it likely indicates that a previous specific address is requested, it likely indicates that a previous
skipping to change at page 108, line 16 skipping to change at page 110, line 10
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.
The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to request The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to request
information from its peer. If an attribute in the CFG_REQUEST information from its peer. If an attribute in the CFG_REQUEST
Configuration Payload is not zero-length, it is taken as a suggestion Configuration Payload is not zero-length, it is taken as a suggestion
for that attribute. The CFG_REPLY Configuration Payload MAY return for that attribute. The CFG_REPLY Configuration Payload MAY return
that value, or a new one. It MAY also add new attributes and not that value, or a new one. It MAY also add new attributes and not
include some requested ones. Requestors MUST ignore returned include some requested ones. Unrecognized or unsupported attributes
attributes that they do not recognize. MUST be ignored in both requests and responses.
The CFG_SET and CFG_ACK pair allows an IKE endpoint to push The CFG_SET and CFG_ACK pair allows an IKE endpoint to push
configuration data to its peer. In this case, the CFG_SET configuration data to its peer. In this case, the CFG_SET
Configuration Payload contains attributes the initiator wants its Configuration Payload contains attributes the initiator wants its
peer to alter. The responder MUST return a Configuration Payload if peer to alter. The responder MUST return a Configuration Payload if
it accepted any of the configuration data and it MUST contain the it accepted any of the configuration data and it MUST contain the
attributes that the responder accepted with zero-length data. Those attributes that the responder accepted with zero-length data. Those
attributes that it did not accept MUST NOT be in the CFG_ACK attributes that it did not accept MUST NOT be in the CFG_ACK
Configuration Payload. If no attributes were accepted, the responder Configuration Payload. If no attributes were accepted, the responder
MUST return either an empty CFG_ACK payload or a response message MUST return either an empty CFG_ACK payload or a response message
skipping to change at page 113, line 8 skipping to change at page 114, line 48
o Length (2 octets) is the length of the EAP message and MUST be o Length (2 octets) is the length of the EAP message and MUST be
four less than the Payload Length of the encapsulating payload. four less than the Payload Length of the encapsulating payload.
o Type (1 octet) is present only if the Code field is Request (1) or o Type (1 octet) is present only if the Code field is Request (1) or
Response (2). For other codes, the EAP message length MUST be Response (2). For other codes, the EAP message length MUST be
four octets and the Type and Type_Data fields MUST NOT be present. four octets and the Type and Type_Data fields MUST NOT be present.
In a Request (1) message, Type indicates the data being requested. In a Request (1) message, Type indicates the data being requested.
In a Response (2) message, Type MUST either be Nak or match the In a Response (2) message, Type MUST either be Nak or match the
type of the data requested. The following types are defined in type of the data requested. The following types are defined in
RFC 3748: [EAP]:
1 Identity 1 Identity
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
skipping to change at page 114, line 42 skipping to change at page 116, line 37
expires (based on locally configured values of either lifetime or expires (based on locally configured values of either lifetime or
octets passed), and implementation MAY either try to renew it with a octets passed), and implementation MAY either try to renew it with a
CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and
create a new one. If the responder rejects the CREATE_CHILD_SA create a new one. If the responder rejects the CREATE_CHILD_SA
request with a NO_ADDITIONAL_SAS notification, the implementation request with a NO_ADDITIONAL_SAS notification, the implementation
MUST be capable of instead deleting the old SA and creating a new MUST be capable of instead deleting the old SA and creating a new
one. one.
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 and its policy requires using temporary
message 3 containing at least a field of type INTERNAL_IP4_ADDRESS or IP addresses, it MUST include a CP payload in message 3 containing at
INTERNAL_IP6_ADDRESS. All other fields are optional. If an least a field of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS.
implementation supports responding to such requests, it MUST parse All other fields are optional. If an implementation supports
the CP payload of type CFG_REQUEST in message 3 and recognize a field responding to such requests, it MUST parse the CP payload of type
of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports CFG_REQUEST in message 3 and recognize a field of type
leasing an address of the appropriate type, it MUST return a CP INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports leasing
payload of type CFG_REPLY containing an address of the requested an address of the appropriate type, it MUST return a CP payload of
type. The responder may include any other related attributes. type CFG_REPLY containing an address of the requested type. The
responder may include any other 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 119, line 41 skipping to change at page 121, line 36
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
[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 in [IKEV2IANA], so the are not
No new types or values are registered in this document. However, listed here again.
Two new additions to the IKEv2 parameters "NOTIFY MESSAGES - ERROR
TYPES" registry are defined here that were not defined in [IKEV2]:
{TBA1} TEMPORARY_FAILURE
{TBA2} CHILD_SA_NOT_FOUND
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
Many individuals in the IPsecME Working Group were very helpful in Many individuals in the IPsecME Working Group were very helpful in
contributing ideas and text for this document, as well as in contributing ideas and text for this document, as well as in
reviewing the clarifications suggested by others. reviewing the clarifications suggested by others.
The acknowledgements from the IKEv2 document were: The acknowledgements from the IKEv2 document were:
skipping to change at page 120, line 20 skipping to change at page 122, line 25
RFC, the following, in alphabetical order, would have been listed: RFC, the following, in alphabetical order, would have been listed:
Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt
Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, John Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, John
Ioannidis, Charlie Kaufman, Steve Kent, Angelos Keromytis, Tero Ioannidis, Charlie Kaufman, Steve Kent, Angelos Keromytis, Tero
Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer
Reingold, and Michael Richardson. Many other people contributed to Reingold, and Michael Richardson. Many other people contributed to
the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI, the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI,
each of which has its own list of authors. Hugh Daniel suggested the each of which has its own list of authors. Hugh Daniel suggested the
feature of having the initiator, in message 3, specify a name for the feature of having the initiator, in message 3, specify a name for the
responder, and gave the feature the cute name "You Tarzan, Me Jane". responder, and gave the feature the cute name "You Tarzan, Me Jane".
David Faucher and Valery Smyzlov helped refine the design of the David Faucher and Valery Smyslov helped refine the design of the
traffic selector negotiation. traffic selector negotiation.
This paragraph lists references that appear only in figures. The This paragraph lists references that appear only in figures. The
section is only here to keep the 'xml2rfc' program happy, and needs section is only here to keep the 'xml2rfc' program happy, and needs
to be removed when the document is published. The RFC Editor will to be removed when the document is published. The RFC Editor will
remove it before publication. [AEAD] [EAI] [DES] [IDEA] [MD5] remove it before publication. [AEAD] [EAI] [DES] [IDEA] [MD5]
[X.501] [X.509] [X.501] [X.509] [DSS]
8. References 8. References
8.1. Normative References 8.1. Normative References
[ADDGROUP] [ADDGROUP]
Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)", Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, May 2003. RFC 3526, May 2003.
[ADDRIPV6] [ADDRIPV6]
Hinden, R. and S. Deering, "Internet Protocol Version 6 Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 4291, February 2006. (IPv6) Addressing Architecture", RFC 4291, February 2006.
[AESCMACPRF128]
Song, J., "The Advanced Encryption Standard-Cipher-based
Message Authentication Code-Pseudo-Random Function-128
(AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange
Protocol (IKE)", RFC 4615, August 2006.
[AESXCBCPRF128]
Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
Internet Key Exchange Protocol (IKE)", RFC 4434,
February 2006.
[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004. RFC 3748, June 2004.
[ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001. RFC 3168, September 2001.
[ESPCBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher [ESPCBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, November 1998. Algorithms", RFC 2451, November 1998.
[IKEV2IANA]
"Internet Key Exchange Version 2 (IKEv2) Parameters",
<http://www.iana.org/assignments/ikev2-parameters>.
[IPSECARCH] [IPSECARCH]
Kent, S. and K. Seo, "Security Architecture for the Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[MUSTSHOULD] [MUSTSHOULD]
Bradner, S., "Key Words for use in RFCs to indicate Bradner, S., "Key Words for use in RFCs to indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography [PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003. Version 2.1", RFC 3447, February 2003.
[PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet [PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280, Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002. April 2002.
[RFC4434] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
Internet Key Exchange Protocol (IKE)", RFC 4434,
February 2006.
[RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The
Advanced Encryption Standard-Cipher-based Message
Authentication Code-Pseudo-Random Function-128 (AES-CMAC-
PRF-128) Algorithm for the Internet Key Exchange Protocol
(IKE)", RFC 4615, August 2006.
[RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption
Algorithms with the Encrypted Payload of the Internet Key
Exchange version 2 (IKEv2) Protocol", RFC 5282,
August 2008.
[UDPENCAPS] [UDPENCAPS]
Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005. RFC 3948, January 2005.
8.2. Informative References 8.2. Informative References
[AEAD] McGrew, D., "An Interface and Algorithms for Authenticated [AEAD] McGrew, D. and D. Black, "Using Authenticated Encryption
Encryption", RFC 5116, January 2008. Algorithms with the Encrypted Payload of the Internet Key
Exchange version 2 (IKEv2) Protocol", RFC 5282,
August 2008.
[AH] Kent, S., "IP Authentication Header", RFC 4302, [AH] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
[ARCHGUIDEPHIL] [ARCHGUIDEPHIL]
Bush, R. and D. Meyer, "Some Internet Architectural Bush, R. and D. Meyer, "Some Internet Architectural
Guidelines and Philosophy", RFC 3439, December 2002. Guidelines and Philosophy", RFC 3439, December 2002.
[ARCHPRINC] [ARCHPRINC]
Carpenter, B., "Architectural Principles of the Internet", Carpenter, B., "Architectural Principles of the Internet",
skipping to change at page 148, line 26 skipping to change at page 150, line 26
parts of the document. [Issue #108] parts of the document. [Issue #108]
Added the following to 3.15.3: "Note that there is an additional Added the following to 3.15.3: "Note that there is an additional
document that discusses IPv6 configuration in IKEv2, [IPV6CONFIG]. document that discusses IPv6 configuration in IKEv2, [IPV6CONFIG].
At the present time, it is an experimental document, but there is a At the present time, it is an experimental document, but there is a
hope that with more implementation experience, it will gain the same hope that with more implementation experience, it will gain the same
standards treatment as this document." [Issue #47 and Issue #60] standards treatment as this document." [Issue #47 and Issue #60]
Reworded the acknowledgements to be more inclusive. Reworded the acknowledgements to be more inclusive.
E.13. Changes from draft-ietf-ipsecme-ikev2bis-05 to
draft-ietf-ipsecme-ikev2bis-06
Many small editorial nits fixed.
Changed all the tables to only list the values that were defined in
RFC 4306. Removed reserved and private use ranges. Also, a pointer
to the IANA registry is given repeatedly.
At the end of 1.3.1, added "See Section 2.21 for a list of error
messages that might occur if creating a Child SA fails."
In 1.3.2, made the response "HDR, SK {SA, Nr, KEr}", as it was
supposed to be from earlier changes. [Issue #50]
In 1.3.2, added "Once a peer receives a request to rekey an IKE SA or
sends a request to rekey an IKE SA, it SHOULD NOT start any new
CREATE_CHILD_SA exchanges on the IKE SA that is being rekeyed."
[Issue #22]
In 1.3.2, removed "[[ Note: this text may be changed in the future.
]]"
Added "All of Section 2.25 was added to explain how to act when there
are timing collisions when deleting and/or rekeying SAs." to 1.7.
[Issue #22]
In 2.8, split the third paragraph into two paragraphs to make the
different types of rekeying clearer. Also, changed "The old IKE SA
is then deleted" to "After the new equivalent IKE SA is created, the
initiator deletes the old IKE SA".
In 2.8, changed "The initiator MAY begin sending on an SA as soon as
it processes the response" to "The initiator SHOULD begin sending on
an SA as soon as it processes the response".
Completely revised and expanded the second paragraph of 2.8.2 ("The
case where both..."). [Issue #22]
Changed the first parenthetical statement at the beginning of 2.15 to
read "or MAC using a padded shared secret as the key, as described
later in this section". Also, changed the formatting of the MAC
calculation at the end of the section very slightly.
Also in 2.15, in the description of the signed octets, fixed two
lines.
. . .
InitiatorIDPayload = PayloadHeader | RestOfIDPayload
RestOfInitIDPayload = IDType | RESERVED | InitIDData
. . .
becomes
. . .
InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload
RestOfInitIDPayload = IDType | RESERVED | InitIDData
. . .
...and the same change for the responder.
In 2.23, removed the second-to-last bullet because it was
accidentally left there when the last bullet was copied and expanded
from it.
Added 2.25 and its subsections. [Issue #22]
Added to the end of 3.6: "Implementations MUST support the HTTP
method for hash-and-URL lookup. The behavior of other URL methods is
not currently specified, and such methods SHOULD NOT be used in the
absence of a document specifying them." [Issue #117]
In 3.7, removed "10" from the list of acceptable types for the
"Certification Authority" field. [Issue #120]
In 3.8, definition of RSA Digital Signature, added: "Implementations
can use the certificates received from a given peer as a hint for
selecting a mutually-understood hash function for the AUTH payload
signature. Note, however, that the hash algorithm used in the AUTH
payload signature doesn't have to be the same as any hash
algorithm(s) used in the certificate(s)." [Isse #116]
In 3.10.1, added
TEMPORARY_FAILURE
See section 2.25.
CHILD_SA_NOT_FOUND
See section 2.25.
Also added these to the IANA considerations in section 6. [Issue
#22]
In 3.15, changed "Requestors MUST ignore returned attributes that
they do not recognize" to "Unrecognized or unsupported attributes
MUST be ignored in both requests and responses". This brings back
some text that was removed a few iterations ago.
In 4, changed "If an implementation does support issuing such
requests" to "If an implementation does support issuing such requests
and its policy requires using temporary IP addresses".
In 8 (Refereneces), changed the reference for AEAD from RFC 5116 to
RFC 5282. Also added IKEV2IANA as a normative reference. Also
changed the FTP URLs to the RFC Editor to HTTP references.
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. 141 change blocks. 
396 lines changed or deleted 604 lines changed or added

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