Request for Comments: 4718 Nokia
Category: Informational P. Hoffman
VPN Consortium
October 2006
IKEv2 Clarifications and Implementation Guidelines
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document clarifies many areas of the IKEv2 specification. It
does not to introduce any changes to the protocol, but rather
provides descriptions that are less prone to ambiguous
interpretations. The purpose of this document is to encourage the
development of interoperable implementations.
Table of Contents
1. Introduction ....................................................4
2. Creating the IKE_SA .............................................4
2.1. SPI Values in IKE_SA_INIT Exchange .........................4
2.2. Message IDs for IKE_SA_INIT Messages .......................5
2.3. Retransmissions of IKE_SA_INIT Requests ....................5
2.4. Interaction of COOKIE and INVALID_KE_PAYLOAD ...............6
2.5. Invalid Cookies ............................................8
3. Authentication ..................................................9
3.1. Data Included in AUTH Payload Calculation ..................9
3.2. Hash Function for RSA Signatures ...........................9
3.3. Encoding Method for RSA Signatures ........................10
3.4. Identification Type for EAP ...............................11
3.5. Identity for Policy Lookups When Using EAP ................11
3.6. Certificate Encoding Types ................................12
3.7. Shared Key Authentication and Fixed PRF Key Size ..........12
3.8. EAP Authentication and Fixed PRF Key Size .................13
3.9. Matching ID Payloads to Certificate Contents ..............13
3.10. Message IDs for IKE_AUTH Messages ........................14
4. Creating CHILD_SAs .............................................14
4.1. Creating SAs with the CREATE_CHILD_SA Exchange ............14
4.2. Creating an IKE_SA without a CHILD_SA .....................16
4.3. Diffie-Hellman for First CHILD_SA .........................16
4.4. Extended Sequence Numbers (ESN) Transform .................17
4.5. Negotiation of ESP_TFC_PADDING_NOT_SUPPORTED ..............17
4.6. Negotiation of NON_FIRST_FRAGMENTS_ALSO ...................18
4.7. Semantics of Complex Traffic Selector Payloads ............18
4.8. ICMP Type/Code in Traffic Selector Payloads ...............19
4.9. Mobility Header in Traffic Selector Payloads ..............20
4.10. Narrowing the Traffic Selectors ..........................20
4.11. SINGLE_PAIR_REQUIRED .....................................21
4.12. Traffic Selectors Violating Own Policy ...................21
4.13. Traffic Selector Authorization ...........................22
5. Rekeying and Deleting SAs ......................................23
5.1. Rekeying SAs with the CREATE_CHILD_SA Exchange ............23
5.2. Rekeying the IKE_SA vs. Reauthentication ..................24
5.3. SPIs When Rekeying the IKE_SA .............................25
5.4. SPI When Rekeying a CHILD_SA ..............................25
5.5. Changing PRFs When Rekeying the IKE_SA ....................26
5.6. Deleting vs. Closing SAs ..................................26
5.7. Deleting a CHILD_SA Pair ..................................26
5.8. Deleting an IKE_SA ........................................27
5.9. Who is the original initiator of IKE_SA ...................27
5.10. Comparing Nonces .........................................27
5.11. Exchange Collisions ......................................28
5.12. Diffie-Hellman and Rekeying the IKE_SA ...................36
6. Configuration Payloads .........................................37
6.1. Assigning IP Addresses ....................................37
6.2. Requesting any INTERNAL_IP4/IP6_ADDRESS ...................38
6.3. INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET ...................38
6.4. INTERNAL_IP4_NETMASK ......................................41
6.5. Configuration Payloads for IPv6 ...........................42
6.6. INTERNAL_IP6_NBNS .........................................43
6.7. INTERNAL_ADDRESS_EXPIRY ...................................43
6.8. Address Assignment Failures ...............................44
7. Miscellaneous Issues ...........................................45
7.1. Matching ID_IPV4_ADDR and ID_IPV6_ADDR ....................45
7.2. Relationship of IKEv2 to RFC 4301 .........................45
7.3. Reducing the Window Size ..................................46
7.4. Minimum Size of Nonces ....................................46
7.5. Initial Zero Octets on Port 4500 ..........................46
7.6. Destination Port for NAT Traversal ........................47
7.7. SPI Values for Messages outside an IKE_SA .................47
7.8. Protocol ID/SPI Fields in Notify Payloads .................48
7.9. Which message should contain INITIAL_CONTACT ..............48
7.10. Alignment of Payloads ....................................48
7.11. Key Length Transform Attribute ...........................48
7.12. IPsec IANA Considerations ................................49
7.13. Combining ESP and AH .....................................50
8. Implementation Mistakes ........................................50
9. Security Considerations ........................................51
10. Acknowledgments ...............................................51
11. References ....................................................51
11.1. Normative References .....................................51
11.2. Informative References ...................................52
Appendix A. Exchanges and Payloads ................................54
A.1. IKE_SA_INIT Exchange ......................................54
A.2. IKE_AUTH Exchange without EAP .............................54
A.3. IKE_AUTH Exchange with EAP ................................55
A.4. CREATE_CHILD_SA Exchange for Creating/Rekeying
CHILD_SAs .................................................56
A.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA ..........56
A.6. INFORMATIONAL Exchange ....................................56
1. Introduction
This document clarifies many areas of the IKEv2 specification that
may be difficult to understand to developers not intimately familiar
with the specification and its history. The clarifications in this
document come from the discussion on the IPsec WG mailing list, from
experience in interoperability testing, and from implementation
issues that have been brought to the editors’ attention.
IKEv2/IPsec can be used for several different purposes, including
IPsec-based remote access (sometimes called the "road warrior" case),
site-to-site virtual private networks (VPNs), and host-to-host
protection of application traffic. While this document attempts to
consider all of these uses, the remote access scenario has perhaps
received more attention here than the other uses.
This document does not place any requirements on anyone and does not
use [RFC2119] keywords such as "MUST" and "SHOULD", except in
quotations from the original IKEv2 documents. The requirements are
given in the IKEv2 specification [IKEv2] and IKEv2 cryptographic
algorithms document [IKEv2ALG].
In this document, references to a numbered section (such as "Section
2.15") mean that section in [IKEv2]. References to mailing list
messages or threads refer to the IPsec WG mailing list at
ipsec@ietf.org. Archives of the mailing list can be found at
<http://www.ietf.org/mail-archive/web/ipsec/index.html>.
2. Creating the IKE_SA
2.1. SPI Values in IKE_SA_INIT Exchange
Normal IKE messages include the initiator’s and responder’s Security
Parameter Indexes (SPIs), both of which are non-zero, in the IKE
header. However, there are some corner cases where the IKEv2
specification is not fully consistent about what values should be
used.
First, Section 3.1 says that the Responder’s SPI "...MUST NOT be zero
in any other message" (than the first message of the IKE_SA_INIT
exchange). However, the figure in Section 2.6 shows the second
IKE_SA_INIT message as "HDR(A,0), N(COOKIE)", contradicting the text
in 3.1.
Since the responder’s SPI identifies security-related state held by
the responder, and in this case no state is created, sending a zero
value seems reasonable.
Second, in addition to cookies, there are several other cases when
the IKE_SA_INIT exchange does not result in the creation of an IKE_SA
(for instance, INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). What
responder SPI value should be used in the IKE_SA_INIT response in
this case?
Since the IKE_SA_INIT request always has a zero responder SPI, the
value will not be actually used by the initiator. Thus, we think
sending a zero value is correct also in this case.
If the responder sends a non-zero responder SPI, the initiator should
not reject the response only for that reason. However, when retrying
the IKE_SA_INIT request, the initiator will use a zero responder SPI,
as described in Section 3.1: "Responder’s SPI [...] This value MUST
be zero in the first message of an IKE Initial Exchange (including
repeats of that message including a cookie) [...]". We believe the
intent was to cover repeats of that message due to other reasons,
such as INVALID_KE_PAYLOAD, as well.
(References: "INVALID_KE_PAYLOAD and clarifications document" thread,
Sep-Oct 2005.)
2.2. Message IDs for IKE_SA_INIT Messages
The Message ID for IKE_SA_INIT messages is always zero. This
includes retries of the message due to responses such as COOKIE and
INVALID_KE_PAYLOAD.
This is because Message IDs are part of the IKE_SA state, and when
the responder replies to IKE_SA_INIT request with N(COOKIE) or
N(INVALID_KE_PAYLOAD), the responder does not allocate any state.
(References: "Question about N(COOKIE) and N(INVALID_KE_PAYLOAD)
combination" thread, Oct 2004. Tero Kivinen’s mail "Comments of
draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.)
2.3. Retransmissions of IKE_SA_INIT Requests
When a responder receives an IKE_SA_INIT request, it has to determine
whether the packet is a retransmission belonging to an existing
"half-open" IKE_SA (in which case the responder retransmits the same
response), or a new request (in which case the responder creates a
new IKE_SA and sends a fresh response).
The specification does not describe in detail how this determination
is done. In particular, it is not sufficient to use the initiator’s
SPI and/or IP address for this purpose: two different peers behind a
single NAT could choose the same initiator SPI (and the probability
of this happening is not necessarily small, since IKEv2 does not
require SPIs to be chosen randomly). Instead, the responder should
do the IKE_SA lookup using the whole packet or its hash (or at the
minimum, the Ni payload which is always chosen randomly).
For all other packets than IKE_SA_INIT requests, looking up right
IKE_SA is of course done based on the recipient’s SPI (either the
initiator or responder SPI depending on the value of the Initiator
bit in the IKE header).
2.4. Interaction of COOKIE and INVALID_KE_PAYLOAD
There are two common reasons why the initiator may have to retry the
IKE_SA_INIT exchange: the responder requests a cookie or wants a
different Diffie-Hellman group than was included in the KEi payload.
Both of these cases are quite simple alone, but it is not totally
obvious what happens when they occur at the same time, that is, the
IKE_SA_INIT exchange is retried several times.
The main question seems to be the following: if the initiator
receives a cookie from the responder, should it include the cookie in
only the next retry of the IKE_SA_INIT request, or in all subsequent
retries as well? Section 3.10.1 says that:
"This notification MUST be included in an IKE_SA_INIT request
retry if a COOKIE notification was included in the initial
response."
This could be interpreted as saying that when a cookie is received in
the initial response, it is included in all retries. On the other
hand, Section 2.6 says that:
"Initiators who receive such responses MUST retry the
IKE_SA_INIT with a Notify payload of type COOKIE containing
the responder supplied cookie data as the first payload and
all other payloads unchanged."
Including the same cookie in later retries makes sense only if the
"all other payloads unchanged" restriction applies only to the first
retry, but not to subsequent retries.
It seems that both interpretations can peacefully coexist. If the
initiator includes the cookie only in the next retry, one additional
roundtrip may be needed in some cases:
Initiator Responder
----------- -----------
HDR(A,0), SAi1, KEi, Ni -->
<-- HDR(A,0), N(COOKIE)
HDR(A,0), N(COOKIE), SAi1, KEi, Ni -->
<-- HDR(A,0), N(INVALID_KE_PAYLOAD)
HDR(A,0), SAi1, KEi’, Ni -->
<-- HDR(A,0), N(COOKIE’)
HDR(A,0), N(COOKIE’), SAi1, KEi’,Ni -->
<-- HDR(A,B), SAr1, KEr, Nr
An additional roundtrip is needed also if the initiator includes the
cookie in all retries, but the responder does not support this
functionality. For instance, if the responder includes the SAi1 and
KEi payloads in cookie calculation, it will reject the request by
sending a new cookie (see also Section 2.5 of this document for more
text about invalid cookies):
Initiator Responder
----------- -----------
HDR(A,0), SAi1, KEi, Ni -->
<-- HDR(A,0), N(COOKIE)
HDR(A,0), N(COOKIE), SAi1, KEi, Ni -->
<-- HDR(A,0), N(INVALID_KE_PAYLOAD)
HDR(A,0), N(COOKIE), SAi1, KEi’, Ni -->
<-- HDR(A,0), N(COOKIE’)
HDR(A,0), N(COOKIE’), SAi1, KEi’,Ni -->
<-- HDR(A,B), SAr1, KEr, Nr
If both peers support including the cookie in all retries, a slightly
shorter exchange can happen:
Initiator Responder
----------- -----------
HDR(A,0), SAi1, KEi, Ni -->
<-- HDR(A,0), N(COOKIE)
HDR(A,0), N(COOKIE), SAi1, KEi, Ni -->
<-- HDR(A,0), N(INVALID_KE_PAYLOAD)
HDR(A,0), N(COOKIE), SAi1, KEi’, Ni -->
<-- HDR(A,B), SAr1, KEr, Nr
This document recommends that implementations should support this
shorter exchange, but it must not be assumed the other peer also
supports the shorter exchange.
In theory, even this exchange has one unnecessary roundtrip, as both
the cookie and Diffie-Hellman group could be checked at the same
time:
Initiator Responder
----------- -----------
HDR(A,0), SAi1, KEi, Ni -->
<-- HDR(A,0), N(COOKIE),
N(INVALID_KE_PAYLOAD)
HDR(A,0), N(COOKIE), SAi1, KEi’,Ni -->
<-- HDR(A,B), SAr1, KEr, Nr
However, it is clear that this case is not allowed by the text in
Section 2.6, since "all other payloads" clearly includes the KEi
payload as well.
(References: "INVALID_KE_PAYLOAD and clarifications document" thread,
Sep-Oct 2005.)
2.5. Invalid Cookies
There has been some confusion what should be done when an IKE_SA_INIT
request containing an invalid cookie is received ("invalid" in the
sense that its contents do not match the value expected by the
responder).
The correct action is to ignore the cookie and process the message as
if no cookie had been included (usually this means sending a response
containing a new cookie). This is shown in Section 2.6 when it says
"The responder in that case MAY reject the message by sending another
response with a new cookie [...]".
Other possible actions, such as ignoring the whole request (or even
all requests from this IP address for some time), create strange
failure modes even in the absence of any malicious attackers and do
not provide any additional protection against DoS attacks.
(References: "Invalid Cookie" thread, Sep-Oct 2005.)
3. Authentication
3.1. Data Included in AUTH Payload Calculation
Section 2.15 describes how the AUTH payloads are calculated; this
calculation involves values prf(SK_pi,IDi’) and prf(SK_pr,IDr’). The
text describes the method in words, but does not give clear
definitions of what is signed or MACed (i.e., protected with a
message authentication code).
The initiator’s signed octets can be described as:
InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI
GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
RealIKEHDR = SPIi | SPIr | . . . | Length
RealMessage1 = RealIKEHDR | RestOfMessage1
NonceRPayload = PayloadHeader | NonceRData
InitiatorIDPayload = PayloadHeader | RestOfIDPayload
RestOfInitIDPayload = IDType | RESERVED | InitIDData
MACedIDForI = prf(SK_pi, RestOfInitIDPayload)
The responder’s signed octets can be described as:
ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR
GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
RealIKEHDR = SPIi | SPIr | . . . | Length
RealMessage2 = RealIKEHDR | RestOfMessage2
NonceIPayload = PayloadHeader | NonceIData
ResponderIDPayload = PayloadHeader | RestOfIDPayload
RestOfRespIDPayload = IDType | RESERVED | InitIDData
MACedIDForR = prf(SK_pr, RestOfRespIDPayload)
3.2. Hash Function for RSA Signatures
Section 3.8 says that RSA digital signature is "Computed as specified
in section 2.15 using an RSA private key over a PKCS#1 padded hash."
Unlike IKEv1, IKEv2 does not negotiate a hash function for the
IKE_SA. The algorithm for signatures is selected by the signing
party who, in general, may not know beforehand what algorithms the
verifying party supports. Furthermore, [IKEv2ALG] does not say what
algorithms implementations are required or recommended to support.
This clearly has a potential for causing interoperability problems,
since authentication will fail if the signing party selects an
algorithm that is not supported by the verifying party, or not
acceptable according to the verifying party’s policy.
This document recommends that all implementations support SHA-1 and
use SHA-1 as the default hash function when generating the
signatures, unless there are good reasons (such as explicit manual
configuration) to believe that the peer supports something else.
Note that hash function collision attacks are not important for the
AUTH payloads, since they are not intended for third-party
verification, and the data includes fresh nonces. See [HashUse] for
more discussion about hash function attacks and IPsec.
Another reasonable choice would be to use the hash function that was
used by the CA when signing the peer certificate. However, this does
not guarantee that the IKEv2 peer would be able to validate the AUTH
payload, because the same code might not be used to validate
certificate signatures and IKEv2 message signatures, and these two
routines may support a different set of hash algorithms. The peer
could be configured with a fingerprint of the certificate, or
certificate validation could be performed by an external entity using
[SCVP]. Furthermore, not all CERT payloads types include a
signature, and the certificate could be signed with some algorithm
other than RSA.
Note that unlike IKEv1, IKEv2 uses the PKCS#1 v1.5 [PKCS1v20]
signature encoding method (see next section for details), which
includes the algorithm identifier for the hash algorithm. Thus, when
the verifying party receives the AUTH payload it can at least
determine which hash function was used.
(References: Magnus Alstrom’s mail "RE:", 2005-01-03. Pasi Eronen’s
reply, 2005-01-04. Tero Kivinen’s reply, 2005-01-04. "First draft
of IKEv2.1" thread, Dec 2005/Jan 2006.)
3.3. Encoding Method for RSA Signatures
Section 3.8 says that the RSA digital signature is "Computed as
specified in section 2.15 using an RSA private key over a PKCS#1
padded hash."
The PKCS#1 specification [PKCS1v21] defines two different encoding
methods (ways of "padding the hash") for signatures. However, the
Internet-Draft approved by the IESG had a reference to the older
PKCS#1 v2.0 [PKCS1v20]. That version has only one encoding method
for signatures (EMSA-PKCS1-v1_5), and thus there is no ambiguity.
Note that this encoding method is different from the encoding method
used in IKEv1. If future revisions of IKEv2 provide support for
other encoding methods (such as EMSA-PSS), they will be given new
Auth Method numbers.
(References: Pasi Eronen’s mail "RE:", 2005-01-04.)
3.4. Identification Type for EAP
Section 3.5 defines several different types for identification
payloads, including, e.g., ID_FQDN, ID_RFC822_ADDR, and ID_KEY_ID.
EAP [EAP] does not mandate the use of any particular type of
identifier, but often EAP is used with Network Access Identifiers
(NAIs) defined in [NAI]. Although NAIs look a bit like email
addresses (e.g., "joe@example.com"), the syntax is not exactly the
same as the syntax of email address in [RFC822]. This raises the
question of which identification type should be used.
This document recommends that ID_RFC822_ADDR identification type is
used for those NAIs that include the realm component. Therefore,
responder implementations should not attempt to verify that the
contents actually conform to the exact syntax given in [RFC822] or
[RFC2822], but instead should accept any reasonable looking NAI.
For NAIs that do not include the realm component, this document
recommends using the ID_KEY_ID identification type.
(References: "need your help on this IKEv2/i18n/EAP issue" and "IKEv2
identifier issue with EAP" threads, Aug 2004.)
3.5. Identity for Policy Lookups When Using EAP
When the initiator authentication uses EAP, it is possible that the
contents of the IDi payload is used only for AAA routing purposes and
selecting which EAP method to use. This value may be different from
the identity authenticated by the EAP method (see [EAP], Sections 5.1
and 7.3).
It is important that policy lookups and access control decisions use
the actual authenticated identity. Often the EAP server is
implemented in a separate AAA server that communicates with the IKEv2
responder using, e.g., RADIUS [RADEAP]. In this case, the
authenticated identity has to be sent from the AAA server to the
IKEv2 responder.
(References: Pasi Eronen’s mail "RE: Reauthentication in IKEv2",
2004-10-28. "Policy lookups" thread, Oct/Nov 2004. RFC 3748,
Section 7.3.)
3.6. Certificate Encoding Types
Section 3.6 defines a total of twelve different certificate encoding
types, and continues that "Specific syntax is for some of the
certificate type codes above is not defined in this document."
However, the text does not provide references to other documents that
：＂RFC 4718 - IKEv2 Clarifications and Implementation Guideline＂
：＂RFC 4718 - IKEv2 Clarifications and Implementation Guideline＂