< draft-hoffman-ikev2bis-02.txt   draft-hoffman-ikev2bis-03.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
Expires: May 19, 2008 P. Eronen Intended status: Standards Track P. Eronen
Nokia Expires: August 28, 2008 Nokia
November 16, 2007 February 25, 2008
Internet Key Exchange Protocol: IKEv2 Internet Key Exchange Protocol: IKEv2
draft-hoffman-ikev2bis-02.txt draft-hoffman-ikev2bis-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 19, 2008. This Internet-Draft will expire on August 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document describes version 2 of the Internet Key Exchange (IKE) This document describes version 2 of the Internet Key Exchange (IKE)
protocol. It is a restatement of RFC 4306, and includes all of the protocol. It is a restatement of RFC 4306, and includes all of the
clarifications from RFC 4718. clarifications from RFC 4718.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
skipping to change at page 2, line 26 skipping to change at page 2, line 26
Exchange . . . . . . . . . . . . . . . . . . . . . . 13 Exchange . . . . . . . . . . . . . . . . . . . . . . 13
1.3.2. Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange . 14 1.3.2. Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange . 14
1.3.3. Rekeying CHILD_SAs with the CREATE_CHILD_SA 1.3.3. Rekeying CHILD_SAs with the CREATE_CHILD_SA
Exchange . . . . . . . . . . . . . . . . . . . . . . 14 Exchange . . . . . . . . . . . . . . . . . . . . . . 14
1.4. The INFORMATIONAL Exchange . . . . . . . . . . . . . . . 15 1.4. The INFORMATIONAL Exchange . . . . . . . . . . . . . . . 15
1.5. Informational Messages outside of an IKE_SA . . . . . . . 17 1.5. Informational Messages outside of an IKE_SA . . . . . . . 17
1.6. Requirements Terminology . . . . . . . . . . . . . . . . 17 1.6. Requirements Terminology . . . . . . . . . . . . . . . . 17
1.7. Differences Between RFC 4306 and This Document . . . . . 18 1.7. Differences Between RFC 4306 and This Document . . . . . 18
2. IKE Protocol Details and Variations . . . . . . . . . . . . . 19 2. IKE Protocol Details and Variations . . . . . . . . . . . . . 19
2.1. Use of Retransmission Timers . . . . . . . . . . . . . . 20 2.1. Use of Retransmission Timers . . . . . . . . . . . . . . 20
2.2. Use of Sequence Numbers for Message ID . . . . . . . . . 20 2.2. Use of Sequence Numbers for Message ID . . . . . . . . . 21
2.3. Window Size for Overlapping Requests . . . . . . . . . . 21 2.3. Window Size for Overlapping Requests . . . . . . . . . . 21
2.4. State Synchronization and Connection Timeouts . . . . . . 23 2.4. State Synchronization and Connection Timeouts . . . . . . 23
2.5. Version Numbers and Forward Compatibility . . . . . . . . 25 2.5. Version Numbers and Forward Compatibility . . . . . . . . 25
2.6. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.6. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . 29 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . 29
2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 30 2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 30
2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 31 2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 31
2.8.1. Simultaneous CHILD_SA rekeying . . . . . . . . . . . 33 2.8.1. Simultaneous CHILD_SA rekeying . . . . . . . . . . . 33
2.8.2. Rekeying the IKE_SA Versus Reauthentication . . . . . 35 2.8.2. Rekeying the IKE_SA Versus Reauthentication . . . . . 35
2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 36 2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 36
2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 38 2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 38
2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 39 2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.11. Address and Port Agility . . . . . . . . . . . . . . . . 39 2.11. Address and Port Agility . . . . . . . . . . . . . . . . 39
2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 40 2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 40
skipping to change at page 2, line 52 skipping to change at page 2, line 52
2.14. Generating Keying Material for the IKE_SA . . . . . . . . 42 2.14. Generating Keying Material for the IKE_SA . . . . . . . . 42
2.15. Authentication of the IKE_SA . . . . . . . . . . . . . . 42 2.15. Authentication of the IKE_SA . . . . . . . . . . . . . . 42
2.16. Extensible Authentication Protocol Methods . . . . . . . 44 2.16. Extensible Authentication Protocol Methods . . . . . . . 44
2.17. Generating Keying Material for CHILD_SAs . . . . . . . . 46 2.17. Generating Keying Material for CHILD_SAs . . . . . . . . 46
2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA Exchange . . . . 47 2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA Exchange . . . . 47
2.19. Requesting an Internal Address on a Remote Network . . . 48 2.19. Requesting an Internal Address on a Remote Network . . . 48
2.19.1. Configuration Payloads . . . . . . . . . . . . . . . 49 2.19.1. Configuration Payloads . . . . . . . . . . . . . . . 49
2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 51 2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 51
2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 51 2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 51
2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 52 2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 53 2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 54
2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 57 2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 57
3. Header and Payload Formats . . . . . . . . . . . . . . . . . 57 3. Header and Payload Formats . . . . . . . . . . . . . . . . . 57
3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 57 3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 58
3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 60 3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 61
3.3. Security Association Payload . . . . . . . . . . . . . . 62 3.3. Security Association Payload . . . . . . . . . . . . . . 63
3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 64 3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 65
3.3.2. Transform Substructure . . . . . . . . . . . . . . . 66 3.3.2. Transform Substructure . . . . . . . . . . . . . . . 66
3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 69 3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 69
3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 69 3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 70
3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 70 3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 71
3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 72 3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 73
3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 72 3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 73
3.5. Identification Payloads . . . . . . . . . . . . . . . . . 73 3.5. Identification Payloads . . . . . . . . . . . . . . . . . 74
3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 76 3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 77
3.7. Certificate Request Payload . . . . . . . . . . . . . . . 78 3.7. Certificate Request Payload . . . . . . . . . . . . . . . 79
3.8. Authentication Payload . . . . . . . . . . . . . . . . . 80 3.8. Authentication Payload . . . . . . . . . . . . . . . . . 81
3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 81 3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 82
3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 82 3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 83
3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 83 3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 84
3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 86 3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 87
3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 88 3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 89
3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 89 3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 90
3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 90 3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 91
3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 92 3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 93
3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 94 3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 95
3.15.1. Configuration Attributes . . . . . . . . . . . . . . 95 3.15.1. Configuration Attributes . . . . . . . . . . . . . . 96
3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 98 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 99
3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 100 3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 101
3.15.4. Address Assignment Failures . . . . . . . . . . . . . 100 3.15.4. Address Assignment Failures . . . . . . . . . . . . . 101
3.16. Extensible Authentication Protocol (EAP) Payload . . . . 101 3.16. Extensible Authentication Protocol (EAP) Payload . . . . 102
4. Conformance Requirements . . . . . . . . . . . . . . . . . . 103 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 104
5. Security Considerations . . . . . . . . . . . . . . . . . . . 105 5. Security Considerations . . . . . . . . . . . . . . . . . . . 106
5.1. Traffic selector authorization . . . . . . . . . . . . . 107 5.1. Traffic selector authorization . . . . . . . . . . . . . 108
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 108 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 109
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 109 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 110
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 109 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 110
8.1. Normative References . . . . . . . . . . . . . . . . . . 109 8.1. Normative References . . . . . . . . . . . . . . . . . . 110
8.2. Informative References . . . . . . . . . . . . . . . . . 111 8.2. Informative References . . . . . . . . . . . . . . . . . 112
Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 114 Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 115
Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 116 Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 117
B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 116 B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 117
B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 116 B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 117
Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 116 Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 118
C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 117 C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 118
C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 117 C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 119
C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 118 C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 120
C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying
CHILD_SAs . . . . . . . . . . . . . . . . . . . . . . . . 119 CHILD_SAs . . . . . . . . . . . . . . . . . . . . . . . . 121
C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA . . . . 119 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA . . . . 121
C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 119 C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 121
Appendix D. Changes Between Internet Draft Versions . . . . . . 119 Appendix D. Changes Between Internet Draft Versions . . . . . . 121
D.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 119 D.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 121
D.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 120 D.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 122
D.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 122 D.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 124
D.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 122 D.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 124
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 123 D.5. Changes from draft -02 to draft -03 . . . . . . . . . . . 125
Intellectual Property and Copyright Statements . . . . . . . . . 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 127
Intellectual Property and Copyright Statements . . . . . . . . . 129
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 12, line 36 skipping to change at page 12, line 36
of forward secrecy for the CHILD_SA. The keying material for the of forward secrecy for the CHILD_SA. The keying material for the
CHILD_SA is a function of SK_d established during the establishment CHILD_SA is a function of SK_d established during the establishment
of the IKE_SA, the nonces exchanged during the CREATE_CHILD_SA of the IKE_SA, the nonces exchanged during the CREATE_CHILD_SA
exchange, and the Diffie-Hellman value (if KE payloads are included exchange, and the Diffie-Hellman value (if KE payloads are included
in the CREATE_CHILD_SA exchange). in the CREATE_CHILD_SA exchange).
If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of
the SA offers MUST include the Diffie-Hellman group of the KEi. The the SA offers MUST include the Diffie-Hellman group of the KEi. The
Diffie-Hellman group of the KEi MUST be an element of the group the Diffie-Hellman group of the KEi MUST be an element of the group the
initiator expects the responder to accept (additional Diffie-Hellman initiator expects the responder to accept (additional Diffie-Hellman
groups can be proposed). If the responder rejects the Diffie-Hellman groups can be proposed). If the responder selects a proposal using a
group of the KEi payload, the responder MUST reject the request and different Diffie-Hellman group (other than NONE), the responder MUST
indicate its preferred Diffie-Hellman group in the INVALID_KE_PAYLOAD reject the request and indicate its preferred Diffie-Hellman group in
Notification payload. {{ 3.10.1-17 }} There are two octets of data the INVALID_KE_PAYLOAD Notification payload. {{ 3.10.1-17 }} There
associated with this notification: the accepted D-H Group number in are two octets of data associated with this notification: the
big endian order. In the case of such a rejection, the accepted D-H Group number in big endian order. In the case of such a
CREATE_CHILD_SA exchange fails, and the initiator will probably retry rejection, the CREATE_CHILD_SA exchange fails, and the initiator will
the exchange with a Diffie-Hellman proposal and KEi in the group that probably retry the exchange with a Diffie-Hellman proposal and KEi in
the responder gave in the INVALID_KE_PAYLOAD. the group that the responder gave in the INVALID_KE_PAYLOAD.
{{ 3.10.1-35 }} The responder sends a NO_ADDITIONAL_SAS notification {{ 3.10.1-35 }} The responder sends a NO_ADDITIONAL_SAS notification
to indicate that a CREATE_CHILD_SA request is unacceptable because to indicate that a CREATE_CHILD_SA request is unacceptable because
the responder is unwilling to accept any more CHILD_SAs on this the responder is unwilling to accept any more CHILD_SAs on this
IKE_SA. Some minimal implementations may only accept a single IKE_SA. Some minimal implementations may only accept a single
CHILD_SA setup in the context of an initial IKE exchange and reject CHILD_SA setup in the context of an initial IKE exchange and reject
any subsequent attempts to add more. any subsequent attempts to add more.
1.3.1. Creating New CHILD_SAs with the CREATE_CHILD_SA Exchange 1.3.1. Creating New CHILD_SAs with the CREATE_CHILD_SA Exchange
skipping to change at page 20, line 44 skipping to change at page 20, line 44
response until it receives a request whose sequence number is larger response until it receives a request whose sequence number is larger
than or equal to the sequence number in the response plus its window than or equal to the sequence number in the response plus its window
size (see Section 2.3). size (see Section 2.3).
IKE is a reliable protocol, in the sense that the initiator MUST IKE is a reliable protocol, in the sense that the initiator MUST
retransmit a request until either it receives a corresponding reply retransmit a request until either it receives a corresponding reply
OR it deems the IKE security association to have failed and it OR it deems the IKE security association to have failed and it
discards all state associated with the IKE_SA and any CHILD_SAs discards all state associated with the IKE_SA and any CHILD_SAs
negotiated using that IKE_SA. negotiated using that IKE_SA.
{{ Clarif-2.3 }} Retransmissions of the IKE_SA_INIT request require
some special handling. When a responder receives an IKE_SA_INIT
request, it has to determine whether the packet is retransmission
belonging to an existing "half-open" IKE_SA (in which case the
responder retransmits the same response), or a new request (in which
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
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
differentiate between these three cases because two different peers
behind a single NAT could choose the same initiator SPI. Instead, a
robust responder will do the IKE_SA lookup using the whole packet,
its hash, or the Ni payload.
2.2. Use of Sequence Numbers for Message ID 2.2. Use of Sequence Numbers for Message ID
Every IKE message contains a Message ID as part of its fixed header. Every IKE message contains a Message ID as part of its fixed header.
This Message ID is used to match up requests and responses, and to This Message ID is used to match up requests and responses, and to
identify retransmissions of messages. identify retransmissions of messages.
The Message ID is a 32-bit quantity, which is zero for the The Message ID is a 32-bit quantity, which is zero for the
IKE_SA_INIT messages (including retries of the message due to IKE_SA_INIT messages (including retries of the message due to
responses such as COOKIE and INVALID_KE_PAYLOAD {{ Clarif-2.2 }}), responses such as COOKIE and INVALID_KE_PAYLOAD {{ Clarif-2.2 }}),
and incremented for each subsequent exchange. Thus, the first pair and incremented for each subsequent exchange. Thus, the first pair
skipping to change at page 21, line 29 skipping to change at page 21, line 44
of requests, the Message IDs in the two directions can be very of requests, the Message IDs in the two directions can be very
different. There is no ambiguity in the messages, however, because different. There is no ambiguity in the messages, however, because
the (I)nitiator and (R)esponse bits in the message header specify the (I)nitiator and (R)esponse bits in the message header specify
which of the four messages a particular one is. which of the four messages a particular one is.
Note that Message IDs are cryptographically protected and provide Note that Message IDs are cryptographically protected and provide
protection against message replays. In the unlikely event that protection against message replays. In the unlikely event that
Message IDs grow too large to fit in 32 bits, the IKE_SA MUST be Message IDs grow too large to fit in 32 bits, the IKE_SA MUST be
closed. Rekeying an IKE_SA resets the sequence numbers. closed. Rekeying an IKE_SA resets the sequence numbers.
{{ Clarif-2.3 }} When a responder receives an IKE_SA_INIT request, it
has to determine whether the packet is a retransmission belonging to
an existing "half-open" IKE_SA (in which case the responder
retransmits the same response), or a new request (in which case the
responder creates a new IKE_SA and sends a fresh response), or it is
a retransmission of an IKE_SA (in which case the responder ignores
it). It is not sufficient to use the initiator's SPI and/or IP
address to differentiate between the two cases because two different
peers behind a single NAT could choose the same initiator SPI.
Instead, a robust responder will do the IKE_SA lookup using the whole
packet, its hash, or the Ni payload.
2.3. Window Size for Overlapping Requests 2.3. Window Size for Overlapping Requests
In order to maximize IKE throughput, an IKE endpoint MAY issue In order to maximize IKE throughput, an IKE endpoint MAY issue
multiple requests before getting a response to any of them if the multiple requests before getting a response to any of them if the
other endpoint has indicated its ability to handle such requests. other endpoint has indicated its ability to handle such requests.
For simplicity, an IKE implementation MAY choose to process requests For simplicity, an IKE implementation MAY choose to process requests
strictly in order and/or wait for a response to one request before strictly in order and/or wait for a response to one request before
issuing another. Certain rules must be followed to ensure issuing another. Certain rules must be followed to ensure
interoperability between implementations using different strategies. interoperability between implementations using different strategies.
skipping to change at page 26, line 29 skipping to change at page 26, line 29
undefined MUST skip over those payloads and ignore their contents. undefined MUST skip over those payloads and ignore their contents.
IKEv2 adds a "critical" flag to each payload header for further IKEv2 adds a "critical" flag to each payload header for further
flexibility for forward compatibility. If the critical flag is set flexibility for forward compatibility. If the critical flag is set
and the payload type is unrecognized, the message MUST be rejected and the payload type is unrecognized, the message MUST be rejected
and the response to the IKE request containing that payload MUST and the response to the IKE request containing that payload MUST
include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an
unsupported critical payload was included. {{ 3.10.1-1 }} In that unsupported critical payload was included. {{ 3.10.1-1 }} In that
Notify payload, the notification data contains the one-octet payload Notify payload, the notification data contains the one-octet payload
type. If the critical flag is not set and the payload type is type. If the critical flag is not set and the payload type is
unsupported, that payload MUST be ignored. unsupported, that payload MUST be ignored. Payloads sent in IKE
response messages MUST NOT have the critical flag set. Note that the
critical flag applies only to the payload type, not the contents. If
the payload type is recognized, but the payload contains something
which is not (such as an unknown transform inside an SA payload, or
an unknown Notify Message Type inside a Notify payload), the critical
flag is ignored.
NOTE TO IMPLEMENTERS: Does anyone require that the payloads be in the NOTE TO IMPLEMENTERS: Does anyone require that the payloads be in the
order shown in the figures in Section 2? Can we eliminate the order shown in the figures in Section 2? Can we eliminate the
requirement in the following paragraph? If not, we will probably requirement in the following paragraph? If not, we will probably
have to add a new appendix with the order, but there is no reason to have to add a new appendix with the order, but there is no reason to
do that if no one actually cares. {{ Remove this paragraph before the do that if no one actually cares. {{ Remove this paragraph before the
document is finalized, of course. }} document is finalized, of course. }}
{{ Demoted the SHOULD in the second clause }}Although new payload {{ Demoted the SHOULD in the second clause }}Although new payload
types may be added in the future and may appear interleaved with the types may be added in the future and may appear interleaved with the
skipping to change at page 27, line 12 skipping to change at page 27, line 21
octet fields titled "cookies", and that syntax is used by both IKEv1 octet fields titled "cookies", and that syntax is used by both IKEv1
and IKEv2, although in IKEv2 they are referred to as the "IKE SPI" and IKEv2, although in IKEv2 they are referred to as the "IKE SPI"
and there is a new separate field in a Notify payload holding the and there is a new separate field in a Notify payload holding the
cookie. The initial two eight-octet fields in the header are used as cookie. The initial two eight-octet fields in the header are used as
a connection identifier at the beginning of IKE packets. {{ Demoted a connection identifier at the beginning of IKE packets. {{ Demoted
the SHOULD }} Each endpoint chooses one of the two SPIs and needs to the SHOULD }} Each endpoint chooses one of the two SPIs and needs to
choose them so as to be unique identifiers of an IKE_SA. An SPI choose them so as to be unique identifiers of an IKE_SA. An SPI
value of zero is special and indicates that the remote SPI value is value of zero is special and indicates that the remote SPI value is
not yet known by the sender. not yet known by the sender.
{{ 3.10.1-16390 }}The COOKIE notification MAY be included in an
IKE_SA_INIT response. It indicates that the request should be
retried with a copy of this notification as the first payload. This
notification MUST be included in an IKE_SA_INIT request retry if a
COOKIE notification was included in the initial response. The data
associated with this notification MUST be between 1 and 64 octets in
length (inclusive).
Unlike ESP and AH where only the recipient's SPI appears in the Unlike ESP and AH where only the recipient's SPI appears in the
header of a message, in IKE the sender's SPI is also sent in every header of a message, in IKE the sender's SPI is also sent in every
message. Since the SPI chosen by the original initiator of the message. Since the SPI chosen by the original initiator of the
IKE_SA is always sent first, an endpoint with multiple IKE_SAs open IKE_SA is always sent first, an endpoint with multiple IKE_SAs open
that wants to find the appropriate IKE_SA using the SPI it assigned that wants to find the appropriate IKE_SA using the SPI it assigned
must look at the I(nitiator) Flag bit in the header to determine must look at the I(nitiator) Flag bit in the header to determine
whether it assigned the first or the second eight octets. whether it assigned the first or the second eight octets.
In the first message of an initial IKE exchange, the initiator will In the first message of an initial IKE exchange, the initiator will
not know the responder's SPI value and will therefore set that field not know the responder's SPI value and will therefore set that field
to zero. to zero.
An expected attack against IKE is state and CPU exhaustion, where the An expected attack against IKE is state and CPU exhaustion, where the
target is flooded with session initiation requests from forged IP target is flooded with session initiation requests from forged IP
addresses. This attack can be made less effective if an addresses. This attack can be made less effective if an
implementation of a responder uses minimal CPU and commits no state implementation of a responder uses minimal CPU and commits no state
to an SA until it knows the initiator can receive packets at the to an SA until it knows the initiator can receive packets at the
address from which it claims to be sending them. To accomplish this, address from which it claims to be sending them.
a responder SHOULD -- when it detects a large number of half-open
IKE_SAs -- reject initial IKE messages unless they contain a Notify When a responder detects a large number of half-open IKE_SAs, it
payload of type COOKIE. {{ Clarified the SHOULD }} If the responder SHOULD reply to IKE_SA_INIT requests with a response containing the
wants to set up an SA, it SHOULD instead send an unprotected IKE COOKIE notification. {{ 3.10.1-16390 }} The data associated with this
message as a response and include a COOKIE Notify payload with the notification MUST be between 1 and 64 octets in length (inclusive),
cookie data to be returned. Initiators who receive such responses and its generation is described later in this section. If the
MUST retry the IKE_SA_INIT with a Notify payload of type COOKIE IKE_SA_INIT response includes the COOKIE notification, the initiator
containing the responder supplied cookie data as the first payload MUST then retry the IKE_SA_INIT request, and include the COOKIE
and all other payloads unchanged. The initial exchange will then be notification containing the received data as the first payload, and
as follows: all other payloads unchanged. The initial exchange will then be as
follows:
Initiator Responder Initiator Responder
------------------------------------------------------------------- -------------------------------------------------------------------
HDR(A,0), SAi1, KEi, Ni --> HDR(A,0), SAi1, KEi, Ni -->
<-- HDR(A,0), N(COOKIE) <-- HDR(A,0), N(COOKIE)
HDR(A,0), N(COOKIE), SAi1, HDR(A,0), N(COOKIE), SAi1,
KEi, Ni --> KEi, Ni -->
<-- HDR(A,B), SAr1, KEr, <-- HDR(A,B), SAr1, KEr,
Nr, [CERTREQ] Nr, [CERTREQ]
HDR(A,B), SK {IDi, [CERT,] HDR(A,B), SK {IDi, [CERT,]
skipping to change at page 28, line 26 skipping to change at page 28, line 26
<-- HDR(A,B), SK {IDr, [CERT,] <-- HDR(A,B), SK {IDr, [CERT,]
AUTH, SAr2, TSi, TSr} AUTH, SAr2, TSi, TSr}
The first two messages do not affect any initiator or responder state The first two messages do not affect any initiator or responder state
except for communicating the cookie. In particular, the message except for communicating the cookie. In particular, the message
sequence numbers in the first four messages will all be zero and the sequence numbers in the first four messages will all be zero and the
message sequence numbers in the last two messages will be one. 'A' message sequence numbers in the last two messages will be one. 'A'
is the SPI assigned by the initiator, while 'B' is the SPI assigned is the SPI assigned by the initiator, while 'B' is the SPI assigned
by the responder. by the responder.
{{ Clarif-2.1 }} Because the responder's SPI identifies security-
related state held by the responder, and in this case no state is
created, the responder sends a zero value for the responder's SPI.
{{ Demoted the SHOULD }} An IKE implementation should implement its {{ Demoted the SHOULD }} An IKE implementation should implement its
responder cookie generation in such a way as to not require any saved responder cookie generation in such a way as to not require any saved
state to recognize its valid cookie when the second IKE_SA_INIT state to recognize its valid cookie when the second IKE_SA_INIT
message arrives. The exact algorithms and syntax they use to message arrives. The exact algorithms and syntax they use to
generate cookies do not affect interoperability and hence are not generate cookies do not affect interoperability and hence are not
specified here. The following is an example of how an endpoint could specified here. The following is an example of how an endpoint could
use cookies to implement limited DOS protection. use cookies to implement limited DOS protection.
A good way to do this is to set the responder cookie to be: A good way to do this is to set the responder cookie to be:
skipping to change at page 31, line 6 skipping to change at page 30, line 51
responder will select from its list of supported groups. If the responder will select from its list of supported groups. If the
initiator guesses wrong, the responder will respond with a Notify initiator guesses wrong, the responder will respond with a Notify
payload of type INVALID_KE_PAYLOAD indicating the selected group. In payload of type INVALID_KE_PAYLOAD indicating the selected group. In
this case, the initiator MUST retry the IKE_SA_INIT with the this case, the initiator MUST retry the IKE_SA_INIT with the
corrected Diffie-Hellman group. The initiator MUST again propose its corrected Diffie-Hellman group. The initiator MUST again propose its
full set of acceptable cryptographic suites because the rejection full set of acceptable cryptographic suites because the rejection
message was unauthenticated and otherwise an active attacker could message was unauthenticated and otherwise an active attacker could
trick the endpoints into negotiating a weaker suite than a stronger trick the endpoints into negotiating a weaker suite than a stronger
one that they both prefer. one that they both prefer.
{{ Clarif-2.1 }} When the IKE_SA_INIT exchange does not result in the
creation of an IKE_SA due to INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN,
or COOKIE (see Section 2.6), the responder's SPI will be zero.
However, if the responder sends a non-zero responder SPI, the
initiator should not reject the response for only that reason.
2.8. Rekeying 2.8. Rekeying
{{ Demoted the SHOULD }} IKE, ESP, and AH security associations use {{ Demoted the SHOULD }} IKE, ESP, and AH security associations use
secret keys that should be used only for a limited amount of time and secret keys that should be used only for a limited amount of time and
to protect a limited amount of data. This limits the lifetime of the to protect a limited amount of data. This limits the lifetime of the
entire security association. When the lifetime of a security entire security association. When the lifetime of a security
association expires, the security association MUST NOT be used. If association expires, the security association MUST NOT be used. If
there is demand, new security associations MAY be established. there is demand, new security associations MAY be established.
Reestablishment of security associations to take the place of ones Reestablishment of security associations to take the place of ones
that expire is referred to as "rekeying". that expire is referred to as "rekeying".
skipping to change at page 41, line 10 skipping to change at page 41, line 10
negotiated: an encryption algorithm, an integrity protection negotiated: an encryption algorithm, an integrity protection
algorithm, a Diffie-Hellman group, and a pseudo-random function algorithm, a Diffie-Hellman group, and a pseudo-random function
(prf). The pseudo-random function is used for the construction of (prf). The pseudo-random function is used for the construction of
keying material for all of the cryptographic algorithms used in both keying material for all of the cryptographic algorithms used in both
the IKE_SA and the CHILD_SAs. the IKE_SA and the CHILD_SAs.
We assume that each encryption algorithm and integrity protection We assume that each encryption algorithm and integrity protection
algorithm uses a fixed-size key and that any randomly chosen value of algorithm uses a fixed-size key and that any randomly chosen value of
that fixed size can serve as an appropriate key. For algorithms that that fixed size can serve as an appropriate key. For algorithms that
accept a variable length key, a fixed key size MUST be specified as accept a variable length key, a fixed key size MUST be specified as
part of the cryptographic transform negotiated. For algorithms for part of the cryptographic transform negotiated (see Section 3.3.5 for
which not all values are valid keys (such as DES or 3DES with key the defintion of the Key Length transform attribute). For algorithms
for which not all values are valid keys (such as DES or 3DES with key
parity), the algorithm by which keys are derived from arbitrary parity), the algorithm by which keys are derived from arbitrary
values MUST be specified by the cryptographic transform. For values MUST be specified by the cryptographic transform. For
integrity protection functions based on Hashed Message Authentication integrity protection functions based on Hashed Message Authentication
Code (HMAC), the fixed key size is the size of the output of the Code (HMAC), the fixed key size is the size of the output of the
underlying hash function. underlying hash function.
It is assumed that pseudo-random functions (PRFs) accept keys of any It is assumed that pseudo-random functions (PRFs) accept keys of any
length, but have a preferred key size. The preferred key size is length, but have a preferred key size. The preferred key size is
used as the length of SK_d, SK_pi, and SK_pr (see Section 2.14). For used as the length of SK_d, SK_pi, and SK_pr (see Section 2.14). For
PRFs based on the HMAC construction, the preferred key size is equal PRFs based on the HMAC construction, the preferred key size is equal
skipping to change at page 47, line 16 skipping to change at page 47, line 16
where g^ir (new) is the shared secret from the ephemeral Diffie- where g^ir (new) is the shared secret from the ephemeral Diffie-
Hellman exchange of this CREATE_CHILD_SA exchange (represented as an Hellman exchange of this CREATE_CHILD_SA exchange (represented as an
octet string in big endian order padded with zeros in the high-order octet string in big endian order padded with zeros in the high-order
bits if necessary to make it the length of the modulus). bits if necessary to make it the length of the modulus).
For ESP and AH, a single CHILD_SA negotiation results in two security For ESP and AH, a single CHILD_SA negotiation results in two security
associations (one in each direction). Keying material MUST be taken associations (one in each direction). Keying material MUST be taken
from the expanded KEYMAT in the following order: from the expanded KEYMAT in the following order:
o All keys for SAs carrying data from the initiator to the responder o The encryption key (if any) for the SA carrying data from the
are taken before SAs going in the reverse direction. initiator to the responder.
o If a single protocol has both encryption and authentication keys, o The authentication key (if any) for the SA carrying data from the
the encryption key is taken from the first octets of KEYMAT and initiator to the responder.
the authentication key is taken from the next octets.
o The encryption key (if any) for the SA carrying data from the
responder to the initiator.
o The authentication key (if any) for the SA carrying data from the
responder to the initiator.
Each cryptographic algorithm takes a fixed number of bits of keying Each cryptographic algorithm takes a fixed number of bits of keying
material specified as part of the algorithm. material specified as part of the algorithm, or negotiated in SA
payloads (see Section 2.13 for description of key lengths, and
Section 3.3.5 for the definition of the Key Length transform
attribute).
2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA Exchange 2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA Exchange
The CREATE_CHILD_SA exchange can be used to rekey an existing IKE_SA The CREATE_CHILD_SA exchange can be used to rekey an existing IKE_SA
(see Section 2.8). {{ Clarif-5.3 }} New initiator and responder SPIs (see Section 2.8). {{ Clarif-5.3 }} New initiator and responder SPIs
are supplied in the SPI fields in the Proposal structures inside the are supplied in the SPI fields in the Proposal structures inside the
Security Association (SA) payloads (not the SPI fields in the IKE Security Association (SA) payloads (not the SPI fields in the IKE
header). The TS payloads are omitted when rekeying an IKE_SA. header). The TS payloads are omitted when rekeying an IKE_SA.
SKEYSEED for the new IKE_SA is computed using SK_d from the existing SKEYSEED for the new IKE_SA is computed using SK_d from the existing
IKE_SA as follows: IKE_SA as follows:
skipping to change at page 56, line 37 skipping to change at page 56, line 47
port 4500. port 4500.
o To tunnel IKE packets over UDP port 4500, the IKE header has four o To tunnel IKE packets over UDP port 4500, the IKE header has four
octets of zero prepended and the result immediately follows the octets of zero prepended and the result immediately follows the
UDP header. To tunnel ESP packets over UDP port 4500, the ESP UDP header. To tunnel ESP packets over UDP port 4500, the ESP
header immediately follows the UDP header. Since the first four header immediately follows the UDP header. Since the first four
octets of the ESP header contain the SPI, and the SPI cannot octets of the ESP header contain the SPI, and the SPI cannot
validly be zero, it is always possible to distinguish ESP and IKE validly be zero, it is always possible to distinguish ESP and IKE
messages. messages.
o Implementations MUST process received UDP-encapsulated ESP packets
even when no NAT was detected.
o The original source and destination IP address required for the o The original source and destination IP address required for the
transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS])
are obtained from the Traffic Selectors associated with the are obtained from the Traffic Selectors associated with the
exchange. In the case of NAT traversal, the Traffic Selectors exchange. In the case of NAT traversal, the Traffic Selectors
MUST contain exactly one IP address, which is then used as the MUST contain exactly one IP address, which is then used as the
original IP address. original IP address.
o There are cases where a NAT box decides to remove mappings that o There are cases where a NAT box decides to remove mappings that
are still alive (for example, the keepalive interval is too long, are still alive (for example, the keepalive interval is too long,
or the NAT box is rebooted). To recover in these cases, hosts or the NAT box is rebooted). To recover in these cases, hosts
skipping to change at page 62, line 21 skipping to change at page 63, line 15
{{ Clarif-7.10 }} Many payloads contain fields marked as "RESERVED". {{ Clarif-7.10 }} Many payloads contain fields marked as "RESERVED".
Some payloads in IKEv2 (and historically in IKEv1) are not aligned to Some payloads in IKEv2 (and historically in IKEv1) are not aligned to
4-octet boundaries. 4-octet boundaries.
3.3. Security Association Payload 3.3. Security Association Payload
The Security Association Payload, denoted SA in this memo, is used to The Security Association Payload, denoted SA in this memo, is used to
negotiate attributes of a security association. Assembly of Security negotiate attributes of a security association. Assembly of Security
Association Payloads requires great peace of mind. An SA payload MAY Association Payloads requires great peace of mind. An SA payload MAY
contain multiple proposals. If there is more than one, they MUST be contain multiple proposals. If there is more than one, they MUST be
ordered from most preferred to least preferred. Each proposal may ordered from most preferred to least preferred. Each proposal
contain a single IPsec protocol (where a protocol is IKE, ESP, or contains a single IPsec protocol (where a protocol is IKE, ESP, or
AH), each protocol MAY contain multiple transforms, and each AH), each protocol MAY contain multiple transforms, and each
transform MAY contain multiple attributes. When parsing an SA, an transform MAY contain multiple attributes. When parsing an SA, an
implementation MUST check that the total Payload Length is consistent implementation MUST check that the total Payload Length is consistent
with the payload's internal lengths and counts. Proposals, with the payload's internal lengths and counts. Proposals,
Transforms, and Attributes each have their own variable length Transforms, and Attributes each have their own variable length
encodings. They are nested such that the Payload Length of an SA encodings. They are nested such that the Payload Length of an SA
includes the combined contents of the SA, Proposal, Transform, and includes the combined contents of the SA, Proposal, Transform, and
Attribute information. The length of a Proposal includes the lengths Attribute information. The length of a Proposal includes the lengths
of all Transforms and Attributes it contains. The length of a of all Transforms and Attributes it contains. The length of a
Transform includes the lengths of all Attributes it contains. Transform includes the lengths of all Attributes it contains.
skipping to change at page 67, line 11 skipping to change at page 67, line 31
type being proposed. type being proposed.
The tranform type values are: The tranform type values are:
Description Trans. Used In Description Trans. Used In
Type Type
------------------------------------------------------------------ ------------------------------------------------------------------
RESERVED 0 RESERVED 0
Encryption Algorithm (ENCR) 1 IKE and ESP Encryption Algorithm (ENCR) 1 IKE and ESP
Pseudo-random Function (PRF) 2 IKE Pseudo-random Function (PRF) 2 IKE
Integrity Algorithm (INTEG) 3 IKE, AH, optional in ESP Integrity Algorithm (INTEG) 3 IKE*, AH, optional in ESP
Diffie-Hellman Group (D-H) 4 IKE, optional in AH & ESP Diffie-Hellman Group (D-H) 4 IKE, optional in AH & ESP
Extended Sequence Numbers (ESN) 5 AH and ESP Extended Sequence Numbers (ESN) 5 AH and ESP
RESERVED TO IANA 6-240 RESERVED TO IANA 6-240
PRIVATE USE 241-255 PRIVATE USE 241-255
(*) Negotiating an integrity algorithm is mandatory for the
Encrypted payload format specified in this document. Future
documents may specify additional formats based on authenticated
encryption, in which case a separate integrity algorithm is not
negotiated.
For Transform Type 1 (Encryption Algorithm), defined Transform IDs For Transform Type 1 (Encryption Algorithm), defined Transform IDs
are: are:
Name Number Defined In Name Number Defined In
--------------------------------------------------- ---------------------------------------------------
RESERVED 0 RESERVED 0
ENCR_DES_IV64 1 (RFC1827) ENCR_DES_IV64 1 (UNSPECIFIED)
ENCR_DES 2 (RFC2405), [DES] ENCR_DES 2 (RFC2405), [DES]
ENCR_3DES 3 (RFC2451) ENCR_3DES 3 (RFC2451)
ENCR_RC5 4 (RFC2451) ENCR_RC5 4 (RFC2451)
ENCR_IDEA 5 (RFC2451), [IDEA] ENCR_IDEA 5 (RFC2451), [IDEA]
ENCR_CAST 6 (RFC2451) ENCR_CAST 6 (RFC2451)
ENCR_BLOWFISH 7 (RFC2451) ENCR_BLOWFISH 7 (RFC2451)
ENCR_3IDEA 8 (RFC2451) ENCR_3IDEA 8 (UNSPECIFIED)
ENCR_DES_IV32 9 ENCR_DES_IV32 9 (UNSPECIFIED)
RESERVED 10 RESERVED 10
ENCR_NULL 11 (RFC2410) ENCR_NULL 11 (RFC2410)
ENCR_AES_CBC 12 (RFC3602) ENCR_AES_CBC 12 (RFC3602)
ENCR_AES_CTR 13 (RFC3686) ENCR_AES_CTR 13 (RFC3686)
RESERVED TO IANA 14-1023 RESERVED TO IANA 14-1023
PRIVATE USE 1024-65535 PRIVATE USE 1024-65535
For Transform Type 2 (Pseudo-random Function), defined Transform IDs For Transform Type 2 (Pseudo-random Function), defined Transform IDs
are: are:
Name Number Defined In Name Number Defined In
------------------------------------------------------ ------------------------------------------------------
RESERVED 0 RESERVED 0
PRF_HMAC_MD5 1 (RFC2104), [MD5] PRF_HMAC_MD5 1 (RFC2104), [MD5]
PRF_HMAC_SHA1 2 (RFC2104), [SHA] PRF_HMAC_SHA1 2 (RFC2104), [SHA]
PRF_HMAC_TIGER 3 (RFC2104) PRF_HMAC_TIGER 3 (UNSPECIFIED)
PRF_AES128_XCBC 4 (RFC4434) PRF_AES128_XCBC 4 (RFC4434)
RESERVED TO IANA 5-1023 RESERVED TO IANA 5-1023
PRIVATE USE 1024-65535 PRIVATE USE 1024-65535
For Transform Type 3 (Integrity Algorithm), defined Transform IDs For Transform Type 3 (Integrity Algorithm), defined Transform IDs
are: are:
Name Number Defined In Name Number Defined In
---------------------------------------- ----------------------------------------
NONE 0 NONE 0
AUTH_HMAC_MD5_96 1 (RFC2403) AUTH_HMAC_MD5_96 1 (RFC2403)
AUTH_HMAC_SHA1_96 2 (RFC2404) AUTH_HMAC_SHA1_96 2 (RFC2404)
AUTH_DES_MAC 3 AUTH_DES_MAC 3 (UNSPECIFIED)
AUTH_KPDK_MD5 4 (RFC1826) AUTH_KPDK_MD5 4 (UNSPECIFIED)
AUTH_AES_XCBC_96 5 (RFC3566) AUTH_AES_XCBC_96 5 (RFC3566)
RESERVED TO IANA 6-1023 RESERVED TO IANA 6-1023
PRIVATE USE 1024-65535 PRIVATE USE 1024-65535
For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs
are: are:
Name Number Defined in Name Number Defined in
---------------------------------------- ----------------------------------------
NONE 0 NONE 0
skipping to change at page 69, line 18 skipping to change at page 70, line 7
dependent on the protocol in the SA itself. An SA payload proposing dependent on the protocol in the SA itself. An SA payload proposing
the establishment of an SA has the following mandatory and optional the establishment of an SA has the following mandatory and optional
transform types. A compliant implementation MUST understand all transform types. A compliant implementation MUST understand all
mandatory and optional types for each protocol it supports (though it mandatory and optional types for each protocol it supports (though it
need not accept proposals with unacceptable suites). A proposal MAY need not accept proposals with unacceptable suites). A proposal MAY
omit the optional types if the only value for them it will accept is omit the optional types if the only value for them it will accept is
NONE. NONE.
Protocol Mandatory Types Optional Types Protocol Mandatory Types Optional Types
--------------------------------------------------- ---------------------------------------------------
IKE ENCR, PRF, INTEG, D-H IKE ENCR, PRF, INTEG*, D-H
ESP ENCR, ESN INTEG, D-H ESP ENCR, ESN INTEG, D-H
AH INTEG, ESN D-H AH INTEG, ESN D-H
(*) Negotiating an integrity algorithm is mandatory for the
Encrypted payload format specified in this document. Future
documents may specify additional formats based on authenticated
encryption, in which case a separate integrity algorithm is not
negotiated.
3.3.4. Mandatory Transform IDs 3.3.4. Mandatory Transform IDs
The specification of suites that MUST and SHOULD be supported for The specification of suites that MUST and SHOULD be supported for
interoperability has been removed from this document because they are interoperability has been removed from this document because they are
likely to change more rapidly than this document evolves. likely to change more rapidly than this document evolves.
An important lesson learned from IKEv1 is that no system should only An important lesson learned from IKEv1 is that no system should only
implement the mandatory algorithms and expect them to be the best implement the mandatory algorithms and expect them to be the best
choice for all customers. For example, at the time that this choice for all customers. For example, at the time that this
document was written, many IKEv1 implementers were starting to document was written, many IKEv1 implementers were starting to
skipping to change at page 73, line 27 skipping to change at page 74, line 27
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). If the selected
proposal uses a different Diffie-Hellman group, the message MUST be proposal uses a different Diffie-Hellman group (other than NONE), the
rejected with a Notify payload of type INVALID_KE_PAYLOAD. 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 75, line 5 skipping to change at page 76, line 5
o Identification Data (variable length) - Value, as indicated by the o Identification Data (variable length) - Value, as indicated by the
Identification Type. The length of the Identification Data is Identification Type. The length of the Identification Data is
computed from the size in the ID payload header. computed from the size in the ID payload header.
The payload types for the Identification Payload are thirty five (35) The payload types for the Identification Payload are thirty five (35)
for IDi and thirty six (36) for IDr. for IDi and thirty six (36) for IDr.
The following table lists the assigned values for the Identification The following table lists the assigned values for the Identification
Type field: Type field:
ID Type Value ID Type Value
RESERVED 0 -------------------------------------------------------------------
RESERVED 0
ID_IPV4_ADDR 1 ID_IPV4_ADDR 1
A single four (4) octet IPv4 address. A single four (4) octet IPv4 address.
ID_FQDN 2 ID_FQDN 2
A fully-qualified domain name string. An example of a ID_FQDN is, A fully-qualified domain name string. An example of a ID_FQDN
"example.com". The string MUST not contain any terminators (e.g., is, "example.com". The string MUST not contain any terminators
NULL, CR, etc.). All characters in the ID_FQDN are ASCII; for an (e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII;
"internationalized domain name", the syntax is as defined in [IDNA], for an "internationalized domain name", the syntax is as defined
for example "xn--tmonesimerkki-bfbb.example.net". in [IDNA], for example "xn--tmonesimerkki-bfbb.example.net".
ID_RFC822_ADDR 3 ID_RFC822_ADDR 3
A fully-qualified RFC822 email address string, An example of a A fully-qualified RFC822 email address string, An example of a
ID_RFC822_ADDR is, "jsmith@example.com". The string MUST not ID_RFC822_ADDR is, "jsmith@example.com". The string MUST not
contain any terminators. contain any terminators.
RESERVED TO IANA 4 RESERVED TO IANA 4
ID_IPV6_ADDR 5 ID_IPV6_ADDR 5
A single sixteen (16) octet IPv6 address. A single sixteen (16) octet IPv6 address.
RESERVED TO IANA 6 - 8 RESERVED TO IANA 6 - 8
ID_DER_ASN1_DN 9 ID_DER_ASN1_DN 9
The binary Distinguished Encoding Rules (DER) encoding of an The binary Distinguished Encoding Rules (DER) encoding of an
ASN.1 X.500 Distinguished Name [X.501]. ASN.1 X.500 Distinguished Name [X.501].
ID_DER_ASN1_GN 10 ID_DER_ASN1_GN 10
The binary DER encoding of an ASN.1 X.500 GeneralName [X.509]. The binary DER encoding of an ASN.1 X.500 GeneralName [X.509].
ID_KEY_ID 11 ID_KEY_ID 11
An opaque octet stream which may be used to pass vendor- An opaque octet stream which may be used to pass vendor-
specific information necessary to do certain proprietary specific information necessary to do certain proprietary
types of identification. types of identification.
RESERVED TO IANA 12-200 RESERVED TO IANA 12-200
PRIVATE USE 201-255 PRIVATE USE 201-255
Two implementations will interoperate only if each can generate a Two implementations will interoperate only if each can generate a
type of ID acceptable to the other. To assure maximum type of ID acceptable to the other. To assure maximum
interoperability, implementations MUST be configurable to send at interoperability, implementations MUST be configurable to send at
least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and
MUST be configurable to accept all of these types. Implementations MUST be configurable to accept all of these types. Implementations
SHOULD be capable of generating and accepting all of these types. SHOULD be capable of generating and accepting all of these types.
IPv6-capable implementations MUST additionally be configurable to IPv6-capable implementations MUST additionally be configurable to
accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable
skipping to change at page 92, line 42 skipping to change at page 93, line 42
The Encrypted Payload, denoted SK{...} or E in this memo, contains The Encrypted Payload, denoted SK{...} or E in this memo, contains
other payloads in encrypted form. The Encrypted Payload, if present other payloads in encrypted form. The Encrypted Payload, if present
in a message, MUST be the last payload in the message. Often, it is in a message, MUST be the last payload in the message. Often, it is
the only payload in the message. the only payload in the message.
The algorithms for encryption and integrity protection are negotiated The algorithms for encryption and integrity protection are negotiated
during IKE_SA setup, and the keys are computed as specified in during IKE_SA setup, and the keys are computed as specified in
Section 2.14 and Section 2.18. Section 2.14 and Section 2.18.
The encryption and integrity protection algorithms are modeled after This document specifies the cryptographic processing of Encrypted
the ESP algorithms described in RFCs 2104 [HMAC], 4303 [ESP], and payloads using a block cipher in CBC mode and an integrity check
2451 [ESPCBC]. This document completely specifies the cryptographic algorithm that computes a fixed-length checksum over a variable size
processing of IKE data, but those documents should be consulted for message. The design is modeled after the ESP algorithms described in
design rationale. We require a block cipher with a fixed block size RFCs 2104 [HMAC], 4303 [ESP], and 2451 [ESPCBC]. This document
and an integrity check algorithm that computes a fixed-length completely specifies the cryptographic processing of IKE data, but
checksum over a variable size message. those documents should be consulted for design rationale. Future
documents may specify the processing of Encrypted payloads for other
types of transforms, such as counter mode encryption and
authenticated encryption algorithms. Peers MUST NOT negotiate
transforms for which no such specification exists.
The payload type for an Encrypted payload is forty six (46). The The payload type for an Encrypted payload is forty six (46). The
Encrypted Payload consists of the IKE generic payload header followed Encrypted Payload consists of the IKE generic payload header followed
by individual fields as follows: by individual fields as follows:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 93, line 35 skipping to change at page 94, line 39
Note that this is an exception in the standard header format, Note that this is an exception in the standard header format,
since the Encrypted payload is the last payload in the message and since the Encrypted payload is the last payload in the message and
therefore the Next Payload field would normally be zero. But therefore the Next Payload field would normally be zero. But
because the content of this payload is embedded payloads and there because the content of this payload is embedded payloads and there
was no natural place to put the type of the first one, that type was no natural place to put the type of the first one, that type
is placed here. is placed here.
o Payload Length - Includes the lengths of the header, IV, Encrypted o Payload Length - Includes the lengths of the header, IV, Encrypted
IKE Payloads, Padding, Pad Length, and Integrity Checksum Data. IKE Payloads, Padding, Pad Length, and Integrity Checksum Data.
o Initialization Vector - A randomly chosen value whose length is o Initialization Vector - The length of the initialization vector
equal to the block length of the underlying encryption algorithm. (IV) is equal to the block length of the underlying encryption
Recipients MUST accept any value. Senders SHOULD either pick this algorithm. Senders MUST select a new unpredictable IV for every
value pseudo-randomly and independently for each message or use message; recipients MUST accept any value. The reader is
the final ciphertext block of the previous message sent. Senders encouraged to consult [MODES] for advice on IV generation. In
MUST NOT use the same value for each message, use a sequence of particular, using the final ciphertext block of the previous
values with low hamming distance (e.g., a sequence number), or use message is not considered unpredictable.
ciphertext from a received message.
o IKE Payloads are as specified earlier in this section. This field o IKE Payloads are as specified earlier in this section. This field
is encrypted with the negotiated cipher. is encrypted with the negotiated cipher.
o Padding MAY contain any value chosen by the sender, and MUST have o Padding MAY contain any value chosen by the sender, and MUST have
a length that makes the combination of the Payloads, the Padding, a length that makes the combination of the Payloads, the Padding,
and the Pad Length to be a multiple of the encryption block size. and the Pad Length to be a multiple of the encryption block size.
This field is encrypted with the negotiated cipher. This field is encrypted with the negotiated cipher.
o Pad Length is the length of the Padding field. The sender SHOULD o Pad Length is the length of the Padding field. The sender SHOULD
set the Pad Length to the minimum value that makes the combination set the Pad Length to the minimum value that makes the combination
of the Payloads, the Padding, and the Pad Length a multiple of the of the Payloads, the Padding, and the Pad Length a multiple of the
block size, but the recipient MUST accept any length that results block size, but the recipient MUST accept any length that results
in proper alignment. This field is encrypted with the negotiated in proper alignment. This field is encrypted with the negotiated
cipher. cipher.
o Integrity Checksum Data is the cryptographic checksum of the o Integrity Checksum Data is the cryptographic checksum of the
skipping to change at page 107, line 25 skipping to change at page 108, line 25
exchange, and use it to initiate an IKEv2 connection. For this exchange, and use it to initiate an IKEv2 connection. For this
reason, use of non-key-generating EAP methods SHOULD be avoided where reason, use of non-key-generating EAP methods SHOULD be avoided where
possible. Where they are used, it is extremely important that all possible. Where they are used, it is extremely important that all
usages of these EAP methods SHOULD utilize a protected tunnel, where usages of these EAP methods SHOULD utilize a protected tunnel, where
the initiator validates the responder's certificate before initiating the initiator validates the responder's certificate before initiating
the EAP exchange. {{ Demoted the SHOULD }} Implementers should the EAP exchange. {{ Demoted the SHOULD }} Implementers should
describe the vulnerabilities of using non-key-generating EAP methods describe the vulnerabilities of using non-key-generating EAP methods
in the documentation of their implementations so that the in the documentation of their implementations so that the
administrators deploying IPsec solutions are aware of these dangers. administrators deploying IPsec solutions are aware of these dangers.
An implementation using EAP MUST also use a public-key-based An implementation using EAP MUST also use strong authentication of
authentication of the server to the client before the EAP exchange the server to the client before the EAP exchange begins, even if the
begins, even if the EAP method offers mutual authentication. This EAP method offers mutual authentication. This avoids having
avoids having additional IKEv2 protocol variations and protects the additional IKEv2 protocol variations and protects the EAP data from
EAP data from active attackers. active attackers.
If the messages of IKEv2 are long enough that IP-level fragmentation If the messages of IKEv2 are long enough that IP-level fragmentation
is necessary, it is possible that attackers could prevent the is necessary, it is possible that attackers could prevent the
exchange from completing by exhausting the reassembly buffers. The exchange from completing by exhausting the reassembly buffers. The
chances of this can be minimized by using the Hash and URL encodings chances of this can be minimized by using the Hash and URL encodings
instead of sending certificates (see Section 3.6). Additional instead of sending certificates (see Section 3.6). Additional
mitigations are discussed in [DOSUDPPROT]. mitigations are discussed in [DOSUDPPROT].
5.1. Traffic selector authorization 5.1. Traffic selector authorization
skipping to change at page 109, line 37 skipping to change at page 110, line 37
Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer
Reingold, and Michael Richardson. Many other people contributed to Reingold, and Michael Richardson. Many other people contributed to
the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI, the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI,
each of which has its own list of authors. Hugh Daniel suggested the each of which has its own list of authors. Hugh Daniel suggested the
feature of having the initiator, in message 3, specify a name for the feature of having the initiator, in message 3, specify a name for the
responder, and gave the feature the cute name "You Tarzan, Me Jane". responder, and gave the feature the cute name "You Tarzan, Me Jane".
David Faucher and Valery Smyzlov helped refine the design of the David Faucher and Valery Smyzlov helped refine the design of the
traffic selector negotiation. traffic selector negotiation.
This paragraph lists references that appear only in figures. The This paragraph lists references that appear only in figures. The
section is only here to keep the 'xml2rfc' program happy, and will be section is only here to keep the 'xml2rfc' program happy, and needs
removed when the document is published. Feel free to ignore it. to be removed when the document is published. Feel free to ignore
[DES] [IDEA] [MD5] [X.501] [X.509] it. [DES] [IDEA] [MD5] [X.501] [X.509]
8. References 8. References
8.1. Normative References 8.1. Normative References
[ADDGROUP] [ADDGROUP]
Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)", Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, May 2003. RFC 3526, May 2003.
skipping to change at page 113, line 30 skipping to change at page 114, line 30
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[MIPV6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [MIPV6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[MLDV2] Vida, R. and L. Costa, "Multicast Listener Discovery [MLDV2] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[MODES] National Institute of Standards and Technology, U.S.
Department of Commerce, "Recommendation for Block Cipher
Modes of Operation", SP 800-38A, 2001.
[NAI] Aboba, B. and M. Beadles, "The Network Access Identifier", [NAI] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999. RFC 2486, January 1999.
[NATREQ] Aboba, B. and W. Dixon, "IPsec-Network Address Translation [NATREQ] Aboba, B. and W. Dixon, "IPsec-Network Address Translation
(NAT) Compatibility Requirements", RFC 3715, March 2004. (NAT) Compatibility Requirements", RFC 3715, March 2004.
[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol",
RFC 2412, November 1998. RFC 2412, November 1998.
[PFKEY] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key [PFKEY] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
skipping to change at page 124, line 5 skipping to change at page 125, line 48
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
In Section 1.3, changed "If the responder rejects the Diffie-Hellman
group of the KEi payload, the responder MUST reject the request and
indicate its preferred Diffie-Hellman group in the INVALID_KE_PAYLOAD
Notification payload." to "If the responder selects a proposal using
a different Diffie-Hellman group (other than NONE), the responder
MUST reject the request and indicate its preferred Diffie-Hellman
group in the INVALID_KE_PAYLOAD Notification payload.
In Section 2.3, added the last two paragraphs covering why you
initiator's SPI and/or IP to differentiate if this is a "half-open"
IKE_SA or a new request. Also removed similar text from Section 2.2.
In Section 2.5, added "Payloads sent in IKE response messages MUST
NOT have the critical flag set. Note that the critical flag applies
only to the payload type, not the contents. If the payload type is
recognized, but the payload contains something which is not (such as
an unknown transform inside an SA payload, or an unknown Notify
Message Type inside a Notify payload), the critical flag is ignored."
In Section 2.6, moved the text about {{ 3.10.1-16390 }} later in the
section. Also reworded the text to make it clearer what the COOKIE
is for.
Moved text from {{ Clarif-2.1 }} from Section 2.6 to Section 2.7.
In Section 2.13, added "(see Section 3.3.5 for the defintion of the
Key Length transform attribute)".
In Section 2.17, change the description of the keying material from
the list with two bullets to a clearer list.
In Section 2.23, added "Implementations MUST process received UDP-
encapsulated ESP packets even when no NAT was detected."
In Section 3.3, changed "Each proposal may contain a" to "Each
proposal contains a".
Added the asterisks to the tranform type table in Section 3.3.2 and
the types table in 3.3.3 to foreshadow future developments.
In Section 3.3.2, changed the following algorithms to (UNSPECIFIED)
because the RFCs listed didn't really specify how to implement them
in an interoperable fashion:
Encryption Algorithms
ENCR_DES_IV64 1 (RFC1827)
ENCR_3IDEA 8 (RFC2451)
ENCR_DES_IV32 9
Pseudo-random Functions
PRF_HMAC_TIGER 3 (RFC2104)
Integrity Algorithms
AUTH_DES_MAC 3
AUTH_KPDK_MD5 4 (RFC1826)
In Section 3.4, added "(other than NONE)" to the second-to-last
paragraph.
Rewrote the third paragraph of Section 3.14 to talk about other
modes, and to clarify which encryption and integrity protection we
are talking about.
Changed the "Initialization Vector" bullet in Section 3.14 to specify
better what is needed for the IV. Upgraded the SHOULDs to MUSTs.
Also added the reference for [MODES].
In Section 5, in the second-to-last paragraph, changed "a public-key-
based" to "strong" to match the wording in Section 2.16.
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 124, line 24 skipping to change at page 128, line 4
Email: charliek@microsoft.com Email: charliek@microsoft.com
Paul Hoffman Paul Hoffman
VPN Consortium VPN Consortium
127 Segre Place 127 Segre Place
Santa Cruz, CA 95060 Santa Cruz, CA 95060
US US
Phone: 1-831-426-9827 Phone: 1-831-426-9827
Email: paul.hoffman@vpnc.org Email: paul.hoffman@vpnc.org
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 Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 55 change blocks. 
180 lines changed or deleted 288 lines changed or added

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