draft-ietf-ipsecme-ikev2bis-04.txt   draft-ietf-ipsecme-ikev2bis-05.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: January 9, 2010 Check Point Expires: April 8, 2010 Check Point
P. Eronen P. Eronen
Nokia Nokia
July 8, 2009 October 5, 2009
Internet Key Exchange Protocol: IKEv2 Internet Key Exchange Protocol: IKEv2
draft-ietf-ipsecme-ikev2bis-04 draft-ietf-ipsecme-ikev2bis-05
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 47 skipping to change at page 1, line 47
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 9, 2010. This Internet-Draft will expire on April 8, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
skipping to change at page 3, line 17 skipping to change at page 3, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 7 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 7
1.1.1. Security Gateway to Security Gateway Tunnel Mode . . 8 1.1.1. Security Gateway to Security Gateway Tunnel Mode . . 8
1.1.2. Endpoint-to-Endpoint Transport Mode . . . . . . . . . 8 1.1.2. Endpoint-to-Endpoint Transport Mode . . . . . . . . . 8
1.1.3. Endpoint to Security Gateway Tunnel Mode . . . . . . 9 1.1.3. Endpoint to Security Gateway Tunnel Mode . . . . . . 9
1.1.4. Other Scenarios . . . . . . . . . . . . . . . . . . . 10 1.1.4. Other Scenarios . . . . . . . . . . . . . . . . . . . 10
1.2. The Initial Exchanges . . . . . . . . . . . . . . . . . . 10 1.2. The Initial Exchanges . . . . . . . . . . . . . . . . . . 10
1.3. The CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 13 1.3. The CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 13
1.3.1. Creating New Child SAs with the CREATE_CHILD_SA 1.3.1. Creating New Child SAs with the CREATE_CHILD_SA
Exchange . . . . . . . . . . . . . . . . . . . . . . 14 Exchange . . . . . . . . . . . . . . . . . . . . . . 14
1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange . 15 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange . 16
1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA
Exchange . . . . . . . . . . . . . . . . . . . . . . 16 Exchange . . . . . . . . . . . . . . . . . . . . . . 16
1.4. The INFORMATIONAL Exchange . . . . . . . . . . . . . . . 17 1.4. The INFORMATIONAL Exchange . . . . . . . . . . . . . . . 17
1.4.1. Deleting an SA with INFORMATIONAL Exchanges . . . . . 17 1.4.1. Deleting an SA with INFORMATIONAL Exchanges . . . . . 18
1.5. Informational Messages outside of an IKE SA . . . . . . . 18 1.5. Informational Messages outside of an IKE SA . . . . . . . 19
1.6. Requirements Terminology . . . . . . . . . . . . . . . . 19 1.6. Requirements Terminology . . . . . . . . . . . . . . . . 20
1.7. Differences Between RFC 4306 and This Document . . . . . 19 1.7. Differences Between RFC 4306 and This Document . . . . . 20
2. IKE Protocol Details and Variations . . . . . . . . . . . . . 21 2. IKE Protocol Details and Variations . . . . . . . . . . . . . 21
2.1. Use of Retransmission Timers . . . . . . . . . . . . . . 21 2.1. Use of Retransmission Timers . . . . . . . . . . . . . . 22
2.2. Use of Sequence Numbers for Message ID . . . . . . . . . 23 2.2. Use of Sequence Numbers for Message ID . . . . . . . . . 23
2.3. Window Size for Overlapping Requests . . . . . . . . . . 23 2.3. Window Size for Overlapping Requests . . . . . . . . . . 24
2.4. State Synchronization and Connection Timeouts . . . . . . 25 2.4. State Synchronization and Connection Timeouts . . . . . . 25
2.5. Version Numbers and Forward Compatibility . . . . . . . . 27 2.5. Version Numbers and Forward Compatibility . . . . . . . . 27
2.6. IKE SA SPIs and Cookies . . . . . . . . . . . . . . . . . 28 2.6. IKE SA SPIs and Cookies . . . . . . . . . . . . . . . . . 29
2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . 31 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . 31
2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 32 2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 32
2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 33 2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 33
2.8.1. Simultaneous Child SA rekeying . . . . . . . . . . . 35 2.8.1. Simultaneous Child SA rekeying . . . . . . . . . . . 35
2.8.2. Simultaneous IKE SA Rekeying . . . . . . . . . . . . 37 2.8.2. Simultaneous IKE SA Rekeying . . . . . . . . . . . . 37
2.8.3. Rekeying the IKE SA Versus Reauthentication . . . . . 38 2.8.3. Rekeying the IKE SA Versus Reauthentication . . . . . 38
2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 39 2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 39
2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 41 2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 41
2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 42
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 . . . . . . . . . . 43
2.13. Generating Keying Material . . . . . . . . . . . . . . . 43 2.13. Generating Keying Material . . . . . . . . . . . . . . . 44
2.14. Generating Keying Material for the IKE SA . . . . . . . . 45 2.14. Generating Keying Material for the IKE SA . . . . . . . . 45
2.15. Authentication of the IKE SA . . . . . . . . . . . . . . 45 2.15. Authentication of the IKE SA . . . . . . . . . . . . . . 46
2.16. Extensible Authentication Protocol Methods . . . . . . . 47 2.16. Extensible Authentication Protocol Methods . . . . . . . 48
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.19.1. Configuration Payloads . . . . . . . . . . . . . . . 53 2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 53
2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 54 2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 53
2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 55 2.21.1. Error Handling in IKE_SA_INIT . . . . . . . . . . . . 54
2.21.2. Error Handling in IKE_AUTH . . . . . . . . . . . . . 54
2.21.3. Error Handling after IKE SA is Authenticated . . . . 55
2.21.4. Error Handling Outside IKE SA . . . . . . . . . . . . 56
2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 56 2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 57 2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 58
2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 61 2.23.1. Transport Mode NAT Traversal . . . . . . . . . . . . 61
3. Header and Payload Formats . . . . . . . . . . . . . . . . . 61 2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 65
3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 61 3. Header and Payload Formats . . . . . . . . . . . . . . . . . 65
3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 64 3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 66
3.3. Security Association Payload . . . . . . . . . . . . . . 66 3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 69
3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 68 3.3. Security Association Payload . . . . . . . . . . . . . . 71
3.3.2. Transform Substructure . . . . . . . . . . . . . . . 70 3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 73
3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 73 3.3.2. Transform Substructure . . . . . . . . . . . . . . . 75
3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 73 3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 78
3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 74 3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 78
3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 76 3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 79
3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 77 3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 81
3.5. Identification Payloads . . . . . . . . . . . . . . . . . 78 3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 82
3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 80 3.5. Identification Payloads . . . . . . . . . . . . . . . . . 83
3.7. Certificate Request Payload . . . . . . . . . . . . . . . 82 3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 86
3.8. Authentication Payload . . . . . . . . . . . . . . . . . 84 3.7. Certificate Request Payload . . . . . . . . . . . . . . . 88
3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 85 3.8. Authentication Payload . . . . . . . . . . . . . . . . . 90
3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 86 3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 91
3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 87 3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 92
3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 90 3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 93
3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 92 3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 96
3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 93 3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 98
3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 94 3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 99
3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 96 3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 100
3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 98 3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 102
3.15.1. Configuration Attributes . . . . . . . . . . . . . . 99 3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 104
3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 102 3.15.1. Configuration Attributes . . . . . . . . . . . . . . 105
3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 104 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 108
3.15.4. Address Assignment Failures . . . . . . . . . . . . . 104 3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 110
3.16. Extensible Authentication Protocol (EAP) Payload . . . . 105 3.15.4. Address Assignment Failures . . . . . . . . . . . . . 111
4. Conformance Requirements . . . . . . . . . . . . . . . . . . 107 3.16. Extensible Authentication Protocol (EAP) Payload . . . . 112
5. Security Considerations . . . . . . . . . . . . . . . . . . . 109 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 113
5.1. Traffic selector authorization . . . . . . . . . . . . . 112 5. Security Considerations . . . . . . . . . . . . . . . . . . . 115
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 113 5.1. Traffic selector authorization . . . . . . . . . . . . . 118
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 113 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 119
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 114 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 119
8.1. Normative References . . . . . . . . . . . . . . . . . . 114 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 120
8.2. Informative References . . . . . . . . . . . . . . . . . 115 8.1. Normative References . . . . . . . . . . . . . . . . . . 120
Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 119 8.2. Informative References . . . . . . . . . . . . . . . . . 121
Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 120 Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 126
B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 120 Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 127
B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 121 B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 127
Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 121 B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 127
C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 122
C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 123 Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 128
C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 124 C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 128
C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 129
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 . . . . . . . . . . . . . . . . . . . . . . . . 125 Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 131
C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA . . . . 125 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA . . . . 131
C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 125 C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 131
Appendix D. Significant Changes from RFC 4306 . . . . . . . . . 125 Appendix D. Significant Changes from RFC 4306 . . . . . . . . . 131
Appendix E. Changes Between Internet Draft Versions . . . . . . 126 Appendix E. Changes Between Internet Draft Versions . . . . . . 132
E.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 126 E.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 132
E.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 126 E.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 132
E.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 128 E.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 134
E.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 129 E.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 135
E.5. Changes from draft -02 to draft -03 . . . . . . . . . . . 130 E.5. Changes from draft -02 to draft -03 . . . . . . . . . . . 136
E.6. Changes from draft -03 to E.6. Changes from draft -03 to
draft-ietf-ipsecme-ikev2bis-00 . . . . . . . . . . . . . 131 draft-ietf-ipsecme-ikev2bis-00 . . . . . . . . . . . . . 137
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 . . . . . . . . . . . . . 132 draft-ietf-ipsecme-ikev2bis-01 . . . . . . . . . . . . . 138
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 . . . . . . . . . . . . . 136 draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 142
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 . . . . . . . . . . . . . 138 draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 144
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 . . . . . . . . . . . . . 139 draft-ietf-ipsecme-ikev2bis-03 . . . . . . . . . . . . . 145
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 . . . . . . . . . . . . . 139 draft-ietf-ipsecme-ikev2bis-04 . . . . . . . . . . . . . 145
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 140 E.12. Changes from draft-ietf-ipsecme-ikev2bis-04 to
draft-ietf-ipsecme-ikev2bis-05 . . . . . . . . . . . . . 146
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 148
1. Introduction 1. Introduction
{{ An introduction to the differences between RFC 4306 [IKEV2] and {{ An introduction to the differences between RFC 4306 [IKEV2] and
this document is given at the end of Section 1. It is put there this document is given at the end of Section 1. It is put there
(instead of here) to preserve the section numbering of RFC 4306. }} (instead of here) to preserve the section numbering of RFC 4306. }}
IP Security (IPsec) provides confidentiality, data integrity, access IP Security (IPsec) provides confidentiality, data integrity, access
control, and data source authentication to IP datagrams. These control, and data source authentication to IP datagrams. These
services are provided by maintaining shared state between the source services are provided by maintaining shared state between the source
skipping to change at page 13, line 12 skipping to change at page 13, line 12
and MACs are computed correctly and that the names in the ID payloads and MACs are computed correctly and that the names in the ID payloads
correspond to the keys used to generate the AUTH payload. correspond to the keys used to generate the AUTH payload.
If creating the Child SA during the IKE_AUTH exchange fails for some If creating the Child SA during the IKE_AUTH exchange fails for some
reason, the IKE SA is still created as usual. The list of responses reason, the IKE SA is still created as usual. The list of responses
in the IKE_AUTH exchange that do not prevent an IKE SA from being set in the IKE_AUTH exchange that do not prevent an IKE SA from being set
up include at least the following: NO_PROPOSAL_CHOSEN, up include at least the following: NO_PROPOSAL_CHOSEN,
TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, and TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, and
FAILED_CP_REQUIRED. FAILED_CP_REQUIRED.
If the failure is related to creating the IKE SA (for example,
AUTHENTICATION_FAILED), the IKE SA is not created. Note that
although the IKE_AUTH messages are encrypted and integrity protected,
if the peer receiving this notification has not yet authenticated the
other end (or if the peer fails to authenticate the other end for
some reason), the information needs to be treated with caution. More
precisely, assuming that the MAC verifies correctly, the sender of
the error indication is known to be the responder of the IKE_SA_INIT
exchange, but the sender's identity cannot be assured.
Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads. Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads.
Thus, the SA payloads in the IKE_AUTH exchange cannot contain Thus, the SA payloads in the IKE_AUTH exchange cannot contain
Transform Type 4 (Diffie-Hellman Group) with any value other than Transform Type 4 (Diffie-Hellman Group) with any value other than
NONE. Implementations SHOULD omit the whole transform substructure NONE. Implementations SHOULD omit the whole transform substructure
instead of sending value NONE. instead of sending value NONE.
1.3. The CREATE_CHILD_SA Exchange 1.3. The CREATE_CHILD_SA Exchange
The CREATE_CHILD_SA exchange is used to create new Child SAs and to The CREATE_CHILD_SA exchange is used to create new Child SAs and to
rekey both IKE SAs and Child SAs. This exchange consists of a single rekey both IKE SAs and Child SAs. This exchange consists of a single
skipping to change at page 17, line 21 skipping to change at page 17, line 32
in the TS payloads in the response, which may be a subset of what the in the TS payloads in the response, which may be a subset of what the
initiator of the Child SA proposed. initiator of the Child SA proposed.
1.4. The INFORMATIONAL Exchange 1.4. The INFORMATIONAL Exchange
At various points during the operation of an IKE SA, peers may desire At various points during the operation of an IKE SA, peers may desire
to convey control messages to each other regarding errors or to convey control messages to each other regarding errors or
notifications of certain events. To accomplish this, IKE defines an notifications of certain events. To accomplish this, IKE defines an
INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur
after the initial exchanges and are cryptographically protected with after the initial exchanges and are cryptographically protected with
the negotiated keys. the negotiated keys. Section 2.21 also covers error messages in
great detail.
Control messages that pertain to an IKE SA MUST be sent under that Control messages that pertain to an IKE SA MUST be sent under that
IKE SA. Control messages that pertain to Child SAs MUST be sent IKE SA. Control messages that pertain to Child SAs MUST be sent
under the protection of the IKE SA which generated them (or its under the protection of the IKE SA which generated them (or its
successor if the IKE SA was rekeyed). successor if the IKE SA was rekeyed).
Messages in an INFORMATIONAL exchange contain zero or more Messages in an INFORMATIONAL exchange contain zero or more
Notification, Delete, and Configuration payloads. The Recipient of Notification, Delete, and Configuration payloads. The Recipient of
an INFORMATIONAL exchange request MUST send some response (else the an INFORMATIONAL exchange request MUST send some response (else the
Sender will assume the message was lost in the network and will Sender will assume the message was lost in the network and will
skipping to change at page 19, line 16 skipping to change at page 19, line 30
exchange when a node receives an ESP or AH packet with an invalid exchange when a node receives an ESP or AH packet with an invalid
SPI. The Notification Data contains the SPI of the invalid packet. SPI. The Notification Data contains the SPI of the invalid packet.
This usually indicates a node has rebooted and forgotten an SA. If This usually indicates a node has rebooted and forgotten an SA. If
this Informational Message is sent outside the context of an IKE SA, this Informational Message is sent outside the context of an IKE SA,
it should only be used by the recipient as a "hint" that something it should only be used by the recipient as a "hint" that something
might be wrong (because it could easily be forged). The recipient of might be wrong (because it could easily be forged). The recipient of
this notification cannot tell whether the SPI is for AH or ESP, but this notification cannot tell whether the SPI is for AH or ESP, but
this is not important because the SPIs are supposed to be different this is not important because the SPIs are supposed to be different
for the two. for the two.
There are two cases when such a one-way notification is sent: There are two cases when a one-way message is sent: INVALID_IKE_SPI
INVALID_IKE_SPI and INVALID_SPI. These notifications are sent and INVALID_SPI. These messages are sent outside of an IKE SA. Note
outside of an IKE SA. Note that such notifications are explicitly that such messages are explicitly not Informational exchanges; these
not Informational exchanges; these are one-way messages that must not are one-way messages that must not be responded to.
be responded to. (INVALID_MAJOR_VERSION is also a one-way message (INVALID_MAJOR_VERSION is also a one-way message which is sent
which is sent outside of an IKE SA, although it is sent as a response outside of an IKE SA, although it is sent as a response to the
to the incoming IKE SA creation.) incoming IKE SA creation.)
In case of INVALID_IKE_SPI, the message sent is a response message, In case of INVALID_IKE_SPI, the message sent is a response message,
and thus it is sent to the IP address and port from whence it came and thus it is sent to the IP address and port from whence it came
with the same IKE SPIs and the Message ID is copied. The Response with the same IKE SPIs and the Message ID is copied. The Response
bit is set to 1, and the version flags are set in the normal fashion. bit is set to 1, and the version flags are set in the normal fashion.
For a one-way INVALID_IKE_SPI notification for an unrecognized SPI, For a one-way INVALID_IKE_SPI notification for an unrecognized SPI,
the responder SHOULD copy the Exchange Type from the request. the responder SHOULD copy the Exchange Type from the request.
In case of INVALID_SPI, however, there are no IKE SPI values that In case of INVALID_SPI, however, there are no IKE SPI values that
would be meaningful to the recipient of such a notification. Using would be meaningful to the recipient of such a notification. Using
skipping to change at page 21, line 5 skipping to change at page 21, line 20
configuration attribute because its implementation was very configuration attribute because its implementation was very
problematic. Implementations that conform to this document MUST problematic. Implementations that conform to this document MUST
ignore proposals that have configuration attribute type 5, the old ignore proposals that have configuration attribute type 5, the old
value for INTERNAL_ADDRESS_EXPIRY. value for INTERNAL_ADDRESS_EXPIRY.
This document adds the restriction in Section 2.13 that all PRFs used This document adds the restriction in Section 2.13 that all PRFs used
with IKEv2 MUST take variable-sized keys. This should not affect any with IKEv2 MUST take variable-sized keys. This should not affect any
implementations because there were no standardized PRFs that have implementations because there were no standardized PRFs that have
fixed-size keys. fixed-size keys.
Section 2.21 has been greatly expanded to cover the different cases
where error responses are needed and the appropriate responses to
them.
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 34, line 14 skipping to change at page 34, line 21
To rekey a Child SA within an existing IKE SA, create a new, To rekey a Child SA within an existing IKE SA, create a new,
equivalent SA (see Section 2.17 below), and when the new one is equivalent SA (see Section 2.17 below), and when the new one is
established, delete the old one. To rekey an IKE SA, establish a new established, delete the old one. To rekey an IKE SA, establish a new
equivalent IKE SA (see Section 2.18 below) with the peer to whom the equivalent IKE SA (see Section 2.18 below) with the peer to whom the
old IKE SA is shared using a CREATE_CHILD_SA within the existing IKE old IKE SA is shared using a CREATE_CHILD_SA within the existing IKE
SA. An IKE SA so created inherits all of the original IKE SA's Child SA. An IKE SA so created inherits all of the original IKE SA's Child
SAs, and the new IKE SA is used for all control messages needed to SAs, and the new IKE SA is used for all control messages needed to
maintain those Child SAs. The old IKE SA is then deleted, and the maintain those Child SAs. The old IKE SA is then deleted, and the
Delete payload to delete itself MUST be the last request sent over Delete payload to delete itself MUST be the last request sent over
the old IKE SA. Note that, when rekeying, the new Child SA MAY have the old IKE SA. Note that, when rekeying, the new Child SA SHOULD
different traffic selectors and algorithms than the old one. 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 53, line 5 skipping to change at page 53, line 16
a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS
to perform an unnecessary configuration lookup if the IRAC cannot to perform an unnecessary configuration lookup if the IRAC cannot
process the REPLY. In the case where the IRAS's configuration process the REPLY. In the case where the IRAS's configuration
requires that CP be used for a given identity IDi, but IRAC has requires that CP be used for a given identity IDi, but IRAC has
failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and
terminate the IKE exchange with a FAILED_CP_REQUIRED error. The terminate the IKE exchange with a FAILED_CP_REQUIRED error. The
FAILED_CP_REQUIRED is not fatal to the IKE SA; it simply causes the FAILED_CP_REQUIRED is not fatal to the IKE SA; it simply causes the
Child SA creation fail. The initiator can fix this by later starting Child SA creation fail. The initiator can fix this by later starting
a new configuration payload request. a new configuration payload request.
2.19.1. Configuration Payloads
Editor's note: some of this sub-section is redundant and will go away
in the next version of the document.
In support of the scenario described in Section 1.1.3, an initiator
may request that the responder assign an IP address and tell the
initiator what it is. That request is done using configuration
payloads, not traffic selectors. An address in a TSi payload in a
response does not mean that the responder has assigned that address
to the initiator: it only means that if packets matching these
traffic selectors are sent by the initiator, IPsec processing can be
performed as agreed for this SA.
Configuration payloads are of type CFG_REQUEST/CFG_REPLY or CFG_SET/
CFG_ACK (see CFG Type in the payload description below). CFG_REQUEST
and CFG_SET payloads may optionally be added to any IKE request. The
IKE response MUST include either a corresponding CFG_REPLY or CFG_ACK
or a Notify payload with an error type indicating why the request
could not be honored. An exception is that a minimal implementation
MAY ignore all CFG_REQUEST and CFG_SET payloads, so a response
message without a corresponding CFG_REPLY or CFG_ACK MUST be accepted
as an indication that the request was not supported.
"CFG_REQUEST/CFG_REPLY" allows an IKE endpoint to request information
from its peer. If an attribute in the CFG_REQUEST Configuration
Payload is not zero-length, it is taken as a suggestion for that
attribute. The CFG_REPLY Configuration Payload MAY return that
value, or a new one. It MAY also add new attributes and not include
some requested ones. Requestors MUST ignore returned attributes that
they do not recognize.
Some attributes MAY be multi-valued, in which case multiple attribute
values of the same type are sent and/or returned. Generally, all
values of an attribute are returned when the attribute is requested.
For some attributes (in this version of the specification only
internal addresses), multiple requests indicates a request that
multiple values be assigned. For these attributes, the number of
values returned SHOULD NOT exceed the number requested.
If the data type requested in a CFG_REQUEST is not recognized or not
supported, the responder MUST NOT return an error type but rather
MUST either send a CFG_REPLY that MAY be empty or a reply not
containing a CFG_REPLY payload at all. Error returns are reserved
for cases where the request is recognized but cannot be performed as
requested or the request is badly formatted.
"CFG_SET/CFG_ACK" allows an IKE endpoint to push configuration data
to its peer. In this case, the CFG_SET Configuration Payload
contains attributes the initiator wants its peer to alter. The
responder MUST return a Configuration Payload if it accepted any of
the configuration data and it MUST contain the attributes that the
responder accepted with zero-length data. Those attributes that it
did not accept MUST NOT be in the CFG_ACK Configuration Payload. If
no attributes were accepted, the responder MUST return either an
empty CFG_ACK payload or a response message without a CFG_ACK
payload. There are currently no defined uses for the CFG_SET/CFG_ACK
exchange, though they may be used in connection with extensions based
on Vendor IDs. An minimal implementation of this specification MAY
ignore CFG_SET payloads.
Extensions via the CP payload should not be used for general purpose
management. Its main intent is to provide a bootstrap mechanism to
exchange information within IPsec from IRAS to IRAC. While it MAY be
useful to use such a method to exchange information between some
Security Gateways (SGW) or small networks, existing management
protocols such as DHCP [DHCP], RADIUS [RADIUS], SNMP, or LDAP [LDAP]
should be preferred for enterprise management as well as subsequent
information exchanges.
2.20. Requesting the Peer's Version 2.20. Requesting the Peer's Version
An IKE peer wishing to inquire about the other peer's IKE software An IKE peer wishing to inquire about the other peer's IKE software
version information MAY use the method below. This is an example of version information MAY use the method below. This is an example of
a configuration request within an INFORMATIONAL exchange, after the a configuration request within an INFORMATIONAL exchange, after the
IKE SA and first Child SA have been created. IKE SA and first Child SA have been created.
An IKE implementation MAY decline to give out version information An IKE implementation MAY decline to give out version information
prior to authentication or even after authentication to prevent prior to authentication or even after authentication to prevent
trolling in case some implementation is known to have some security trolling in case some implementation is known to have some security
skipping to change at page 55, line 8 skipping to change at page 53, line 43
CP(CFG_REQUEST)= CP(CFG_REQUEST)=
APPLICATION_VERSION("") APPLICATION_VERSION("")
CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar
Inc.") Inc.")
2.21. Error Handling 2.21. Error Handling
There are many kinds of errors that can occur during IKE processing. There are many kinds of errors that can occur during IKE processing.
If a request is received that is badly formatted or unacceptable for The general rule is that if a request is received that is badly
reasons of policy (e.g., no matching cryptographic algorithms), the formatted, or unacceptable for reasons of policy (such as no matching
response MUST contain a Notify payload indicating the error. If an cryptographic algorithms), the response contains a Notify payload
error occurs outside the context of an IKE request (e.g., the node is indicating the error. The decision whether or not to send such a
getting ESP messages on a nonexistent SPI), the node SHOULD initiate response depends whether or not there is an authenticated IKE SA.
an INFORMATIONAL exchange with a Notify payload describing the
problem. If there is an error parsing or processing a response packet, the
general rule is to not send back any error message because responses
should not generate new requests (and a new request would be the only
way to send back an error message). Such errors in parsing or
processing response packets should still cause the recipient to clean
up the IKE state (for example, by sending a DELETE for a bad SA).
Only authentication failures (AUTHENTICATION_FAILED) and malformed
messages (INVALID_SYNTAX) lead to a deletion of the IKE SA without
requiring an explicit INFORMATIONAL exchange carrying a DELETE
payload. Other error conditions MAY require such an exchange if
policy dictates that this is needed.
2.21.1. Error Handling in IKE_SA_INIT
Errors that occur before a cryptographically protected IKE SA is Errors that occur before a cryptographically protected IKE SA is
established must be handled very carefully. There is a trade-off established need to be handled very carefully. There is a trade-off
between wanting to be helpful in diagnosing a problem and responding between wanting to help the peer to diagnose a problem and thus
to it and wanting to avoid being a dupe in a denial of service attack responding to the error, and wanting to avoid being part of a denial
based on forged messages. of service attack based on forged messages.
In an IKE_SA_INIT exchange, any error notification causes the
exchange to fail. Note that some error notifications such as COOKIE,
INVALID_KE_PAYLOAD or INVALID_MAJOR_VERSION may lead to a subsequent
successful exchange. Because all error notifications are completely
unauthenticated, the recipient should continue trying for some time
before giving up. The recipient should not immediately act based on
the error notification unless corrective actions are defined in this
specification, such as for COOKIE, INVALID_KE_PAYLOAD, and
INVALID_MAJOR_VERSION.
2.21.2. Error Handling in IKE_AUTH
All errors that occur in an IKE_AUTH exchange, causing the
authentication to fail for whatever reason (invalid shared secret,
invalid ID, untrusted certificate issuer, revoked or expired
certificate, etc.) SHOULD result in an AUTHENTICATION_FAILED
notification. If the error occurred on the responder, the
notification is returned in the protected response, and is usually
the only payload in that response. Although the IKE_AUTH messages
are encrypted and integrity protected, if the peer receiving this
notification has not authenticated the other end yet, that peer needs
to treat the information with caution.
If the error occurs on the initiator, the notification MAY be
returned in a separate INFORMATIONAL exchange, usually with no other
payloads. This is exception for the general rule of not starting new
exchanges based on errors in responses.
Note, however, that request messages that contain an unsupported
critical payload, or where the whole message is malformed (rather
than just bad payload contents), MUST be rejected in their entirety,
and MUST only lead to an UNSUPPORTED_CRITICAL_PAYLOAD or
INVALID_SYNTAX Notification sent as response. The receiver should
not verify the payloads related to authentication in this case.
If authentication has succeeded in the IKE_AUTH exchange, the IKE SA
is established; however, establishing the Child SA or requesting
configuration information may still fail. This failure does not
automatically cause the IKE SA to be deleted. Specifically, a
responder may include all the payloads associated with authentication
(IDr, Cert and AUTH) while sending error notifications for the
piggybacked exchanges (FAILED_CP_REQUIRED, INVALID_SELECTORS,
NO_PROPOSAL_CHOSEN, and so on), and the initiator MUST NOT fail the
authentication because of this. The initiator MAY, of course, for
reasons of policy later delete such an IKE SA.
In an IKE_AUTH exchange, or in the INFORMATIONAL exchange immediately
following it (in case an error happened in when processing response
to IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and
AUTHENTICATION_FAILED notifications are the only ones to cause the
IKE SA to be deleted or not created, without a DELETE payload.
Extension documents may define new error notifications with these
semantics, but MUST NOT use them unless the peer has been shown to
understand them.
NOTE FOR WG DISCUSSION: Having other payloads in the message is
allowed but there are none suggested. One WG member mentioned the
possibility of adding a DELETE payload when the error is sent in a
separate INFORMATIONAL exchange. Do we want to allow such additional
payloads that have operational semantics?
2.21.3. Error Handling after IKE SA is Authenticated
After the IKE SA is authenticated all requests having errors MUST
result in response notifying about the error.
In normal situations, there should not be cases where valid response
from one peer results in an error situation in the other peer, so
there should not be any reason for a peer to send error messages to
the other end except as a response. Because sending such error
messages as INFORMATIONAL exchange might lead to further errors that
could cause loops, such errors SHOULD NOT be sent. If errors are
seen that indicate that the peers do not have same state, it might be
good to delete the IKE SA to clean up state and start over.
If a peer parsing a request notices that it is badly formatted (after
it has passed the message authentication code checks and window
checks) and it returns an INVALID_SYNTAX notification, then this
error notification is considered fatal in both peers, meaning that
the IKE SA is deleted without needing an explicit DELETE payload.
2.21.4. Error Handling Outside IKE SA
A node needs to limit the rate at which it will send messages in
response to unprotected messages.
If a node receives a message on UDP port 500 or 4500 outside the If a node receives a message on UDP port 500 or 4500 outside the
context of an IKE SA known to it (and not a request to start one), it context of an IKE SA known to it (and the message is not a request to
may be the result of a recent crash of the node. If the message is start an IKE SA), this may be the result of a recent crash of the
marked as a response, the node MAY audit the suspicious event but node. If the message is marked as a response, the node can audit the
MUST NOT respond. If the message is marked as a request, the node suspicious event but MUST NOT respond. If the message is marked as a
MAY audit the suspicious event and MAY send a response. If a request, the node can audit the suspicious event and MAY send a
response is sent, the response MUST be sent to the IP address and response. If a response is sent, the response MUST be sent to the IP
port from whence it came with the same IKE SPIs and the Message ID address and port from where it came with the same IKE SPIs and the
copied. The response MUST NOT be cryptographically protected and Message ID copied. The response MUST NOT be cryptographically
MUST contain a Notify payload indicating INVALID_IKE_SPI. The protected and MUST contain an INVALID_IKE_SPI Notify payload. The
INVALID_IKE_SPI notification indicates an IKE message was received INVALID_IKE_SPI notification indicates an IKE message was received
with an unrecognized destination SPI; this usually indicates that the with an unrecognized destination SPI; this usually indicates that the
recipient has rebooted and forgotten the existence of an IKE SA. recipient has rebooted and forgotten the existence of an IKE SA.
A node receiving such an unprotected Notify payload MUST NOT respond A peer receiving such an unprotected Notify payload MUST NOT respond
and MUST NOT change the state of any existing SAs. The message might and MUST NOT change the state of any existing SAs. The message might
be a forgery or might be a response the genuine correspondent was be a forgery or might be a response that a genuine correspondent was
tricked into sending. A node should treat such a message (and also a tricked into sending. A node should treat such a message (and also a
network message like ICMP destination unreachable) as a hint that network message like ICMP destination unreachable) as a hint that
there might be problems with SAs to that IP address and should there might be problems with SAs to that IP address and should
initiate a liveness test for any such IKE SA. An implementation initiate a liveness check for any such IKE SA. An implementation
SHOULD limit the frequency of such tests to avoid being tricked into SHOULD limit the frequency of such tests to avoid being tricked into
participating in a denial of service attack. participating in a denial of service attack.
A node receiving a suspicious message from an IP address with which If an error occurs outside the context of an IKE request (e.g., the
it has an IKE SA MAY send an IKE Notify payload in an IKE node is getting ESP messages on a nonexistent SPI), the node SHOULD
INFORMATIONAL exchange over that SA. The recipient MUST NOT change initiate an INFORMATIONAL exchange with a Notify payload describing
the state of any SAs as a result, but may wish to audit the event to the problem.
aid in diagnosing malfunctions. A node MUST limit the rate at which
it will send messages in response to unprotected messages. A node receiving a suspicious message from an IP address (and port,
if NAT traversal is used) with which it has an IKE SA SHOULD send an
IKE Notify payload in an IKE INFORMATIONAL exchange over that SA.
The recipient MUST NOT change the state of any SAs as a result, but
may wish to audit the event to aid in diagnosing malfunctions.
2.22. IPComp 2.22. IPComp
Use of IP compression [IP-COMP] can be negotiated as part of the Use of IP compression [IP-COMP] can be negotiated as part of the
setup of a Child SA. While IP compression involves an extra header setup of a Child SA. While IP compression involves an extra header
in each packet and a compression parameter index (CPI), the virtual in each packet and a compression parameter index (CPI), the virtual
"compression association" has no life outside the ESP or AH SA that "compression association" has no life outside the ESP or AH SA that
contains it. Compression associations disappear when the contains it. Compression associations disappear when the
corresponding ESP or AH SA goes away. It is not explicitly mentioned corresponding ESP or AH SA goes away. It is not explicitly mentioned
in any DELETE payload. in any DELETE payload.
skipping to change at page 61, line 5 skipping to change at page 61, line 44
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
MOBIKE's way of recovering from the same situation, so this method MOBIKE's way of recovering from the same situation, so this method
MUST NOT be used when MOBIKE is used. See Section 3.8 of [MOBIKE] MUST NOT be used when MOBIKE is used. See Section 3.8 of [MOBIKE]
for more information. for more information.
2.23.1. Transport Mode NAT Traversal
Transport mode used with NAT Traversal requires special handling of
the traffic selectors used in the IKEv2. The complete scenario looks
like:
+------+ +------+ +------+ +------+
|Client| IP1 | NAT | IPN1 IPN2 | NAT | IP2 |Server|
|node |<------>| A |<---------->| B |<------->| |
+------+ +------+ +------+ +------+
(Other scenarios are simplications of this complex case, so this
discussion uses the complete scenario.)
In this scenario, there are two address translating NATs: NAT A and
NAT B. NAT A is dynamic NAT that maps the clients source address IP1
to IPN1. NAT B is static NAT configured so that connections coming
to IPN2 address are mapped to the gateways adddress IP2, that is,
IPN2 destination address is mapped to IP2. This allows the client to
connect to a server by connecting to the IPN2. NAT B does not
necessarily need to be a static NAT, but the client needs to know how
to connect to the server, and it can only do that if it somehow knows
the outer address of the NAT B, that is, the IPN2 address. If NAT B
is a static NAT, then its address can be configured to the client's
configuration. Other options would be find it using some other
protocol (like DNS), but those are outside of scope of IKEv2.
In this scenario, both client and server are configured to use
transport mode for the traffic originating from the client node and
destined to the server.
When the client starts creating the IKEv2 SA and Child SA for sending
traffic to the server, it has a triggering packet with source IP
address of IP1, and a destination IP address of IPN2. Its PAD and
SPD needs to have configuration matching those addresses (or wildcard
entries covering them). Because this is transport mode, it uses
exactly same addresses as the traffic selectors and outer IP address
of the IKE packets. For transport mode, it MUST use exactly one IP
address in the TSi and TSr payloads. It can have multiple traffic
selectors if it has, for example, multiple port ranges that it wants
to negotiate, but all TSi entries must use IP1-IP1 range as the IP
addresses, and all TSr entries must have the IPN2-IPN2 range as IP
the addresses. The first traffic selector of TSi and TSr SHOULD have
very specific traffic selectors including protocol and port numbers
from the packet triggering the request.
NAT A will then replace the source address of the IKE packet from IP1
to IPN1, and NAT B will replace the destination address of the IKE
packet from IPN2 to IP2, so when the packet arrives to the server it
will still have the exactly same traffic selectors which were sent by
the client, but the IP address of the IKE packet has been replaced to
IPN1 and IP2.
When the server receives this packet, it normally looks the PAD based
on the ID and then searches the SPD based on the traffic selectors.
Because IP1 does not really mean anything to the server (it is the
address client has behind the NAT), it is useless to do lookup based
on that if transport mode is used. On the other hand, the server
cannot know whether transport mode is allowed by its policy before it
finds the matching SPD entry.
In this case, the server should first check that as initiator
requested transport mode and do address substitution on the traffic
selectors. It needs to first store the old traffic selector IP
addresses to be used later for the incremental checksum fixup (the IP
address in the TSi can be stored as the real source address and the
IP address in the TSr can be stored as the real destination address).
After that, if the other end was detected as being behind a NAT, the
server replaces the IP address in TSi payloads with the IP address
obtained from the source address of the IKE packet received (that is,
it replaces IP1 in TSi with IPN1). If the server's end was detected
to be behind NAT, it replaces the IP address in the TSr payloads with
the IP address obtained from the destination address of the IKE
packet received (thta is, it replaces IPN2 in TSr with IP2).
After this address substitution, both the traffic selectors and the
IKE UDP source/destination addresses look the same, and the server
does SPD lookup based on those new traffic selectors. If an entry is
found and it allows transport mode, then that entry is used. If an
entry is found but it does not allow transport mode, then the server
MAY undo the address substitution and redo the SPD lookup using the
original traffic selectors. If the second lookup succeeds, the
server will create an SA in tunnel mode using real traffic selectors
sent by the other end.
This address substitution in transport mode is needed because the SPD
is looked up using the addresses that will be seen by the local host.
This also will make sure the SAD entries for the tunnel exit checks
and return packets is added using the addresses as seen by the local
operating system stack.
The most common case is that the server's SPD will contain wildcard
entries matching any addresses, but this allows also making different
SPD entries, for example, for different known NATs outer addresses.
After the SPD lookup, the server will do traffic selector narrowing
based on the SPD entry it found. It will again use the already-
substituted traffic selectors, and it will thus send back traffic
selectors having IPN1 and IP2 as their IP addresses; it can still
narrow down the protocol number or port ranges used by the traffic
selectors. The SAD entry created for the Child SA will have the
addresses as seen by the server, namely IPN1 and IP2.
When the client receives the server's reply to the Child SA, it will
do similar processing. If the transport mode SA was created, the
client can store the original returned traffic selectors as real
source and destination addresses. It will replace the IP addresses
in the traffic selectors with the ones from the IP header of the IKE
packet: it will replace IPN1 with IP1 and IP2 with IPN2. Then it
will use those traffic selectors when verifying the SA against sent
traffic selectors, and when installing the SAD entry.
A summary of the rules for NAT-traversal in transport mode is:
For the client proposing transport mode:
- The TSi entries MUST have exactly one IP address, and that MUST
match the source address of the IKE SA.
- The TSr entries MUST have exactly one IP address, and that MUST
match the destination address of the IKE SA.
- The first TSi and TSr traffic selectors SHOULD have very specific
traffic selectors including protocol and port numbers from the
packet triggering the request.
- There MAY be multiple TSi and TSr entries.
- If transport mode for the SA was selected (that is, if the server
included USE_TRANSPORT_MODE notification in its reply):
- Store the original traffic selectors as the real source and
destination address.
- If the server is behind a NAT, substitute the IP address in the
TSr entries with the remote address of the IKE SA.
- If the client is behind a NAT, substitute the IP address in the
TSi entries with the local address of the IKE SA.
- Do address substitution before using those traffic selectors
for anything else other than storing original content of them.
This includes verification that traffic selectors were narrowed
correctly by other end, creation of the SAD entry, and so on.
For the responder, when transport mode is proposed by client:
- Store the original traffic selector IP addresses as real source
and destination address in case we need to undo address
substitution.
- If the client is behind a NAT, substitute the IP address in the
TSi entries with the remote address of the IKE SA.
- If the server is behind a NAT substitute the IP address in the
TSr entries with the local address of the IKE SA.
- Do PAD and SPD lookup using the ID and substituted traffic
selectors.
- If no SPD entry was found, or if found SPD entry does not
allow transport mode, undo the traffic selector substitutions.
Do PAD and SPD lookup again using the ID and original traffic
selectors, but also searching for tunnel mode SPD entry (that
is, fall back to tunnel mode).
- However, if a transport mode SPD entry was found, do normal
traffic selection narrowing based on the substituted traffic
selectors and SPD entry. Use the resulting traffic selectors when
creating SAD entries, and when sending traffic selectors back to
the client.
2.24. Explicit Congestion Notification (ECN) 2.24. Explicit Congestion Notification (ECN)
When IPsec tunnels behave as originally specified in [IPSECARCH-OLD], When IPsec tunnels behave as originally specified in [IPSECARCH-OLD],
ECN usage is not appropriate for the outer IP headers because tunnel ECN usage is not appropriate for the outer IP headers because tunnel
decapsulation processing discards ECN congestion indications to the decapsulation processing discards ECN congestion indications to the
detriment of the network. ECN support for IPsec tunnels for IKEv1- detriment of the network. ECN support for IPsec tunnels for IKEv1-
based IPsec requires multiple operating modes and negotiation (see based IPsec requires multiple operating modes and negotiation (see
[ECN]). IKEv2 simplifies this situation by requiring that ECN be [ECN]). IKEv2 simplifies this situation by requiring that ECN be
usable in the outer IP headers of all tunnel-mode IPsec SAs created usable in the outer IP headers of all tunnel-mode IPsec SAs created
by IKEv2. Specifically, tunnel encapsulators and decapsulators for by IKEv2. Specifically, tunnel encapsulators and decapsulators for
skipping to change at page 72, line 48 skipping to change at page 77, line 48
1536-bit MODP 5 [ADDGROUP] 1536-bit MODP 5 [ADDGROUP]
RESERVED TO IANA 6-13 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 RESERVED TO IANA 19-1023
PRIVATE USE 1024-65535 PRIVATE USE 1024-65535
Although ESP and AH do not directly include a Diffie-Hellman
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
exchange, providing perfect forward secrecy for the generated Child
SA keys.
For Transform Type 5 (Extended Sequence Numbers), defined Transform For Transform Type 5 (Extended Sequence Numbers), defined Transform
IDs are: IDs are:
Name Number Name Number
-------------------------------------------- --------------------------------------------
No Extended Sequence Numbers 0 No Extended Sequence Numbers 0
Extended Sequence Numbers 1 Extended Sequence Numbers 1
RESERVED 2 - 65535 RESERVED 2 - 65535
Note that an initiator who supports ESNs will usually include two ESN Note that an initiator who supports ESNs will usually include two ESN
skipping to change at page 78, line 24 skipping to change at page 83, line 36
ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2
does not require this address to match the address in the IP header does not require this address to match the address in the IP header
of IKEv2 packets, or anything in the TSi/TSr payloads. The contents of IKEv2 packets, or anything in the TSi/TSr payloads. The contents
of IDi/IDr is used purely to fetch the policy and authentication data of IDi/IDr is used purely to fetch the policy and authentication data
related to the other party. related to the other party.
NOTE: In IKEv1, two ID payloads were used in each direction to hold NOTE: In IKEv1, two ID payloads were used in each direction to hold
Traffic Selector (TS) information for data passing over the SA. In Traffic Selector (TS) information for data passing over the SA. In
IKEv2, this information is carried in TS payloads (see Section 3.13). IKEv2, this information is carried in TS payloads (see Section 3.13).
The Peer Authorization Database (PAD) as described in RFC 4301
[IPSECARCH] describes the use of the ID payload in IKEv2 and provides
a formal model for the binding of identity to policy in addition to
providing services that deal more specifically with the details of
policy enforcement. The PAD is intended to provide a link between
the SPD and the IKE security association management. See Section
4.4.3 of RFC 4301 for more details.
The Identification Payload consists of the IKE generic payload header The Identification Payload consists of the IKE generic payload header
followed by identification fields as follows: followed by identification fields as follows:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID Type | RESERVED | | ID Type | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 81, line 39 skipping to change at page 87, line 35
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 (4) contains a DER encoded X.509
certificate whose public key is used to validate the sender's AUTH certificate whose public key is used to validate the sender's AUTH
payload. Note that with this encoding, if a chain of certificates
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
payload. payload.
o Certificate Revocation List (7) contains a DER encoded X.509 o Certificate Revocation List (7) contains a DER encoded X.509
certificate revocation list. certificate revocation list.
o Raw RSA Key (11) contains a PKCS #1 encoded RSA key, that is, a o Raw RSA Key (11) contains a PKCS #1 encoded RSA key, that is, a
DER-encoded RSAPublicKey structure (see [RSA] and [PKCS1]). DER-encoded RSAPublicKey structure (see [RSA] and [PKCS1]).
o Hash and URL encodings (12-13) allow IKE messages to remain short o Hash and URL encodings (12-13) allow IKE messages to remain short
by replacing long data structures with a 20 octet SHA-1 hash (see by replacing long data structures with a 20 octet SHA-1 hash (see
skipping to change at page 97, line 5 skipping to change at page 103, line 5
algorithm that computes a fixed-length checksum over a variable size algorithm that computes a fixed-length checksum over a variable size
message. The design is modeled after the ESP algorithms described in message. The design is modeled after the ESP algorithms described in
RFCs 2104 [HMAC], 4303 [ESP], and 2451 [ESPCBC]. This document RFCs 2104 [HMAC], 4303 [ESP], and 2451 [ESPCBC]. This document
completely specifies the cryptographic processing of IKE data, but completely specifies the cryptographic processing of IKE data, but
those documents should be consulted for design rationale. Future those documents should be consulted for design rationale. Future
documents may specify the processing of Encrypted payloads for other documents may specify the processing of Encrypted payloads for other
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
SA, the construction of the encrypted payload is different that what
is described here. See [RFC5282] for more information on
authenticated 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector | | Initialization Vector |
skipping to change at page 102, line 11 skipping to change at page 108, line 11
prefix-length as defined in [ADDRIPV6]. Multiple sub-networks MAY prefix-length as defined in [ADDRIPV6]. Multiple sub-networks MAY
be requested. The responder MAY respond with zero or more sub- be requested. The responder MAY respond with zero or more sub-
network attributes. This is discussed in more detail in Section network attributes. This is discussed in more detail in Section
3.15.2. 3.15.2.
Note that no recommendations are made in this document as to how an Note that no recommendations are made in this document as to how an
implementation actually figures out what information to send in a implementation actually figures out what information to send in a
reply. That is, we do not recommend any specific method of an IRAS reply. That is, we do not recommend any specific method of an IRAS
determining which DNS server should be returned to a requesting IRAC. determining which DNS server should be returned to a requesting IRAC.
The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to request
information from its peer. If an attribute in the CFG_REQUEST
Configuration Payload is not zero-length, it is taken as a suggestion
for that attribute. The CFG_REPLY Configuration Payload MAY return
that value, or a new one. It MAY also add new attributes and not
include some requested ones. Requestors MUST ignore returned
attributes that they do not recognize.
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 Payload contains attributes the initiator wants its
peer to alter. The responder MUST return a Configuration Payload if
it accepted any of the configuration data and it MUST contain the
attributes that the responder accepted with zero-length data. Those
attributes that it did not accept MUST NOT be in the CFG_ACK
Configuration Payload. If no attributes were accepted, the responder
MUST return either an empty CFG_ACK payload or a response message
without a CFG_ACK payload. There are currently no defined uses for
the CFG_SET/CFG_ACK exchange, though they may be used in connection
with extensions based on Vendor IDs. An implementation of this
specification MAY ignore CFG_SET payloads.
3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET
INTERNAL_IP4/6_SUBNET attributes can indicate additional subnets, INTERNAL_IP4/6_SUBNET attributes can indicate additional subnets,
ones that need one or more separate SAs, that can be reached through ones that need one or more separate SAs, that can be reached through
the gateway that announces the attributes. INTERNAL_IP4/6_SUBNET the gateway that announces the attributes. INTERNAL_IP4/6_SUBNET
attributes may also express the gateway's policy about what traffic attributes may also express the gateway's policy about what traffic
should be sent through the gateway; the client can choose whether should be sent through the gateway; the client can choose whether
other traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is other traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is
sent through the gateway or directly to the destination. Thus, sent through the gateway or directly to the destination. Thus,
traffic to the addresses listed in the INTERNAL_IP4/6_SUBNET traffic to the addresses listed in the INTERNAL_IP4/6_SUBNET
skipping to change at page 104, line 11 skipping to change at page 110, line 30
Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET is in Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET is in
CFG_REQUESTs is unclear, they cannot be used reliably in CFG_REQUESTs is unclear, they cannot be used reliably in
CFG_REQUESTs. CFG_REQUESTs.
3.15.3. Configuration payloads for IPv6 3.15.3. Configuration payloads for IPv6
The configuration payloads for IPv6 are based on the corresponding The configuration payloads for IPv6 are based on the corresponding
IPv4 payloads, and do not fully follow the "normal IPv6 way of doing IPv4 payloads, and do not fully follow the "normal IPv6 way of doing
things". In particular, IPv6 stateless autoconfiguration or router things". In particular, IPv6 stateless autoconfiguration or router
advertisement messages are not used; neither is neighbor discovery. advertisement messages are not used; neither is neighbor discovery.
Note that there is an additional document that discusses IPv6
configuration in IKEv2, [IPV6CONFIG]. At the present time, it is an
experimental document, but there is a hope that with more
implementation experience, it will gain the same standards treatment
as this document.
A client can be assigned an IPv6 address using the A client can be assigned an IPv6 address using the
INTERNAL_IP6_ADDRESS configuration payload. A minimal exchange might INTERNAL_IP6_ADDRESS configuration payload. A minimal exchange might
look like this: look like this:
CP(CFG_REQUEST) = CP(CFG_REQUEST) =
INTERNAL_IP6_ADDRESS() INTERNAL_IP6_ADDRESS()
INTERNAL_IP6_DNS() INTERNAL_IP6_DNS()
TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
skipping to change at page 113, line 22 skipping to change at page 119, line 48
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, so the are not listed here again.
No new types or values are registered in this document. However, No new types or values are registered in this document. However,
IANA should update all references to RFC 4306 to point to this IANA should update all references to RFC 4306 to point to this
document. document.
7. Acknowledgements 7. Acknowledgements
The individuals on the IPsec mailing list was very helpful in both Many individuals in the IPsecME Working Group were very helpful in
pointing out where clarifications and changes were needed, as well as contributing ideas and text for this document, as well as in
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:
This document is a collaborative effort of the entire IPsec WG. If This document is a collaborative effort of the entire IPsec WG. If
there were no limit to the number of authors that could appear on an there were no limit to the number of authors that could appear on an
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
skipping to change at page 115, line 7 skipping to change at page 121, line 33
[RFC4434] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the [RFC4434] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
Internet Key Exchange Protocol (IKE)", RFC 4434, Internet Key Exchange Protocol (IKE)", RFC 4434,
February 2006. February 2006.
[RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The
Advanced Encryption Standard-Cipher-based Message Advanced Encryption Standard-Cipher-based Message
Authentication Code-Pseudo-Random Function-128 (AES-CMAC- Authentication Code-Pseudo-Random Function-128 (AES-CMAC-
PRF-128) Algorithm for the Internet Key Exchange Protocol PRF-128) Algorithm for the Internet Key Exchange Protocol
(IKE)", RFC 4615, August 2006. (IKE)", RFC 4615, August 2006.
[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., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, January 2008. Encryption", RFC 5116, January 2008.
skipping to change at page 115, line 39 skipping to change at page 122, line 22
Implementation Guidelines", RFC 4718, October 2006. Implementation Guidelines", RFC 4718, October 2006.
[DES] American National Standards Institute, "American National [DES] American National Standards Institute, "American National
Standard for Information Systems-Data Link Encryption", Standard for Information Systems-Data Link Encryption",
ANSI X3.106, 1983. ANSI X3.106, 1983.
[DH] Diffie, W. and M. Hellman, "New Directions in [DH] Diffie, W. and M. Hellman, "New Directions in
Cryptography", IEEE Transactions on Information Theory, Cryptography", IEEE Transactions on Information Theory,
V.IT-22 n. 6, June 1977. V.IT-22 n. 6, June 1977.
[DHCP] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[DIFFSERVARCH] [DIFFSERVARCH]
Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475. Services", RFC 2475.
[DIFFSERVFIELD] [DIFFSERVFIELD]
Nichols, K., Blake, S., Baker, F., and D. Black, Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998. December 1998.
skipping to change at page 117, line 23 skipping to change at page 124, line 5
September 2001. September 2001.
[IPSECARCH-OLD] [IPSECARCH-OLD]
Kent, S. and R. Atkinson, "Security Architecture for the Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[IPV6ADDR] [IPV6ADDR]
Hinden, R. and S. Deering, "Internet Protocol Version 6 Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 4291, February 2006. (IPv6) Addressing Architecture", RFC 4291, February 2006.
[IPV6CONFIG]
Eronen, et. al., P., "IPv6 Configuration in IKEv2",
draft-ietf-ipsecme-ikev2-ipv6-config (work in progress),
August 2009.
[ISAKMP] Maughan, D., Schneider, M., and M. Schertler, "Internet [ISAKMP] Maughan, D., Schneider, M., and M. Schertler, "Internet
Security Association and Key Management Protocol Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998. (ISAKMP)", RFC 2408, November 1998.
[LDAP] Sermersheim, J., "Lightweight Directory Access Protocol
(v3)", RFC 4511, June 2006.
[MAILFORMAT] [MAILFORMAT]
Resnick, P., "Internet Message Format", RFC 2822, Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[MIPV6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [MIPV6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
skipping to change at page 118, line 18 skipping to change at page 124, line 50
[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol",
RFC 2412, November 1998. RFC 2412, November 1998.
[PFKEY] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key [PFKEY] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
Management API, Version 2", RFC 2367, July 1998. Management API, Version 2", RFC 2367, July 1998.
[PHOTURIS] [PHOTURIS]
Karn, P. and W. Simpson, "Photuris: Session-Key Management Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999. Protocol", RFC 2522, March 1999.
[RADIUS] Rigney, C., Rubens, A., Simpson, W., and S. Willens,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2138, April 1997.
[RANDOMNESS] [RANDOMNESS]
Eastlake, D., Schiller, J., and S. Crocker, "Randomness Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[REAUTH] Nir, Y., "Repeated Authentication in Internet Key Exchange [REAUTH] Nir, Y., "Repeated Authentication in Internet Key Exchange
(IKEv2) Protocol", RFC 4478, April 2006. (IKEv2) Protocol", RFC 4478, April 2006.
[REUSE] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In [REUSE] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In
Diffie-Hellman Key Agreement Protocols", December 2008, Diffie-Hellman Key Agreement Protocols", December 2008,
<http://www.cacr.math.uwaterloo.ca/~ajmeneze/ <http://www.cacr.math.uwaterloo.ca/~ajmeneze/
publications/ephemeral.pdf>. publications/ephemeral.pdf>.
[ROHCV2] Ertekin, et. al., E., "IKEv2 Extensions to Support Robust [ROHCV2] Ertekin, et. al., E., "IKEv2 Extensions to Support Robust
Header Compression over IPsec (ROHCoIPsec)", Header Compression over IPsec (ROHCoIPsec)",
draft-ietf-rohc-ikev2-extensions-hcoipsec (work in draft-ietf-rohc-ikev2-extensions-hcoipsec (work in
progress), October 2008. progress), August 2009.
[RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for [RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for
Obtaining Digital Signatures and Public-Key Obtaining Digital Signatures and Public-Key
Cryptosystems", February 1978. Cryptosystems", February 1978.
[SHA] National Institute of Standards and Technology, U.S. [SHA] National Institute of Standards and Technology, U.S.
Department of Commerce, "Secure Hash Standard", Department of Commerce, "Secure Hash Standard",
FIPS 180-3, October 2008. FIPS 180-3, October 2008.
[SIGMA] H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to [SIGMA] H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to
skipping to change at page 141, line 5 skipping to change at page 146, line 47
In 2.18, added "using SPIi, SPIr, Ni, and Nr from the new exchange" In 2.18, added "using SPIi, SPIr, Ni, and Nr from the new exchange"
to the last sentence. to the last sentence.
Removed INTERNAL_IP6_NBNS from 3.15.1. [Issue #44] Removed INTERNAL_IP6_NBNS from 3.15.1. [Issue #44]
Changed "The requested address is valid until there are no IKE_SAs Changed "The requested address is valid until there are no IKE_SAs
between the peers" to "The requested address is valid as long as this between the peers" to "The requested address is valid as long as this
IKE SA (or its rekeyed successors) requesting the address is valid." IKE SA (or its rekeyed successors) requesting the address is valid."
[Issue #43] [Issue #43]
E.12. Changes from draft-ietf-ipsecme-ikev2bis-04 to
draft-ietf-ipsecme-ikev2bis-05
Added the following near the end of 1.2: "If the failure is related
to creating the IKE SA (for example, AUTHENTICATION_FAILED), the IKE
SA is not created. Note that although the IKE_AUTH messages are
encrypted and integrity protected, if the peer receiving this
notification has not yet authenticated the other end (or if the peer
fails to authenticate the other end for some reason), the information
needs to be treated with caution. More precisely, assuming that the
MAC verifies correctly, the sender of the error indication is known
to be the responder of the IKE_SA_INIT exchange, but the sender's
identity cannot be assured." [Issue #9]
Added "Section 2.21 also covers error messages in great detail" near
the beginning of 1.4.
Added "Section 2.21 has been greatly expanded to cover the different
cases where error responses are needed and the appropriate responses
to them" to the end of 1.7.
In 1.5, changed "There are two cases when such a one-way
notification" to "There are two cases when a one-way notification".
Also changed "notification" to "message" throughout this paragraph.
In 2.8, changed "Note that, when rekeying, the new Child SA MAY have
different traffic selectors and algorithms than the old one." to
"Note that, when rekeying, the new Child SA SHOULD NOT have different
traffic selectors and algorithms than the old one.". [Issue #12]
Section 2.21 was replaced and significantly expanded to cover many
different error situations. [Issue #26]
Added 2.23.1, which covers how to handle NAT traversal when transport
mode is requested. [Issue #28]
In 3.3.2, after the table for tranform type 4, added "Although ESP
and AH do not directly include a Diffie-Hellman 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 exchange,
providing perfect forward secrecy for the generated Child SA keys."
[Issue #57]
In 3.5, added "The Peer Authorization Database (PAD) as described in
RFC 4301 [IPSECARCH] describes the use of the ID payload in IKEv2 and
provides a formal model for the binding of identity to policy in
addition to providing services that deal more specifically with the
details of policy enforcement. The PAD is intended to provide a link
between the SPD and the IKE security association management. See
Section 4.4.3 of RFC 4301 for more details." [Issue #58]
Added to the definition of "X.509 Certificate" in 3.6: "Note that
with this encoding, if a chain of certificates 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 payload." [Issue
#107].
In 3.14, added "When an authenticated encryption algorithm is used to
protect the IKE SA, the construction of the encrypted payload is
different that what is described here. See [RFC5282] for more
information on authenticated encryption algorithms and their use in
ESP."
Added the last two paragraphs of 3.15 (on CFG_REQUEST and CFG_REPLY,
and CFG_SET and CFG_ACK). Removed all of 2.19.1 which contained the
same material and a lot of material that was duplicated from other
parts of the document. [Issue #108]
Added the following to 3.15.3: "Note that there is an additional
document that discusses IPv6 configuration in IKEv2, [IPV6CONFIG].
At the present time, it is an experimental document, but there is a
hope that with more implementation experience, it will gain the same
standards treatment as this document." [Issue #47 and Issue #60]
Reworded the acknowledgements to be more inclusive.
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. 48 change blocks. 
205 lines changed or deleted 557 lines changed or added

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