Internet Key Exchange Protocol Version 2 (IKEv2)
RFC 7296
also known as STD 79
| Document | Type |
RFC
- Internet Standard
(October 2014)
Errata
IPR
Obsoletes RFC 5996
|
|
|---|---|---|---|
| Authors | Charlie Kaufman , Paul E. Hoffman , Yoav Nir , Pasi Eronen , Tero Kivinen | ||
| Last updated | 2021-09-02 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Kathleen Moriarty | |
| Send notices to | (None) |
RFC 7296
's netmask. Only one
netmask is allowed in the request and response messages (e.g.,
255.255.255.0), and it MUST be used only with an
INTERNAL_IP4_ADDRESS attribute. INTERNAL_IP4_NETMASK in a
CFG_REPLY means roughly the same thing as INTERNAL_IP4_SUBNET
Kaufman, et al. Standards Track [Page 114]
RFC 7296 IKEv2bis October 2014
containing the same information ("send traffic to these addresses
through me"), but also implies a link boundary. For instance, the
client could use its own address and the netmask to calculate the
broadcast address of the link. An empty INTERNAL_IP4_NETMASK
attribute can be included in a CFG_REQUEST to request this
information (although the gateway can send the information even
when not requested). Non-empty values for this attribute in a
CFG_REQUEST do not make sense and thus MUST NOT be included.
o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a DNS
server within the network. Multiple DNS servers MAY be requested.
The responder MAY respond with zero or more DNS server attributes.
o INTERNAL_IP4_NBNS - Specifies an address of a NetBios Name Server
(WINS) within the network. Multiple NBNS servers MAY be
requested. The responder MAY respond with zero or more NBNS
server attributes.
o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to send
any internal DHCP requests to the address contained within the
attribute. Multiple DHCP servers MAY be requested. The responder
MAY respond with zero or more DHCP server attributes.
o APPLICATION_VERSION - The version or application information of
the IPsec host. This is a string of printable ASCII characters
that is NOT null terminated.
o INTERNAL_IP4_SUBNET - The protected sub-networks that this edge-
device protects. This attribute is made up of two fields: the
first being an IP address and the second being a netmask.
Multiple sub-networks MAY be requested. The responder MAY respond
with zero or more sub-network attributes. This is discussed in
more detail in Section 3.15.2.
o SUPPORTED_ATTRIBUTES - When used within a Request, this attribute
MUST be zero-length and specifies a query to the responder to
reply back with all of the attributes that it supports. The
response contains an attribute that contains a set of attribute
identifiers each in 2 octets. The length divided by 2 (octets)
would state the number of supported attributes contained in the
response.
o INTERNAL_IP6_SUBNET - The protected sub-networks that this
edge-device protects. This attribute is made up of two fields:
the first is a 16-octet IPv6 address, and the second is a
one-octet prefix-length as defined in [ADDRIPV6]. Multiple
Kaufman, et al. Standards Track [Page 115]
RFC 7296 IKEv2bis October 2014
sub-networks MAY be requested. The responder MAY respond with
zero or more sub-network attributes. This is discussed in more
detail in Section 3.15.2.
Note that no recommendations are made in this document as to how an
implementation actually figures out what information to send in a
response. That is, we do not recommend any specific method of an
IRAS determining which DNS server should be returned to a requesting
IRAC.
The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to request
information from its peer. If an attribute in the CFG_REQUEST
Configuration payload is not zero-length, it is taken as a suggestion
for that attribute. The CFG_REPLY Configuration payload MAY return
that value, or a new one. It MAY also add new attributes and not
include some requested ones. Unrecognized or unsupported attributes
MUST be ignored in both requests and responses.
The CFG_SET and CFG_ACK pair allows an IKE endpoint to push
configuration data to its peer. In this case, the CFG_SET
Configuration payload contains attributes the initiator wants its
peer to alter. The responder MUST return a Configuration payload if
it accepted any of the configuration data, and the Configuration
payload MUST contain the attributes that the responder accepted with
zero-length data. Those attributes that it did not accept MUST NOT
be in the CFG_ACK Configuration payload. If no attributes were
accepted, the responder MUST return either an empty CFG_ACK payload
or a response message without a CFG_ACK payload. There are currently
no defined uses for the CFG_SET/CFG_ACK exchange, though they may be
used in connection with extensions based on Vendor IDs. An
implementation of this specification MAY ignore CFG_SET payloads.
3.15.2. Meaning of INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET
INTERNAL_IP4/6_SUBNET attributes can indicate additional subnets,
ones that need one or more separate SAs, that can be reached through
the gateway that announces the attributes. INTERNAL_IP4/6_SUBNET
attributes may also express the gateway's policy about what traffic
should be sent through the gateway; the client can choose whether
other traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is
sent through the gateway or directly to the destination. Thus,
traffic to the addresses listed in the INTERNAL_IP4/6_SUBNET
attributes should be sent through the gateway that announces the
attributes. If there are no existing Child SAs whose Traffic
Selectors cover the address in question, new SAs need to be created.
Kaufman, et al. Standards Track [Page 116]
RFC 7296 IKEv2bis October 2014
For instance, if there are two subnets, 198.51.100.0/26 and
192.0.2.0/24, and the client's request contains the following:
CP(CFG_REQUEST) =
INTERNAL_IP4_ADDRESS()
TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)
then a valid response could be the following (in which TSr and
INTERNAL_IP4_SUBNET contain the same information):
CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(198.51.100.234)
INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
TSr = ((0, 0-65535, 198.51.100.0-198.51.100.63),
(0, 0-65535, 192.0.2.0-192.0.2.255))
In these cases, the INTERNAL_IP4_SUBNET does not really carry any
useful information.
A different possible response would have been this:
CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(198.51.100.234)
INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)
That response would mean that the client can send all its traffic
through the gateway, but the gateway does not mind if the client
sends traffic not included by INTERNAL_IP4_SUBNET directly to the
destination (without going through the gateway).
A different situation arises if the gateway has a policy that
requires the traffic for the two subnets to be carried in separate
SAs. Then a response like this would indicate to the client that
if it wants access to the second subnet, it needs to create a
separate SA:
CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(198.51.100.234)
INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
TSr = (0, 0-65535, 198.51.100.0-198.51.100.63)
Kaufman, et al. Standards Track [Page 117]
RFC 7296 IKEv2bis October 2014
INTERNAL_IP4_SUBNET can also be useful if the client's TSr included
only part of the address space. For instance, if the client requests
the following:
CP(CFG_REQUEST) =
INTERNAL_IP4_ADDRESS()
TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)
then the gateway's response might be:
CP(CFG_REPLY) =
INTERNAL_IP4_ADDRESS(198.51.100.234)
INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)
Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET in
CFG_REQUESTs is unclear, they cannot be used reliably in
CFG_REQUESTs.
3.15.3. Configuration Payloads for IPv6
The Configuration payloads for IPv6 are based on the corresponding
IPv4 payloads, and do not fully follow the "normal IPv6 way of doing
things". In particular, IPv6 stateless autoconfiguration or router
advertisement messages are not used, neither is neighbor discovery.
Note that there is an additional document that discusses IPv6
configuration in IKEv2, [IPV6CONFIG]. At the present time, it is an
experimental document, but there is a hope that with more
implementation experience, it will gain the same standards treatment
as this document.
Kaufman, et al. Standards Track [Page 118]
RFC 7296 IKEv2bis October 2014
A client can be assigned an IPv6 address using the
INTERNAL_IP6_ADDRESS Configuration payload. A minimal exchange might
look like this:
CP(CFG_REQUEST) =
INTERNAL_IP6_ADDRESS()
INTERNAL_IP6_DNS()
TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
CP(CFG_REPLY) =
INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5)
TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
The client MAY send a non-empty INTERNAL_IP6_ADDRESS attribute in the
CFG_REQUEST to request a specific address or interface identifier.
The gateway first checks if the specified address is acceptable, and
if it is, returns that one. If the address was not acceptable, the
gateway attempts to use the interface identifier with some other
prefix; if even that fails, the gateway selects another interface
identifier.
The INTERNAL_IP6_ADDRESS attribute also contains a prefix length
field. When used in a CFG_REPLY, this corresponds to the
INTERNAL_IP4_NETMASK attribute in the IPv4 case.
Although this approach to configuring IPv6 addresses is reasonably
simple, it has some limitations. IPsec tunnels configured using
IKEv2 are not fully featured "interfaces" in the IPv6 addressing
architecture sense [ADDRIPV6]. In particular, they do not
necessarily have link-local addresses, and this may complicate the
use of protocols that assume them, such as [MLDV2].
3.15.4. Address Assignment Failures
If the responder encounters an error while attempting to assign an IP
address to the initiator during the processing of a Configuration
payload, it responds with an INTERNAL_ADDRESS_FAILURE notification.
The IKE SA is still created even if the initial Child SA cannot be
created because of this failure. If this error is generated within
an IKE_AUTH exchange, no Child SA will be created. However, there
are some more complex error cases.
If the responder does not support Configuration payloads at all, it
can simply ignore all Configuration payloads. This type of
implementation never sends INTERNAL_ADDRESS_FAILURE notifications.
Kaufman, et al. Standards Track [Page 119]
RFC 7296 IKEv2bis October 2014
If the initiator requires the assignment of an IP address, it will
treat a response without CFG_REPLY as an error.
The initiator may request a particular type of address (IPv4 or IPv6)
that the responder does not support, even though the responder
supports Configuration payloads. In this case, the responder simply
ignores the type of address it does not support and processes the
rest of the request as usual.
If the initiator requests multiple addresses of a type that the
responder supports, and some (but not all) of the requests fail, the
responder replies with the successful addresses only. The responder
sends INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned.
If the initiator does not receive the IP address(es) required by its
policy, it MAY keep the IKE SA up and retry the Configuration payload
as separate INFORMATIONAL exchange after suitable timeout, or it MAY
tear down the IKE SA by sending a Delete payload inside a separate
INFORMATIONAL exchange and later retry IKE SA from the beginning
after some timeout. Such a timeout should not be too short
(especially if the IKE SA is started from the beginning) because
these error situations may not be able to be fixed quickly; the
timeout should likely be several minutes. For example, an address
shortage problem on the responder will probably only be fixed when
more entries are returned to the address pool when other clients
disconnect or when responder is reconfigured with larger address
pool.
3.16. Extensible Authentication Protocol (EAP) Payload
The Extensible Authentication Protocol payload, denoted EAP in this
document, allows IKE SAs to be authenticated using the protocol
defined in RFC 3748 [EAP] and subsequent extensions to that protocol.
When using EAP, an appropriate EAP method needs to be selected. Many
of these methods have been defined, specifying the protocol's use
with various authentication mechanisms. EAP method types are listed
in [EAP-IANA]. A short summary of the EAP format is included here
for clarity.
Kaufman, et al. Standards Track [Page 120]
RFC 7296 IKEv2bis October 2014
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ EAP Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: EAP Payload Format
The payload type for an EAP payload is forty-eight (48).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Type_Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 25: EAP Message Format
o Code (1 octet) - Indicates whether this message is a Request (1),
Response (2), Success (3), or Failure (4).
o Identifier (1 octet) - Used in PPP to distinguish replayed
messages from repeated ones. Since in IKE, EAP runs over a
reliable protocol, the Identifier serves no function here. In a
response message, this octet MUST be set to match the identifier
in the corresponding request.
o Length (2 octets, unsigned integer) - The length of the EAP
message. MUST be four less than the Payload Length of the
encapsulating payload.
o Type (1 octet) - Present only if the Code field is Request (1) or
Response (2). For other codes, the EAP message length MUST be
four octets and the Type and Type_Data fields MUST NOT be present.
In a Request (1) message, Type indicates the data being requested.
In a Response (2) message, Type MUST either be Nak or match the
type of the data requested. Note that since IKE passes an
indication of initiator identity in the first message in the
IKE_AUTH exchange, the responder SHOULD NOT send EAP Identity
requests (type 1). The initiator MAY, however, respond to such
requests if it receives them.
Kaufman, et al. Standards Track [Page 121]
RFC 7296 IKEv2bis October 2014
o Type_Data (variable length) - Varies with the Type of Request and
the associated Response. For the documentation of the EAP
methods, see [EAP].
Note that since IKE passes an indication of initiator identity in the
first message in the IKE_AUTH exchange, the responder SHOULD NOT send
EAP Identity requests. The initiator MAY, however, respond to such
requests if it receives them.
4. Conformance Requirements
In order to assure that all implementations of IKEv2 can
interoperate, there are "MUST support" requirements in addition to
those listed elsewhere. Of course, IKEv2 is a security protocol, and
one of its major functions is to allow only authorized parties to
successfully complete establishment of SAs. So a particular
implementation may be configured with any of a number of restrictions
concerning algorithms and trusted authorities that will prevent
universal interoperability.
IKEv2 is designed to permit minimal implementations that can
interoperate with all compliant implementations. The following are
features that can be omitted in a minimal implementation:
o Ability to negotiate SAs through a NAT and tunnel the resulting
ESP SA over UDP.
o Ability to request (and respond to a request for) a temporary IP
address on the remote end of a tunnel.
o Ability to support EAP-based authentication.
o Ability to support window sizes greater than one.
o Ability to establish multiple ESP or AH SAs within a single
IKE SA.
o Ability to rekey SAs.
To assure interoperability, all implementations MUST be capable of
parsing all payload types (if only to skip over them) and to ignore
payload types that it does not support unless the critical bit is set
in the payload header. If the critical bit is set in an unsupported
payload header, all implementations MUST reject the messages
containing those payloads.
Kaufman, et al. Standards Track [Page 122]
RFC 7296 IKEv2bis October 2014
Every implementation MUST be capable of doing four-message
IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE,
one for ESP or AH). Implementations MAY be initiate-only or respond-
only if appropriate for their platform. Every implementation MUST be
capable of responding to an INFORMATIONAL exchange, but a minimal
implementation MAY respond to any request in the INFORMATIONAL
exchange with an empty response (note that within the context of an
IKE SA, an "empty" message consists of an IKE header followed by an
Encrypted payload with no payloads contained in it). A minimal
implementation MAY support the CREATE_CHILD_SA exchange only in so
far as to recognize requests and reject them with a Notify payload of
type NO_ADDITIONAL_SAS. A minimal implementation need not be able to
initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA
expires (based on locally configured values of either lifetime or
octets passed), an implementation MAY either try to renew it with a
CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and
create a new one. If the responder rejects the CREATE_CHILD_SA
request with a NO_ADDITIONAL_SAS notification, the implementation
MUST be capable of instead deleting the old SA and creating a
new one.
Implementations are not required to support requesting temporary IP
addresses or responding to such requests. If an implementation does
support issuing such requests and its policy requires using temporary
IP addresses, it MUST include a CP payload in the first message in
the IKE_AUTH exchange containing at least a field of type
INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. All other fields are
optional. If an implementation supports responding to such requests,
it MUST parse the CP payload of type CFG_REQUEST in the first message
in the IKE_AUTH exchange and recognize a field of type
INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports leasing
an address of the appropriate type, it MUST return a CP payload of
type CFG_REPLY containing an address of the requested type. The
responder may include any other related attributes.
For an implementation to be called conforming to this specification,
it MUST be possible to configure it to accept the following:
o Public Key Infrastructure using X.509 (PKIX) Certificates
containing and signed by RSA keys of size 1024 or 2048 bits, where
the ID passed is any of ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR, or
ID_DER_ASN1_DN.
o Shared key authentication where the ID passed is any of ID_KEY_ID,
ID_FQDN, or ID_RFC822_ADDR.
Kaufman, et al. Standards Track [Page 123]
RFC 7296 IKEv2bis October 2014
o Authentication where the responder is authenticated using PKIX
Certificates and the initiator is authenticated using shared key
authentication.
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) not only can probe the initiator for its identity but may,
by using CERTREQ payloads, 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 additional Diffie-
Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a
single key. Implementers should take note of this fact and set a
limit on CREATE_CHILD_SA exchanges between exponentiations. This
document does not prescribe such a limit.
The strength of a key derived from a Diffie-Hellman exchange using
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 random number generator used. Due to these inputs, it is
difficult to determine the strength of a key for any of the defined
groups. Diffie-Hellman group number two, when used with a strong
random number generator and an exponent no less than 200 bits, is
common for use with 3DES. Group five provides greater security than
group two. Group one is for historic purposes only and does not
provide sufficient strength except for use with DES, which is also
for historic use only. Implementations should make note of these
estimates when establishing policy and negotiating security
parameters.
Note that these limitations are on the Diffie-Hellman groups
themselves. There is nothing in IKE that prohibits using stronger
groups nor is there anything that will dilute the strength obtained
from stronger groups (limited by the strength of the other algorithms
Kaufman, et al. Standards Track [Page 124]
RFC 7296 IKEv2bis October 2014
negotiated including the PRF). In fact, the extensible framework of
IKE encourages the definition of more groups; use of elliptic curve
groups may greatly increase strength using much smaller numbers.
It is assumed that all Diffie-Hellman exponents are erased from
memory after use.
The IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator
has been authenticated. As a result, an implementation of this
protocol needs to be completely robust when deployed on any insecure
network. Implementation vulnerabilities, particularly DoS attacks,
can be exploited by unauthenticated peers. This issue is
particularly worrisome because of the unlimited number of messages in
EAP-based authentication.
The strength of all keys is limited by the size of the output of the
negotiated PRF. For this reason, a PRF whose output is less than
128 bits (e.g., 3DES-CBC) MUST NOT be used with this protocol.
The security of this protocol is critically dependent on the
randomness of the randomly chosen parameters. These should be
generated by a strong random or properly seeded pseudorandom source
(see [RANDOMNESS]). Implementers should take care to ensure that use
of random numbers for both keys and nonces is engineered in a fashion
that does not undermine the security of the keys.
For information on the rationale of many of the cryptographic design
choices in this protocol, see [SIGMA] and [SKEME]. Though the
security of negotiated Child SAs does not depend on the strength of
the encryption and integrity protection negotiated in the IKE SA,
implementations MUST NOT negotiate NONE as the IKE integrity
protection algorithm or ENCR_NULL as the IKE encryption algorithm.
When using pre-shared keys, a critical consideration is how to assure
the randomness of these secrets. The strongest practice is to ensure
that any pre-shared key contain as much randomness as the strongest
key being negotiated. Deriving a shared secret from a password,
name, or other low-entropy source is not secure. These sources are
subject to dictionary and social-engineering attacks, among others.
The NAT_DETECTION_*_IP notifications contain a hash of the addresses
and ports in an attempt to hide internal IP addresses behind a NAT.
Since the IPv4 address space is only 32 bits, and it is usually very
sparse, it would be possible for an attacker to find out the internal
address used behind the NAT box by trying all possible IP addresses
and trying to find the matching hash. The port numbers are normally
fixed to 500, and the SPIs can be extracted from the packet. This
reduces the number of hash calculations to 2^32. With an educated
Kaufman, et al. Standards Track [Page 125]
RFC 7296 IKEv2bis October 2014
guess of the use of private address space, the number of hash
calculations is much smaller. Designers should therefore not assume
that use of IKE will not leak internal address information.
When using an EAP authentication method that does not generate a
shared key for protecting a subsequent AUTH payload, certain man-in-
the-middle and server-impersonation attacks are possible [EAPMITM].
These vulnerabilities occur when EAP is also used in protocols that
are not protected with a secure tunnel. Since EAP is a general-
purpose authentication protocol, which is often used to provide
single-signon facilities, a deployed IPsec solution that relies on an
EAP authentication method that does not generate a shared key (also
known as a non-key-generating EAP method) can become compromised due
to the deployment of an entirely unrelated application that also
happens to use the same non-key-generating EAP method, but in an
unprotected fashion. Note that this vulnerability is not limited to
just EAP, but can occur in other scenarios where an authentication
infrastructure is reused. For example, if the EAP mechanism used by
IKEv2 utilizes a token authenticator, a man-in-the-middle attacker
could impersonate the web server, intercept the token authentication
exchange, and use it to initiate an IKEv2 connection. For this
reason, use of non-key-generating EAP methods SHOULD be avoided where
possible. Where they are used, it is extremely important that all
usages of these EAP methods SHOULD utilize a protected tunnel, where
the initiator validates the responder's certificate before initiating
the EAP authentication. Implementers should describe the
vulnerabilities of using non-key-generating EAP methods in the
documentation of their implementations so that the administrators
deploying IPsec solutions are aware of these dangers.
An implementation using EAP MUST also use a public-key-based
authentication of the server to the client before the EAP
authentication begins, even if the EAP method offers mutual
authentication. This avoids having additional IKEv2 protocol
variations and protects the EAP data from active attackers.
If the messages of IKEv2 are long enough that IP-level fragmentation
is necessary, it is possible that attackers could prevent the
exchange from completing by exhausting the reassembly buffers. The
chances of this can be minimized by using the Hash and URL encodings
instead of sending certificates (see Section 3.6). Additional
mitigations are discussed in [DOSUDPPROT].
Admission control is critical to the security of the protocol. For
example, trust anchors used for identifying IKE peers should probably
be different than those used for other forms of trust, such as those
used to identify public web servers. Moreover, although IKE provides
a great deal of leeway in defining the security policy for a trusted
Kaufman, et al. Standards Track [Page 126]
RFC 7296 IKEv2bis October 2014
peer's identity, credentials, and the correlation between them,
having such security policy defined explicitly is essential to a
secure implementation.
5.1. Traffic Selector Authorization
IKEv2 relies on information in the Peer Authorization Database (PAD)
when determining what kind of Child SAs a peer is allowed to create.
This process is described in Section 4.4.3 of [IPSECARCH]. When a
peer requests the creation of a Child SA with some Traffic Selectors,
the PAD must contain "Child SA Authorization Data" linking the
identity authenticated by IKEv2 and the addresses permitted for
Traffic Selectors.
For example, the PAD might be configured so that authenticated
identity "sgw23.example.com" is allowed to create Child SAs for
192.0.2.0/24, meaning this security gateway is a valid
"representative" for these addresses. Host-to-host IPsec requires
similar entries, linking, for example, "fooserver4.example.com" with
198.51.100.66/32, meaning this identity is a valid "owner" or
"representative" of the address in question.
As noted in [IPSECARCH], "It is necessary to impose these constraints
on creation of child SAs to prevent an authenticated peer from
spoofing IDs associated with other, legitimate peers". In the
example given above, a correct configuration of the PAD prevents
sgw23 from creating Child SAs with address 198.51.100.66, and
prevents fooserver4 from creating Child SAs with addresses from
192.0.2.0/24.
It is important to note that simply sending IKEv2 packets using some
particular address does not imply a permission to create Child SAs
with that address in the Traffic Selectors. For example, even if
sgw23 would be able to spoof its IP address as 198.51.100.66, it
could not create Child SAs matching fooserver4's traffic.
The IKEv2 specification does not specify how exactly IP address
assignment using Configuration payloads interacts with the PAD. Our
interpretation is that when a security gateway assigns an address
using Configuration payloads, it also creates a temporary PAD entry
linking the authenticated peer identity and the newly allocated inner
address.
It has been recognized that configuring the PAD correctly may be
difficult in some environments. For instance, if IPsec is used
between a pair of hosts whose addresses are allocated dynamically
using DHCP, it is extremely difficult to ensure that the PAD
Kaufman, et al. Standards Track [Page 127]
RFC 7296 IKEv2bis October 2014
specifies the correct "owner" for each IP address. This would
require a mechanism to securely convey address assignments from the
DHCP server, and link them to identities authenticated using IKEv2.
Due to this limitation, some vendors have been known to configure
their PADs to allow an authenticated peer to create Child SAs with
Traffic Selectors containing the same address that was used for the
IKEv2 packets. In environments where IP spoofing is possible (i.e.,
almost everywhere) this essentially allows any peer to create Child
SAs with any Traffic Selectors. This is not an appropriate or secure
configuration in most circumstances. See [H2HIPSEC] for an extensive
discussion about this issue, and the limitations of host-to-host
IPsec in general.
6. IANA Considerations
[IKEV2] defined many field types and values. IANA has already
registered those types and values in [IKEV2IANA], so they are not
listed here again.
One item has been deprecated from the "IKEv2 Certificate Encodings"
registry: "Raw RSA Key".
IANA has updated all references to RFC 5996 to point to this
document.
7. References
7.1. Normative References
[ADDGROUP] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, May 2003,
<http://www.rfc-editor.org/info/rfc3526>.
[ADDRIPV6] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006,
<http://www.rfc-editor.org/info/rfc4291>.
[AEAD] Black, D. and D. McGrew, "Using Authenticated Encryption
Algorithms with the Encrypted Payload of the Internet Key
Exchange version 2 (IKEv2) Protocol", RFC 5282, August
2008, <http://www.rfc-editor.org/info/rfc5282>.
Kaufman, et al. Standards Track [Page 128]
RFC 7296 IKEv2bis October 2014
[AESCMACPRF128]
Song, J., Poovendran, R., Lee, J., and T. Iwata, "The
Advanced Encryption Standard-Cipher-based Message
Authentication Code-Pseudo-Random Function-128 (AES-CMAC-
PRF-128) Algorithm for the Internet Key Exchange Protocol
(IKE)", RFC 4615, August 2006,
<http://www.rfc-editor.org/info/rfc4615>.
[AESXCBCPRF128]
Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
Internet Key Exchange Protocol (IKE)", RFC 4434, February
2006, <http://www.rfc-editor.org/info/rfc4434>.
[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004, <http://www.rfc-editor.org/info/rfc3748>.
[ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC
3168, September 2001,
<http://www.rfc-editor.org/info/rfc3168>.
[ESPCBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, November 1998,
<http://www.rfc-editor.org/info/rfc2451>.
[IKEV2IANA]
IANA, "Internet Key Exchange Version 2 (IKEv2)
Parameters",
<http://www.iana.org/assignments/ikev2-parameters/>.
[IPSECARCH]
Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005,
<http://www.rfc-editor.org/info/rfc4301>.
[MUSTSHOULD]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003,
<http://www.rfc-editor.org/info/rfc3447>.
Kaufman, et al. Standards Track [Page 129]
RFC 7296 IKEv2bis October 2014
[PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>.
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
December 2005, <http://www.rfc-editor.org/info/rfc4307>.
[UDPENCAPS]
Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC
3948, January 2005,
<http://www.rfc-editor.org/info/rfc3948>.
[URLS] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
7.2. Informative References
[AH] Kent, S., "IP Authentication Header", RFC 4302, December
2005, <http://www.rfc-editor.org/info/rfc4302>.
[ARCHGUIDEPHIL]
Bush, R. and D. Meyer, "Some Internet Architectural
Guidelines and Philosophy", RFC 3439, December 2002,
<http://www.rfc-editor.org/info/rfc3439>.
[ARCHPRINC]
Carpenter, B., "Architectural Principles of the Internet",
RFC 1958, June 1996,
<http://www.rfc-editor.org/info/rfc1958>.
[Clarif] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
Implementation Guidelines", RFC 4718, October 2006,
<http://www.rfc-editor.org/info/rfc4718>.
[DES] American National Standards Institute, "American National
Standard for Information Systems-Data Link Encryption",
ANSI X3.106, 1983.
[DH] Diffie, W. and M. Hellman, "New Directions in
Cryptography", IEEE Transactions on Information Theory,
V.IT-22 n. 6, June 1977.
Kaufman, et al. Standards Track [Page 130]
RFC 7296 IKEv2bis October 2014
[DIFFSERVARCH]
Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998,
<http://www.rfc-editor.org/info/rfc2475>.
[DIFFSERVFIELD]
Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998, <http://www.rfc-editor.org/info/rfc2474>.
[DIFFTUNNEL]
Black, D., "Differentiated Services and Tunnels", RFC
2983, October 2000,
<http://www.rfc-editor.org/info/rfc2983>.
[DOI] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998,
<http://www.rfc-editor.org/info/rfc2407>.
[DOSUDPPROT]
Kaufman, C., Perlman, R., and B. Sommerfeld, "DoS
protection for UDP-based protocols", ACM Conference on
Computer and Communications Security, October 2003.
[DSS] National Institute of Standards and Technology, U.S.
Department of Commerce, "Digital Signature Standard
(DSS)", FIPS 186-4, July 2013,
<http://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.186-4.pdf>.
[EAI] Yang, A., Steele, S., and N. Freed, "Internationalized
Email Headers", RFC 6532, February 2012,
<http://www.rfc-editor.org/info/rfc6532>.
[EAP-IANA] IANA, "Extensible Authentication Protocol (EAP) Registry:
Method Types",
<http://http://www.iana.org/assignments/eap-eke/>.
[EAPMITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
in Tunneled Authentication Protocols", November 2002,
<http://eprint.iacr.org/2002/163>.
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005,
<http://www.rfc-editor.org/info/rfc4303>.
Kaufman, et al. Standards Track [Page 131]
RFC 7296 IKEv2bis October 2014
[EXCHANGEANALYSIS]
Perlman, R. and C. Kaufman, "Analysis of the IPsec key
exchange Standard", WET-ICE Security Conference, MIT,
2001, <http://www.computer.org/csdl/proceedings/
wetice/2001/1269/00/12690150.pdf>.
[FIPS.180-4.2012]
National Institute of Standards and Technology, U.S.
Department of Commerce, "Secure Hash Standard (SHS)", FIPS
180-4, March 2012,
<http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>.
[H2HIPSEC] Aura, T., Roe, M., and A. Mohammed, "Experiences with
Host-to-Host IPsec", 13th International Workshop on
Security Protocols, Cambridge, UK, April 2005.
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997, <http://www.rfc-editor.org/info/rfc2104>.
[IDEA] Lai, X., "On the Design and Security of Block Ciphers",
ETH Series in Information Processing, v. 1, Konstanz:
Hartung-Gorre Verlag, 1992.
[IDNA] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010,
<http://www.rfc-editor.org/info/rfc5890>.
[IKEV1] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998,
<http://www.rfc-editor.org/info/rfc2409>.
[IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005,
<http://www.rfc-editor.org/info/rfc4306>.
[IP] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981, <http://www.rfc-editor.org/info/rfc791>.
[IP-COMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP
Payload Compression Protocol (IPComp)", RFC 3173,
September 2001, <http://www.rfc-editor.org/info/rfc3173>.
Kaufman, et al. Standards Track [Page 132]
RFC 7296 IKEv2bis October 2014
[IPSECARCH-OLD]
Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998,
<http://www.rfc-editor.org/info/rfc2401>.
[IPV6CONFIG]
Eronen, P., Laganier, J., and C. Madson, "IPv6
Configuration in Internet Key Exchange Protocol Version 2
(IKEv2)", RFC 5739, February 2010,
<http://www.rfc-editor.org/info/rfc5739>.
[ISAKMP] Maughan, D., Schneider, M., and M. Schertler, "Internet
Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998,
<http://www.rfc-editor.org/info/rfc2408>.
[MAILFORMAT]
Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008, <http://www.rfc-editor.org/info/rfc5322>.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992, <http://www.rfc-editor.org/info/rfc1321>.
[MIPV6] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011,
<http://www.rfc-editor.org/info/rfc6275>.
[MLDV2] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004,
<http://www.rfc-editor.org/info/rfc3810>.
[MOBIKE] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006,
<http://www.rfc-editor.org/info/rfc4555>.
[MODES] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation", National Institute of Standards and
Technology, NIST Special Publication 800-38A 2001 Edition,
December 2001.
[NAI] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005,
<http://www.rfc-editor.org/info/rfc4282>.
[NATREQ] Aboba, B. and W. Dixon, "IPsec-Network Address Translation
(NAT) Compatibility Requirements", RFC 3715, March 2004,
<http://www.rfc-editor.org/info/rfc3715>.
Kaufman, et al. Standards Track [Page 133]
RFC 7296 IKEv2bis October 2014
[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", RFC
2412, November 1998,
<http://www.rfc-editor.org/info/rfc2412>.
[PFKEY] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
Management API, Version 2", RFC 2367, July 1998,
<http://www.rfc-editor.org/info/rfc2367>.
[PHOTURIS] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999,
<http://www.rfc-editor.org/info/rfc2522>.
[RANDOMNESS]
Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
June 2005, <http://www.rfc-editor.org/info/rfc4086>.
[REAUTH] Nir, Y., "Repeated Authentication in Internet Key Exchange
(IKEv2) Protocol", RFC 4478, April 2006,
<http://www.rfc-editor.org/info/rfc4478>.
[REUSE] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In
Diffie-Hellman Key Agreement Protocols", December 2008,
<http://www.cacr.math.uwaterloo.ca/techreports/2008/
cacr2008-24.pdf>.
[RFC4945] Korver, B., "The Internet IP Security PKI Profile of
IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007,
<http://www.rfc-editor.org/info/rfc4945>.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
5996, September 2010,
<http://www.rfc-editor.org/info/rfc5996>.
[RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman
Tests for the Internet Key Exchange Protocol Version 2
(IKEv2)", RFC 6989, July 2013,
<http://www.rfc-editor.org/info/rfc6989>.
[ROHCV2] Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C.
Bormann, "IKEv2 Extensions to Support Robust Header
Compression over IPsec", RFC 5857, May 2010,
<http://www.rfc-editor.org/info/rfc5857>.
Kaufman, et al. Standards Track [Page 134]
RFC 7296 IKEv2bis October 2014
[SIGMA] Krawczyk, H., "SIGMA: the 'SIGn-and-MAc' Approach to
Authenticated Diffie-Hellman and its Use in the IKE
Protocols", Advances in Cryptography - CRYPTO 2003
Proceedings LNCS 2729, 2003,
<http://www.informatik.uni-trier.de/~ley/db/conf/crypto/
crypto2003.html>.
[SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange
Mechanism for Internet", IEEE Proceedings of the 1996
Symposium on Network and Distributed Systems Security,
1996.
[TRANSPARENCY]
Carpenter, B., "Internet Transparency", RFC 2775, February
2000, <http://www.rfc-editor.org/info/rfc2775>.
Kaufman, et al. Standards Track [Page 135]
RFC 7296 IKEv2bis October 2014
Appendix A. Summary of Changes from IKEv1
The goals of this revision to IKE are:
1. To define the entire IKE protocol in a single document,
replacing RFCs 2407, 2408, and 2409 and incorporating subsequent
changes to support NAT traversal, Extensible Authentication, and
Remote Address acquisition;
2. To simplify IKE by replacing the eight different initial
exchanges with a single four-message exchange (with changes in
authentication mechanisms affecting only a single AUTH payload
rather than restructuring the entire exchange) see
[EXCHANGEANALYSIS];
3. To remove the Domain of Interpretation (DOI), Situation (SIT),
and Labeled Domain Identifier fields, and the Commit and
Authentication only bits;
4. To decrease IKE's latency in the common case by making the
initial exchange be 2 round trips (4 messages), and allowing the
ability to piggyback setup of a Child SA on that exchange;
5. To replace the cryptographic syntax for protecting the IKE
messages themselves with one based closely on ESP to simplify
implementation and security analysis;
6. To reduce the number of possible error states by making the
protocol reliable (all messages are acknowledged) and sequenced.
This allows shortening CREATE_CHILD_SA exchanges from 3 messages
to 2;
7. To increase robustness by allowing the responder to not do
significant processing until it receives a message proving that
the initiator can receive messages at its claimed IP address;
8. To fix cryptographic weaknesses such as the problem with
symmetries in hashes used for authentication (documented by Tero
Kivinen);
9. To specify Traffic Selectors in their own payloads type rather
than overloading ID payloads, and making more flexible the
Traffic Selectors that may be specified;
10. To specify required behavior under certain error conditions or
when data that is not understood is received in order to make it
easier to make future revisions in a way that does not break
backward compatibility;
Kaufman, et al. Standards Track [Page 136]
RFC 7296 IKEv2bis October 2014
11. To simplify and clarify how shared state is maintained in the
presence of network failures and DoS attacks; and
12. To maintain existing syntax and magic numbers to the extent
possible to make it likely that implementations of IKEv1 can be
enhanced to support IKEv2 with minimum effort.
Appendix B. Diffie-Hellman Groups
There are two Diffie-Hellman groups defined here for use in IKE.
These groups were generated by Richard Schroeppel at the University
of Arizona. Properties of these primes are described in [OAKLEY].
The strength supplied by group 1 may not be sufficient for typical
uses and is here for historic reasons.
Additional Diffie-Hellman groups have been defined in [ADDGROUP].
B.1. Group 1 - 768-bit MODP
This group is assigned ID 1 (one).
The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 }
Its hexadecimal value is:
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
The generator is 2.
B.2. Group 2 - 1024-bit MODP
This group is assigned ID 2 (two).
The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
Its hexadecimal value is:
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
FFFFFFFF FFFFFFFF
The generator is 2.
Kaufman, et al. Standards Track [Page 137]
RFC 7296 IKEv2bis October 2014
Appendix C. Exchanges and Payloads
This appendix contains a short summary of the IKEv2 exchanges, and
what payloads can appear in which message. This appendix is purely
informative; if it disagrees with the body of this document, the
other text is considered correct.
Vendor ID (V) payloads may be included in any place in any message.
This sequence here shows what are the most logical places for them.
C.1. IKE_SA_INIT Exchange
request --> [N(COOKIE),]
SA, KE, Ni,
[N(NAT_DETECTION_SOURCE_IP)+,
N(NAT_DETECTION_DESTINATION_IP),]
[V+][N+]
normal response <-- SA, KE, Nr,
(no cookie) [N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP),]
[[N(HTTP_CERT_LOOKUP_SUPPORTED),] CERTREQ+,]
[V+][N+]
cookie response <-- N(COOKIE),
[V+][N+]
different Diffie- <-- N(INVALID_KE_PAYLOAD),
Hellman group [V+][N+]
wanted
C.2. IKE_AUTH Exchange without EAP
request --> IDi, [CERT+,]
[N(INITIAL_CONTACT),]
[[N(HTTP_CERT_LOOKUP_SUPPORTED),] CERTREQ+,]
[IDr,]
AUTH,
[CP(CFG_REQUEST),]
[N(IPCOMP_SUPPORTED)+,]
[N(USE_TRANSPORT_MODE),]
[N(ESP_TFC_PADDING_NOT_SUPPORTED),]
[N(NON_FIRST_FRAGMENTS_ALSO),]
SA, TSi, TSr,
[V+][N+]
Kaufman, et al. Standards Track [Page 138]
RFC 7296 IKEv2bis October 2014
response <-- IDr, [CERT+,]
AUTH,
[CP(CFG_REPLY),]
[N(IPCOMP_SUPPORTED),]
[N(USE_TRANSPORT_MODE),]
[N(ESP_TFC_PADDING_NOT_SUPPORTED),]
[N(NON_FIRST_FRAGMENTS_ALSO),]
SA, TSi, TSr,
[N(ADDITIONAL_TS_POSSIBLE),]
[V+][N+]
error in Child SA <-- IDr, [CERT+,]
creation AUTH,
N(error),
[V+][N+]
C.3. IKE_AUTH Exchange with EAP
first request --> IDi,
[N(INITIAL_CONTACT),]
[[N(HTTP_CERT_LOOKUP_SUPPORTED),] CERTREQ+,]
[IDr,]
[CP(CFG_REQUEST),]
[N(IPCOMP_SUPPORTED)+,]
[N(USE_TRANSPORT_MODE),]
[N(ESP_TFC_PADDING_NOT_SUPPORTED),]
[N(NON_FIRST_FRAGMENTS_ALSO),]
SA, TSi, TSr,
[V+][N+]
first response <-- IDr, [CERT+,] AUTH,
EAP,
[V+][N+]
/ --> EAP
repeat 1..N times |
\ <-- EAP
Kaufman, et al. Standards Track [Page 139]
RFC 7296 IKEv2bis October 2014
last request --> AUTH
last response <-- AUTH,
[CP(CFG_REPLY),]
[N(IPCOMP_SUPPORTED),]
[N(USE_TRANSPORT_MODE),]
[N(ESP_TFC_PADDING_NOT_SUPPORTED),]
[N(NON_FIRST_FRAGMENTS_ALSO),]
SA, TSi, TSr,
[N(ADDITIONAL_TS_POSSIBLE),]
[V+][N+]
C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying Child SAs
request --> [N(REKEY_SA),]
[CP(CFG_REQUEST),]
[N(IPCOMP_SUPPORTED)+,]
[N(USE_TRANSPORT_MODE),]
[N(ESP_TFC_PADDING_NOT_SUPPORTED),]
[N(NON_FIRST_FRAGMENTS_ALSO),]
SA, Ni, [KEi,] TSi, TSr,
[V+][N+]
normal <-- [CP(CFG_REPLY),]
response [N(IPCOMP_SUPPORTED),]
[N(USE_TRANSPORT_MODE),]
[N(ESP_TFC_PADDING_NOT_SUPPORTED),]
[N(NON_FIRST_FRAGMENTS_ALSO),]
SA, Nr, [KEr,] TSi, TSr,
[N(ADDITIONAL_TS_POSSIBLE),]
[V+][N+]
error case <-- N(error)
different Diffie- <-- N(INVALID_KE_PAYLOAD),
Hellman group [V+][N+]
wanted
C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA
request --> SA, Ni, KEi,
[V+][N+]
response <-- SA, Nr, KEr,
[V+][N+]
Kaufman, et al. Standards Track [Page 140]
RFC 7296 IKEv2bis October 2014
C.6. INFORMATIONAL Exchange
request --> [N+,]
[D+,]
[CP(CFG_REQUEST)]
response <-- [N+,]
[D+,]
[CP(CFG_REPLY)]
Acknowledgements
Many individuals in the IPsecME Working Group were very helpful in
contributing ideas and text for this document, as well as in
reviewing the clarifications suggested by others.
The acknowledgements from the IKEv2 document were:
This document is a collaborative effort of the entire IPsec WG. If
there were no limit to the number of authors that could appear on an
RFC, the following, in alphabetical order, would have been listed:
Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt
Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, John
Ioannidis, Charlie Kaufman, Steve Kent, Angelos Keromytis, Tero
Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer
Reingold, and Michael Richardson. Many other people contributed to
the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI,
each of which has its own list of authors. Hugh Daniel suggested the
feature of having the initiator, in message 3, specify a name for the
responder, and gave the feature the cute name "You Tarzan, Me Jane".
David Faucher and Valery Smyslov helped refine the design of the
Traffic Selector negotiation.
Kaufman, et al. Standards Track [Page 141]
RFC 7296 IKEv2bis October 2014
Authors' Addresses
Charlie Kaufman
Microsoft
1 Microsoft Way
Redmond, WA 98052
United States
EMail: charliekaufman@outlook.com
Paul Hoffman
VPN Consortium
127 Segre Place
Santa Cruz, CA 95060
United States
Phone: 1-831-426-9827
EMail: paul.hoffman@vpnc.org
Yoav Nir
Check Point Software Technologies Ltd.
5 Hasolelim St.
Tel Aviv 6789735
Israel
EMail: ynir.ietf@gmail.com
Pasi Eronen
Independent
EMail: pe@iki.fi
Tero Kivinen
INSIDE Secure
Eerikinkatu 28
HELSINKI FI-00180
Finland
EMail: kivinen@iki.fi
Kaufman, et al. Standards Track [Page 142]