draft-ietf-ipsecme-ikev2bis-01.txt   draft-ietf-ipsecme-ikev2bis-02.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: May 3, 2009 Check Point Expires: August 30, 2009 Check Point
P. Eronen P. Eronen
Nokia Nokia
October 30, 2008 February 26, 2009
Internet Key Exchange Protocol: IKEv2 Internet Key Exchange Protocol: IKEv2
draft-ietf-ipsecme-ikev2bis-01 draft-ietf-ipsecme-ikev2bis-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. 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 May 3, 2009. This Internet-Draft will expire on August 30, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
Copyright (C) The IETF Trust (2008). This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This document describes version 2 of the Internet Key Exchange (IKE) This document describes version 2 of the Internet Key Exchange (IKE)
protocol. IKE is a component of IPsec used for performing mutual protocol. IKE is a component of IPsec used for performing mutual
authentication and establishing and maintaining security associations authentication and establishing and maintaining security associations
(SAs). It replaces and updates RFC 4306, and includes all of the (SAs). It replaces and updates RFC 4306, and includes all of the
clarifications from RFC 4718. clarifications from RFC 4718.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 6 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 7
1.1.1. Security Gateway to Security Gateway Tunnel Mode . . 6 1.1.1. Security Gateway to Security Gateway Tunnel Mode . . 7
1.1.2. Endpoint-to-Endpoint Transport Mode . . . . . . . . . 7 1.1.2. Endpoint-to-Endpoint Transport Mode . . . . . . . . . 8
1.1.3. Endpoint to Security Gateway Tunnel Mode . . . . . . 8 1.1.3. Endpoint to Security Gateway Tunnel Mode . . . . . . 9
1.1.4. Other Scenarios . . . . . . . . . . . . . . . . . . . 8 1.1.4. Other Scenarios . . . . . . . . . . . . . . . . . . . 9
1.2. The Initial Exchanges . . . . . . . . . . . . . . . . . . 9 1.2. The Initial Exchanges . . . . . . . . . . . . . . . . . . 10
1.3. The CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . . 13 Exchange . . . . . . . . . . . . . . . . . . . . . . 14
1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange . 14 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange . 16
1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA
Exchange . . . . . . . . . . . . . . . . . . . . . . 15 Exchange . . . . . . . . . . . . . . . . . . . . . . 16
1.4. The INFORMATIONAL Exchange . . . . . . . . . . . . . . . 16 1.4. The INFORMATIONAL Exchange . . . . . . . . . . . . . . . 17
1.4.1. Deleting an SA with INFORMATIONAL Exchanges . . . . . 16 1.4.1. Deleting an SA with INFORMATIONAL Exchanges . . . . . 18
1.5. Informational Messages outside of an IKE SA . . . . . . . 17 1.5. Informational Messages outside of an IKE SA . . . . . . . 18
1.6. Requirements Terminology . . . . . . . . . . . . . . . . 18 1.6. Requirements Terminology . . . . . . . . . . . . . . . . 19
1.7. Differences Between RFC 4306 and This Document . . . . . 18 1.7. Differences Between RFC 4306 and This Document . . . . . 20
2. IKE Protocol Details and Variations . . . . . . . . . . . . . 20 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 . . . . . . . . . 22 2.2. Use of Sequence Numbers for Message ID . . . . . . . . . 23
2.3. Window Size for Overlapping Requests . . . . . . . . . . 22 2.3. Window Size for Overlapping Requests . . . . . . . . . . 24
2.4. State Synchronization and Connection Timeouts . . . . . . 24 2.4. State Synchronization and Connection Timeouts . . . . . . 25
2.5. Version Numbers and Forward Compatibility . . . . . . . . 26 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 . . . . 30 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . 32
2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 31 2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 32
2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 32 2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 34
2.8.1. Simultaneous Child SA rekeying . . . . . . . . . . . 34 2.8.1. Simultaneous Child SA rekeying . . . . . . . . . . . 36
2.8.2. Rekeying the IKE SA Versus Reauthentication . . . . . 36 2.8.2. Simultaneous IKE SA Rekeying . . . . . . . . . . . . 38
2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 37 2.8.3. Rekeying the IKE SA Versus Reauthentication . . . . . 39
2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 40 2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 39
2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 42
2.11. Address and Port Agility . . . . . . . . . . . . . . . . 41 2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 41 2.11. Address and Port Agility . . . . . . . . . . . . . . . . 43
2.13. Generating Keying Material . . . . . . . . . . . . . . . 42 2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 43
2.14. Generating Keying Material for the IKE SA . . . . . . . . 43 2.13. Generating Keying Material . . . . . . . . . . . . . . . 44
2.15. Authentication of the IKE SA . . . . . . . . . . . . . . 44 2.14. Generating Keying Material for the IKE SA . . . . . . . . 45
2.16. Extensible Authentication Protocol Methods . . . . . . . 46 2.15. Authentication of the IKE SA . . . . . . . . . . . . . . 46
2.17. Generating Keying Material for Child SAs . . . . . . . . 48 2.16. Extensible Authentication Protocol Methods . . . . . . . 48
2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange . . . . 49 2.17. Generating Keying Material for Child SAs . . . . . . . . 50
2.19. Requesting an Internal Address on a Remote Network . . . 50 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange . . . . 51
2.19.1. Configuration Payloads . . . . . . . . . . . . . . . 51 2.19. Requesting an Internal Address on a Remote Network . . . 52
2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 53 2.19.1. Configuration Payloads . . . . . . . . . . . . . . . 53
2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 53 2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 55
2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 54 2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 55
2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 55 2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 59 2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 57
3. Header and Payload Formats . . . . . . . . . . . . . . . . . 59 2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 61
3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 59 3. Header and Payload Formats . . . . . . . . . . . . . . . . . 61
3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 62 3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 61
3.3. Security Association Payload . . . . . . . . . . . . . . 64 3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 64
3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 66 3.3. Security Association Payload . . . . . . . . . . . . . . 66
3.3.2. Transform Substructure . . . . . . . . . . . . . . . 68 3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 68
3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 71 3.3.2. Transform Substructure . . . . . . . . . . . . . . . 70
3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 71 3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 73
3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 72 3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 73
3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 74 3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 74
3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 75 3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 76
3.5. Identification Payloads . . . . . . . . . . . . . . . . . 75 3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 77
3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 78 3.5. Identification Payloads . . . . . . . . . . . . . . . . . 78
3.7. Certificate Request Payload . . . . . . . . . . . . . . . 80 3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 80
3.8. Authentication Payload . . . . . . . . . . . . . . . . . 82 3.7. Certificate Request Payload . . . . . . . . . . . . . . . 82
3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 83 3.8. Authentication Payload . . . . . . . . . . . . . . . . . 84
3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 84 3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 85
3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 85 3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 86
3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 88 3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 87
3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 90 3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 90
3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 91 3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 92
3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 92 3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 93
3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 94 3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 94
3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 96 3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 96
3.15.1. Configuration Attributes . . . . . . . . . . . . . . 97 3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 98
3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 100 3.15.1. Configuration Attributes . . . . . . . . . . . . . . 99
3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 102 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 102
3.15.4. Address Assignment Failures . . . . . . . . . . . . . 103 3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 104
3.16. Extensible Authentication Protocol (EAP) Payload . . . . 103 3.15.4. Address Assignment Failures . . . . . . . . . . . . . 105
4. Conformance Requirements . . . . . . . . . . . . . . . . . . 105 3.16. Extensible Authentication Protocol (EAP) Payload . . . . 105
5. Security Considerations . . . . . . . . . . . . . . . . . . . 107 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 107
5.1. Traffic selector authorization . . . . . . . . . . . . . 109 5. Security Considerations . . . . . . . . . . . . . . . . . . . 109
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 111 5.1. Traffic selector authorization . . . . . . . . . . . . . 112
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 111 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 113
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 111 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 113
8.1. Normative References . . . . . . . . . . . . . . . . . . 111 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 114
8.2. Informative References . . . . . . . . . . . . . . . . . 113 8.1. Normative References . . . . . . . . . . . . . . . . . . 114
Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 117 8.2. Informative References . . . . . . . . . . . . . . . . . 115
Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 118 Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 119
B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 118 Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 120
B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 118 B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 120
Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 119 B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 121
C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 119 Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 121
C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 120 C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 122
C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 121 C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 123
C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 124
C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying
Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 122 Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 125
C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA . . . . 122 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA . . . . 125
C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 122 C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 125
Appendix D. Changes Between Internet Draft Versions . . . . . . 122 Appendix D. Significant Changes from RFC 4306 . . . . . . . . . 125
D.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 123 Appendix E. Changes Between Internet Draft Versions . . . . . . 126
D.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 123 E.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 126
D.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 125 E.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 126
D.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 126 E.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 128
D.5. Changes from draft -02 to draft -03 . . . . . . . . . . . 127 E.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 129
D.6. Changes from draft -03 to E.5. Changes from draft -02 to draft -03 . . . . . . . . . . . 130
draft-ietf-ipsecme-ikev2bis-00 . . . . . . . . . . . . . 128 E.6. Changes from draft -03 to
D.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to draft-ietf-ipsecme-ikev2bis-00 . . . . . . . . . . . . . 131
draft-ietf-ipsecme-ikev2bis-01 . . . . . . . . . . . . . 129 E.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 133 draft-ietf-ipsecme-ikev2bis-01 . . . . . . . . . . . . . 132
Intellectual Property and Copyright Statements . . . . . . . . . 134 E.8. Changes from draft-ietf-ipsecme-ikev2bis-01 to
draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 136
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 138
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 14, line 42 skipping to change at page 15, line 42
{{ 3.10.1-16395 }} The NON_FIRST_FRAGMENTS_ALSO notification is used {{ 3.10.1-16395 }} The NON_FIRST_FRAGMENTS_ALSO notification is used
for fragmentation control. See [IPSECARCH] for a fuller explanation. for fragmentation control. See [IPSECARCH] for a fuller explanation.
{{ Clarif-4.6 }} Both parties need to agree to sending non-first {{ Clarif-4.6 }} Both parties need to agree to sending non-first
fragments before either party does so. It is enabled only if fragments before either party does so. It is enabled only if
NON_FIRST_FRAGMENTS_ALSO notification is included in both the request NON_FIRST_FRAGMENTS_ALSO notification is included in both the request
proposing an SA and the response accepting it. If the responder does proposing an SA and the response accepting it. If the responder does
not want to send or receive non-first fragments, it only omits not want to send or receive non-first fragments, it only omits
NON_FIRST_FRAGMENTS_ALSO notification from its response, but does not NON_FIRST_FRAGMENTS_ALSO notification from its response, but does not
reject the whole Child SA creation. reject the whole Child SA creation.
Failure of an attempt to create a CHILD SA SHOULD NOT tear down the
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
NOT be encrypted because the other party will not be able to
authenticate that message. [[ Note: this text may be changed in the
future. ]]
1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange
The CREATE_CHILD_SA request for rekeying an IKE SA is: The CREATE_CHILD_SA request for rekeying an IKE SA is:
Initiator Responder Initiator Responder
------------------------------------------------------------------- -------------------------------------------------------------------
HDR, SK {SA, Ni, [KEi]} --> HDR, SK {SA, Ni, [KEi]} -->
The initiator sends SA offer(s) in the SA payload, a nonce in the Ni The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
payload, and a Diffie-Hellman value in the KEi payload. The KEi payload, and a Diffie-Hellman value in the KEi payload. The KEi
payload SHOULD be included. New initiator and responder SPIs are payload 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.
The CREATE_CHILD_SA response for rekeying an IKE SA is: The CREATE_CHILD_SA response for rekeying an IKE SA is:
<-- HDR, SK {SA, Nr,[KEr]} <-- HDR, SK {SA, Nr,[KEr]}
The responder replies (using the same Message ID to respond) with the The responder replies (using the same Message ID to respond) with the
accepted offer in an SA payload, and a Diffie-Hellman value in the accepted offer in an SA payload, and a Diffie-Hellman value in the
KEr payload if the selected cryptographic suite includes that group. KEr payload if the selected cryptographic suite includes that group.
The new IKE SA has its message counters set to 0, regardless of what The new IKE SA has its message counters set to 0, regardless of what
they were in the earlier IKE SA. The window size starts at 1 for any they were in the earlier IKE SA. The first IKE requests from both
new 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
delete the IKE SA) will have consecutive numbering. The new IKE SA
also has its window size reset to 1, and the initiator in this rekey
exchange is the new "original initiator" of the new IKE SA.
1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA Exchange 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA Exchange
The CREATE_CHILD_SA request for rekeying a Child SA is: The CREATE_CHILD_SA request for rekeying a Child SA is:
Initiator Responder Initiator Responder
------------------------------------------------------------------- -------------------------------------------------------------------
HDR, SK {N, SA, Ni, [KEi], HDR, SK {N, SA, Ni, [KEi],
TSi, TSr} --> TSi, TSr} -->
skipping to change at page 18, line 19 skipping to change at page 19, line 33
{{ Clarif-7.7 }} There are two cases when such a one-way notification {{ Clarif-7.7 }} There are two cases when such a one-way notification
is sent: INVALID_IKE_SPI and INVALID_SPI. These notifications are is sent: INVALID_IKE_SPI and INVALID_SPI. These notifications are
sent outside of an IKE SA. Note that such notifications are sent outside of an IKE SA. Note that such notifications are
explicitly not Informational exchanges; these are one-way messages explicitly not Informational exchanges; these are one-way messages
that must not be responded to. that must not be responded to.
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,
the responder SHOULD copy the Exchange Type from the request.
In case of INVALID_SPI, however, there are no IKE SPI values that In case of INVALID_SPI, however, there are no IKE SPI values that
would be meaningful to the recipient of such a notification. Using would be meaningful to the recipient of such a notification. Using
zero values or random values are both acceptable. The Initiator flag zero values or random values are both acceptable. The Initiator flag
is set, the Response bit is set to 0, and the version flags are set is set, the Response bit is set to 0, and the version flags are set
in the normal fashion. in the normal fashion.
1.6. Requirements Terminology 1.6. Requirements Terminology
Definitions of the primitive terms in this document (such as Security Definitions of the primitive terms in this document (such as Security
skipping to change at page 21, line 25 skipping to change at page 22, line 38
For every pair of IKE messages, the initiator is responsible for For every pair of IKE messages, the initiator is responsible for
retransmission in the event of a timeout. The responder MUST never retransmission in the event of a timeout. The responder MUST never
retransmit a response unless it receives a retransmission of the retransmit a response unless it receives a retransmission of the
request. In that event, the responder MUST ignore the retransmitted request. In that event, the responder MUST ignore the retransmitted
request except insofar as it triggers a retransmission of the request except insofar as it triggers a retransmission of the
response. The initiator MUST remember each request until it receives response. The initiator MUST remember each request until it receives
the corresponding response. The responder MUST remember each the corresponding response. The responder MUST remember each
response until it receives a request whose sequence number is larger response until it receives a request whose sequence number is larger
than or equal to the sequence number in the response plus its window than or equal to the sequence number in the response plus its window
size (see Section 2.3). size (see Section 2.3). In order to allow saving memory, responders
are allowed to forget response after a timeout of several minutes.
If the responder receives a retransmitted request for which it has
already forgotten the response, it MUST ignore the request (and not,
for example, attempt constructing a new response).
IKE is a reliable protocol, in the sense that the initiator MUST IKE is a reliable protocol, in the sense that the initiator MUST
retransmit a request until either it receives a corresponding reply retransmit a request until either it receives a corresponding reply
OR it deems the IKE security association to have failed and it OR it deems the IKE security association to have failed and it
discards all state associated with the IKE SA and any Child SAs discards all state associated with the IKE SA and any Child SAs
negotiated using that IKE SA. A retransmission from the initiator negotiated using that IKE SA. A retransmission from the initiator
MUST be bitwise identical to the original request. That is, MUST be bitwise identical to the original request. That is,
everything starting from the IKE Header (the IKE SA Initiator's SPI everything starting from the IKE Header (the IKE SA Initiator's SPI
onwards) must be bitwise identical; items before it (such as the IP onwards) must be bitwise identical; items before it (such as the IP
and UDP headers, and the zero non-ESP marker) do not have to be and UDP headers, and the zero non-ESP marker) do not have to be
identical. identical.
{{ Clarif-2.3 }} Retransmissions of the IKE_SA_INIT request require {{ Clarif-2.3 }} Retransmissions of the IKE_SA_INIT request require
some special handling. When a responder receives an IKE_SA_INIT some special handling. When a responder receives an IKE_SA_INIT
request, it has to determine whether the packet is retransmission request, it has to determine whether the packet is a retransmission
belonging to an existing "half-open" IKE SA (in which case the belonging to an existing "half-open" IKE SA (in which case the
responder retransmits the same response), or a new request (in which responder retransmits the same response), or a new request (in which
case the responder creates a new IKE SA and sends a fresh response), case the responder creates a new IKE SA and sends a fresh response),
or it belongs to an existing IKE SA where the IKE_AUTH request has or it belongs to an existing IKE SA where the IKE_AUTH request has
been already received (in which case the responder ignores it). been already received (in which case the responder ignores it).
It is not sufficient to use the initiator's SPI and/or IP address to It is not sufficient to use the initiator's SPI and/or IP address to
differentiate between these three cases because two different peers differentiate between these three cases because two different peers
behind a single NAT could choose the same initiator SPI. Instead, a behind a single NAT could choose the same initiator SPI. Instead, a
robust responder will do the IKE SA lookup using the whole packet, robust responder will do the IKE SA lookup using the whole packet,
skipping to change at page 29, line 48 skipping to change at page 31, line 17
where <secret> is a randomly generated secret known only to the where <secret> is a randomly generated secret known only to the
responder and periodically changed and | indicates concatenation. responder and periodically changed and | indicates concatenation.
<VersionIDofSecret> should be changed whenever <secret> is <VersionIDofSecret> should be changed whenever <secret> is
regenerated. The cookie can be recomputed when the IKE_SA_INIT regenerated. The cookie can be recomputed when the IKE_SA_INIT
arrives the second time and compared to the cookie in the received arrives the second time and compared to the cookie in the received
message. If it matches, the responder knows that the cookie was message. If it matches, the responder knows that the cookie was
generated since the last change to <secret> and that IPi must be the generated since the last change to <secret> and that IPi must be the
same as the source address it saw the first time. Incorporating SPIi same as the source address it saw the first time. Incorporating SPIi
into the calculation ensures that if multiple IKE SAs are being set into the calculation ensures that if multiple IKE SAs are being set
up in parallel they will all get different cookies (assuming the up in parallel they will all get different cookies (assuming the
initiator chooses unique SPIi's). Incorporating Ni into the hash initiator chooses unique SPIi's). Incorporating Ni 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. forge a message 3. Also, incorporating Ni in the hash prevents an
attacker from fetching one one cookie from the other end, and then
initiating many IKE_SA_INIT exchanges all with different initiator
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
connect.
If a new value for <secret> is chosen while there are connections in If a new value for <secret> is chosen while there are connections in
the process of being initialized, an IKE_SA_INIT might be returned the process of being initialized, an IKE_SA_INIT might be returned
with other than the current <VersionIDofSecret>. The responder in with other than the current <VersionIDofSecret>. The responder in
that case MAY reject the message by sending another response with a that case MAY reject the message by sending another response with a
new cookie or it MAY keep the old value of <secret> around for a new cookie or it MAY keep the old value of <secret> around for a
short time and accept cookies computed from either one. {{ Demoted short time and accept cookies computed from either one. {{ Demoted
the SHOULD NOT }} The responder should not accept cookies the SHOULD NOT }} The responder should not accept cookies
indefinitely after <secret> is changed, since that would defeat part indefinitely after <secret> is changed, since that would defeat part
of the denial of service protection. {{ Demoted the SHOULD }} The of the denial of service protection. {{ Demoted the SHOULD }} The
skipping to change at page 36, line 39 skipping to change at page 38, line 14
To B, it looks like A is trying to rekey an SA that no longer exists; To B, it looks like A is trying to rekey an SA that no longer exists;
thus, B responds to the request with something non-fatal such as thus, B responds to the request with something non-fatal such as
NO_PROPOSAL_CHOSEN. NO_PROPOSAL_CHOSEN.
<-- send resp1: N(NO_PROPOSAL_CHOSEN) <-- send resp1: N(NO_PROPOSAL_CHOSEN)
recv resp1 <-- recv resp1 <--
When A receives this error, it already knows there was simultaneous When A receives this error, it already knows there was simultaneous
rekeying, so it can ignore the error message. rekeying, so it can ignore the error message.
2.8.2. Rekeying the IKE SA Versus Reauthentication 2.8.2. Simultaneous IKE SA Rekeying
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
applies to this case as well; however, it is important to ensure that
the CHILD_SAs are inherited by the right IKE_SA.
The case where both endpoints notice the simultaneous rekeying works
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
nonce inherits the CHILD_SAs.
However, there is a twist to the other case where one rekeying
finishes first:
Host A Host B
-------------------------------------------------------------------
send req1:
SA(..,SPIa1,..),Ni1,.. -->
<-- send req2: SA(..,SPIb1,..),Ni2,..
--> recv req1
<-- send resp1: SA(..,SPIb2,..),Nr2,..
recv resp1 <--
send req3: D() -->
--> recv req3
At this point, host B sees a request to close the IKE_SA. There's
not much more to do than to reply as usual. However, at this point
host B should stop retransmitting req2, since once host A receives
resp3, it will delete all the state associated with the old IKE_SA
and will not be able to reply to it.
<-- send resp3: ()
2.8.3. Rekeying the IKE SA Versus Reauthentication
{{ Added this section from Clarif-5.2 }} {{ Added this section from Clarif-5.2 }}
Rekeying the IKE SA and reauthentication are different concepts in Rekeying the IKE SA and reauthentication are different concepts in
IKEv2. Rekeying the IKE SA establishes new keys for the IKE SA and IKEv2. Rekeying the IKE SA establishes new keys for the IKE SA and
resets the Message ID counters, but it does not authenticate the resets the Message ID counters, but it does not authenticate the
parties again (no AUTH or EAP payloads are involved). parties again (no AUTH or EAP payloads are involved).
Although rekeying the IKE SA may be important in some environments, Although rekeying the IKE SA may be important in some environments,
reauthentication (the verification that the parties still have access reauthentication (the verification that the parties still have access
skipping to change at page 42, line 14 skipping to change at page 44, line 28
associated with the exponential only when some corresponding associated with the exponential only when some corresponding
connection was closed. This would allow the exponential to be reused connection was closed. This would allow the exponential to be reused
without losing perfect forward secrecy at the cost of maintaining without losing perfect forward secrecy at the cost of maintaining
more state. more state.
Decisions as to whether and when to reuse Diffie-Hellman exponentials Decisions as to whether and when to reuse Diffie-Hellman exponentials
is a private decision in the sense that it will not affect is a private decision in the sense that it will not affect
interoperability. An implementation that reuses exponentials MAY interoperability. An implementation that reuses exponentials MAY
choose to remember the exponential used by the other endpoint on past choose to remember the exponential used by the other endpoint on past
exchanges and if one is reused to avoid the second half of the exchanges and if one is reused to avoid the second half of the
calculation. calculation. See [REUSE] for a security analysis of this practice
and for additional security considerations when reusing ephemeral DH
keys.
2.13. Generating Keying Material 2.13. Generating Keying Material
In the context of the IKE SA, four cryptographic algorithms are In the context of the IKE SA, four cryptographic algorithms are
negotiated: an encryption algorithm, an integrity protection negotiated: an encryption algorithm, an integrity protection
algorithm, a Diffie-Hellman group, and a pseudo-random function algorithm, a Diffie-Hellman group, and a pseudo-random function
(prf). The pseudo-random function is used for the construction of (prf). The pseudo-random function is used for the construction of
keying material for all of the cryptographic algorithms used in both keying material for all of the cryptographic algorithms used in both
the IKE SA and the Child SAs. the IKE SA and the Child SAs.
skipping to change at page 49, line 24 skipping to change at page 51, line 27
2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange
The CREATE_CHILD_SA exchange can be used to rekey an existing IKE SA The CREATE_CHILD_SA exchange can be used to rekey an existing IKE SA
(see Section 2.8). {{ Clarif-5.3 }} New initiator and responder SPIs (see Section 2.8). {{ Clarif-5.3 }} New initiator and responder SPIs
are supplied in the SPI fields in the Proposal structures inside the are supplied in the SPI fields in the Proposal structures inside the
Security Association (SA) payloads (not the SPI fields in the IKE Security Association (SA) payloads (not the SPI fields in the IKE
header). The TS payloads are omitted when rekeying an IKE SA. header). The TS payloads are omitted when rekeying an IKE SA.
SKEYSEED for the new IKE SA is computed using SK_d from the existing SKEYSEED for the new IKE SA is computed using SK_d from the existing
IKE SA as follows: IKE SA as follows:
SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr) SKEYSEED = prf(SK_d (old), g^ir (new) | Ni | Nr)
where g^ir (new) is the shared secret from the ephemeral Diffie- where g^ir (new) is the shared secret from the ephemeral Diffie-
Hellman exchange of this CREATE_CHILD_SA exchange (represented as an Hellman exchange of this CREATE_CHILD_SA exchange (represented as an
octet string in big endian order padded with zeros if necessary to octet string in big endian order padded with zeros if necessary to
make it the length of the modulus) and Ni and Nr are the two nonces make it the length of the modulus) and Ni and Nr are the two nonces
stripped of any headers. stripped of any headers.
{{ Clarif-5.5 }} The old and new IKE SA may have selected a different {{ Clarif-5.5 }} The old and new IKE SA may have selected a different
PRF. Because the rekeying exchange belongs to the old IKE SA, it is PRF. Because the rekeying exchange belongs to the old IKE SA, it is
the old IKE SA's PRF that is used. the old IKE SA's PRF that is used.
{{ Clarif-5.12}} The main rekeying the IKE SA is to ensure that the {{ Clarif-5.12}} The main reason for rekeying the IKE SA is to ensure
compromise of old keying material does not provide information about that the compromise of old keying material does not provide
the current keys, or vice versa. Therefore, implementations SHOULD information about the current keys, or vice versa. Therefore,
perform a new Diffie-Hellman exchange when rekeying the IKE SA. In implementations MUST perform a new Diffie-Hellman exchange when
other words, an initiator SHOULD NOT propose the value "NONE" for the rekeying the IKE SA. In other words, an initiator MUST NOT propose
D-H transform, and a responder SHOULD NOT accept such a proposal. the value "NONE" for the D-H transform, and a responder MUST NOT
This means that a succesful exchange rekeying the IKE SA always accept such a proposal. This means that a succesful exchange
includes the KEi/KEr payloads. rekeying the IKE SA always includes the KEi/KEr payloads.
The new IKE SA MUST reset its message counters to 0. The new IKE SA MUST reset its message counters to 0.
SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as
specified in Section 2.14. specified in Section 2.14.
2.19. Requesting an Internal Address on a Remote Network 2.19. Requesting an Internal Address on a Remote Network
Most commonly occurring in the endpoint-to-security-gateway scenario, Most commonly occurring in the endpoint-to-security-gateway scenario,
an endpoint may need an IP address in the network protected by the an endpoint may need an IP address in the network protected by the
security gateway and may need to have that address dynamically security gateway and may need to have that address dynamically
assigned. A request for such a temporary address can be included in assigned. A request for such a temporary address can be included in
any request to create a Child SA (including the implicit request in any request to create a Child SA (including the implicit request in
message 3) by including a CP payload. message 3) by including a CP payload. Note, however, it is usual to
only assign one IP address during the IKE_AUTH exchange. That
address persists at least until the deletion of the IKE SA.
This function provides address allocation to an IPsec Remote Access This function provides address allocation to an IPsec Remote Access
Client (IRAC) trying to tunnel into a network protected by an IPsec Client (IRAC) trying to tunnel into a network protected by an IPsec
Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an
IKE SA and a Child SA, the IRAC MUST request the IRAS-controlled IKE SA and a Child SA, the IRAC MUST request the IRAS-controlled
address (and optionally other information concerning the protected address (and optionally other information concerning the protected
network) in the IKE_AUTH exchange. The IRAS may procure an address network) in the IKE_AUTH exchange. The IRAS may procure an address
for the IRAC from any number of sources such as a DHCP/BOOTP server for the IRAC from any number of sources such as a DHCP/BOOTP server
or its own address pool. or its own address pool.
skipping to change at page 57, line 6 skipping to change at page 59, line 10
ports may be modified as the packets pass through NATs. Similarly, ports may be modified as the packets pass through NATs. Similarly,
IP addresses of the IKE endpoints are generally not included in the IP addresses of the IKE endpoints are generally not included in the
IKE payloads because the payloads are cryptographically protected and IKE payloads because the payloads are cryptographically protected and
could not be transparently modified by NATs. could not be transparently modified by NATs.
Port 4500 is reserved for UDP-encapsulated ESP and IKE. {{ Clarif-7.6 Port 4500 is reserved for UDP-encapsulated ESP and IKE. {{ Clarif-7.6
}} An IPsec endpoint that discovers a NAT between it and its }} An IPsec endpoint that discovers a NAT between it and its
correspondent MUST send all subsequent traffic from port 4500, which correspondent MUST send all subsequent traffic from port 4500, which
NATs should not treat specially (as they might with port 500). NATs should not treat specially (as they might with port 500).
An initiator can float to port 4500, regardless whether or not there
is NAT, even at the beginning of IKE. When either side is using port
4500, sending with UDP encapsulation is not required, but
understanding received packets with UDP encapsulation is required.
UDP encapsulation MUST NOT be done on port 500. If NAT-T is
supported (that is, if NAT_DETECTION_*_IP payloads were exchanged
during IKE_SA_INIT), all devices MUST be able to receive and process
both UDP encapsulated and non-UDP encapsulated packets at any time.
Either side can decide whether or not to use UDP encapsulation
irrespective of the choice made by the other side. However, if a NAT
is detected, both devices MUST send UDP encapsulated packets.
The specific requirements for supporting NAT traversal [NATREQ] are The specific requirements for supporting NAT traversal [NATREQ] are
listed below. Support for NAT traversal is optional. In this listed below. Support for NAT traversal is optional. In this
section only, requirements listed as MUST apply only to section only, requirements listed as MUST apply only to
implementations supporting NAT traversal. implementations supporting NAT traversal.
o IKE MUST listen on port 4500 as well as port 500. IKE MUST o IKE MUST listen on port 4500 as well as port 500. IKE MUST
respond to the IP address and port from which packets arrived. respond to the IP address and port from which packets arrived.
o Both IKE initiator and responder MUST include in their IKE_SA_INIT o Both IKE initiator and responder MUST include in their IKE_SA_INIT
packets Notify payloads of type NAT_DETECTION_SOURCE_IP and packets Notify payloads of type NAT_DETECTION_SOURCE_IP and
skipping to change at page 75, line 41 skipping to change at page 77, line 41
Figure 10: Key Exchange Payload Format Figure 10: Key Exchange Payload Format
A key exchange payload is constructed by copying one's Diffie-Hellman A key exchange payload is constructed by copying one's Diffie-Hellman
public value into the "Key Exchange Data" portion of the payload. public value into the "Key Exchange Data" portion of the payload.
The length of the Diffie-Hellman public value MUST be equal to the The length of the Diffie-Hellman public value MUST be equal to the
length of the prime modulus over which the exponentiation was length of the prime modulus over which the exponentiation was
performed, prepending zero bits to the value if necessary. performed, prepending zero bits to the value if necessary.
The DH Group # identifies the Diffie-Hellman group in which the Key The DH Group # identifies the Diffie-Hellman group in which the Key
Exchange Data was computed (see Section 3.3.2). If the selected Exchange Data was computed (see Section 3.3.2. This Group # MUST
proposal uses a different Diffie-Hellman group (other than NONE), the match a DH Group specified in a proposal in the SA payload that is
message MUST be rejected with a Notify payload of type sent in the same message, and SHOULD match the DH group in the first
INVALID_KE_PAYLOAD. group in the first proposal, if such exists. If none of the
proposals in that SA payload specifies a DH Group, the KE payload
MUST NOT be present. If the selected proposal uses a different
Diffie-Hellman group (other than NONE), the message MUST be rejected
with a Notify payload of type INVALID_KE_PAYLOAD.
The payload type for the Key Exchange payload is thirty four (34). The payload type for the Key Exchange payload is thirty four (34).
3.5. Identification Payloads 3.5. Identification Payloads
The Identification Payloads, denoted IDi and IDr in this memo, allow The Identification Payloads, denoted IDi and IDr in this memo, allow
peers to assert an identity to one another. This identity may be peers to assert an identity to one another. This identity may be
used for policy lookup, but does not necessarily have to match used for policy lookup, but does not necessarily have to match
anything in the CERT payload; both fields may be used by an anything in the CERT payload; both fields may be used by an
implementation to perform access control decisions. {{ Clarif-7.1 }} implementation to perform access control decisions. {{ Clarif-7.1 }}
skipping to change at page 87, line 7 skipping to change at page 89, line 7
{{ Demoted the SHOULD }} To aid debugging, more detailed error {{ Demoted the SHOULD }} To aid debugging, more detailed error
information should be written to a console or log. information should be written to a console or log.
INVALID_MESSAGE_ID 9 INVALID_MESSAGE_ID 9
See Section 2.3. See Section 2.3.
INVALID_SPI 11 INVALID_SPI 11
See Section 1.5. See Section 1.5.
NO_PROPOSAL_CHOSEN 14 NO_PROPOSAL_CHOSEN 14
See Section 2.7. None of the proposed crypto suites was acceptable. This can be
sent in any case where the offered proposal (including but not
limited to SA payload values, USE_TRANSPORT_MODE notify,
IPCOMP_SUPPORTED notify) are not acceptable for the responder.
This can also be used as "generic" Child SA error when Child SA
cannot be created for some other reason. See also Section 2.7.
INVALID_KE_PAYLOAD 17 INVALID_KE_PAYLOAD 17
See Section 1.3. See Section 1.3.
AUTHENTICATION_FAILED 24 AUTHENTICATION_FAILED 24
Sent in the response to an IKE_AUTH message when for some reason Sent in the response to an IKE_AUTH message when for some reason
the authentication failed. There is no associated data. the authentication failed. There is no associated data.
SINGLE_PAIR_REQUIRED 34 SINGLE_PAIR_REQUIRED 34
See Section 2.9. See Section 2.9.
skipping to change at page 95, line 43 skipping to change at page 97, line 43
was no natural place to put the type of the first one, that type was no natural place to put the type of the first one, that type
is placed here. is placed here.
o Payload Length - Includes the lengths of the header, IV, Encrypted o Payload Length - Includes the lengths of the header, IV, Encrypted
IKE Payloads, Padding, Pad Length, and Integrity Checksum Data. IKE Payloads, Padding, Pad Length, and Integrity Checksum Data.
o Initialization Vector - For CBC mode ciphers, the length of the o Initialization Vector - For CBC mode ciphers, the length of the
initialization vector (IV) is equal to the block length of the initialization vector (IV) is equal to the block length of the
underlying encryption algorithm. Senders MUST select a new underlying encryption algorithm. Senders MUST select a new
unpredictable IV for every message; recipients MUST accept any unpredictable IV for every message; recipients MUST accept any
value. For other modes than CBC, the IV format and processing is value. The reader is encouraged to consult [MODES] for advice on
specified in the document specifying the encryption algorithm and
mode. The reader is encouraged to consult [MODES] for advice on
IV generation. In particular, using the final ciphertext block of IV generation. In particular, using the final ciphertext block of
the previous message is not considered unpredictable. the previous message is not considered unpredictable. For modes
other than CBC, the IV format and processing is specified in the
document specifying the encryption algorithm and mode.
o IKE Payloads are as specified earlier in this section. This field o IKE Payloads are as specified earlier in this section. This field
is encrypted with the negotiated cipher. is encrypted with the negotiated cipher.
o Padding MAY contain any value chosen by the sender, and MUST have o Padding MAY contain any value chosen by the sender, and MUST have
a length that makes the combination of the Payloads, the Padding, a length that makes the combination of the Payloads, the Padding,
and the Pad Length to be a multiple of the encryption block size. and the Pad Length to be a multiple of the encryption block size.
This field is encrypted with the negotiated cipher. This field is encrypted with the negotiated cipher.
o Pad Length is the length of the Padding field. The sender SHOULD o Pad Length is the length of the Padding field. The sender SHOULD
skipping to change at page 108, line 13 skipping to change at page 110, line 13
groups nor is there anything that will dilute the strength obtained groups nor is there anything that will dilute the strength obtained
from stronger groups (limited by the strength of the other algorithms from stronger groups (limited by the strength of the other algorithms
negotiated including the prf function). In fact, the extensible negotiated including the prf function). In fact, the extensible
framework of IKE encourages the definition of more groups; use of framework of IKE encourages the definition of more groups; use of
elliptical curve groups may greatly increase strength using much elliptical curve groups may greatly increase strength using much
smaller numbers. smaller numbers.
It is assumed that all Diffie-Hellman exponents are erased from It is assumed that all Diffie-Hellman exponents are erased from
memory after use. memory after use.
The IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator
has been authenticated. As a result, an implementation of this
protocol needs to be completely robust when deployed on any insecure
network. Implementation vulnerabilities, particularly denial-of-
service attacks, can be exploited by unauthenticated peers. This
issue is particularly worrisome because of the unlimited number of
messages in EAP-based authentication.
The strength of all keys is limited by the size of the output of the The strength of all keys is limited by the size of the output of the
negotiated prf function. For this reason, a prf function whose negotiated prf function. For this reason, a prf function whose
output is less than 128 bits (e.g., 3DES-CBC) MUST NOT be used with output is less than 128 bits (e.g., 3DES-CBC) MUST NOT be used with
this protocol. this protocol.
The security of this protocol is critically dependent on the The security of this protocol is critically dependent on the
randomness of the randomly chosen parameters. These should be randomness of the randomly chosen parameters. These should be
generated by a strong random or properly seeded pseudo-random source generated by a strong random or properly seeded pseudo-random source
(see [RANDOMNESS]). Implementers should take care to ensure that use (see [RANDOMNESS]). Implementers should take care to ensure that use
of random numbers for both keys and nonces is engineered in a fashion of random numbers for both keys and nonces is engineered in a fashion
skipping to change at page 116, line 21 skipping to change at page 118, line 32
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2138, April 1997. RFC 2138, April 1997.
[RANDOMNESS] [RANDOMNESS]
Eastlake, D., Schiller, J., and S. Crocker, "Randomness Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[REAUTH] Nir, Y., "Repeated Authentication in Internet Key Exchange [REAUTH] Nir, Y., "Repeated Authentication in Internet Key Exchange
(IKEv2) Protocol", RFC 4478, April 2006. (IKEv2) Protocol", RFC 4478, April 2006.
[REUSE] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In
Diffie-Hellman Key Agreement Protocols", December 2008,
<http://www.cacr.math.uwaterloo.ca/~ajmeneze/
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), October 2008.
[RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for [RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for
Obtaining Digital Signatures and Public-Key Obtaining Digital Signatures and Public-Key
Cryptosystems", February 1978. Cryptosystems", February 1978.
[SHA] National Institute of Standards and Technology, U.S. [SHA] National Institute of Standards and Technology, U.S.
skipping to change at page 122, line 48 skipping to change at page 125, line 48
C.6. INFORMATIONAL Exchange C.6. INFORMATIONAL Exchange
request --> [N+], request --> [N+],
[D+], [D+],
[CP(CFG_REQUEST)] [CP(CFG_REQUEST)]
response <-- [N+], response <-- [N+],
[D+], [D+],
[CP(CFG_REPLY)] [CP(CFG_REPLY)]
Appendix D. Changes Between Internet Draft Versions Appendix D. Significant Changes from RFC 4306
This is a placeholder that will be filled in. The WG needs to decide
what level of specificity is most useful here. For example, it might
only be changes that involve SHOULD-level or MUST-level requirements,
or it might also include additional "significant" advice that was
added.
Appendix E. Changes Between Internet Draft Versions
This section will be removed before publication as an RFC, but should This section will be removed before publication as an RFC, but should
be left intact until then so that reviewers can follow what has be left intact until then so that reviewers can follow what has
changed. changed.
D.1. Changes from IKEv2 to draft -00 E.1. Changes from IKEv2 to draft -00
There were a zillion additions from RFC 4718. These are noted with There were a zillion additions from RFC 4718. These are noted with
"{{ Clarif-nn }}". "{{ Clarif-nn }}".
Cleaned up many of the figures. Made the table headings consistent. Cleaned up many of the figures. Made the table headings consistent.
Made some tables easier to read by removing blank spaces. Removed Made some tables easier to read by removing blank spaces. Removed
the "reserved to IANA" and "private use" text wording and moved it the "reserved to IANA" and "private use" text wording and moved it
into the tables. into the tables.
Changed many SHOULD requirements to better match RFC 2119. These are Changed many SHOULD requirements to better match RFC 2119. These are
also marked with comments such as "{{ Demoted the SHOULD }}". also marked with comments such as "{{ Demoted the SHOULD }}".
In Section 2.16, changed the MUST requirement of authenticating the In Section 2.16, changed the MUST requirement of authenticating the
responder from "public key signature based" to "strong" because that responder from "public key signature based" to "strong" because that
is what most current IKEv2 implementations do, and it better matches is what most current IKEv2 implementations do, and it better matches
the actual security requirement. the actual security requirement.
D.2. Changes from draft -00 to draft -01 E.2. Changes from draft -00 to draft -01
The most significant technical change was to make KE optional but The most significant technical change was to make KE optional but
strongly recommended in Section 1.3.2. strongly recommended in Section 1.3.2.
Updated all references to the IKEv2 Clarifications document to RFC Updated all references to the IKEv2 Clarifications document to RFC
4718. 4718.
Moved a lot of the protocol description out of the long tables in Moved a lot of the protocol description out of the long tables in
Section 3.10.1 into the body of the document. These are noted with Section 3.10.1 into the body of the document. These are noted with
"{{ 3.10.1-nnnn }}", where "nnnn" is the notification type number. "{{ 3.10.1-nnnn }}", where "nnnn" is the notification type number.
skipping to change at page 125, line 35 skipping to change at page 128, line 43
address is valid until there are no IKE SAs between the peers." address is valid until there are no IKE SAs between the peers."
In Section 3.15.1, changed "INTERNAL_IP6_NBNS" to unspecified. In Section 3.15.1, changed "INTERNAL_IP6_NBNS" to unspecified.
Made [ADDRIPV6] an informative reference instead of a normative Made [ADDRIPV6] an informative reference instead of a normative
reference and updated it. reference and updated it.
Made [PKCS1] a normative reference instead of an informative Made [PKCS1] a normative reference instead of an informative
reference and changed the pointer to RFC 3447. reference and changed the pointer to RFC 3447.
D.3. Changes from draft -00 to draft -01 E.3. Changes from draft -00 to draft -01
In Section 1.5, added "request" to first sentence to make it "If an In Section 1.5, added "request" to first sentence to make it "If an
encrypted IKE request packet arrives on port 500 or 4500 with an encrypted IKE request packet arrives on port 500 or 4500 with an
unrecognized SPI...". unrecognized SPI...".
In Section 3.3, fifth paragraph, upped the number of transforms for In Section 3.3, fifth paragraph, upped the number of transforms for
AH and ESP by one each to account for ESN, which is now mandatory. AH and ESP by one each to account for ESN, which is now mandatory.
In Section 2.1, added "or equal to" in "The responder MUST remember In Section 2.1, added "or equal to" in "The responder MUST remember
each response until it receives a request whose sequence number is each response until it receives a request whose sequence number is
larger than or equal to the sequence number in the response plus its larger than or equal to the sequence number in the response plus its
window size." window size."
In Section 2.18, removed " Note that this may not work if the new IKE In Section 2.18, removed " Note that this may not work if the new IKE
SA's PRF has a fixed key size because the output of the PRF may not SA's PRF has a fixed key size because the output of the PRF may not
be of the correct size." because it is no longer relevant. be of the correct size." because it is no longer relevant.
D.4. Changes from draft -01 to draft -02 E.4. Changes from draft -01 to draft -02
Many grammatical fixes. Many grammatical fixes.
In Section 1.2, reworded Clarif-4.3 to be clearer. In Section 1.2, reworded Clarif-4.3 to be clearer.
In Section 1.3.3, reworded 3.10.1-16393 and Clarif-5.4 to remove In Section 1.3.3, reworded 3.10.1-16393 and Clarif-5.4 to remove
redundant text. redundant text.
In Section 2.13, replaced text about variable length keys with In Section 2.13, replaced text about variable length keys with
clearer explanation and requirement on non-HMAC PRFs. Also added clearer explanation and requirement on non-HMAC PRFs. Also added
skipping to change at page 127, line 9 skipping to change at page 130, line 17
In Section 3.10, clarified 3.10.1-16394. In Section 3.10, clarified 3.10.1-16394.
Updated Section 6 to indicate that there is nothing new for IANA in Updated Section 6 to indicate that there is nothing new for IANA in
this spec. Also removed the definition of "Expert Review" from this spec. Also removed the definition of "Expert Review" from
Section 1.6 for the same reason. Section 1.6 for the same reason.
In Appendix A, removed "and not commit any state to an exchange until In Appendix A, removed "and not commit any state to an exchange until
the initiator can be cryptographically authenticated" because that the initiator can be cryptographically authenticated" because that
was only true in an earlier version of IKEv2. was only true in an earlier version of IKEv2.
D.5. Changes from draft -02 to draft -03 E.5. Changes from draft -02 to draft -03
In Section 1.3, changed "If the responder rejects the Diffie-Hellman In Section 1.3, changed "If the responder rejects the Diffie-Hellman
group of the KEi payload, the responder MUST reject the request and group of the KEi payload, the responder MUST reject the request and
indicate its preferred Diffie-Hellman group in the INVALID_KE_PAYLOAD indicate its preferred Diffie-Hellman group in the INVALID_KE_PAYLOAD
Notification payload." to "If the responder selects a proposal using Notification payload." to "If the responder selects a proposal using
a different Diffie-Hellman group (other than NONE), the responder a different Diffie-Hellman group (other than NONE), the responder
MUST reject the request and indicate its preferred Diffie-Hellman MUST reject the request and indicate its preferred Diffie-Hellman
group in the INVALID_KE_PAYLOAD Notification payload. group in the INVALID_KE_PAYLOAD Notification payload.
In Section 2.3, added the last two paragraphs covering why you In Section 2.3, added the last two paragraphs covering why you
skipping to change at page 128, line 30 skipping to change at page 131, line 38
modes, and to clarify which encryption and integrity protection we modes, and to clarify which encryption and integrity protection we
are talking about. are talking about.
Changed the "Initialization Vector" bullet in Section 3.14 to specify Changed the "Initialization Vector" bullet in Section 3.14 to specify
better what is needed for the IV. Upgraded the SHOULDs to MUSTs. better what is needed for the IV. Upgraded the SHOULDs to MUSTs.
Also added the reference for [MODES]. Also added the reference for [MODES].
In Section 5, in the second-to-last paragraph, changed "a public-key- In Section 5, in the second-to-last paragraph, changed "a public-key-
based" to "strong" to match the wording in Section 2.16. based" to "strong" to match the wording in Section 2.16.
D.6. Changes from draft -03 to draft-ietf-ipsecme-ikev2bis-00 E.6. Changes from draft -03 to draft-ietf-ipsecme-ikev2bis-00
Changed the document's filename to draft-ietf-ipsecme-ikev2bis-00. Changed the document's filename to draft-ietf-ipsecme-ikev2bis-00.
Added Yoav Nir as a co-author. Added Yoav Nir as a co-author.
In many places in the document, changed "and/or" to "or" when talking In many places in the document, changed "and/or" to "or" when talking
about combinations of ESP and AH SAs. For example, in the intro, it about combinations of ESP and AH SAs. For example, in the intro, it
said "can be used to efficiently establish SAs for Encapsulating said "can be used to efficiently establish SAs for Encapsulating
Security Payload (ESP) and/or Authentication Header (AH)". This is Security Payload (ESP) and/or Authentication Header (AH)". This is
changed to "or" to indicate that you can only establish one type of changed to "or" to indicate that you can only establish one type of
SA at a time. SA at a time.
skipping to change at page 129, line 4 skipping to change at page 132, line 11
In Section 1, clarified that RFC 4306 already replaced IKEv1, and In Section 1, clarified that RFC 4306 already replaced IKEv1, and
that this document replaces RFC 4306. Also fixed Section 2.5 for that this document replaces RFC 4306. Also fixed Section 2.5 for
similar issue. Also updated the Abstract to cover this. similar issue. Also updated the Abstract to cover this.
In Section 2.15, in the responder's signed octets, changed: In Section 2.15, in the responder's signed octets, changed:
RestOfRespIDPayload = IDType | RESERVED | InitIDData RestOfRespIDPayload = IDType | RESERVED | InitIDData
to to
RestOfRespIDPayload = IDType | RESERVED | RespIDData RestOfRespIDPayload = IDType | RESERVED | RespIDData
In 2.16, changed "strong" back to "public key signature based" to In 2.16, changed "strong" back to "public key signature based" to
make it the same as 4306. make it the same as 4306.
In section 3.10, added "and the field must be empty" to make it clear In section 3.10, added "and the field must be empty" to make it clear
that a zero-length SPI is really empty. that a zero-length SPI is really empty.
D.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to E.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to
draft-ietf-ipsecme-ikev2bis-01 draft-ietf-ipsecme-ikev2bis-01
Throughout, changed "IKE_SA" to "IKE SA", and changed "CHILD_SA" to Throughout, changed "IKE_SA" to "IKE SA", and changed "CHILD_SA" to
"Child SA" (except left "CREATE_CHILD_SA" alone). "Child SA" (except left "CREATE_CHILD_SA" alone).
Added the middle sentence in the Abstract to say what IKE actually Added the middle sentence in the Abstract to say what IKE actually
does. does.
Added in section 1 "(unless there is failure setting up the AH or ESP Added in section 1 "(unless there is failure setting up the AH or ESP
Child SA, in which case the IKE SA is still established without IPsec Child SA, in which case the IKE SA is still established without IPsec
skipping to change at page 133, line 11 skipping to change at page 136, line 23
most implementations to do so. most implementations to do so.
Updated a bunch of reference to their newer versions. Updated a bunch of reference to their newer versions.
Added "[V+]" to the end of the exchanges in C.4 and C.5. Added "[V+]" to the end of the exchanges in C.4 and C.5.
Added two more response templates to Appendix C.1. Added another Added two more response templates to Appendix C.1. Added another
response template in Appendix C.2. Added two more responses in response template in Appendix C.2. Added two more responses in
Appendix C.4. Appendix C.4.
E.8. Changes from draft-ietf-ipsecme-ikev2bis-01 to
draft-ietf-ipsecme-ikev2bis-02
In section 1.3.1, added "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 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 authenticate that message." This may be changed again
in the future. [Issue #9]
In section 1.3.2, changed "The KEi payload SHOULD be included" to be
"The KEi payload MUST be included". This also lead to changes in
section 2.18. The square brackets around "g^ir (new)" in the
SKEYSEED calculation are eliminated, and the requirement language in
the paragraph starting "The main rekeying" is changed from SHOULD to
MUST. [Issue #50]
In section 1.3.2, changed "The window size starts at 1 for any new
IKE SA." to "The first IKE requests from both 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 delete the IKE SA) will have
consecutive numbering. The new IKE SA also has its window size reset
to 1, and the initiator in this rekey exchange is the new "original
initiator" of the new IKE SA." [Issue #65]
Added to section 1.5: For a one-way INVALID_IKE_SPI notification for
an unrecognized SPI, the responder SHOULD copy the Exchange Type from
the request. [Issue #46]
In 2.1, at the end of the paragraph about retransmission timers,
added "In order to allow saving memory, responders are allowed to
forget response after a timeout of several minutes. If the responder
receives a retransmitted request for which it has already forgotten
the response, it MUST ignore the request (and not, for example,
attempt constructing a new response)." [Issue #14]
In 2.6, added: "Also, incorporating Ni in the hash prevents an
attacker from fetching one one cookie from the other end, and then
initiating many IKE_SA_INIT exchanges all with different initiator
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
connect." [Issue #19]
Added text for the new 2.8.2, and bumped the section number of the
old 2.8.2 to 2.8.3. [Issue #22]
Added a reference to the end of 2.12 on key reuse.
Added to the end of the first paragraph in 2.19: Note, however, it is
usual to only assign one IP address during the IKE_AUTH exchange.
That address persists at least until the deletion of the IKE SA.
[Issue #79]
Added the following to 2.23: An initiator can float to port 4500,
regardless whether or not there is NAT, even at the beginning of IKE.
When either side is using port 4500, sending with UDP encapsulation
is not required, but understanding received packets with UDP
encapsulation is required. UDP encapsulation MUST NOT be done on
port 500. If NAT-T is supported (that is, if NAT_DETECTION_*_IP
payloads were exchanged during IKE_SA_INIT), all devices MUST be able
to receive and process both UDP encapsulated and non-UDP encapsulated
packets at any time. Either side can decide whether or not to use
UDP encapsulation irrespective of the choice made by the other side.
However, if a NAT is detected, both devices MUST send UDP
encapsulated packets. [Issue #40]
The second-to-last paragraph in section 3.4 is changed to: The DH
Group # identifies the Diffie-Hellman group in which the Key Exchange
Data was computed (see Section 3.3.2. This Group # MUST match a DH
Group specified in a proposal in the SA payload that is sent in the
same message, and SHOULD match the DH group in the first group in the
first proposal, if such exists. If none of the proposals in that SA
payload specifies a DH Group, the KE payload MUST NOT be present. If
the selected proposal uses a different Diffie-Hellman group (other
than NONE), the message MUST be rejected with a Notify payload of
type INVALID_KE_PAYLOAD. [Issue #30]
In 3.10.1, changed the definition of NO_PROPOSAL_CHOSEN, 14, to: None
of the proposed crypto suites was acceptable. This can be sent in
any case where the offered proposal (including but not limited to SA
payload values, USE_TRANSPORT_MODE notify, IPCOMP_SUPPORTED notify)
are not acceptable for the responder. This can also be used as
"generic" Child SA error when Child SA cannot be created for some
other reason. See also Section 2.7. [Issue #81]
In the description of IVs in 3.14, reorganized the text a bit to
emphasize when we are and are not talking about CBC. [Issue #68]
Added the following to section 5 (Security Considerations): "The
IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator has
been authenticated. As a result, an implementation of this protocol
needs to be completely robust when deployed on any insecure network.
Implementation vulnerabilities, particularly denial-of-service
attacks, can be exploited by unauthenticated peers. This issue is
particularly worrisome because of the unlimited number of messages in
EAP-based authentication." [Issue #62]
Added new Appendix D, "Significant Changes from RFC 4306", as a
placeholder for now. [Issue #3]
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
skipping to change at page 134, line 4 skipping to change at line 6438
Email: ynir@checkpoint.com Email: ynir@checkpoint.com
Pasi Eronen Pasi Eronen
Nokia Research Center Nokia Research Center
P.O. Box 407 P.O. Box 407
FIN-00045 Nokia Group FIN-00045 Nokia Group
Finland Finland
Email: pasi.eronen@nokia.com Email: pasi.eronen@nokia.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 42 change blocks. 
151 lines changed or deleted 371 lines changed or added

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