< draft-ietf-ipsec-ikev2-12.txt   draft-ietf-ipsec-ikev2-13.txt >
INTERNET-DRAFT Charlie Kaufman, Editor INTERNET-DRAFT Charlie Kaufman, Editor
draft-ietf-ipsec-ikev2-12.txt draft-ietf-ipsec-ikev2-13.txt
Obsoletes: 2407, 2408, 2409 January 6, 2004 Obsoletes: 2407, 2408, 2409 March 22, 2004
Expires: July 2004 Expires: September 2004
Internet Key Exchange (IKEv2) Protocol Internet Key Exchange (IKEv2) Protocol
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. Internet-Drafts are working documents of of Section 10 of RFC2026. Internet-Drafts are working documents of
the Internet Engineering Task Force (IETF), its areas, and its the Internet Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also distribute working working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 34
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 document is a submission by the IPSEC Working Group of the This document is a submission by the IPSEC Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted Internet Engineering Task Force (IETF). Comments should be submitted
to the ipsec@lists.tislabs.com mailing list. to the ipsec@lists.tislabs.com mailing list.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This Internet-Draft expires in July 2004. This Internet-Draft expires in September 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
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 authentication and establishing and maintaining security
skipping to change at page 2, line 29 skipping to change at page 2, line 29
1.5 Informational Messages outside of an IKE_SA.............12 1.5 Informational Messages outside of an IKE_SA.............12
2 IKE Protocol Details and Variations.......................12 2 IKE Protocol Details and Variations.......................12
2.1 Use of Retransmission Timers............................12 2.1 Use of Retransmission Timers............................12
2.2 Use of Sequence Numbers for Message ID..................13 2.2 Use of Sequence Numbers for Message ID..................13
2.3 Window Size for overlapping requests....................13 2.3 Window Size for overlapping requests....................13
2.4 State Synchronization and Connection Timeouts...........14 2.4 State Synchronization and Connection Timeouts...........14
2.5 Version Numbers and Forward Compatibility...............16 2.5 Version Numbers and Forward Compatibility...............16
2.6 Cookies.................................................17 2.6 Cookies.................................................17
2.7 Cryptographic Algorithm Negotiation.....................19 2.7 Cryptographic Algorithm Negotiation.....................19
2.8 Rekeying................................................20 2.8 Rekeying................................................20
2.9 Traffic Selector Negotiation............................22 2.9 Traffic Selector Negotiation............................23
2.10 Nonces.................................................24 2.10 Nonces.................................................25
2.11 Address and Port Agility...............................25 2.11 Address and Port Agility...............................25
2.12 Reuse of Diffie-Hellman Exponentials...................25 2.12 Reuse of Diffie-Hellman Exponentials...................25
2.13 Generating Keying Material.............................26 2.13 Generating Keying Material.............................26
2.14 Generating Keying Material for the IKE_SA..............27 2.14 Generating Keying Material for the IKE_SA..............27
2.15 Authentication of the IKE_SA...........................28 2.15 Authentication of the IKE_SA...........................28
2.16 Extended Authentication Protocol Methods...............29 2.16 Extended Authentication Protocol Methods...............29
2.17 Generating Keying Material for CHILD_SAs...............31 2.17 Generating Keying Material for CHILD_SAs...............31
2.18 Rekeying IKE_SAs using a CREATE_CHILD_SA exchange......32 2.18 Rekeying IKE_SAs using a CREATE_CHILD_SA exchange......32
2.19 Requesting an internal address on a remote network.....32 2.19 Requesting an internal address on a remote network.....32
2.20 Requesting a Peer's Version............................33 2.20 Requesting a Peer's Version............................33
2.21 Error Handling.........................................34 2.21 Error Handling.........................................34
2.22 IPComp.................................................35 2.22 IPComp.................................................35
2.23 NAT Traversal..........................................36 2.23 NAT Traversal..........................................36
2.24 ECN (Explicit Congestion Notification).................38 2.24 ECN (Explicit Congestion Notification).................39
3 Header and Payload Formats................................39 3 Header and Payload Formats................................39
3.1 The IKE Header..........................................39 3.1 The IKE Header..........................................39
3.2 Generic Payload Header..................................42 3.2 Generic Payload Header..................................42
3.3 Security Association Payload............................43 3.3 Security Association Payload............................43
3.4 Key Exchange Payload....................................53 3.4 Key Exchange Payload....................................53
3.5 Identification Payloads.................................54 3.5 Identification Payloads.................................54
3.6 Certificate Payload.....................................56 3.6 Certificate Payload.....................................56
3.7 Certificate Request Payload.............................58 3.7 Certificate Request Payload.............................59
3.8 Authentication Payload..................................60 3.8 Authentication Payload..................................60
3.9 Nonce Payload...........................................61 3.9 Nonce Payload...........................................61
3.10 Notify Payload.........................................61 3.10 Notify Payload.........................................62
3.11 Delete Payload.........................................68 3.11 Delete Payload.........................................69
3.12 Vendor ID Payload......................................70 3.12 Vendor ID Payload......................................70
3.13 Traffic Selector Payload...............................71 3.13 Traffic Selector Payload...............................71
3.14 Encrypted Payload......................................73 3.14 Encrypted Payload......................................74
3.15 Configuration Payload..................................75 3.15 Configuration Payload..................................75
3.16 Extended Authentication Protocol (EAP) Payload.........80 3.16 Extended Authentication Protocol (EAP) Payload.........80
4 Conformance Requirements..................................82 4 Conformance Requirements..................................82
5 Security Considerations...................................84 5 Security Considerations...................................84
6 IANA Considerations.......................................86 6 IANA Considerations.......................................86
7 Intellectual property rights..............................86 7 Acknowledgements..........................................87
8 Acknowledgements..........................................86 8 References................................................87
9 References................................................87 8.1 Normative References....................................87
9.1 Normative References....................................87 8.2 Informative References..................................88
9.2 Informative References..................................88 Appendix A: Summary of Changes from IKEv1...................92
Appendix A: Summary of Changes from IKEv1...................91 Appendix B: Diffie-Hellman Groups...........................94
Appendix B: Diffie-Hellman Groups...........................93 Change History (To be removed from RFC).....................96
Change History (To be removed from RFC).....................95 Editor's Address...........................................104
Editor's Address...........................................102 Full Copyright Statement...................................104
Full Copyright Statement...................................102 Intellectual Property Statement............................104
Requirements Terminology Requirements Terminology
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
"MAY" that appear in this document are to be interpreted as described "MAY" that appear in this document are to be interpreted as described
in [Bra97]. in [Bra97].
The term "Expert Review" is to be interpreted as defined in
[RFC2434].
1 Introduction 1 Introduction
IP Security (IPsec) provides confidentiality, data integrity, access IP Security (IPsec) provides confidentiality, data integrity, access
control, and data source authentication to IP datagrams. These control, and data source authentication to IP datagrams. These
services are provided by maintaining shared state between the source services are provided by maintaining shared state between the source
and the sink of an IP datagram. This state defines, among other and the sink of an IP datagram. This state defines, among other
things, the specific services provided to the datagram, which things, the specific services provided to the datagram, which
cryptographic algorithms will be used to provide the services, and cryptographic algorithms will be used to provide the services, and
the keys used as input to the cryptographic algorithms. the keys used as input to the cryptographic algorithms.
skipping to change at page 27, line 26 skipping to change at page 27, line 32
The constant concatenated to the end of each string feeding the prf The constant concatenated to the end of each string feeding the prf
is a single octet. prf+ in this document is not defined beyond 255 is a single octet. prf+ in this document is not defined beyond 255
times the size of the prf output. times the size of the prf output.
2.14 Generating Keying Material for the IKE_SA 2.14 Generating Keying Material for the IKE_SA
The shared keys are computed as follows. A quantity called SKEYSEED The shared keys are computed as follows. A quantity called SKEYSEED
is calculated from the nonces exchanged during the IKE_SA_INIT is calculated from the nonces exchanged during the IKE_SA_INIT
exchange and the Diffie-Hellman shared secret established during that exchange and the Diffie-Hellman shared secret established during that
exchange. SKEYSEED is used to calculate five other secrets: SK_d exchange. SKEYSEED is used to calculate seven other secrets: SK_d
used for deriving new keys for the CHILD_SAs established with this used for deriving new keys for the CHILD_SAs established with this
IKE_SA; SK_ai and SK_ar used as a key to the integrity protection IKE_SA; SK_ai and SK_ar used as a key to the integrity protection
algorithm for authenticating the component messages of subsequent algorithm for authenticating the component messages of subsequent
exchanges; and SK_ei and SK_er used for encrypting (and of course exchanges; SK_ei and SK_er used for encrypting (and of course
decrypting) all subsequent exchanges. SKEYSEED and its derivatives decrypting) all subsequent exchanges; and SK_pi and SK_pr which are
are computed as follows: only used when authenticating with an EAP authentication mechanism
that does not generate a shared key.
SKEYSEED and its derivatives are computed as follows:
SKEYSEED = prf(Ni | Nr, g^ir) SKEYSEED = prf(Ni | Nr, g^ir)
{SK_d | SK_ai | SK_ar | SK_ei | SK_er} {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr }
= prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )
(indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, and SK_er (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er,
are taken in order from the generated bits of the prf+). g^ir is the SK_pi, and SK_pr are taken in order from the generated bits of the
shared secret from the ephemeral Diffie-Hellman exchange. g^ir is prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman
represented as a string of octets in big endian order padded with exchange. g^ir is represented as a string of octets in big endian
zeros if necessary to make it the length of the modulus. Ni and Nr order padded with zeros if necessary to make it the length of the
are the nonces, stripped of any headers. If the negotiated prf takes modulus. Ni and Nr are the nonces, stripped of any headers. If the
a fixed length key and the lengths of Ni and Nr do not add up to that negotiated prf takes a fixed length key and the lengths of Ni and Nr
length, half the bits must come from Ni and half from Nr, taking the do not add up to that length, half the bits must come from Ni and
first bits of each. half from Nr, taking the first bits of each.
The two directions of traffic flow use different keys. The keys used The two directions of traffic flow use different keys. The keys used
to protect messages from the original initiator are SK_ai and SK_ei. to protect messages from the original initiator are SK_ai and SK_ei.
The keys used to protect messages in the other direction are SK_ar The keys used to protect messages in the other direction are SK_ar
and SK_er. Each algorithm takes a fixed number of bits of keying and SK_er. Each algorithm takes a fixed number of bits of keying
material, which is specified as part of the algorithm. For integrity material, which is specified as part of the algorithm. For integrity
algorithms based on HMAC, the key size is always equal to the length algorithms based on a keyed hash, the key size is always equal to the
of the output of the underlying hash function. length of the output of the underlying hash function.
2.15 Authentication of the IKE_SA 2.15 Authentication of the IKE_SA
When not using extended authentication (see section 2.16), the peers When not using extended authentication (see section 2.16), the peers
are authenticated by having each sign (or MAC using a shared secret are authenticated by having each sign (or MAC using a shared secret
as the key) a block of data. For the responder, the octets to be as the key) a block of data. For the responder, the octets to be
signed start with the first octet of the first SPI in the header of signed start with the first octet of the first SPI in the header of
the second message and end with the last octet of the last payload in the second message and end with the last octet of the last payload in
the second message. Appended to this (for purposes of computing the the second message. Appended to this (for purposes of computing the
signature) are the initiator's nonce Ni (just the value, not the signature) are the initiator's nonce Ni (just the value, not the
skipping to change at page 30, line 24 skipping to change at page 30, line 35
HDR, SAi1, KEi, Ni --> HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ] <-- HDR, SAr1, KEr, Nr, [CERTREQ]
HDR, SK {IDi, [CERTREQ,] [IDr,] HDR, SK {IDi, [CERTREQ,] [IDr,]
SAi2, TSi, TSr} --> SAi2, TSi, TSr} -->
<-- HDR, SK {IDr, [CERT,] AUTH, <-- HDR, SK {IDr, [CERT,] AUTH,
EAP } EAP }
HDR, SK {EAP, AUTH} --> HDR, SK {EAP} -->
<-- HDR, SK {EAP, AUTH, <-- HDR, SK {EAP (success)}
SAr2, TSi, TSr }
HDR, SK {AUTH} -->
<-- HDR, SK {AUTH, SAr2, TSi, TSr }
For EAP methods that create a shared key as a side effect of For EAP methods that create a shared key as a side effect of
authentication, that shared key MUST be used by both the Initiator authentication, that shared key MUST be used by both the Initiator
and Responder to generate AUTH payloads in messages 5 and 6 using the and Responder to generate AUTH payloads in messages 5 and 6 using the
syntax for shared secrets specified in section 2.15. The shared key syntax for shared secrets specified in section 2.15. The shared key
generated during an IKE exchange MUST NOT be used for any other from EAP is the field from the EAP specification named MSK. The
purpose. shared key generated during an IKE exchange MUST NOT be used for any
other purpose.
EAP methods that do not establish a shared key SHOULD NOT be used, as EAP methods that do not establish a shared key SHOULD NOT be used, as
they are subject to a number of man-in-the-middle attacks [EAPMITM] they are subject to a number of man-in-the-middle attacks [EAPMITM]
if these EAP methods are used in other protocols that do not use a if these EAP methods are used in other protocols that do not use a
server-authenticated tunnel. Please see the Security Considerations server-authenticated tunnel. Please see the Security Considerations
section for more details. If EAP methods that do not generate a section for more details. If EAP methods that do not generate a
shared key are used, the AUTH payloads in messages 5 and 6 MUST be shared key are used, the AUTH payloads in messages 7 and 8 MUST be
generated using SK_ai and SK_ar respectively. generated using SK_pi and SK_pr respectively.
The Initiator of an IKE_SA using EAP SHOULD be capable of extending The Initiator of an IKE_SA using EAP SHOULD be capable of extending
the initial protocol exchange to at least ten IKE_AUTH exchanges in the initial protocol exchange to at least ten IKE_AUTH exchanges in
the event the Responder sends notification messages and/or retries the event the Responder sends notification messages and/or retries
the authentication prompt. The protocol terminates when the Responder the authentication prompt. The protocol terminates when the Responder
sends the Initiator an EAP payload containing either a success or sends the Initiator an EAP payload containing either a success or
failure type. In such an extended exchange, the EAP AUTH payloads failure type. In such an extended exchange, the EAP AUTH payloads
MUST be included in the first message each end sends after having MUST be included in the two messages following the one containing the
sufficient information to compute the key. This will usually be in EAP (success) message.
the last two messages of the exchange.
2.17 Generating Keying Material for CHILD_SAs 2.17 Generating Keying Material for CHILD_SAs
CHILD_SAs are created either by being piggybacked on the IKE_AUTH CHILD_SAs are created either by being piggybacked on the IKE_AUTH
exchange, or in a CREATE_CHILD_SA exchange. Keying material for them exchange, or in a CREATE_CHILD_SA exchange. Keying material for them
is generated as follows: is generated as follows:
KEYMAT = prf+(SK_d, Ni | Nr) KEYMAT = prf+(SK_d, Ni | Nr)
Where Ni and Nr are the Nonces from the IKE_SA_INIT exchange if this Where Ni and Nr are the Nonces from the IKE_SA_INIT exchange if this
skipping to change at page 38, line 5 skipping to change at page 38, line 15
of the original packet to match the address of the NAT box). In of the original packet to match the address of the NAT box). In
this case this end should allow dynamic update of the other ends this case this end should allow dynamic update of the other ends
IP address, as described later. IP address, as described later.
If the NAT_DETECTION_DESTINATION_IP payload received does not If the NAT_DETECTION_DESTINATION_IP payload received does not
match the hash of the destination IP and port found from the IP match the hash of the destination IP and port found from the IP
header of the packet containing the payload, it means that this header of the packet containing the payload, it means that this
end is behind NAT (i.e the original sender sent the packet to end is behind NAT (i.e the original sender sent the packet to
address of the NAT box, which then changed the destination address address of the NAT box, which then changed the destination address
to this host). In this case the this end should start sending to this host). In this case the this end should start sending
keepalive packets as explaind in [Hutt02]. keepalive packets as explained in [Hutt04].
The IKE initiator MUST check these payloads if present and if they The IKE initiator MUST check these payloads if present and if they
do not match the addresses in the outer packet MUST tunnel all do not match the addresses in the outer packet MUST tunnel all
future IKE, ESP, and AH packets associated with this IKE_SA over future IKE, ESP, and AH packets associated with this IKE_SA over
UDP port 4500. UDP port 4500.
To tunnel IKE packets over UDP port 4500, the IKE header has four 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
bytes of the ESP header contain the SPI, and the SPI cannot bytes 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.
The original source and destination IP address required for the The original source and destination IP address required for the
transport mode TCP and UDP packet checksum fixup (see [Hutt02]) transport mode TCP and UDP packet checksum fixup (see [Hutt04])
are obtained from the Traffic Selectors associated with the are obtained from the Traffic Selectors associated with the
exchange. In the case of NAT-T, the Traffic Selectors MUST contain exchange. In the case of NAT-T, the Traffic Selectors MUST contain
exactly one IP address which is then used as the original IP exactly one IP address which is then used as the original IP
address. address.
There are cases where a NAT box decides to remove mappings that 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 that or the NAT box is rebooted). To recover in these cases, hosts that
are not behind a NAT SHOULD send all packets (including are not behind a NAT SHOULD send all packets (including
retranmission packets) to the IP address and port from the last retranmission packets) to the IP address and port from the last
skipping to change at page 46, line 50 skipping to change at page 47, line 6
o Proposal # (1 octet) - When a proposal is made, the first o Proposal # (1 octet) - When a proposal is made, the first
proposal in an SA MUST be #1, and subsequent proposals proposal in an SA MUST be #1, and subsequent proposals
MUST either be the same as the previous proposal (indicating MUST either be the same as the previous proposal (indicating
an AND of the two proposals) or one more than the previous an AND of the two proposals) or one more than the previous
proposal (indicating an OR of the two proposals). When a proposal (indicating an OR of the two proposals). When a
proposal is accepted, all of the proposal numbers in the proposal is accepted, all of the proposal numbers in the
SA MUST be the same and MUST match the number on the SA MUST be the same and MUST match the number on the
proposal sent that was accepted. proposal sent that was accepted.
o Protocol ID (1 octet) - Specifies the IPsec protocol o Protocol ID (1 octet) - Specifies the IPsec protocol
identifier for the current negotiation. One (1) indicates identifier for the current negotiation. The defined values
IKE, two (2) indicates AH, and three (3) indicates ESP. are:
Protocol Protocol ID
RESERVED 0
IKE 1
AH 2
ESP 3
RESERVED TO IANA 4-200
PRIVATE USE 201-255
o SPI Size (1 octet) - For an initial IKE_SA negotiation, o SPI Size (1 octet) - For an initial IKE_SA negotiation,
this field MUST be zero; the SPI is obtained from the this field MUST be zero; the SPI is obtained from the
outer header. During subsequent negotiations, outer header. During subsequent negotiations,
it is equal to the size, in octets, of the SPI of the it is equal to the size, in octets, of the SPI of the
corresponding protocol (8 for IKE, 4 for ESP and AH). corresponding protocol (8 for IKE, 4 for ESP and AH).
o # of Transforms (1 octet) - Specifies the number of o # of Transforms (1 octet) - Specifies the number of
transforms in this proposal. transforms in this proposal.
skipping to change at page 48, line 25 skipping to change at page 48, line 38
Transform Type Values Transform Type Values
Transform Used In Transform Used In
Type Type
Encryption Algorithm 1 (IKE and ESP) Encryption Algorithm 1 (IKE and ESP)
Pseudo-random Function 2 (IKE) Pseudo-random Function 2 (IKE)
Integrity Algorithm 3 (IKE, AH, and optional in ESP) Integrity Algorithm 3 (IKE, AH, and optional in ESP)
Diffie-Hellman Group 4 (IKE and optional in AH and ESP) Diffie-Hellman Group 4 (IKE and optional in AH and ESP)
Extended Sequence Numbers 5 (Optional in AH and ESP) Extended Sequence Numbers 5 (Optional in AH and ESP)
RESERVED TO IANA 6-240
values 6-240 are reserved to IANA. Values 241-255 are for PRIVATE USE 241-255
private use among mutually consenting parties.
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 (RFC1827)
ENCR_DES 2 (RFC2405) ENCR_DES 2 (RFC2405)
ENCR_3DES 3 (RFC2451) ENCR_3DES 3 (RFC2451)
ENCR_RC5 4 (RFC2451) ENCR_RC5 4 (RFC2451)
skipping to change at page 67, line 46 skipping to change at page 68, line 4
This notification is used by its recipient to determine This notification is used by its recipient to determine
whether it is behind a NAT box. The data associated with whether it is behind a NAT box. The data associated with
this notification is a SHA-1 digest of the SPIs (in the this notification is a SHA-1 digest of the SPIs (in the
order they appear in the header), IP address and port to order they appear in the header), IP address and port to
which this packet was sent. The recipient of this which this packet was sent. The recipient of this
notification MAY compare the supplied value to a hash of the notification MAY compare the supplied value to a hash of the
SPIs, destination IP address and port and if they don't SPIs, destination IP address and port and if they don't
match it SHOULD invoke NAT traversal (see section 2.23). If match it SHOULD invoke NAT traversal (see section 2.23). If
they don't match, it means that this end is behind a NAT and they don't match, it means that this end is behind a NAT and
this end SHOULD start start sending keepalive packets as this end SHOULD start start sending keepalive packets as
defined in [Hutt02]. Alternately, it MAY reject the defined in [Hutt04]. Alternately, it MAY reject the
connection attempt if NAT traversal is not supported. connection attempt if NAT traversal is not supported.
COOKIE 16390 COOKIE 16390
This notification MAY be included in an IKE_SA_INIT This notification MAY be included in an IKE_SA_INIT
response. It indicates that the request should be retried response. It indicates that the request should be retried
with a copy of this notification as the first payload. This with a copy of this notification as the first payload. This
notification MUST be included in an IKE_SA_INIT request notification MUST be included in an IKE_SA_INIT request
retry if a COOKIE notification was included in the initial retry if a COOKIE notification was included in the initial
response. The data associated with this notification MUST response. The data associated with this notification MUST
skipping to change at page 68, line 42 skipping to change at page 68, line 49
URL (and hence presumably would prefer to receive URL (and hence presumably would prefer to receive
certificate specifications in that format). certificate specifications in that format).
REKEY_SA 16393 REKEY_SA 16393
This notification MUST be included in a CREATE_CHILD_SA This notification MUST be included in a CREATE_CHILD_SA
exchange if the purpose of the exchange is to replace an exchange if the purpose of the exchange is to replace an
existing ESP or AH SA. The SPI field identifies the SA being existing ESP or AH SA. The SPI field identifies the SA being
rekeyed. There is no data. rekeyed. There is no data.
RESERVED TO IANA - STATUS TYPES 16394 - 40959 ESP_TFC_PADDING_NOT_SUPPORTED 16394
This notification asserts that the sending endpoint will NOT
accept packets that contain Flow Confidentiality (TFC)
padding.
RESERVED TO IANA - STATUS TYPES 16395 - 40959
Private Use - STATUS TYPES 40960 - 65535 Private Use - STATUS TYPES 40960 - 65535
3.11 Delete Payload 3.11 Delete Payload
The Delete Payload, denoted D in this memo, contains a protocol The Delete Payload, denoted D in this memo, contains a protocol
specific security association identifier that the sender has removed specific security association identifier that the sender has removed
from its security association database and is, therefore, no longer from its security association database and is, therefore, no longer
valid. Figure 17 shows the format of the Delete Payload. It is valid. Figure 17 shows the format of the Delete Payload. It is
possible to send multiple SPIs in a Delete payload, however, each SPI possible to send multiple SPIs in a Delete payload, however, each SPI
skipping to change at page 72, line 41 skipping to change at page 73, line 10
o IP protocol ID (1 octet) - Value specifying an associated IP o IP protocol ID (1 octet) - Value specifying an associated IP
protocol ID (e.g., UDP/TCP/ICMP). A value of zero means that protocol ID (e.g., UDP/TCP/ICMP). A value of zero means that
the protocol ID is not relevant to this traffic selector-- the protocol ID is not relevant to this traffic selector--
the SA can carry all protocols. the SA can carry all protocols.
o Selector Length - Specifies the length of this Traffic o Selector Length - Specifies the length of this Traffic
Selector Substructure including the header. Selector Substructure including the header.
o Start Port (2 octets) - Value specifying the smallest port o Start Port (2 octets) - Value specifying the smallest port
number allowed by this Traffic Selector. For protocols for number allowed by this Traffic Selector. For protocols for
which port is undefined, or if all ports are allowed by which port is undefined, or if all ports are allowed or
this Traffic Selector, this field MUST be zero. For the port is OPAQUE, this field MUST be zero. For the
ICMP protocol, the two one octet fields Type and Code are ICMP protocol, the two one octet fields Type and Code are
treated as a single 16 bit integer port number for the treated as a single 16 bit integer (with Type in the most
purposes of filtering based on this field. significant eight bits and Code in the least significant
eight bits) port number for the purposes of filtering based
on this field.
o End Port (2 octets) - Value specifying the largest port o End Port (2 octets) - Value specifying the largest port
number allowed by this Traffic Selector. For protocols for number allowed by this Traffic Selector. For protocols for
which port is undefined, or if all ports are allowed by which port is undefined, or if all ports are allowed or
this Traffic Selector, this field MUST be 65535. For the port is OPAQUE, this field MUST be 65535. For the
ICMP protocol, the two one octet fields Type and Code are ICMP protocol, the two one octet fields Type and Code are
treated as a single 16 bit integer port number for the treated as a single 16 bit integer (with Type in the most
purposed of filtering based on this field. significant eight bits and Code in the least significant
eight bits) port number for the purposed of filtering based
on this field.
o Starting Address - The smallest address included in this o Starting Address - The smallest address included in this
Traffic Selector (length determined by TS type). Traffic Selector (length determined by TS type).
o Ending Address - The largest address included in this o Ending Address - The largest address included in this
Traffic Selector (length determined by TS type). Traffic Selector (length determined by TS type).
The following table lists the assigned values for the Traffic The following table lists the assigned values for the Traffic
Selector Type field and the corresponding Address Selector Data. Selector Type field and the corresponding Address Selector Data.
skipping to change at page 73, line 35 skipping to change at page 74, line 8
addresses are considered to be within the list. addresses are considered to be within the list.
TS_IPV6_ADDR_RANGE 8 TS_IPV6_ADDR_RANGE 8
A range of IPv6 addresses, represented by two sixteen (16) A range of IPv6 addresses, represented by two sixteen (16)
octet values. The first value is the beginning IPv6 address octet values. The first value is the beginning IPv6 address
(inclusive) and the second value is the ending IPv6 address (inclusive) and the second value is the ending IPv6 address
(inclusive). All addresses falling between the two specified (inclusive). All addresses falling between the two specified
addresses are considered to be within the list. addresses are considered to be within the list.
RESERVED TO IANA 9-240
PRIVATE USE 241-255
3.14 Encrypted Payload 3.14 Encrypted Payload
The Encrypted Payload, denoted SK{...} in this memo, contains other The Encrypted Payload, denoted SK{...} in this memo, contains other
payloads in encrypted form. The Encrypted Payload, if present in a payloads in encrypted form. The Encrypted Payload, if present in a
message, MUST be the last payload in the message. Often, it is the message, MUST be the last payload in the message. Often, it is the
only payload in the message. 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
sections 2.14 and 2.18. sections 2.14 and 2.18.
skipping to change at page 75, line 21 skipping to change at page 75, line 46
o Pad Length is the length of the Padding field. The sender o Pad Length is the length of the Padding field. The sender
SHOULD set the Pad Length to the minimum value that makes SHOULD set the Pad Length to the minimum value that makes
the combination of the Payloads, the Padding, and the Pad the combination of the Payloads, the Padding, and the Pad
Length a multiple of the block size, but the recipient MUST Length a multiple of the block size, but the recipient MUST
accept any length that results in proper alignment. This accept any length that results in proper alignment. This
field is encrypted with the negotiated cipher. field is encrypted with the negotiated cipher.
o Integrity Checksum Data is the cryptographic checksum of o Integrity Checksum Data is the cryptographic checksum of
the entire message starting with the Fixed IKE Header the entire message starting with the Fixed IKE Header
through the Pad Length. The checksum MUST be computed over through the Pad Length. The checksum MUST be computed over
the encrypted message. the encrypted message. Its length is determined by the
integrity algorithm negotiated.
3.15 Configuration Payload 3.15 Configuration Payload
The Configuration payload, denoted CP in this document, is used to The Configuration payload, denoted CP in this document, is used to
exchange configuration information between IKE peers. Currently, the exchange configuration information between IKE peers. The exchange is
only defined uses for this exchange is for an IRAC to request an for an IRAC to request an internal IP address from an IRAS and to
internal IP address from an IRAS or for either party to request exchange other information of the sort that one would acquire with
version information from the other, but this payload is intended as a DHCP if the IRAC were directly connected to a LAN.
likely place for future extensions.
Configuration payloads are of type CFG_REQUEST/CFG_REPLY or Configuration payloads are of type CFG_REQUEST/CFG_REPLY or
CFG_SET/CFG_ACK (see CFG Type in the payload description below). CFG_SET/CFG_ACK (see CFG Type in the payload description below).
CFG_REQUEST and CFG_SET payloads may optionally be added to any IKE CFG_REQUEST and CFG_SET payloads may optionally be added to any IKE
request. The IKE response MUST include either a corresponding request. The IKE response MUST include either a corresponding
CFG_REPLY or CFG_ACK or a Notify payload with an error type CFG_REPLY or CFG_ACK or a Notify payload with an error type
indicating why the request could not be honored. An exception is that indicating why the request could not be honored. An exception is that
a minimal implementation MAY ignore all CFG_REQUEST and CFG_SET a minimal implementation MAY ignore all CFG_REQUEST and CFG_SET
payloads, so a response message without a corresponding CFG_REPLY or payloads, so a response message without a corresponding CFG_REPLY or
CFG_ACK MUST be accepted as an indication that the request was not CFG_ACK MUST be accepted as an indication that the request was not
skipping to change at page 86, line 17 skipping to change at page 86, line 32
An implementation using EAP MUST also use a public key based An implementation using EAP MUST also use a public key based
authentication of the server to the client before the EAP exchange authentication of the server to the client before the EAP exchange
begins, even if the EAP method offers mutual authentication. This begins, even if the EAP method offers mutual authentication. This
avoids having additional IKEv2 protocol variations and protects the avoids having additional IKEv2 protocol variations and protects the
EAP data from active attackers. EAP data from active attackers.
6 IANA Considerations 6 IANA Considerations
This document defines a number of new field types and values where This document defines a number of new field types and values where
future assignments will be managed by the IANA. The initial IANA future assignments will be managed by the IANA.
registry values are documented in [IKEv2IANA].
7 Intellectual Property Rights The following registries should be created:
The IETF takes no position regarding the validity or scope of any IKEv2 Exchange Types
intellectual property or other rights that might be claimed to IKEv2 Payload Types
pertain to the implementation or use of the technology described in IKEv2 Transform Types
this document or the extent to which any license under such rights IKEv2 Transform Attribute Types
might or might not be available; neither does it represent that it IKEv2 Encryption Transform IDs
has made any effort to identify any such rights. Information on the IKEv2 Pseudo-ramdom Function Transform IDs
IETF's procedures with respect to rights in standards-track and IKEv2 Integrity Algorithm Transform IDs
standards-related documentation can be found in BCP-11. Copies of IKEv2 Diffie-Hellman, ECP and EC2N Transform IDs
claims of rights made available for publication and any assurances of IKEv2 Identification Payload ID Types
licenses to be made available, or the result of an attempt made to IKEv2 Certification Encodings
obtain a general license or permission for the use of such IKEv2 Authentication Method
proprietary rights by implementors or users of this specification can IKEv2 Notification Payload Types
be obtained from the IETF Secretariat. IKEv2 Notification IPCOMP Transform IDs
IKEv2 Security Protocol Identfiers
IKEv2 Traffic Selector Types
IKEv2 Configuration Payload CFG Types
IKEv2 Configuration Payload Attribute Types
The IETF encourages any interested party to bring to its attention Note: when creating a new Transform Type, a new registry for it must
any copyrights, patents, or patent applications, or other proprietary be created.
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
The IETF has been notified of intellectual property rights claimed in New allocations to any of those registries may be allocated by expert
regard to some or all of the specification contained in this review.
document. For more information consult the online list of claimed
rights.
8 Acknowledgements 7 Acknowledgements
This document is a collaborative effort of the entire IPsec WG. If This document is a collaborative effort of the entire IPsec WG. If
there were no limit to the number of authors that could appear on an there were no limit to the number of authors that could appear on an
RFC, the following, in alphabetical order, would have been listed: RFC, the following, in alphabetical order, would have been listed:
Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt
Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, J. Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, J.
Ioannidis, Steve Kent, Angelos Keromytis, Tero Kivinen, Hugo Ioannidis, Steve Kent, Angelos Keromytis, Tero Kivinen, Hugo
Krawczyk, Andrew Krywaniuk, Radia Perlman, O. Reingold. Many other Krawczyk, Andrew Krywaniuk, Radia Perlman, O. Reingold, Michael
people contributed to the design. It is an evolution of IKEv1, Richardson. Many other people contributed to the design. It is an
ISAKMP, and the IPsec DOI, each of which has its own list of authors. evolution of IKEv1, ISAKMP, and the IPsec DOI, each of which has its
Hugh Daniel suggested the feature of having the initiator, in message own list of authors. Hugh Daniel suggested the feature of having the
3, specify a name for the responder, and gave the feature the cute initiator, in message 3, specify a name for the responder, and gave
name "You Tarzan, Me Jane". David Faucher and Valery Smyzlov helped the feature the cute name "You Tarzan, Me Jane". David Faucher and
refine the design of the traffic selector negotiation. Valery Smyzlov helped refine the design of the traffic selector
negotiation.
9 References 8 References
9.1 Normative References 8.1 Normative References
[ADDGROUP] Kivinen, T., and Kojo, M., "More Modular Exponential [ADDGROUP] Kivinen, T., and Kojo, M., "More Modular Exponential
(MODP) Diffie-Hellman groups for Internet Key (MODP) Diffie-Hellman groups for Internet Key
Exchange (IKE)", RFC 3526, May 2003. Exchange (IKE)", RFC 3526, May 2003.
[ADDRIPV6] Hinden, R., and Deering, S., [ADDRIPV6] Hinden, R., and Deering, S.,
"Internet Protocol Version 6 (IPv6) Addressing "Internet Protocol Version 6 (IPv6) Addressing
Architecture", RFC 3513, April 2003. Architecture", RFC 3513, April 2003.
[Bra97] Bradner, S., "Key Words for use in RFCs to indicate [Bra97] Bradner, S., "Key Words for use in RFCs to indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[EAP] Blunk, L. and Vollbrecht, J., "PPP Extensible [EAP] Blunk, L. and Vollbrecht, J., "PPP Extensible
Authentication Protocol (EAP), RFC 2284, March 1998. Authentication Protocol (EAP), RFC 2284, March 1998.
[ESPCBC] Pereira, R., Adams, R., "The ESP CBC-Mode Cipher [ESPCBC] Pereira, R., Adams, R., "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, November 1998. Algorithms", RFC 2451, November 1998.
[Hutt04] Huttunen, A. et. al., "UDP Encapsulation of IPsec
Packets", draft-ietf-ipsec-udp-encaps-08.txt, February
2004, work in progress.
[RFC2401bis] Kent, S. and Atkinson, R., "Security Architecture [RFC2401bis] Kent, S. and Atkinson, R., "Security Architecture
for the Internet Protocol", un-issued Internet for the Internet Protocol", un-issued Internet
Draft, work in progress. Draft, work in progress.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3168] Ramakrishnan, K., Floyd, S., and Black, D., [RFC3168] Ramakrishnan, K., Floyd, S., and Black, D.,
"The Addition of Explicit Congestion Notification (ECN) "The Addition of Explicit Congestion Notification (ECN)
to IP", RFC 3168, September 2001. to IP", RFC 3168, September 2001.
[RFC3280] Housley, R., Polk, W., Ford, W., Solo, D., "Internet [RFC3280] Housley, R., Polk, W., Ford, W., Solo, D., "Internet
X.509 Public Key Infrastructure Certificate and X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280, Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002. April 2002.
9.2 Informative References [RFC3667] Bradner, S., "IETF Rights in Submissions", BCP 78,
RFC 3667, February 2004.
[RFC3668] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.
8.2 Informative References
[DES] ANSI X3.106, "American National Standard for Information [DES] ANSI X3.106, "American National Standard for Information
Systems-Data Link Encryption", American National Standards Systems-Data Link Encryption", American National Standards
Institute, 1983. Institute, 1983.
[DH] Diffie, W., and Hellman M., "New Directions in [DH] Diffie, W., and Hellman M., "New Directions in
Cryptography", IEEE Transactions on Information Theory, V. Cryptography", IEEE Transactions on Information Theory, V.
IT-22, n. 6, June 1977. IT-22, n. 6, June 1977.
[DHCP] R. Droms, "Dynamic Host Configuration Protocol", [DHCP] R. Droms, "Dynamic Host Configuration Protocol",
skipping to change at page 88, line 29 skipping to change at page 89, line 5
Institute of Standards and Technology, U.S. Department of Institute of Standards and Technology, U.S. Department of
Commerce, May, 1994. Commerce, May, 1994.
[EAPMITM] Asokan, N., Nierni, V., and Nyberg, K., "Man-in-the-Middle [EAPMITM] Asokan, N., Nierni, V., and Nyberg, K., "Man-in-the-Middle
in Tunneled Authentication Protocols", in Tunneled Authentication Protocols",
http://eprint.iacr.org/2002/163, November 2002. http://eprint.iacr.org/2002/163, November 2002.
[HC98] Harkins, D., Carrel, D., "The Internet Key Exchange [HC98] Harkins, D., Carrel, D., "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (IKE)", RFC 2409, November 1998.
[Hutt02] Huttunen, A. et. al., "UDP Encapsulation of IPsec
Packets", draft-ietf-ipsec-udp-encaps-05.txt, December
2002.
[IDEA] Lai, X., "On the Design and Security of Block Ciphers," [IDEA] Lai, X., "On the Design and Security of Block Ciphers,"
ETH Series in Information Processing, v. 1, Konstanz: ETH Series in Information Processing, v. 1, Konstanz:
Hartung-Gorre Verlag, 1992 Hartung-Gorre Verlag, 1992
[IKEv2IANA]Richardson, M., "Initial IANA registry contents", [IKEv2IANA]Richardson, M., "Initial IANA registry contents",
draft-ietf-ipsec-ikev2-iana-00.txt, work in progress. draft-ietf-ipsec-ikev2-iana-00.txt, work in progress.
[IPCOMP] Shacham, A., Monsour, R., Pereira, R., and Thomas, M., "IP [IPCOMP] Shacham, A., Monsour, R., Pereira, R., and Thomas, M., "IP
Payload Compression Protocol (IPComp)", RFC 3173, Payload Compression Protocol (IPComp)", RFC 3173,
September 2001. September 2001.
skipping to change at page 90, line 8 skipping to change at page 90, line 29
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and Weiss, W., "An Architecture for Differentiated and Weiss, W., "An Architecture for Differentiated
Services", RFC 2475, December 1998. Services", RFC 2475, December 1998.
[RFC2522] Karn, P., and Simpson, W., "Photuris: Session-Key [RFC2522] Karn, P., and Simpson, W., "Photuris: Session-Key
Management Protocol", RFC 2522, March 1999. Management Protocol", RFC 2522, March 1999.
[RFC2983] Black, D., "Differentiated Services and Tunnels", [RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, October 2000. RFC 2983, October 2000.
[RFC3715] Aboba, B and Dixon, W., "IPsec-Network Address
Translation (NAT) Compatibility Requirements",
RFC 3715, March 2004.
[RSA] Rivest, R., Shamir, A., and Adleman, L., "A Method for [RSA] Rivest, R., Shamir, A., and Adleman, L., "A Method for
Obtaining Digital Signatures and Public-Key Obtaining Digital Signatures and Public-Key
Cryptosystems", Communications of the ACM, v. 21, n. 2, Cryptosystems", Communications of the ACM, v. 21, n. 2,
February 1978. February 1978.
[SHA] NIST, "Secure Hash Standard", FIPS 180-1, National [SHA] NIST, "Secure Hash Standard", FIPS 180-1, National
Institute of Standards and Technology, U.S. Department Institute of Standards and Technology, U.S. Department
of Commerce, May 1994. of Commerce, May 1994.
[SIGMA] Krawczyk, H., "SIGMA: the `SIGn-and-MAc' Approach to [SIGMA] Krawczyk, H., "SIGMA: the `SIGn-and-MAc' Approach to
skipping to change at page 102, line 5 skipping to change at page 102, line 25
11) 41 Editorial Corrections and Clarifications. 11) 41 Editorial Corrections and Clarifications.
12) 6 Grammatical and Spelling errors fixed. 12) 6 Grammatical and Spelling errors fixed.
13) 4 Corrected capitalizations of MAY/MUST/etc. 13) 4 Corrected capitalizations of MAY/MUST/etc.
14) 4 Attempts to make capitalization and use of underscores more 14) 4 Attempts to make capitalization and use of underscores more
consistent. consistent.
H.12 Changes from IKEv2-12 to IKEv2-13 March 2004
1) Updated copyright and intellectual property right sections per RFC
3667. Added normative references to RFC 3667 and RFC 3668.
2) Updated IANA Considerations section and adjusted some assignment
tables to be consistent with the IANA registries document. Added
Michael Richardson to the acknowledgements.
3) Changed the cryptographic formula for computing the AUTH payload
in the case where EAP authentication is used and the EAP algorithm
does not produce a shared key. Clarified the case where it does
produce a shared key.
4) Extended the EAP authentication protocol by two messages so that
the AUTH message is always sent after the success status is received.
5) Updated reference to ESP encapsulation in UDP and made it
normative.
6) Added notification type ESP_TFC_PADDING_NOT_SUPPORTED.
7) Clarified encoding of port number fields in transport selectors in
the cases of ICMP and OPAQUE.
8) Clarified that the length of the integrity checksum is fixed
length and determined by the negotiated integrity algorithm.
9) Added an informative reference to RFC3715 (NAT Compatibility
Requirements).
10) Fixed 2 typos.
Editor's Address Editor's Address
Charlie Kaufman Charlie Kaufman
Microsoft Corporation Microsoft Corporation
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
1-425-707-3335 1-425-707-3335
charliek@microsoft.com charliek@microsoft.com
Full Copyright Statement Full Copyright Statement
"Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). 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 translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Intellectual Property Statement
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an The IETF takes no position regarding the validity or scope of any
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING Intellectual Property Rights or other rights that might be claimed to
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING pertain to the implementation or use of the technology described in
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION this document or the extent to which any license under such rights
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF might or might not be available; nor does it represent that it has
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 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.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
Expiration Expiration
This Internet-Draft (draft-ietf-ipsec-ikev2-12.txt) expires in July This Internet-Draft (draft-ietf-ipsec-ikev2-13.txt) expires in
2004. September 2004.
 End of changes. 54 change blocks. 
134 lines changed or deleted 217 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/