< draft-ietf-ipsec-ikev2-13.txt   draft-ietf-ipsec-ikev2-14.txt >
INTERNET-DRAFT Charlie Kaufman, Editor INTERNET-DRAFT Charlie Kaufman, Editor
draft-ietf-ipsec-ikev2-13.txt draft-ietf-ipsec-ikev2-14.txt
Obsoletes: 2407, 2408, 2409 March 22, 2004 Obsoletes: 2407, 2408, 2409 May 29, 2004
Expires: September 2004 Expires: November 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 34 skipping to change at page 1, line 35
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 September 2004. This Internet-Draft expires in November 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 40 skipping to change at page 2, line 40
2.10 Nonces.................................................25 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............................34
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).................39 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............................44
3.4 Key Exchange Payload....................................53 3.4 Key Exchange Payload....................................54
3.5 Identification Payloads.................................54 3.5 Identification Payloads.................................55
3.6 Certificate Payload.....................................56 3.6 Certificate Payload.....................................57
3.7 Certificate Request Payload.............................59 3.7 Certificate Request Payload.............................59
3.8 Authentication Payload..................................60 3.8 Authentication Payload..................................61
3.9 Nonce Payload...........................................61 3.9 Nonce Payload...........................................62
3.10 Notify Payload.........................................62 3.10 Notify Payload.........................................62
3.11 Delete Payload.........................................69 3.11 Delete Payload.........................................70
3.12 Vendor ID Payload......................................70 3.12 Vendor ID Payload......................................71
3.13 Traffic Selector Payload...............................71 3.13 Traffic Selector Payload...............................72
3.14 Encrypted Payload......................................74 3.14 Encrypted Payload......................................75
3.15 Configuration Payload..................................75 3.15 Configuration Payload..................................76
3.16 Extended Authentication Protocol (EAP) Payload.........80 3.16 Extended Authentication Protocol (EAP) Payload.........81
4 Conformance Requirements..................................82 4 Conformance Requirements..................................83
5 Security Considerations...................................84 5 Security Considerations...................................85
6 IANA Considerations.......................................86 6 IANA Considerations.......................................87
7 Acknowledgements..........................................87 7 Acknowledgements..........................................88
8 References................................................87 8 References................................................88
8.1 Normative References....................................87 8.1 Normative References....................................88
8.2 Informative References..................................88 8.2 Informative References..................................89
Appendix A: Summary of Changes from IKEv1...................92 Appendix A: Summary of Changes from IKEv1...................93
Appendix B: Diffie-Hellman Groups...........................94 Appendix B: Diffie-Hellman Groups...........................95
Change History (To be removed from RFC).....................96 Change History (To be removed from RFC).....................97
Editor's Address...........................................104 Editor's Address...........................................105
Full Copyright Statement...................................104 Full Copyright Statement...................................105
Intellectual Property Statement............................104 Intellectual Property Statement............................105
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 The term "Expert Review" is to be interpreted as defined in
[RFC2434]. [RFC2434].
skipping to change at page 5, line 43 skipping to change at page 5, line 43
IPsec, but network nodes between them protect traffic for part of the IPsec, but network nodes between them protect traffic for part of the
way. Protection is transparent to the endpoints, and depends on way. Protection is transparent to the endpoints, and depends on
ordinary routing to send packets through the tunnel endpoints for ordinary routing to send packets through the tunnel endpoints for
processing. Each endpoint would announce the set of addresses processing. Each endpoint would announce the set of addresses
"behind" it, and packets would be sent in Tunnel Mode where the inner "behind" it, and packets would be sent in Tunnel Mode where the inner
IP header would contain the IP addresses of the actual endpoints. IP header would contain the IP addresses of the actual endpoints.
1.1.2 Endpoint to Endpoint Transport 1.1.2 Endpoint to Endpoint Transport
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
! ! IPsec ! ! ! ! IPsec Transport ! !
!Protected! Tunnel !Protected! !Protected! or Tunnel Mode SA !Protected!
!Endpoint !<---------------------------------------->!Endpoint ! !Endpoint !<---------------------------------------->!Endpoint !
! ! ! ! ! ! ! !
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
Figure 2: Endpoint to Endpoint Figure 2: Endpoint to Endpoint
In this scenario, both endpoints of the IP connection implement In this scenario, both endpoints of the IP connection implement
IPsec. These endpoints may implement application layer access IPsec, as required of hosts in [RFC2401bis]. Transport mode will
controls based on the authenticated identities of the participants. commonly be used with no inner IP header. If there is an inner IP
Transport mode will commonly be used with no inner IP header. If header, the inner addresses will be the same as the outer addresses.
there is an inner IP header, the inner addresses will be the same as A single pair of addresses will be negotiated for packets to be
the outer addresses. A single pair of addresses will be negotiated protected by this SA. These endpoints MAY implement application layer
for packets to be protected by this SA. access controls based on the IPsec authenticated identities of the
participants. This scenario enables the end-to-end security that has
been a guiding principle for the Internet since [RFC1958], [RFC2775],
and a method of limiting the inherent problems with complexity in
networks noted by [RFC3439]. While this scenario may not be fully
applicable to the IPv4 Internet, it has been deployed successfully in
specific scenarios within intranets using IKEv1. It should be more
broadly enabled during the transition to IPv6 and with the adoption
of IKEv2.
It is possible in this scenario that one or both of the protected It is possible in this scenario that one or both of the protected
endpoints will be behind a network address translation (NAT) node, in endpoints will be behind a network address translation (NAT) node, in
which case the tunnelled packets will have to be UDP encapsulated so which case the tunneled packets will have to be UDP encapsulated so
that port numbers in the UDP headers can be used to identify that port numbers in the UDP headers can be used to identify
individual endpoints "behind" the NAT (see section 2.23). individual endpoints "behind" the NAT (see section 2.23).
1.1.3 Endpoint to Security Gateway Transport 1.1.3 Endpoint to Security Gateway Transport
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
! ! IPsec ! ! Protected ! ! IPsec ! ! Protected
!Protected! Tunnel !Tunnel ! Subnet !Protected! Tunnel !Tunnel ! Subnet
!Endpoint !<------------------------>!Endpoint !<--- and/or !Endpoint !<------------------------>!Endpoint !<--- and/or
! ! ! ! Internet ! ! ! ! Internet
skipping to change at page 6, line 35 skipping to change at page 6, line 43
Figure 3: Endpoint to Security Gateway Tunnel Figure 3: Endpoint to Security Gateway Tunnel
In this scenario, a protected endpoint (typically a portable roaming In this scenario, a protected endpoint (typically a portable roaming
computer) connects back to its corporate network through an IPsec computer) connects back to its corporate network through an IPsec
protected tunnel. It might use this tunnel only to access information protected tunnel. It might use this tunnel only to access information
on the corporate network or it might tunnel all of its traffic back on the corporate network or it might tunnel all of its traffic back
through the corporate network in order to take advantage of through the corporate network in order to take advantage of
protection provided by a corporate firewall against Internet based protection provided by a corporate firewall against Internet based
attacks. In either case, the protected endpoint will want an IP attacks. In either case, the protected endpoint will want an IP
address associated with the security gateway so that packets returned address associated with the security gateway so that packets returned
to it will go to the security gateway and be tunnelled back. This IP to it will go to the security gateway and be tunneled back. This IP
address may be static or may be dynamically allocated by the security address may be static or may be dynamically allocated by the security
gateway. In support of the latter case, IKEv2 includes a mechanism gateway. In support of the latter case, IKEv2 includes a mechanism
for the initiator to request an IP address owned by the security for the initiator to request an IP address owned by the security
gateway for use for the duration of its SA. gateway for use for the duration of its SA.
In this scenario, packets will use tunnel mode. On each packet from In this scenario, packets will use tunnel mode. On each packet from
the protected endpoint, the outer IP header will contain the source the protected endpoint, the outer IP header will contain the source
IP address associated with its current location (i.e., the address IP address associated with its current location (i.e., the address
that will get traffic routed to the endpoint directly) while the that will get traffic routed to the endpoint directly) while the
inner IP header will contain the source IP address assigned by the inner IP header will contain the source IP address assigned by the
skipping to change at page 10, line 10 skipping to change at page 10, line 18
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR, SK {[N], SA, Ni, [KEi], HDR, SK {[N], SA, Ni, [KEi],
[TSi, TSr]} --> [TSi, TSr]} -->
The initiator sends SA offer(s) in the SA payload, a nonce in the Ni The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
payload, optionally a Diffie-Hellman value in the KEi payload, and payload, optionally a Diffie-Hellman value in the KEi payload, and
the proposed traffic selectors in the TSi and TSr payloads. If this the proposed traffic selectors in the TSi and TSr payloads. If this
CREATE_CHILD_SA exchange is rekeying an existing SA other than the CREATE_CHILD_SA exchange is rekeying an existing SA other than the
IKE_SA, the leading N payload of type REKEY_SA MUST identify the SA IKE_SA, the leading N payload of type REKEY_SA MUST identify the SA
being rekeyed. If this CREATE_CHILD_SA exchange is not rekeying and being rekeyed. If this CREATE_CHILD_SA exchange is not rekeying an
existing SA, the N payload MUST be omitted. If the SA offers include existing SA, the N payload MUST be omitted. If the SA offers include
different Diffie-Hellman groups, KEi MUST be an element of the group different Diffie-Hellman groups, KEi MUST be an element of the group
the initiator expects the responder to accept. If it guesses wrong, the initiator expects the responder to accept. If it guesses wrong,
the CREATE_CHILD_SA exchange will fail and it will have to retry with the CREATE_CHILD_SA exchange will fail and it will have to retry with
a different KEi. a different KEi.
The message following the header is encrypted and the message The message following the header is encrypted and the message
including the header is integrity protected using the cryptographic including the header is integrity protected using the cryptographic
algorithms negotiated for the IKE_SA. algorithms negotiated for the IKE_SA.
skipping to change at page 12, line 40 skipping to change at page 12, line 49
the absence of those minimum performance requirements, IKE is the absence of those minimum performance requirements, IKE is
designed to fail cleanly (as though the network were broken). designed to fail cleanly (as though the network were broken).
2.1 Use of Retransmission Timers 2.1 Use of Retransmission Timers
All messages in IKE exist in pairs: a request and a response. The All messages in IKE exist in pairs: a request and a response. The
setup of an IKE_SA normally consists of two request/response pairs. setup of an IKE_SA normally consists of two request/response pairs.
Once the IKE_SA is set up, either end of the security association may Once the IKE_SA is set up, either end of the security association may
initiate requests at any time, and there can be many requests and initiate requests at any time, and there can be many requests and
responses "in flight" at any given moment. But each message is responses "in flight" at any given moment. But each message is
labelled as either a request or a response and for each labeled as either a request or a response and for each
request/response pair one end of the security association is the request/response pair one end of the security association is the
Initiator and the other is the Responder. Initiator and the other is the Responder.
For every pair of IKE messages, the Initiator is responsible for For every pair of IKE messages, the Initiator is responsible for
retransmission in the event of a timeout. The Responder MUST never retransmission in the event of a timeout. The Responder MUST never
retransmit a response unless it receives a retransmission of the retransmit a response unless it receives a retransmission of the
request. In that event, the Responder MUST ignore the retransmitted request. In that event, the Responder MUST ignore the retransmitted
request except insofar as it triggers a retransmission of the request except insofar as it triggers a retransmission of the
response. The Initiator MUST remember each request until it receives response. The Initiator MUST remember each request until it receives
the corresponding response. The Responder MUST remember each response the corresponding response. The Responder MUST remember each response
skipping to change at page 17, line 36 skipping to change at page 17, line 45
While new payload types may be added in the future and may appear While new payload types may be added in the future and may appear
interleaved with the fields defined in this specification, interleaved with the fields defined in this specification,
implementations MUST send the payloads defined in this specification implementations MUST send the payloads defined in this specification
in the order shown in the figures in section 2 and implementations in the order shown in the figures in section 2 and implementations
SHOULD reject as invalid a message with those payloads in any other SHOULD reject as invalid a message with those payloads in any other
order. order.
2.6 Cookies 2.6 Cookies
The term "cookies" originates with Karn and Simpson [RFC 2522] in The term "cookies" originates with Karn and Simpson [RFC2522] in
Photuris, an early proposal for key management with IPsec, and it has Photuris, an early proposal for key management with IPsec, and it has
persisted. The ISAKMP fixed message header includes two eight octet persisted. The ISAKMP fixed message header includes two eight octet
fields titled "cookies", and that syntax is used by both IKEv1 and fields titled "cookies", and that syntax is used by both IKEv1 and
IKEv2 though in IKEv2 they are referred to as the IKE SPI and there IKEv2 though in IKEv2 they are referred to as the IKE SPI and there
is a new separate field in a Notify payload holding the cookie. The is a new separate field in a Notify payload holding the cookie. The
initial two eight octet fields in the header are used as a connection initial two eight octet fields in the header are used as a connection
identifier at the beginning of IKE packets. Each endpoint chooses one identifier at the beginning of IKE packets. Each endpoint chooses one
of the two SPIs and SHOULD choose them so as to be unique identifiers of the two SPIs and SHOULD choose them so as to be unique identifiers
of an IKE_SA. An SPI value of zero is special and indicates that the of an IKE_SA. An SPI value of zero is special and indicates that the
remote SPI value is not yet known by the sender. remote SPI value is not yet known by the sender.
skipping to change at page 22, line 10 skipping to change at page 22, line 17
This form of rekeying may temporarily result in multiple similar SAs This form of rekeying may temporarily result in multiple similar SAs
between the same pairs of nodes. When there are two SAs eligible to between the same pairs of nodes. When there are two SAs eligible to
receive packets, a node MUST accept incoming packets through either receive packets, a node MUST accept incoming packets through either
SA. If redundant SAs are created though such a collision, the SA SA. If redundant SAs are created though such a collision, the SA
created with the lowest of the four nonces used in the two exchanges created with the lowest of the four nonces used in the two exchanges
SHOULD be closed by the endpoint that created it. SHOULD be closed by the endpoint that created it.
Note that IKEv2 deliberately allows parallel SAs with the same Note that IKEv2 deliberately allows parallel SAs with the same
traffic selectors between common endpoints. One of the purposes of traffic selectors between common endpoints. One of the purposes of
this is to support traffic QoS differences among the SAs (see section this is to support traffic QoS differences among the SAs (see section
4.1 of [RFC 2983]). Hence unlike IKEv1, the combination of the 4.1 of [RFC2983]). Hence unlike IKEv1, the combination of the
endpoints and the traffic selectors may not uniquely identify an SA endpoints and the traffic selectors may not uniquely identify an SA
between those endpoints, so the IKEv1 rekeying heuristic of deleting between those endpoints, so the IKEv1 rekeying heuristic of deleting
SAs on the basis of duplicate traffic selectors SHOULD NOT be used. SAs on the basis of duplicate traffic selectors SHOULD NOT be used.
The node that initiated the surviving rekeyed SA SHOULD delete the The node that initiated the surviving rekeyed SA SHOULD delete the
replaced SA after the new one is established. replaced SA after the new one is established.
There are timing windows - particularly in the presence of lost There are timing windows - particularly in the presence of lost
packets - where endpoints may not agree on the state of an SA. The packets - where endpoints may not agree on the state of an SA. The
responder to a CREATE_CHILD_SA MUST be prepared to accept messages on responder to a CREATE_CHILD_SA MUST be prepared to accept messages on
skipping to change at page 27, line 38 skipping to change at page 27, line 42
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 seven 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; 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; and SK_pi and SK_pr which are decrypting) all subsequent exchanges; and SK_pi and SK_pr which are
only used when authenticating with an EAP authentication mechanism used when generating an AUTH payload.
that does not generate a shared key.
SKEYSEED and its derivatives are computed as follows: 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_pi | SK_pr } {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, SK_er, (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er,
SK_pi, and SK_pr are taken in order from the generated bits of the SK_pi, and SK_pr are taken in order from the generated bits of the
skipping to change at page 28, line 27 skipping to change at page 28, line 29
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
payload containing it), and the value prf(SK_ar,IDr') where IDr' is payload containing it), and the value prf(SK_pr,IDr') where IDr' is
the responder's ID payload excluding the fixed header. Note that the responder's ID payload excluding the fixed header. Note that
neither the nonce Ni nor the value prf(SK_ar,IDr') are transmitted. neither the nonce Ni nor the value prf(SK_pr,IDr') are transmitted.
Similarly, the initiator signs the first message, starting with the Similarly, the initiator signs the first message, starting with the
first octet of the first SPI in the header and ending with the last first octet of the first SPI in the header and ending with the last
octet of the last payload. Appended to this (for purposes of octet of the last payload. Appended to this (for purposes of
computing the signature) are the responder's nonce Nr, and the value computing the signature) are the responder's nonce Nr, and the value
prf(SK_ai,IDi'). In the above calculation, IDi' and IDr' are the prf(SK_pi,IDi'). In the above calculation, IDi' and IDr' are the
entire ID payloads excluding the fixed header. It is critical to the entire ID payloads excluding the fixed header. It is critical to the
security of the exchange that each side sign the other side's nonce. security of the exchange that each side sign the other side's nonce.
Note that all of the payloads are included under the signature, Note that all of the payloads are included under the signature,
including any payload types not defined in this document. If the including any payload types not defined in this document. If the
first message of the exchange is sent twice (the second time with a first message of the exchange is sent twice (the second time with a
responder cookie and/or a different Diffie-Hellman group), it is the responder cookie and/or a different Diffie-Hellman group), it is the
second version of the message that is signed. second version of the message that is signed.
Optionally, messages 3 and 4 MAY include a certificate, or Optionally, messages 3 and 4 MAY include a certificate, or
skipping to change at page 33, line 26 skipping to change at page 33, line 28
In all cases, the CP payload MUST be inserted before the SA payload. In all cases, the CP payload MUST be inserted before the SA payload.
In variations of the protocol where there are multiple IKE_AUTH In variations of the protocol where there are multiple IKE_AUTH
exchanges, the CP payloads MUST be inserted in the messages exchanges, the CP payloads MUST be inserted in the messages
containing the SA payloads. containing the SA payloads.
CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute
(either IPv4 or IPv6) but MAY contain any number of additional (either IPv4 or IPv6) but MAY contain any number of additional
attributes the initiator wants returned in the response. attributes the initiator wants returned in the response.
For example, message from Initiator to Responder: For example, message from Initiator to Responder:
CP(CFG_REQUEST)= CP(CFG_REQUEST)
INTERNAL_ADDRESS(0.0.0.0) INTERNAL_ADDRESS(0.0.0.0)
INTERNAL_NETMASK(0.0.0.0) INTERNAL_NETMASK(0.0.0.0)
INTERNAL_DNS(0.0.0.0) INTERNAL_DNS(0.0.0.0)
TSi = (0, 0-65536,0.0.0.0-255.255.255.255) TSi = (0, 0-65536,0.0.0.0-255.255.255.255)
TSr = (0, 0-65536,0.0.0.0-255.255.255.255) TSr = (0, 0-65536,0.0.0.0-255.255.255.255)
NOTE: Traffic Selectors contain (protocol, port range, address range) NOTE: Traffic Selectors contain (protocol, port range, address range)
Message from Responder to Initiator: Message from Responder to Initiator:
CP(CFG_REPLY)= CP(CFG_REPLY)
INTERNAL_ADDRESS(10.168.219.202) INTERNAL_ADDRESS(10.168.219.202)
INTERNAL_NETMASK(255.255.255.0) INTERNAL_NETMASK(255.255.255.0)
INTERNAL_SUBNET(10.168.219.0/255.255.255.0) INTERNAL_SUBNET(10.168.219.0/255.255.255.0)
TSi = (0, 0-65536,10.168.219.202-10.168.219.202) TSi = (0, 0-65536,10.168.219.202-10.168.219.202)
TSr = (0, 0-65536,10.168.219.0-10.168.219.255) TSr = (0, 0-65536,10.168.219.0-10.168.219.255)
All returned values will be implementation dependent. As can be seen All returned values will be implementation dependent. As can be seen
in the above example, the IRAS MAY also send other attributes that in the above example, the IRAS MAY also send other attributes that
were not included in CP(CFG_REQUEST) and MAY ignore the non- were not included in CP(CFG_REQUEST) and MAY ignore the non-
mandatory attributes that it does not support. mandatory attributes that it does not support.
skipping to change at page 34, line 27 skipping to change at page 34, line 29
prior to authentication or even after authentication to prevent prior to authentication or even after authentication to prevent
trolling in case some implementation is known to have some security trolling in case some implementation is known to have some security
weakness. In that case, it MUST either return an empty string or no weakness. In that case, it MUST either return an empty string or no
CP payload if CP is not supported. CP payload if CP is not supported.
Initiator Responder Initiator Responder
----------------------------- -------------------------- ----------------------------- --------------------------
HDR, SK{CP(CFG_REQUEST)} --> HDR, SK{CP(CFG_REQUEST)} -->
<-- HDR, SK{CP(CFG_REPLY)} <-- HDR, SK{CP(CFG_REPLY)}
CP(CFG_REQUEST)= CP(CFG_REQUEST)
APPLICATION_VERSION("") APPLICATION_VERSION("")
CP(CFG_REPLY) CP(CFG_REPLY)
APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar Inc.") APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar Inc.")
2.21 Error Handling 2.21 Error Handling
There are many kinds of errors that can occur during IKE processing. There are many kinds of errors that can occur during IKE processing.
If a request is received that is badly formatted or unacceptable for If a request is received that is badly formatted or unacceptable for
reasons of policy (e.g., no matching cryptographic algorithms), the reasons of policy (e.g., no matching cryptographic algorithms), the
skipping to change at page 37, line 25 skipping to change at page 37, line 27
reason, even though IKE packets MUST be sent from and to UDP port reason, even though IKE packets MUST be sent from and to UDP port
500, they MUST be accepted coming from any port and responses MUST be 500, they MUST be accepted coming from any port and responses MUST be
sent to the port from whence they came. This is because the ports may sent to the port from whence they came. This is because the ports may
be modified as the packets pass through NATs. Similarly, IP addresses be modified as the packets pass through NATs. Similarly, IP addresses
of the IKE endpoints are generally not included in the IKE payloads of the IKE endpoints are generally not included in the IKE payloads
because the payloads are cryptographically protected and could not be because the payloads are cryptographically protected and could not be
transparently modified by NATs. transparently modified by NATs.
Port 4500 is reserved for UDP encapsulated ESP, AH, and IKE. When Port 4500 is reserved for UDP encapsulated ESP, AH, and IKE. When
working through a NAT, it is generally better to pass IKE packets working through a NAT, it is generally better to pass IKE packets
over port 4500 because some older NATs modify IKE traffic on port 500 over port 4500 because some older NATs handle IKE traffic on port 500
in an attempt to transparently establish IPsec connections. Such NATs cleverly in an attempt to transparently establish IPsec connections
may interfere with the straightforward NAT traversal envisioned by between endpoints that don't handle NAT traversal themselves. Such
this document, so an IPsec endpoint that discovers a NAT between it NATs may interfere with the straightforward NAT traversal envisioned
and its correspondent MUST send all subsequent traffic to and from by this document, so an IPsec endpoint that discovers a NAT between
it and its correspondent MUST send all subsequent traffic to and from
port 4500, which NATs should not treat specially (as they might with port 4500, which NATs should not treat specially (as they might with
port 500). port 500).
The specific requirements for supporting NAT traversal are listed The specific requirements for supporting NAT traversal are listed
below. Support for NAT traversal is optional. In this section only, below. Support for NAT traversal is optional. In this section only,
requirements listed as MUST only apply to implementations supporting requirements listed as MUST only apply to implementations supporting
NAT traversal. NAT traversal.
IKE MUST listen on port 4500 as well as port 500. IKE MUST respond IKE MUST listen on port 4500 as well as port 500. IKE MUST respond
to the IP address and port from which packets arrived. to the IP address and port from which packets arrived.
skipping to change at page 37, line 51 skipping to change at page 38, line 7
Both IKE initiator and responder MUST include in their IKE_SA_INIT Both IKE initiator and responder MUST include in their IKE_SA_INIT
packets Notify payloads of type NAT_DETECTION_SOURCE_IP and packets Notify payloads of type NAT_DETECTION_SOURCE_IP and
NAT_DETECTION_DESTINATION_IP. Those payloads can be used to detect NAT_DETECTION_DESTINATION_IP. Those payloads can be used to detect
if there is NAT between the hosts, and which end is behind the if there is NAT between the hosts, and which end is behind the
NAT. The location of the payloads in the IKE_SA_INIT packets are NAT. The location of the payloads in the IKE_SA_INIT packets are
just after the Ni and Nr payloads (before the optional CERTREQ just after the Ni and Nr payloads (before the optional CERTREQ
payload). payload).
If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches
the hash of the source IP and port found from the IP header of the the hash of the source IP and port found from the IP header of the
packet containing the payload, it means that the the other end is packet containing the payload, it means that the other end is
behind NAT (i.e someone along the route changed the source address behind NAT (i.e., someone along the route changed the source
of the original packet to match the address of the NAT box). In address of the original packet to match the address of the NAT
this case this end should allow dynamic update of the other ends box). In this case this end should allow dynamic update of the
IP address, as described later. other ends 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 explained in [Hutt04]. 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
skipping to change at page 38, line 41 skipping to change at page 38, line 45
transport mode TCP and UDP packet checksum fixup (see [Hutt04]) 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 retransmission packets) to the IP address and port from the last
valid authenticated packet from the other end (i.e dynamically valid authenticated packet from the other end (i.e., dynamically
update the address). A host behind a NAT SHOULD NOT do this update the address). A host behind a NAT SHOULD NOT do this
because it opens a DoS attack possibility. Any authenticated IKE because it opens a DoS attack possibility. Any authenticated IKE
packet or any authenticated UDP encapsulated ESP packet can be packet or any authenticated UDP encapsulated ESP packet can be
used to detect that the IP address or the port has changed. used to detect that the IP address or the port has changed.
Note that similar but probably not identical actions will likely Note that similar but probably not identical actions will likely
be needed to make IKE work with Mobile IP, but such processing is be needed to make IKE work with Mobile IP, but such processing is
not addressed by this document. not addressed by this document.
2.24 ECN (Explicit Congestion Notification) 2.24 ECN (Explicit Congestion Notification)
When IPsec tunnels behave as originally specified in [RFC 2401], ECN When IPsec tunnels behave as originally specified in [RFC2401], ECN
usage is not appropriate for the outer IP headers because tunnel usage is not appropriate for the outer IP headers because tunnel
decapsulation processing discards ECN congestion indications to the decapsulation processing discards ECN congestion indications to the
detriment of the network. ECN support for IPsec tunnels for detriment of the network. ECN support for IPsec tunnels for
IKEv1-based IPsec requires multiple operating modes and negotiation IKEv1-based IPsec requires multiple operating modes and negotiation
(see RFC 3168]). IKEv2 simplifies this situation by requiring that (see RFC3168]). IKEv2 simplifies this situation by requiring that
ECN be usable in the outer IP headers of all tunnel-mode IPsec SAs ECN be usable in the outer IP headers of all tunnel-mode IPsec SAs
created by IKEv2. Specifically, tunnel encapsulators and created by IKEv2. Specifically, tunnel encapsulators and
decapsulators for all tunnel-mode Security Associations (SAs) created decapsulators for all tunnel-mode Security Associations (SAs) created
by IKEv2 MUST support the ECN full-functionality option for tunnels by IKEv2 MUST support the ECN full-functionality option for tunnels
specified in [RFC3168] and MUST implement the tunnel encapsulation specified in [RFC3168] and MUST implement the tunnel encapsulation
and decapsulation processing specified in [RFC2401bis] to prevent and decapsulation processing specified in [RFC2401bis] to prevent
discarding of ECN congestion indications. discarding of ECN congestion indications.
3 Header and Payload Formats 3 Header and Payload Formats
skipping to change at page 45, line 31 skipping to change at page 45, line 36
transforms. transforms.
A given transform MAY have one or more Attributes. Attributes are A given transform MAY have one or more Attributes. Attributes are
necessary when the transform can be used in more than one way, as necessary when the transform can be used in more than one way, as
when an encryption algorithm has a variable key size. The transform when an encryption algorithm has a variable key size. The transform
would specify the algorithm and the attribute would specify the key would specify the algorithm and the attribute would specify the key
size. Most transforms do not have attributes. A transform MUST NOT size. Most transforms do not have attributes. A transform MUST NOT
have multiple attributes of the same type. To propose alternate have multiple attributes of the same type. To propose alternate
values for an attribute (for example, multiple key sizes for the AES values for an attribute (for example, multiple key sizes for the AES
encryption algorithm), and implementation MUST include multiple encryption algorithm), and implementation MUST include multiple
Transorms with the same Transform Type each with a single Attribute. Transforms with the same Transform Type each with a single Attribute.
Note that the semantics of Transforms and Attributes are quite Note that the semantics of Transforms and Attributes are quite
different than in IKEv1. In IKEv1, a single Transform carried different than in IKEv1. In IKEv1, a single Transform carried
multiple algorithms for a protocol with one carried in the Transform multiple algorithms for a protocol with one carried in the Transform
and the others carried in the Attributes. and the others carried in the Attributes.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length ! ! Next Payload !C! RESERVED ! Payload Length !
skipping to change at page 49, line 37 skipping to change at page 50, line 7
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
AUTH_KPDK_MD5 4 (RFC1826) AUTH_KPDK_MD5 4 (RFC1826)
AUTH_AES_XCBC_96 5 AUTH_AES_PRF_128 5 (RFC3664)
values 6-1023 are reserved to IANA. Values 1024-65535 are for values 6-1023 are reserved to IANA. Values 1024-65535 are for
private use among mutually consenting parties. private use among mutually consenting parties.
For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs
are: are:
Name Number Name Number
NONE 0 NONE 0
Defined in Appendix B 1 - 4 Defined in Appendix B 1 - 4
skipping to change at page 50, line 34 skipping to change at page 51, line 4
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 INTEG, D-H, ESN ESP ENCR INTEG, D-H, ESN
AH INTEG D-H, ESN AH INTEG D-H, ESN
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 document choice for all customers. For example, at the time that this document
was being written, many IKEv1 implementers are starting to migrate to was being written, many IKEv1 implementers are starting to migrate to
AES in CBC mode for VPN applications. Many IPsec systems based on AES in CBC mode for VPN applications. Many IPsec systems based on
IKEv2 will implement AES, longer Diffie-Hellman keys, and additional IKEv2 will implement AES, additional Diffie-Hellman groups, and
hash algorithms, and some IPsec customers already require these additional hash algorithms, and some IPsec customers already require
algorithms in addition to the ones listed above. these algorithms in addition to the ones listed above.
It is likely that IANA will add additional transforms in the future, It is likely that IANA will add additional transforms in the future,
and some users may want to use private suites, especially for IKE and some users may want to use private suites, especially for IKE
where implementations should be capable of supporting different where implementations should be capable of supporting different
parameters, up to certain size limits. In support of this goal, all parameters, up to certain size limits. In support of this goal, all
implementations of IKEv2 SHOULD include a management facility that implementations of IKEv2 SHOULD include a management facility that
allows specification (by a user or system administrator) of Diffie- allows specification (by a user or system administrator) of Diffie-
Hellman parameters (the generator, modulus, and exponent lengths and Hellman parameters (the generator, modulus, and exponent lengths and
values) for new DH groups. Implementations SHOULD provide a values) for new DH groups. Implementations SHOULD provide a
management interface via which these parameters and the associated management interface via which these parameters and the associated
skipping to change at page 56, line 22 skipping to change at page 56, line 38
The binary DER encoding of an ASN.1 X.500 Distinguished Name The binary DER encoding of an ASN.1 X.500 Distinguished Name
[X.501]. [X.501].
ID_DER_ASN1_GN 10 ID_DER_ASN1_GN 10
The binary DER encoding of an ASN.1 X.500 GeneralName The binary DER encoding of an ASN.1 X.500 GeneralName
[X.509]. [X.509].
ID_KEY_ID 11 ID_KEY_ID 11
An opaque octet stream which may be used to pass an account An opaque octet stream which may be used to pass vendor-
name or to pass vendor-specific information necessary to do specific information necessary to do certain proprietary
certain proprietary types of identification. types of identification.
Reserved to IANA 12-200 Reserved to IANA 12-200
Reserved for private use 201-255 Reserved for 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
skipping to change at page 58, line 26 skipping to change at page 58, line 38
when the endpoints have certificate data cached and makes IKE less when the endpoints have certificate data cached and makes IKE less
subject to denial of service attacks that become easier to mount subject to denial of service attacks that become easier to mount
when IKE messages are large enough to require IP fragmentation when IKE messages are large enough to require IP fragmentation
[KPS03]. [KPS03].
Use the following ASN.1 definition for an X.509 bundle: Use the following ASN.1 definition for an X.509 bundle:
CertBundle CertBundle
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-cert-bundle(TBD) } id-mod-cert-bundle(34) }
DEFINITIONS EXPLICIT TAGS ::= DEFINITIONS EXPLICIT TAGS ::
BEGIN BEGIN
IMPORTS IMPORTS
Certificate, CertificateList Certificate, CertificateList
FROM PKIX1Explicit88 FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6) { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) } ; id-mod(0) id-pkix1-explicit(18) } ;
CertificateOrCRL ::= CHOICE { CertificateOrCRL ::= CHOICE {
skipping to change at page 59, line 47 skipping to change at page 60, line 10
certificate requested. certificate requested.
The payload type for the Certificate Request Payload is thirty eight The payload type for the Certificate Request Payload is thirty eight
(38). (38).
The Certificate Encoding field has the same values as those defined The Certificate Encoding field has the same values as those defined
in section 3.6. The Certification Authority field contains an in section 3.6. The Certification Authority field contains an
indicator of trusted authorities for this certificate type. The indicator of trusted authorities for this certificate type. The
Certification Authority value is a concatenated list of SHA-1 hashes Certification Authority value is a concatenated list of SHA-1 hashes
of the public keys of trusted CAs. Each is encoded as the SHA-1 hash of the public keys of trusted CAs. Each is encoded as the SHA-1 hash
of the Subject Public Key Info element (see section 4.1.2.7 of [RFC of the Subject Public Key Info element (see section 4.1.2.7 of
3280]) from each Trust Anchor certificate. The twenty-octet hashes [RFC3280]) from each Trust Anchor certificate. The twenty-octet
are concatenated and included with no other formatting. hashes are concatenated and included with no other formatting.
Note that the term "Certificate Request" is somewhat misleading, in Note that the term "Certificate Request" is somewhat misleading, in
that values other than certificates are defined in a "Certificate" that values other than certificates are defined in a "Certificate"
payload and requests for those values can be present in a Certificate payload and requests for those values can be present in a Certificate
Request Payload. The syntax of the Certificate Request payload in Request Payload. The syntax of the Certificate Request payload in
such cases is not defined in this document. such cases is not defined in this document.
The Certificate Request Payload is processed by inspecting the "Cert The Certificate Request Payload is processed by inspecting the "Cert
Encoding" field to determine whether the processor has any Encoding" field to determine whether the processor has any
certificates of this type. If so the "Certification Authority" field certificates of this type. If so the "Certification Authority" field
is inspected to determine if the processor has any certificates which is inspected to determine if the processor has any certificates which
can be validated up to one of the specified certification can be validated up to one of the specified certification
authorities. This can be a chain of certificates. If a certificate authorities. This can be a chain of certificates.
exists which satisfies the criteria specified in the Certificate
Request Payload, the certificate MUST be sent back to the certificate If an end-entity certificate exists which satisfies the criteria
requestor; if a certificate chain exists which goes back to the specified in the CERTREQ, a certificate or certificate chain SHOULD
certification authority specified in the request the entire chain be sent back to the certificate requestor if:
SHOULD be sent back to the certificate requestor. If multiple
certificates or chains exist that satisfy the request, the sender - the recipient of the CERTREQ is configured to use certificate
MUST pick one. If no certificates exist then the Certificate Request authentication,
Payload is ignored. This is not an error condition of the protocol.
There may be cases where there is a preferred CA, but an alternate - is allowed to send a CERT payload,
might be acceptable (perhaps after prompting a human operator).
- has matching CA trust policy governing the current negotiation,
and
- has at least one time-wise and usage appropriate end-entity
certificate chaining to a CA provided in the CERTREQ.
Certificate revocation checking must be considered during the
chaining process used to select a certificate. Note that even if two
peers are configured to use two different CAs, cross-certification
relationships should be supported by appropriate selection logic. The
intent is not to prevent communication through the strict adherence
of selection of a certificate based on CERTREQ, when an alternate
certificate could be selected by the sender which would still enable
the recipient to successfully validate and trust it through trust
conveyed by cross-certification, CRLs or other out-of-band configured
means. Thus the processing of a CERTREQ CA name should be seen as a
suggestion for a certificate to select, not a mandated one. If no
certificates exist then the CERTREQ is ignored. This is not an error
condition of the protocol. There may be cases where there is a
preferred CA sent in the CERTREQ, but an alternate might be
acceptable (perhaps after prompting a human operator)."
3.8 Authentication Payload 3.8 Authentication Payload
The Authentication Payload, denoted AUTH in this memo, contains data The Authentication Payload, denoted AUTH in this memo, contains data
used for authentication purposes. The syntax of the Authentication used for authentication purposes. The syntax of the Authentication
data varies according to the Auth Method as specified below. data varies according to the Auth Method as specified below.
The Authentication Payload is defined as follows: The Authentication Payload is defined as follows:
1 2 3 1 2 3
skipping to change at page 67, line 51 skipping to change at page 68, line 45
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 sending keepalive packets as defined
defined in [Hutt04]. Alternately, it MAY reject the in [Hutt04]. Alternately, it MAY reject the connection
connection attempt if NAT traversal is not supported. 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
be between 1 and 64 octets in length (inclusive). be between 1 and 64 octets in length (inclusive).
skipping to change at page 69, line 7 skipping to change at page 69, line 48
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.
ESP_TFC_PADDING_NOT_SUPPORTED 16394 ESP_TFC_PADDING_NOT_SUPPORTED 16394
This notification asserts that the sending endpoint will NOT This notification asserts that the sending endpoint will NOT
accept packets that contain Flow Confidentiality (TFC) accept packets that contain Flow Confidentiality (TFC)
padding. padding.
RESERVED TO IANA - STATUS TYPES 16395 - 40959 NON_FIRST_FRAGMENTS_ALSO 16395
Used for fragmentation control. See [2401bis] for
explanation.
RESERVED TO IANA - STATUS TYPES 16396 - 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 73, line 10 skipping to change at page 73, line 42
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 or which port is undefined, or if all ports are allowed,
port is OPAQUE, this field MUST be zero. For the 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 (with Type in the most treated as a single 16 bit integer (with Type in the most
significant eight bits and Code in the least significant significant eight bits and Code in the least significant
eight bits) port number for the purposes of filtering based eight bits) port number for the purposes of filtering based
on this field. 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 or which port is undefined, or if all ports are allowed,
port is OPAQUE, this field MUST be 65535. For the 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 (with Type in the most treated as a single 16 bit integer (with Type in the most
significant eight bits and Code in the least significant significant eight bits and Code in the least significant
eight bits) port number for the purposed of filtering based eight bits) port number for the purposed of filtering based
on this field. 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).
Systems that are complying with [RFC2401bis] that wish to indicate
"ANY" ports MUST set the start port to 0 and the end port to 65535;
note that according to [RFC2401bis], "ANY" includes "OPAQUE". Systems
working with [RFC2401bis] that wish to indicate "OPAQUE" ports, but
not "ANY" ports, MUST set the start port to 65535 and the end port to
0.
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.
TS Type Value TS Type Value
------- ----- ------- -----
RESERVED 0-6 RESERVED 0-6
TS_IPV4_ADDR_RANGE 7 TS_IPV4_ADDR_RANGE 7
A range of IPv4 addresses, represented by two four (4) octet A range of IPv4 addresses, represented by two four (4) octet
skipping to change at page 74, line 22 skipping to change at page 75, line 16
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.
The encryption and integrity protection algorithms are modelled after The encryption and integrity protection algorithms are modeled after
the ESP algorithms described in RFCs 2104, 2406, 2451. This document the ESP algorithms described in RFCs 2104, 2406, 2451. This document
completely specifies the cryptographic processing of IKE data, but completely specifies the cryptographic processing of IKE data, but
those documents should be consulted for design rationale. We assume a those documents should be consulted for design rationale. We assume a
block cipher with a fixed block size and an integrity check algorithm block cipher with a fixed block size and an integrity check algorithm
that computes a fixed length checksum over a variable size message. that computes a fixed length checksum over a variable size message.
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:
skipping to change at page 77, line 39 skipping to change at page 78, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: Configuration Payload Format Figure 22: Configuration Payload Format
The payload type for the Configuration Payload is forty seven (47). The payload type for the Configuration Payload is forty seven (47).
o CFG Type (1 octet) - The type of exchange represented by the o CFG Type (1 octet) - The type of exchange represented by the
Configuration Attributes. Configuration Attributes.
CFG Type Value CFG Type Value
=========== ===== =========== ====
RESERVED 0 RESERVED 0
CFG_REQUEST 1 CFG_REQUEST 1
CFG_REPLY 2 CFG_REPLY 2
CFG_SET 3 CFG_SET 3
CFG_ACK 4 CFG_ACK 4
values 5-127 are reserved to IANA. Values 128-255 are for private values 5-127 are reserved to IANA. Values 128-255 are for private
use among mutually consenting parties. use among mutually consenting parties.
o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on
skipping to change at page 78, line 39 skipping to change at page 79, line 34
o Length (2 octets) - Length in octets of Value. o Length (2 octets) - Length in octets of Value.
o Value (0 or more octets) - The variable length value of this o Value (0 or more octets) - The variable length value of this
Configuration Attribute. Configuration Attribute.
The following attribute types have been defined: The following attribute types have been defined:
Multi- Multi-
Attribute Type Value Valued Length Attribute Type Value Valued Length
======================= ===== ====== ================== ======================= ===== ====== =================
RESERVED 0 RESERVED 0
INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets
INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets
INTERNAL_IP4_DNS 3 YES 0 or 4 octets INTERNAL_IP4_DNS 3 YES 0 or 4 octets
INTERNAL_IP4_NBNS 4 YES 0 or 4 octets INTERNAL_IP4_NBNS 4 YES 0 or 4 octets
INTERNAL_ADDRESS_EXPIRY 5 NO 0 or 4 octets INTERNAL_ADDRESS_EXPIRY 5 NO 0 or 4 octets
INTERNAL_IP4_DHCP 6 YES 0 or 4 octets INTERNAL_IP4_DHCP 6 YES 0 or 4 octets
APPLICATION_VERSION 7 NO 0 or more APPLICATION_VERSION 7 NO 0 or more
INTERNAL_IP6_ADDRESS 8 YES* 0 or 16 octets INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets
INTERNAL_IP6_NETMASK 9 NO 0 or 16 octets RESERVED 9
INTERNAL_IP6_DNS 10 YES 0 or 16 octets INTERNAL_IP6_DNS 10 YES 0 or 16 octets
INTERNAL_IP6_NBNS 11 YES 0 or 16 octets INTERNAL_IP6_NBNS 11 YES 0 or 16 octets
INTERNAL_IP6_DHCP 12 YES 0 or 16 octets INTERNAL_IP6_DHCP 12 YES 0 or 16 octets
INTERNAL_IP4_SUBNET 13 NO 0 or 8 octets INTERNAL_IP4_SUBNET 13 NO 0 or 8 octets
SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 SUPPORTED_ATTRIBUTES 14 NO Multiple of 2
INTERNAL_IP6_SUBNET 15 NO 17 octets INTERNAL_IP6_SUBNET 15 NO 17 octets
* These attributes may be multi-valued on return only if * These attributes may be multi-valued on return only if
multiple values were requested. multiple values were requested.
Types 16-16383 are reserved to IANA. Values 16384-32767 are for Types 16-16383 are reserved to IANA. Values 16384-32767 are for
private use among mutually consenting parties. private use among mutually consenting parties.
o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the
internal network, sometimes called a red node address or internal network, sometimes called a red node address or
private address and MAY be a private address on the Internet. private address and MAY be a private address on the Internet.
Multiple internal addresses MAY be requested by requesting Multiple internal addresses MAY be requested by requesting
multiple internal address attributes. The responder MAY only multiple internal address attributes. The responder MAY only
send up to the number of addresses requested. send up to the number of addresses requested. The
INTERNAL_IP6_ADDRESS is made up of two fields; the first
being a 16 octet IPv6 address and the second being a one octet
prefix-length as defined in [ADDRIPV6].
The requested address is valid until the expiry time defined The requested address is valid until the expiry time defined
with the INTERNAL_ADDRESS EXPIRY attribute or there are no with the INTERNAL_ADDRESS EXPIRY attribute or there are no
IKE_SAs between the peers. IKE_SAs between the peers.
o INTERNAL_IP4_NETMASK, INTERNAL_IP6_NETMASK - The internal o INTERNAL_IP4_NETMASK - The internal network's netmask. Only
network's netmask. Only one netmask is allowed in the request one netmask is allowed in the request and reply messages
and reply messages (e.g., 255.255.255.0) and it MUST be used (e.g., 255.255.255.0) and it MUST be used only with an
only with an INTERNAL_ADDRESS attribute. INTERNAL_IP4_ADDRESS attribute.
o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a
DNS server within the network. Multiple DNS servers MAY be DNS server within the network. Multiple DNS servers MAY be
requested. The responder MAY respond with zero or more DNS requested. The responder MAY respond with zero or more DNS
server attributes. server attributes.
o INTERNAL_IP4_NBNS, INTERNAL_IP6_NBNS - Specifies an address of o INTERNAL_IP4_NBNS, INTERNAL_IP6_NBNS - Specifies an address of
a NetBios Name Server (WINS) within the network. Multiple NBNS a NetBios Name Server (WINS) within the network. Multiple NBNS
servers MAY be requested. The responder MAY respond with zero servers MAY be requested. The responder MAY respond with zero
or more NBNS server attributes. or more NBNS server attributes.
skipping to change at page 84, line 25 skipping to change at page 85, line 14
Shared key authentication where the ID passes is any of ID_KEY_ID, Shared key authentication where the ID passes is any of ID_KEY_ID,
ID_FQDN, or ID_RFC822_ADDR. ID_FQDN, or ID_RFC822_ADDR.
Authentication where the responder is authenticated using PKIX Authentication where the responder is authenticated using PKIX
Certificates and the initiator is authenticated using shared key Certificates and the initiator is authenticated using shared key
authentication. authentication.
5 Security Considerations 5 Security Considerations
While this protocol is designed to minimize disclosure of
configuration information to unauthenticated peers, some such
disclosure is unavoidable. One peer or the other must identify
itself first and prove its identity first. To avoid probing, the
initiator of an exchange is required to identify itself first, and
usually is required to authenticate itself first. The initiator can,
however, learn that the responder supports IKE and what cryptographic
protocols it supports. The responder (or someone impersonating the
responder) can probe the initiator not only for its identity, but
using CERTREQ payloads may be able to determine what certificates the
initiator is willing to use.
Use of EAP authentication changes the probing possibilities somewhat.
When EAP authentication is used, the responder proves its identity
before the initiator does, so an initiator that knew the name of a
valid initiator could probe the responder for both its name and
certificates.
Repeated rekeying using CREATE_CHILD_SA without PFS leaves all SAs Repeated rekeying using CREATE_CHILD_SA without PFS leaves all SAs
vulnerable to cryptanalysis of a single key or overrun of either vulnerable to cryptanalysis of a single key or overrun of either
endpoint. Implementers should take note of this fact and set a limit endpoint. Implementers should take note of this fact and set a limit
on CREATE_CHILD_SA exchanges between exponentiations. This memo does on CREATE_CHILD_SA exchanges between exponentiations. This memo does
not prescribe such a limit. not prescribe such a limit.
The strength of a key derived from a Diffie-Hellman exchange using The strength of a key derived from a Diffie-Hellman exchange using
any of the groups defined here depends on the inherent strength of any of the groups defined here depends on the inherent strength of
the group, the size of the exponent used, and the entropy provided by the group, the size of the exponent used, and the entropy provided by
the random number generator used. Due to these inputs it is difficult the random number generator used. Due to these inputs it is difficult
to determine the strength of a key for any of the defined groups. to determine the strength of a key for any of the defined groups.
Diffie-Hellman group number two, when used with a strong random Diffie-Hellman group number two, when used with a strong random
number generator and an exponent no less than 200 bits, is sufficient number generator and an exponent no less than 200 bits, is common for
for use with 3DES. Groups three through five provide greater use with 3DES. Group five provides greater security than group two.
security. Group one is for historic purposes only and does not Group one is for historic purposes only and does not provide
provide sufficient strength except for use with DES, which is also sufficient strength except for use with DES, which is also for
for historic use only. Implementations should make note of these historic use only. Implementations should make note of these
conservative estimates when establishing policy and negotiating estimates when establishing policy and negotiating security
security parameters. parameters.
Note that these limitations are on the Diffie-Hellman groups Note that these limitations are on the Diffie-Hellman groups
themselves. There is nothing in IKE which prohibits using stronger themselves. There is nothing in IKE which prohibits using stronger
groups nor is there anything which will dilute the strength obtained groups nor is there anything which will dilute the strength obtained
from stronger groups (limited by the strength of the other algorithms from stronger groups (limited by the strength of the other algorithms
negotiated including the prf function). In fact, the extensible negotiated including the prf function). In fact, the extensible
framework of IKE encourages the definition of more groups; use of framework of IKE encourages the definition of more groups; use of
elliptical curve groups may greatly increase strength using much elliptical curve groups may greatly increase strength using much
smaller numbers. smaller numbers.
skipping to change at page 86, line 18 skipping to change at page 87, line 24
method, but in an unprotected fashion. Note that this vulnerability method, but in an unprotected fashion. Note that this vulnerability
is not limited to just EAP, but can occur in other scenarios where an is not limited to just EAP, but can occur in other scenarios where an
authentication infrastructure is reused. For example, if the EAP authentication infrastructure is reused. For example, if the EAP
mechanism used by IKEv2 utilizes a token authenticator, a man-in-the- mechanism used by IKEv2 utilizes a token authenticator, a man-in-the-
middle attacker could impersonate the web server, intercept the token middle attacker could impersonate the web server, intercept the token
authentication exchange, and use it to initiate an IKEv2 connection. authentication exchange, and use it to initiate an IKEv2 connection.
For this reason, use of non-key-generating EAP methods SHOULD be For this reason, use of non-key-generating EAP methods SHOULD be
avoided where possible. Where they are used, it is extremely avoided where possible. Where they are used, it is extremely
important that all usages of these EAP methods SHOULD utilize a important that all usages of these EAP methods SHOULD utilize a
protected tunnel, where the initiator validates the responder's protected tunnel, where the initiator validates the responder's
certificate before initiating the EAP exchange. Implementors SHOULD certificate before initiating the EAP exchange. 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 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.
skipping to change at page 86, line 41 skipping to change at page 87, line 47
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. future assignments will be managed by the IANA.
The following registries should be created: The following registries should be created:
IKEv2 Exchange Types IKEv2 Exchange Types
IKEv2 Payload Types IKEv2 Payload Types
IKEv2 Transform Types IKEv2 Transform Types
IKEv2 Transform Attribute Types IKEv2 Transform Attribute Types
IKEv2 Encryption Transform IDs IKEv2 Encryption Transform IDs
IKEv2 Pseudo-ramdom Function Transform IDs IKEv2 Pseudo-random Function Transform IDs
IKEv2 Integrity Algorithm Transform IDs IKEv2 Integrity Algorithm Transform IDs
IKEv2 Diffie-Hellman, ECP and EC2N Transform IDs IKEv2 Diffie-Hellman, ECP and EC2N Transform IDs
IKEv2 Identification Payload ID Types IKEv2 Identification Payload ID Types
IKEv2 Certification Encodings IKEv2 Certification Encodings
IKEv2 Authentication Method IKEv2 Authentication Method
IKEv2 Notification Payload Types IKEv2 Notification Payload Types
IKEv2 Notification IPCOMP Transform IDs IKEv2 Notification IPCOMP Transform IDs
IKEv2 Security Protocol Identfiers IKEv2 Security Protocol Identifiers
IKEv2 Traffic Selector Types IKEv2 Traffic Selector Types
IKEv2 Configuration Payload CFG Types IKEv2 Configuration Payload CFG Types
IKEv2 Configuration Payload Attribute Types IKEv2 Configuration Payload Attribute Types
Note: when creating a new Transform Type, a new registry for it must Note: when creating a new Transform Type, a new registry for it must
be created. be created.
New allocations to any of those registries may be allocated by expert New allocations to any of those registries may be allocated by expert
review. review.
skipping to change at page 89, line 28 skipping to change at page 90, line 33
Computer and Communications Security, October 2003. Computer and Communications Security, October 2003.
[Ker01] Keromytis, A., Sommerfeld, B., "The 'Suggested ID' [Ker01] Keromytis, A., Sommerfeld, B., "The 'Suggested ID'
Extension for IKE", draft-keromytis-ike-id-00.txt, 2001 Extension for IKE", draft-keromytis-ike-id-00.txt, 2001
[KBC96] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [KBC96] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February Hashing for Message Authentication", RFC 2104, February
1997. 1997.
[LDAP] M. Wahl, T. Howes, S. Kille., "Lightweight Directory [LDAP] M. Wahl, T. Howes, S. Kille., "Lightweight Directory
Access Protocol (v3)", RFC2251 Access Protocol (v3)", RFC 2251
[MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
April 1992. April 1992.
[MSST98] Maughhan, D., Schertler, M., Schneider, M., and Turner, J. [MSST98] Maughhan, D., Schertler, M., Schneider, M., and Turner, J.
"Internet Security Association and Key Management Protocol "Internet Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998. (ISAKMP)", RFC 2408, November 1998.
[Orm96] Orman, H., "The Oakley Key Determination Protocol", RFC [Orm96] Orman, H., "The Oakley Key Determination Protocol", RFC
2412, November 1998. 2412, November 1998.
[PFKEY] McDonald, D., Metz, C., and Phan, B., "PFKEY Key [PFKEY] McDonald, D., Metz, C., and Phan, B., "PFKEY Key
Management API, Version 2", RFC2367, July 1998. Management API, Version 2", RFC 2367, July 1998.
[PKCS1] Kaliski, B., and J. Staddon, "PKCS #1: RSA Cryptography [PKCS1] Kaliski, B., and J. Staddon, "PKCS #1: RSA Cryptography
Specifications Version 2", September 1998. Specifications Version 2", September 1998.
[PK01] Perlman, R., and Kaufman, C., "Analysis of the IPsec key [PK01] Perlman, R., and Kaufman, C., "Analysis of the IPsec key
exchange Standard", WET-ICE Security Conference, MIT,2001, exchange Standard", WET-ICE Security Conference, MIT,2001,
http://sec.femto.org/wetice-2001/papers/radia-paper.pdf. http://sec.femto.org/wetice-2001/papers/radia-paper.pdf.
[Pip98] Piper, D., "The Internet IP Security Domain Of [Pip98] Piper, D., "The Internet IP Security Domain Of
Interpretation for ISAKMP", RFC 2407, November 1998. Interpretation for ISAKMP", RFC 2407, November 1998.
[RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC2138 Authentication Dial In User Service (RADIUS)", RFC 2138
[RFC1750] Eastlake, D., Crocker, S., and Schiller, J., "Randomness [RFC1750] Eastlake, D., Crocker, S., and Schiller, J., "Randomness
Recommendations for Security", RFC 1750, December 1994. Recommendations for Security", RFC 1750, December 1994.
[RFC1958] Carpenter, B., "Architectural Principles of the
Internet", RFC 1958, June 1996.
[RFC2401] Kent, S., and Atkinson, R., "Security Architecture for [RFC2401] Kent, S., and Atkinson, R., "Security Architecture for
the Internet Protocol", RFC 2401, November 1998. the Internet Protocol", RFC 2401, November 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F. and Black, D., [RFC2474] Nichols, K., Blake, S., Baker, F. and Black, D.,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998. December 1998.
[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.
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775,
February 2000.
[RFC2983] Black, D., "Differentiated Services and Tunnels", [RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, October 2000. RFC 2983, October 2000.
[RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural
Guidelines and Philosophy", RFC 3429, December 2002.
[RFC3715] Aboba, B and Dixon, W., "IPsec-Network Address [RFC3715] Aboba, B and Dixon, W., "IPsec-Network Address
Translation (NAT) Compatibility Requirements", Translation (NAT) Compatibility Requirements",
RFC 3715, March 2004. 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
skipping to change at page 94, line 7 skipping to change at page 95, line 7
12) To simplify and clarify how shared state is maintained in the 12) To simplify and clarify how shared state is maintained in the
presence of network failures and Denial of Service attacks; and presence of network failures and Denial of Service attacks; and
13) To maintain existing syntax and magic numbers to the extent 13) To maintain existing syntax and magic numbers to the extent
possible to make it likely that implementations of IKEv1 can be possible to make it likely that implementations of IKEv1 can be
enhanced to support IKEv2 with minimum effort. enhanced to support IKEv2 with minimum effort.
Appendix B: Diffie-Hellman Groups Appendix B: Diffie-Hellman Groups
There are 5 different Diffie-Hellman groups defined for use in IKE. There are 4 different Diffie-Hellman groups defined here for use in
These groups were generated by Richard Schroeppel at the University IKE. These groups were generated by Richard Schroeppel at the
of Arizona. Properties of these primes are described in [Orm96]. University of Arizona. Properties of these primes are described in
[Orm96].
The strength supplied by group one may not be sufficient for the The strength supplied by group one may not be sufficient for the
mandatory-to-implement encryption algorithm and is here for historic mandatory-to-implement encryption algorithm and is here for historic
reasons. reasons.
Additional Diffie-Hellman groups have been defined in [ADDGROUP]. Additional Diffie-Hellman groups have been defined in [ADDGROUP].
B.1 Group 1 - 768 Bit MODP B.1 Group 1 - 768 Bit MODP
This group is assigned id 1 (one). This group is assigned id 1 (one).
skipping to change at page 94, line 52 skipping to change at page 96, line 4
49286651 ECE65381 FFFFFFFF FFFFFFFF 49286651 ECE65381 FFFFFFFF FFFFFFFF
The generator is 2. The generator is 2.
B.3 Group 3 - 155 Bit EC2N B.3 Group 3 - 155 Bit EC2N
This group is assigned id 3 (three). The curve is based on the Galois This group is assigned id 3 (three). The curve is based on the Galois
Field GF[2^155]. The field size is 155. The irreducible polynomial Field GF[2^155]. The field size is 155. The irreducible polynomial
for the field is: for the field is:
u^155 + u^62 + 1. u^155 + u^62 + 1.
The equation for the elliptic curve is:
The equation for the elliptic curve is:
y^2 + xy = x^3 + ax^2 + b. y^2 + xy = x^3 + ax^2 + b.
Field Size: 155 Field Size: 155
Group Prime/Irreducible Polynomial: Group Prime/Irreducible Polynomial:
0x0800000000000000000000004000000000000001 0x0800000000000000000000004000000000000001
Group Generator One: 0x7b Group Generator One: 0x7b
Group Curve A: 0x0 Group Curve A: 0x0
Group Curve B: 0x07338f Group Curve B: 0x07338f
Group Order: 0x0800000000000000000057db5698537193aef944 Group Order: 0x0800000000000000000057db5698537193aef944
skipping to change at page 96, line 52 skipping to change at page 97, line 52
2) Added a second optional ID payload in message 3 for the Initiator 2) Added a second optional ID payload in message 3 for the Initiator
to name a desired Responder to support the case where multiple named to name a desired Responder to support the case where multiple named
identities are served by a single IP address. identities are served by a single IP address.
3) Deleted the optimization whereby the Diffie-Hellman group did not 3) Deleted the optimization whereby the Diffie-Hellman group did not
need to be specified in phase 2 if it was the same as in phase 1 (it need to be specified in phase 2 if it was the same as in phase 1 (it
complicated the design with no meaningful benefit). complicated the design with no meaningful benefit).
4) Added a section on the implications of reusing Diffie-Hellman 4) Added a section on the implications of reusing Diffie-Hellman
expontentials exponentials
5) Changed the specification of sequence numbers to being at 0 in 5) Changed the specification of sequence numbers to being at 0 in
both directions. both directions.
6) Many editorial changes and corrections, the most significant being 6) Many editorial changes and corrections, the most significant being
a global replace of "byte" with "octet". a global replace of "byte" with "octet".
H.3 Changes from IKEv2-02 to IKEv2-03 October 2002 H.3 Changes from IKEv2-02 to IKEv2-03 October 2002
1) Reorganized the document moving introductory material to the 1) Reorganized the document moving introductory material to the
front. front.
skipping to change at page 97, line 50 skipping to change at page 98, line 50
3) Made capitalization of IKE_SA and CHILD_SA consistent. 3) Made capitalization of IKE_SA and CHILD_SA consistent.
4) Changed how IPComp was negotiated. 4) Changed how IPComp was negotiated.
5) Added usage scenarios. 5) Added usage scenarios.
6) Added configuration payload for acquiring internal addresses on 6) Added configuration payload for acquiring internal addresses on
remote networks. remote networks.
7) Added negotiation of tunnel vs transport mode. 7) Added negotiation of tunnel vs. transport mode.
H.5 Changes from IKEv2-04 to IKEv2-05 February 2003 H.5 Changes from IKEv2-04 to IKEv2-05 February 2003
1) Shortened Abstract 1) Shortened Abstract
2) Moved NAT Traversal from Appendix to section 2. Moved changes from 2) Moved NAT Traversal from Appendix to section 2. Moved changes from
IKEv2 to Appendix A. Renumbered sections. IKEv2 to Appendix A. Renumbered sections.
3) Made language more consistent. Removed most references to Phase 1 3) Made language more consistent. Removed most references to Phase 1
and Phase 2. and Phase 2.
skipping to change at page 99, line 51 skipping to change at page 100, line 51
H.8 Changes from IKEv2-07 to IKEv2-08 May 2003 H.8 Changes from IKEv2-07 to IKEv2-08 May 2003
1) Numerous editorial corrections and clarifications. 1) Numerous editorial corrections and clarifications.
2) Renamed Gateway to Security Gateway. 2) Renamed Gateway to Security Gateway.
3) Made explicit that the ability to rekey SAs without restarting IKE 3) Made explicit that the ability to rekey SAs without restarting IKE
was optional. was optional.
4) Removed last references to MUST and SHOULD ciphersuites. 4) Removed last references to MUST and SHOULD cipher suites.
5) Changed examples to "example.com". 5) Changed examples to "example.com".
6) Changed references to status codes to status types. 6) Changed references to status codes to status types.
7) Simplified IANA Considerations section 7) Simplified IANA Considerations section
8) Updated References 8) Updated References
H.9 Changes from IKEv2-08 to IKEv2-09 August 2003 H.9 Changes from IKEv2-08 to IKEv2-09 August 2003
skipping to change at page 101, line 24 skipping to change at page 102, line 24
H.11 Changes from IKEv2-10 to IKEv2-11 October 2003 H.11 Changes from IKEv2-10 to IKEv2-11 October 2003
1) Added SHOULD NOT language concerning use of non-key-generating EAP 1) Added SHOULD NOT language concerning use of non-key-generating EAP
authentication methods and added reference [EAPMITM]. authentication methods and added reference [EAPMITM].
2) Clarified use of parallel SAs with identical traffic selectors for 2) Clarified use of parallel SAs with identical traffic selectors for
purposes of QoS handling. purposes of QoS handling.
3) Fixed description of ECN handling to make normative references to 3) Fixed description of ECN handling to make normative references to
[RFC 2401bis] and [RFC 3168]. [RFC2401bis] and [RFC3168].
4) Fixed two typos in the description of NAT traversal. 4) Fixed two typos in the description of NAT traversal.
5) Added specific ASN.1 encoding of certificate bundles in section 5) Added specific ASN.1 encoding of certificate bundles in section
3.6. 3.6.
H.12 Changes from IKEv2-11 to IKEv2-12 January 2004 H.12 Changes from IKEv2-11 to IKEv2-12 January 2004
1) Made the values of the one byte IPsec Protocol ID consistent 1) Made the values of the one byte IPsec Protocol ID consistent
between payloads and made the naming more nearly consistent. between payloads and made the naming more nearly consistent.
skipping to change at page 102, line 25 skipping to change at page 103, 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 H.13 Changes from IKEv2-12 to IKEv2-13 March 2004
1) Updated copyright and intellectual property right sections per RFC 1) Updated copyright and intellectual property right sections per RFC
3667. Added normative references to RFC 3667 and RFC 3668. 3667. Added normative references to RFC 3667 and RFC 3668.
2) Updated IANA Considerations section and adjusted some assignment 2) Updated IANA Considerations section and adjusted some assignment
tables to be consistent with the IANA registries document. Added tables to be consistent with the IANA registries document. Added
Michael Richardson to the acknowledgements. Michael Richardson to the acknowledgements.
3) Changed the cryptographic formula for computing the AUTH payload 3) Changed the cryptographic formula for computing the AUTH payload
in the case where EAP authentication is used and the EAP algorithm in the case where EAP authentication is used and the EAP algorithm
skipping to change at page 103, line 5 skipping to change at page 104, line 5
normative. normative.
6) Added notification type ESP_TFC_PADDING_NOT_SUPPORTED. 6) Added notification type ESP_TFC_PADDING_NOT_SUPPORTED.
7) Clarified encoding of port number fields in transport selectors in 7) Clarified encoding of port number fields in transport selectors in
the cases of ICMP and OPAQUE. the cases of ICMP and OPAQUE.
8) Clarified that the length of the integrity checksum is fixed 8) Clarified that the length of the integrity checksum is fixed
length and determined by the negotiated integrity algorithm. length and determined by the negotiated integrity algorithm.
9) Added an informative reference to RFC3715 (NAT Compatibility 9) Added an informative reference to RFC 3715 (NAT Compatibility
Requirements). Requirements).
10) Fixed 2 typos. 10) Fixed 2 typos.
H.14 Changes from IKEv2-13 to IKEv2-14 May 2004
1) ISSUE #99: Clarified use of tunnel mode vs. transport mode.
2) Changed the cryptographic formula for computing the AUTH payload
in response to a suggestion from Hugo Krawczyk.
3) Fixed a wording error in the explanation of why NAT traversal
works as it does related to processing by legacy NAT gateways.
4) Corrected the label AUTH_AES_XCBC_96 to AUTH_AES_PRF_128.
5) Deleted suggestion that ID_KEY_ID field might be used to pass an
account name.
6) Listed the newly allocated OID for certificate bundle.
7) Added NON_FIRST_FRAGMENTS_ALSO notification for negotiating the
ability to send non-initial fragments of packets on the same SA as
the initial fragments.
8) ISSUE #97: Removed language concerning the relative strength of
Diffie-Hellman groups.
9) ISSUE #100: Reduced requirements concerning sending of
certificates to allow implementations to by more coy about their
identities and protect themselves from probing attacks. Listed in
Security Considerations some issues an implementer might consider in
deciding how to deal with such attacks.
10) Made the punctuation of references to RFCs more consistent.
11) Fixed fourteen 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
skipping to change at page 105, line 12 skipping to change at page 106, line 12
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. 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-13.txt) expires in This Internet-Draft (draft-ietf-ipsec-ikev2-14.txt) expires in
September 2004. November 2004.
 End of changes. 70 change blocks. 
133 lines changed or deleted 239 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/