e0fe765152
new configuration structure: peer_cfg: configuration related to a peer (authenitcation, ...= ike_cfg: config to use for IKE setup (proposals) child_Cfg: config for CHILD_SA (proposals, traffic selectors) a peer_cfg has one ike_cfg and multiple child_cfg's stroke now uses fixed count of threads
3252 lines
127 KiB
Text
3252 lines
127 KiB
Text
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group P. Eronen
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 1]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
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
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 2]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
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
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 3]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 4]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
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
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 5]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
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:
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 6]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 7]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
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.)
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 8]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 9]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 10]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
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.)
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 11]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
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
|
||
would contain information about the exact contents and use of those
|
||
values.
|
||
|
||
Without this information, it is not possible to develop interoperable
|
||
implementations. Therefore, this document recommends that the
|
||
following certificate encoding values should not be used before new
|
||
specifications that specify their use are available.
|
||
|
||
PKCS #7 wrapped X.509 certificate 1
|
||
PGP Certificate 2
|
||
DNS Signed Key 3
|
||
Kerberos Token 6
|
||
SPKI Certificate 9
|
||
|
||
This document recommends that most implementations should use only
|
||
those values that are "MUST"/"SHOULD" requirements in [IKEv2]; i.e.,
|
||
"X.509 Certificate - Signature" (4), "Raw RSA Key" (11), "Hash and
|
||
URL of X.509 certificate" (12), and "Hash and URL of X.509 bundle"
|
||
(13).
|
||
|
||
Furthermore, Section 3.7 says that the "Certificate Encoding" field
|
||
for the Certificate Request payload uses the same values as for
|
||
Certificate payload. However, the contents of the "Certification
|
||
Authority" field are defined only for X.509 certificates (presumably
|
||
covering at least types 4, 10, 12, and 13). This document recommends
|
||
that other values should not be used before new specifications that
|
||
specify their use are available.
|
||
|
||
The "Raw RSA Key" type needs one additional clarification. Section
|
||
3.6 says it contains "a PKCS #1 encoded RSA key". What this means is
|
||
a DER-encoded RSAPublicKey structure from PKCS#1 [PKCS1v21].
|
||
|
||
3.7. Shared Key Authentication and Fixed PRF Key Size
|
||
|
||
Section 2.15 says that "If the negotiated prf takes a fixed-size key,
|
||
the shared secret MUST be of that fixed size". This statement is
|
||
correct: the shared secret must be of the correct size. If it is
|
||
not, it cannot be used; there is no padding, truncation, or other
|
||
processing involved to force it to that correct size.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 12]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
This requirement means that it is difficult to use these pseudo-
|
||
random functions (PRFs) with shared key authentication. The authors
|
||
think this part of the specification was very poorly thought out, and
|
||
using PRFs with a fixed key size is likely to result in
|
||
interoperability problems. Thus, we recommend that such PRFs should
|
||
not be used with shared key authentication. PRF_AES128_XCBC
|
||
[RFC3664] originally used fixed key sizes; that RFC has been updated
|
||
to handle variable key sizes in [RFC4434].
|
||
|
||
Note that Section 2.13 also contains text that is related to PRFs
|
||
with fixed key size: "When the key for the prf function has fixed
|
||
length, the data provided as a key is truncated or padded with zeros
|
||
as necessary unless exceptional processing is explained following the
|
||
formula". However, this text applies only to the prf+ construction,
|
||
so it does not contradict the text in Section 2.15.
|
||
|
||
(References: Paul Hoffman's mail "Re: ikev2-07: last nits",
|
||
2003-05-02. Hugo Krawczyk's reply, 2003-05-12. Thread "Question
|
||
about PRFs with fixed size key", Jan 2005.)
|
||
|
||
3.8. EAP Authentication and Fixed PRF Key Size
|
||
|
||
As described in the previous section, PRFs with a fixed key size
|
||
require a shared secret of exactly that size. This restriction
|
||
applies also to EAP authentication. For instance, a PRF that
|
||
requires a 128-bit key cannot be used with EAP since [EAP] specifies
|
||
that the MSK is at least 512 bits long.
|
||
|
||
(References: Thread "Question about PRFs with fixed size key", Jan
|
||
2005.)
|
||
|
||
3.9. Matching ID Payloads to Certificate Contents
|
||
|
||
In IKEv1, there was some confusion about whether or not the
|
||
identities in certificates used to authenticate IKE were required to
|
||
match the contents of the ID payloads. The PKI4IPsec Working Group
|
||
produced the document [PKI4IPsec] which covers this topic in much
|
||
more detail. However, Section 3.5 of [IKEv2] explicitly says that
|
||
the ID payload "does not necessarily have to match anything in the
|
||
CERT payload".
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 13]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
3.10. Message IDs for IKE_AUTH Messages
|
||
|
||
According to Section 2.2, "The IKE_SA initial setup messages will
|
||
always be numbered 0 and 1." That is true when the IKE_AUTH exchange
|
||
does not use EAP. When EAP is used, each pair of messages has their
|
||
message numbers incremented. The first pair of AUTH messages will
|
||
have an ID of 1, the second will be 2, and so on.
|
||
|
||
(References: "Question about MsgID in AUTH exchange" thread, April
|
||
2005.)
|
||
|
||
4. Creating CHILD_SAs
|
||
|
||
4.1. Creating SAs with the CREATE_CHILD_SA Exchange
|
||
|
||
Section 1.3's organization does not lead to clear understanding of
|
||
what is needed in which environment. The section can be reorganized
|
||
with subsections for each use of the CREATE_CHILD_SA exchange
|
||
(creating child SAs, rekeying IKE SAs, and rekeying child SAs.)
|
||
|
||
The new Section 1.3 with subsections and the above changes might look
|
||
like the following.
|
||
|
||
NEW-1.3 The CREATE_CHILD_SA Exchange
|
||
|
||
The CREATE_CHILD_SA Exchange is used to create new CHILD_SAs and
|
||
to rekey both IKE_SAs and CHILD_SAs. This exchange consists of
|
||
a single request/response pair, and some of its function was
|
||
referred to as a phase 2 exchange in IKEv1. It MAY be initiated
|
||
by either end of the IKE_SA after the initial exchanges are
|
||
completed.
|
||
|
||
All messages following the initial exchange are
|
||
cryptographically protected using the cryptographic algorithms
|
||
and keys negotiated in the first two messages of the IKE
|
||
exchange. These subsequent messages use the syntax of the
|
||
Encrypted Payload described in section 3.14. All subsequent
|
||
messages include an Encrypted Payload, even if they are referred
|
||
to in the text as "empty".
|
||
|
||
The CREATE_CHILD_SA is used for rekeying IKE_SAs and CHILD_SAs.
|
||
This section describes the first part of rekeying, the creation
|
||
of new SAs; Section 2.8 covers the mechanics of rekeying,
|
||
including moving traffic from old to new SAs and the deletion of
|
||
the old SAs. The two sections must be read together to
|
||
understand the entire process of rekeying.
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 14]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
Either endpoint may initiate a CREATE_CHILD_SA exchange, so in
|
||
this section the term initiator refers to the endpoint
|
||
initiating this exchange. An implementation MAY refuse all
|
||
CREATE_CHILD_SA requests within an IKE_SA.
|
||
|
||
The CREATE_CHILD_SA request MAY optionally contain a KE payload
|
||
for an additional Diffie-Hellman exchange to enable stronger
|
||
guarantees of forward secrecy for the CHILD_SA or IKE_SA. The
|
||
keying material for the SA is a function of SK_d established
|
||
during the establishment of the IKE_SA, the nonces exchanged
|
||
during the CREATE_CHILD_SA exchange, and the Diffie-Hellman
|
||
value (if KE payloads are included in the CREATE_CHILD_SA
|
||
exchange). The details are described in sections 2.17 and 2.18.
|
||
|
||
If a CREATE_CHILD_SA exchange includes a KEi payload, at least
|
||
one of the SA offers MUST include the Diffie-Hellman group of
|
||
the KEi. The Diffie-Hellman group of the KEi MUST be an element
|
||
of the group the initiator expects the responder to accept
|
||
(additional Diffie-Hellman groups can be proposed). If the
|
||
responder rejects the Diffie-Hellman group of the KEi payload,
|
||
the responder MUST reject the request and indicate its preferred
|
||
Diffie-Hellman group in the INVALID_KE_PAYLOAD Notification
|
||
payload. In the case of such a rejection, the CREATE_CHILD_SA
|
||
exchange fails, and the initiator SHOULD retry the exchange with
|
||
a Diffie-Hellman proposal and KEi in the group that the
|
||
responder gave in the INVALID_KE_PAYLOAD.
|
||
|
||
NEW-1.3.1 Creating New CHILD_SAs with the CREATE_CHILD_SA Exchange
|
||
|
||
A CHILD_SA may be created by sending a CREATE_CHILD_SA request.
|
||
The CREATE_CHILD_SA request for creating a new CHILD_SA is:
|
||
|
||
Initiator Responder
|
||
----------- -----------
|
||
HDR, SK {[N+], SA, Ni, [KEi],
|
||
TSi, TSr} -->
|
||
|
||
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 the proposed traffic selectors for the proposed
|
||
CHILD_SA in the TSi and TSr payloads. The request can also
|
||
contain Notify payloads that specify additional details for the
|
||
CHILD_SA: these include IPCOMP_SUPPORTED, USE_TRANSPORT_MODE,
|
||
ESP_TFC_PADDING_NOT_SUPPORTED, and NON_FIRST_FRAGMENTS_ALSO.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 15]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
The CREATE_CHILD_SA response for creating a new CHILD_SA is:
|
||
|
||
<-- HDR, SK {[N+], SA, Nr,
|
||
[KEr], TSi, TSr}
|
||
|
||
The responder replies with the accepted offer in an SA payload,
|
||
and a Diffie-Hellman value in the KEr payload if KEi was
|
||
included in the request and the selected cryptographic suite
|
||
includes that group. As with the request, optional Notification
|
||
payloads can specify additional details for the CHILD_SA.
|
||
|
||
The traffic selectors for traffic to be sent on that SA are
|
||
specified in the TS payloads in the response, which may be a
|
||
subset of what the initiator of the CHILD_SA proposed.
|
||
|
||
The text about rekeying SAs can be found in Section 5.1 of this
|
||
document.
|
||
|
||
4.2. Creating an IKE_SA without a CHILD_SA
|
||
|
||
CHILD_SAs can be created either by being piggybacked on the IKE_AUTH
|
||
exchange, or using a separate CREATE_CHILD_SA exchange. The
|
||
specification is not clear about what happens if creating the
|
||
CHILD_SA during the IKE_AUTH exchange fails for some reason.
|
||
|
||
Our recommendation in this situation is that the IKE_SA is created as
|
||
usual. This is also in line with how the CREATE_CHILD_SA exchange
|
||
works: a failure to create a CHILD_SA does not close the IKE_SA.
|
||
|
||
The list of responses in the IKE_AUTH exchange that do not prevent an
|
||
IKE_SA from being set up include at least the following:
|
||
NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED,
|
||
INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED.
|
||
|
||
(References: "Questions about internal address" thread, April 2005.)
|
||
|
||
4.3. Diffie-Hellman for First CHILD_SA
|
||
|
||
Section 1.2 shows that IKE_AUTH messages do not contain KEi/KEr or
|
||
Ni/Nr payloads. This implies that the SA payload in IKE_AUTH
|
||
exchange cannot contain Transform Type 4 (Diffie-Hellman Group) with
|
||
any other value than NONE. Implementations should probably leave the
|
||
transform out entirely in this case.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 16]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
4.4. Extended Sequence Numbers (ESN) Transform
|
||
|
||
The description of the ESN transform in Section 3.3 has be proved
|
||
difficult to understand. The ESN transform has the following
|
||
meaning:
|
||
|
||
o A proposal containing one ESN transform with value 0 means "do not
|
||
use extended sequence numbers".
|
||
|
||
o A proposal containing one ESN transform with value 1 means "use
|
||
extended sequence numbers".
|
||
|
||
o A proposal containing two ESN transforms with values 0 and 1 means
|
||
"I support both normal and extended sequence numbers, you choose".
|
||
(Obviously this case is only allowed in requests; the response
|
||
will contain only one ESN transform.)
|
||
|
||
In most cases, the exchange initiator will include either the first
|
||
or third alternative in its SA payload. The second alternative is
|
||
rarely useful for the initiator: it means that using normal sequence
|
||
numbers is not acceptable (so if the responder does not support ESNs,
|
||
the exchange will fail with NO_PROPOSAL_CHOSEN).
|
||
|
||
Note that including the ESN transform is mandatory when creating
|
||
ESP/AH SAs (it was optional in earlier drafts of the IKEv2
|
||
specification).
|
||
|
||
(References: "Technical change needed to IKEv2 before publication",
|
||
"STRAW POLL: Dealing with the ESN negotiation interop issue in IKEv2"
|
||
and "Results of straw poll regarding: IKEv2 interoperability issue"
|
||
threads, March-April 2005.)
|
||
|
||
4.5. Negotiation of ESP_TFC_PADDING_NOT_SUPPORTED
|
||
|
||
The description of ESP_TFC_PADDING_NOT_SUPPORTED notification in
|
||
Section 3.10.1 says that "This notification asserts that the sending
|
||
endpoint will NOT accept packets that contain Flow Confidentiality
|
||
(TFC) padding".
|
||
|
||
However, the text does not say in which messages this notification
|
||
should be included, or whether the scope of this notification is a
|
||
single CHILD_SA or all CHILD_SAs of the peer.
|
||
|
||
Our interpretation is that the scope is a single CHILD_SA, and thus
|
||
this notification is included in messages containing an SA payload
|
||
negotiating a CHILD_SA. If neither endpoint accepts TFC padding,
|
||
this notification will be included in both the request proposing an
|
||
SA and the response accepting it. If this notification is included
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 17]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
in only one of the messages, TFC padding can still be sent in one
|
||
direction.
|
||
|
||
4.6. Negotiation of NON_FIRST_FRAGMENTS_ALSO
|
||
|
||
NON_FIRST_FRAGMENTS_ALSO notification is described in Section 3.10.1
|
||
simply as "Used for fragmentation control. See [RFC4301] for
|
||
explanation."
|
||
|
||
[RFC4301] says "Implementations that will transmit non-initial
|
||
fragments on a tunnel mode SA that makes use of non-trivial port (or
|
||
ICMP type/code or MH type) selectors MUST notify a peer via the IKE
|
||
NOTIFY NON_FIRST_FRAGMENTS_ALSO payload. The peer MUST reject this
|
||
proposal if it will not accept non-initial fragments in this context.
|
||
If an implementation does not successfully negotiate transmission of
|
||
non-initial fragments for such an SA, it MUST NOT send such fragments
|
||
over the SA."
|
||
|
||
However, it is not clear exactly how the negotiation works. Our
|
||
interpretation is that the negotiation works the same way as for
|
||
IPCOMP_SUPPORTED and USE_TRANSPORT_MODE: sending non-first fragments
|
||
is enabled only if NON_FIRST_FRAGMENTS_ALSO notification is included
|
||
in both the request proposing an SA and the response accepting it.
|
||
In other words, if the peer "rejects this proposal", it only omits
|
||
NON_FIRST_FRAGMENTS_ALSO notification from the response, but does not
|
||
reject the whole CHILD_SA creation.
|
||
|
||
4.7. Semantics of Complex Traffic Selector Payloads
|
||
|
||
As described in Section 3.13, the TSi/TSr payloads can include one or
|
||
more individual traffic selectors.
|
||
|
||
There is no requirement that TSi and TSr contain the same number of
|
||
individual traffic selectors. Thus, they are interpreted as follows:
|
||
a packet matches a given TSi/TSr if it matches at least one of the
|
||
individual selectors in TSi, and at least one of the individual
|
||
selectors in TSr.
|
||
|
||
For instance, the following traffic selectors:
|
||
|
||
TSi = ((17, 100, 192.0.1.66-192.0.1.66),
|
||
(17, 200, 192.0.1.66-192.0.1.66))
|
||
TSr = ((17, 300, 0.0.0.0-255.255.255.255),
|
||
(17, 400, 0.0.0.0-255.255.255.255))
|
||
|
||
would match UDP packets from 192.0.1.66 to anywhere, with any of the
|
||
four combinations of source/destination ports (100,300), (100,400),
|
||
(200,300), and (200, 400).
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 18]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
This implies that some types of policies may require several CHILD_SA
|
||
pairs. For instance, a policy matching only source/destination ports
|
||
(100,300) and (200,400), but not the other two combinations, cannot
|
||
be negotiated as a single CHILD_SA pair using IKEv2.
|
||
|
||
(References: "IKEv2 Traffic Selectors?" thread, Feb 2005.)
|
||
|
||
4.8. ICMP Type/Code in Traffic Selector Payloads
|
||
|
||
The traffic selector types 7 and 8 can also refer to ICMP type and
|
||
code fields. As described in Section 3.13.1, "For the ICMP protocol,
|
||
the two one-octet fields Type and Code are treated as a single 16-bit
|
||
integer (with Type in the most significant eight bits and Code in the
|
||
least significant eight bits) port number for the purposes of
|
||
filtering based on this field."
|
||
|
||
Since ICMP packets do not have separate source and destination port
|
||
fields, there is some room for confusion what exactly the four TS
|
||
payloads (two in the request, two in the response, each containing
|
||
both start and end port fields) should contain.
|
||
|
||
The answer to this question can be found from [RFC4301] Section
|
||
4.4.1.3.
|
||
|
||
To give a concrete example, if a host at 192.0.1.234 wants to create
|
||
a transport mode SA for sending "Destination Unreachable" packets
|
||
(ICMPv4 type 3) to 192.0.2.155, but is not willing to receive them
|
||
over this SA pair, the CREATE_CHILD_SA exchange would look like this:
|
||
|
||
Initiator Responder
|
||
----------- -----------
|
||
HDR, SK { N(USE_TRANSPORT_MODE), SA, Ni,
|
||
TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
|
||
TSr(1, 65535-0, 192.0.2.155-192.0.2.155) } -->
|
||
|
||
<-- HDR, SK { N(USE_TRANSPORT_MODE), SA, Nr,
|
||
TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
|
||
TSr(1, 65535-0, 192.0.2.155-192.0.2.155) }
|
||
|
||
Since IKEv2 always creates IPsec SAs in pairs, two SAs are also
|
||
created in this case, even though the second SA is never used for
|
||
data traffic.
|
||
|
||
An exchange creating an SA pair that can be used both for sending and
|
||
receiving "Destination Unreachable" places the same value in all the
|
||
port:
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 19]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
Initiator Responder
|
||
----------- -----------
|
||
HDR, SK { N(USE_TRANSPORT_MODE), SA, Ni,
|
||
TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
|
||
TSr(1, 0x0300-0x03FF, 192.0.2.155-192.0.2.155) } -->
|
||
|
||
<-- HDR, SK { N(USE_TRANSPORT_MODE), SA, Nr,
|
||
TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
|
||
TSr(1, 0x0300-0x03FF, 192.0.2.155-192.0.2.155) }
|
||
|
||
(References: "ICMP and MH TSs for IKEv2" thread, Sep 2005.)
|
||
|
||
4.9. Mobility Header in Traffic Selector Payloads
|
||
|
||
Traffic selectors can use IP Protocol ID 135 to match the IPv6
|
||
mobility header [MIPv6]. However, the IKEv2 specification does not
|
||
define how to represent the "MH Type" field in traffic selectors.
|
||
|
||
At some point, it was expected that this will be defined in a
|
||
separate document later. However, [RFC4301] says that "For IKE, the
|
||
IPv6 mobility header message type (MH type) is placed in the most
|
||
significant eight bits of the 16 bit local "port" selector". The
|
||
direction semantics of TSi/TSr port fields are the same as for ICMP
|
||
and are described in the previous section.
|
||
|
||
(References: Tero Kivinen's mail "Issue #86: Add IPv6 mobility header
|
||
message type as selector", 2003-10-14. "ICMP and MH TSs for IKEv2"
|
||
thread, Sep 2005.)
|
||
|
||
4.10. Narrowing the Traffic Selectors
|
||
|
||
Section 2.9 describes how traffic selectors are negotiated when
|
||
creating a CHILD_SA. A more concise summary of the narrowing process
|
||
is presented below.
|
||
|
||
o If the responder's policy does not allow any part of the traffic
|
||
covered by TSi/TSr, it responds with TS_UNACCEPTABLE.
|
||
|
||
o If the responder's policy allows the entire set of traffic covered
|
||
by TSi/TSr, no narrowing is necessary, and the responder can
|
||
return the same TSi/TSr values.
|
||
|
||
o Otherwise, narrowing is needed. If the responder's policy allows
|
||
all traffic covered by TSi[1]/TSr[1] (the first traffic selectors
|
||
in TSi/TSr) but not entire TSi/TSr, the responder narrows to an
|
||
acceptable subset of TSi/TSr that includes TSi[1]/TSr[1].
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 20]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
o If the responder's policy does not allow all traffic covered by
|
||
TSi[1]/TSr[1], but does allow some parts of TSi/TSr, it narrows to
|
||
an acceptable subset of TSi/TSr.
|
||
|
||
In the last two cases, there may be several subsets that are
|
||
acceptable (but their union is not); in this case, the responder
|
||
arbitrarily chooses one of them and includes ADDITIONAL_TS_POSSIBLE
|
||
notification in the response.
|
||
|
||
4.11. SINGLE_PAIR_REQUIRED
|
||
|
||
The description of the SINGLE_PAIR_REQUIRED notify payload in
|
||
Sections 2.9 and 3.10.1 is not fully consistent.
|
||
|
||
We do not attempt to describe this payload in this document either,
|
||
since it is expected that most implementations will not have policies
|
||
that require separate SAs for each address pair.
|
||
|
||
Thus, if only some part (or parts) of the TSi/TSr proposed by the
|
||
initiator is (are) acceptable to the responder, most responders
|
||
should simply narrow TSi/TSr to an acceptable subset (as described in
|
||
the last two paragraphs of Section 2.9), rather than use
|
||
SINGLE_PAIR_REQUIRED.
|
||
|
||
4.12. Traffic Selectors Violating Own Policy
|
||
|
||
Section 2.9 describes traffic selector negotiation in great detail.
|
||
One aspect of this negotiation that may need some clarification is
|
||
that when creating a new SA, the initiator should not propose traffic
|
||
selectors that violate its own policy. If this rule is not followed,
|
||
valid traffic may be dropped.
|
||
|
||
This is best illustrated by an example. Suppose that host A has a
|
||
policy whose effect is that traffic to 192.0.1.66 is sent via host B
|
||
encrypted using Advanced Encryption Standard (AES), and traffic to
|
||
all other hosts in 192.0.1.0/24 is also sent via B, but encrypted
|
||
using Triple Data Encryption Standard (3DES). Suppose also that host
|
||
B accepts any combination of AES and 3DES.
|
||
|
||
If host A now proposes an SA that uses 3DES, and includes TSr
|
||
containing (192.0.1.0-192.0.1.0.255), this will be accepted by host
|
||
B. Now, host B can also use this SA to send traffic from 192.0.1.66,
|
||
but those packets will be dropped by A since it requires the use of
|
||
AES for those traffic. Even if host A creates a new SA only for
|
||
192.0.1.66 that uses AES, host B may freely continue to use the first
|
||
SA for the traffic. In this situation, when proposing the SA, host A
|
||
should have followed its own policy, and included a TSr containing
|
||
((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead.
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 21]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
In general, if (1) the initiator makes a proposal "for traffic X
|
||
(TSi/TSr), do SA", and (2) for some subset X' of X, the initiator
|
||
does not actually accept traffic X' with SA, and (3) the initiator
|
||
would be willing to accept traffic X' with some SA' (!=SA), valid
|
||
traffic can be unnecessarily dropped since the responder can apply
|
||
either SA or SA' to traffic X'.
|
||
|
||
(References: "Question about "narrowing" ..." thread, Feb 2005.
|
||
"IKEv2 needs a "policy usage mode"..." thread, Feb 2005. "IKEv2
|
||
Traffic Selectors?" thread, Feb 2005. "IKEv2 traffic selector
|
||
negotiation examples", 2004-08-08.)
|
||
|
||
4.13. Traffic Selector Authorization
|
||
|
||
IKEv2 relies on information in the Peer Authorization Database (PAD)
|
||
when determining what kind of IPsec SAs a peer is allowed to create.
|
||
This process is described in [RFC4301] Section 4.4.3. When a peer
|
||
requests the creation of an IPsec 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 IPsec 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
|
||
192.0.1.66/32, meaning this identity a valid "owner" or
|
||
"representative" of the address in question.
|
||
|
||
As noted in [RFC4301], "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 IPsec SAs with address 192.0.1.66 and prevents
|
||
fooserver4 from creating IPsec 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 IPsec SAs
|
||
with that address in the traffic selectors. For example, even if
|
||
sgw23 would be able to spoof its IP address as 192.0.1.66, it could
|
||
not create IPsec 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
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 22]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
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 Dynamic Host Configuration Protocol (DHCP), it is extremely
|
||
difficult to ensure that the PAD 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 IPsec 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 IPsec
|
||
SAs with any traffic selectors. This is not an appropriate or secure
|
||
configuration in most circumstances. See [Aura05] for an extensive
|
||
discussion about this issue, and the limitations of host-to-host
|
||
IPsec in general.
|
||
|
||
5. Rekeying and Deleting SAs
|
||
|
||
5.1. Rekeying SAs with the CREATE_CHILD_SA Exchange
|
||
|
||
Continued from Section 4.1 of this document.
|
||
|
||
NEW-1.3.2 Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange
|
||
|
||
The CREATE_CHILD_SA request for rekeying an IKE_SA is:
|
||
|
||
Initiator Responder
|
||
----------- -----------
|
||
HDR, SK {SA, Ni, [KEi]} -->
|
||
|
||
The initiator sends SA offer(s) in the SA payload, a nonce in
|
||
the Ni payload, and optionally a Diffie-Hellman value in the KEi
|
||
payload.
|
||
|
||
The CREATE_CHILD_SA response for rekeying an IKE_SA is:
|
||
|
||
<-- HDR, SK {SA, Nr, [KEr]}
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 23]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
The responder replies (using the same Message ID to respond)
|
||
with the accepted offer in an SA payload, a nonce in the Nr
|
||
payload, and, optionally, a Diffie-Hellman value in the KEr
|
||
payload.
|
||
|
||
The new IKE_SA has its message counters set to 0, regardless of
|
||
what they were in the earlier IKE_SA. The window size starts at
|
||
1 for any new IKE_SA. The new initiator and responder SPIs are
|
||
supplied in the SPI fields of the SA payloads.
|
||
|
||
NEW-1.3.3 Rekeying CHILD_SAs with the CREATE_CHILD_SA Exchange
|
||
|
||
The CREATE_CHILD_SA request for rekeying a CHILD_SA is:
|
||
|
||
Initiator Responder
|
||
----------- -----------
|
||
HDR, SK {N(REKEY_SA), [N+], SA,
|
||
Ni, [KEi], TSi, TSr} -->
|
||
|
||
The leading Notify payload of type REKEY_SA identifies the
|
||
CHILD_SA being rekeyed, and it contains the SPI that the initiator
|
||
expects in the headers of inbound packets. In addition, 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 the proposed traffic selectors in the TSi and TSr payloads.
|
||
The request can also contain Notify payloads that specify
|
||
additional details for the CHILD_SA.
|
||
|
||
The CREATE_CHILD_SA response for rekeying a CHILD_SA is:
|
||
|
||
<-- HDR, SK {[N+], SA, Nr,
|
||
[KEr], TSi, TSr}
|
||
|
||
The responder replies with the accepted offer in an SA payload,
|
||
and a Diffie-Hellman value in the KEr payload if KEi was
|
||
included in the request and the selected cryptographic suite
|
||
includes that group.
|
||
|
||
The traffic selectors for traffic to be sent on that SA are
|
||
specified in the TS payloads in the response, which may be a
|
||
subset of what the initiator of the CHILD_SA proposed.
|
||
|
||
5.2. Rekeying the IKE_SA vs. Reauthentication
|
||
|
||
Rekeying the IKE_SA and reauthentication are different concepts in
|
||
IKEv2. Rekeying the IKE_SA establishes new keys for the IKE_SA and
|
||
resets the Message ID counters, but it does not authenticate the
|
||
parties again (no AUTH or EAP payloads are involved).
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 24]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
While rekeying the IKE_SA may be important in some environments,
|
||
reauthentication (the verification that the parties still have access
|
||
to the long-term credentials) is often more important.
|
||
|
||
IKEv2 does not have any special support for reauthentication.
|
||
Reauthentication is done by creating a new IKE_SA from scratch (using
|
||
IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify
|
||
payloads), creating new CHILD_SAs within the new IKE_SA (without
|
||
REKEY_SA notify payloads), and finally deleting the old IKE_SA (which
|
||
deletes the old CHILD_SAs as well).
|
||
|
||
This means that reauthentication also establishes new keys for the
|
||
IKE_SA and CHILD_SAs. Therefore, while rekeying can be performed
|
||
more often than reauthentication, the situation where "authentication
|
||
lifetime" is shorter than "key lifetime" does not make sense.
|
||
|
||
While creation of a new IKE_SA can be initiated by either party
|
||
(initiator or responder in the original IKE_SA), the use of EAP
|
||
authentication and/or configuration payloads means in practice that
|
||
reauthentication has to be initiated by the same party as the
|
||
original IKE_SA. IKEv2 base specification does not allow the
|
||
responder to request reauthentication in this case; however, this
|
||
functionality is added in [ReAuth].
|
||
|
||
(References: "Reauthentication in IKEv2" thread, Oct/Nov 2004.)
|
||
|
||
5.3. SPIs When Rekeying the IKE_SA
|
||
|
||
Section 2.18 says that "New initiator and responder SPIs are supplied
|
||
in the SPI fields". This refers to the SPI fields in the Proposal
|
||
structures inside the Security Association (SA) payloads, not the SPI
|
||
fields in the IKE header.
|
||
|
||
(References: Tom Stiemerling's mail "Rekey IKE SA", 2005-01-24.
|
||
Geoffrey Huang's reply, 2005-01-24.)
|
||
|
||
5.4. SPI When Rekeying a CHILD_SA
|
||
|
||
Section 3.10.1 says that in REKEY_SA notifications, "The SPI field
|
||
identifies the SA being rekeyed."
|
||
|
||
Since CHILD_SAs always exist in pairs, there are two different SPIs.
|
||
The SPI placed in the REKEY_SA notification is the SPI the exchange
|
||
initiator would expect in inbound ESP or AH packets (just as in
|
||
Delete payloads).
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 25]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
5.5. Changing PRFs When Rekeying the IKE_SA
|
||
|
||
When rekeying the IKE_SA, Section 2.18 says that "SKEYSEED for the
|
||
new IKE_SA is computed using SK_d from the existing IKE_SA as
|
||
follows:
|
||
|
||
SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr)"
|
||
|
||
If the old and new IKE_SA selected a different PRF, it is not totally
|
||
clear which PRF should be used.
|
||
|
||
Since the rekeying exchange belongs to the old IKE_SA, it is the old
|
||
IKE_SA's PRF that is used. This also follows the principle that the
|
||
same key (the old SK_d) should not be used with multiple
|
||
cryptographic algorithms.
|
||
|
||
Note that this may work poorly if the new IKE_SA's PRF has a fixed
|
||
key size, since the output of the PRF may not be of the correct size.
|
||
This supports our opinion earlier in the document that the use of
|
||
PRFs with a fixed key size is a bad idea.
|
||
|
||
(References: "Changing PRFs when rekeying the IKE_SA" thread, June
|
||
2005.)
|
||
|
||
5.6. Deleting vs. Closing SAs
|
||
|
||
The IKEv2 specification talks about "closing" and "deleting" SAs, but
|
||
it is not always clear what exactly is meant. However, other parts
|
||
of the specification make it clear that when local state related to a
|
||
CHILD_SA is removed, the SA must also be actively deleted with a
|
||
Delete payload.
|
||
|
||
In particular, Section 2.4 says that "If an IKE endpoint chooses to
|
||
delete CHILD_SAs, it MUST send Delete payloads to the other end
|
||
notifying it of the deletion". Section 1.4 also explains that "ESP
|
||
and AH SAs always exist in pairs, with one SA in each direction.
|
||
When an SA is closed, both members of the pair MUST be closed."
|
||
|
||
5.7. Deleting a CHILD_SA Pair
|
||
|
||
Section 1.4 describes how to delete SA pairs using the Informational
|
||
exchange: "To delete an SA, an INFORMATIONAL exchange with one or
|
||
more delete payloads is sent listing the SPIs (as they would be
|
||
expected in the headers of inbound packets) of the SAs to be deleted.
|
||
The recipient MUST close the designated SAs."
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 26]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
The "one or more delete payloads" phrase has caused some confusion.
|
||
You never send delete payloads for the two sides of an SA in a single
|
||
message. If you have many SAs to delete at the same time (such as
|
||
the nested example given in that paragraph), you include delete
|
||
payloads for the inbound half of each SA in your Informational
|
||
exchange.
|
||
|
||
5.8. Deleting an IKE_SA
|
||
|
||
Since IKE_SAs do not exist in pairs, it is not totally clear what the
|
||
response message should contain when the request deleted the IKE_SA.
|
||
|
||
Since there is no information that needs to be sent to the other side
|
||
(except that the request was received), an empty Informational
|
||
response seems like the most logical choice.
|
||
|
||
(References: "Question about delete IKE SA" thread, May 2005.)
|
||
|
||
5.9. Who is the original initiator of IKE_SA
|
||
|
||
In the IKEv2 document, "initiator" refers to the party who initiated
|
||
the exchange being described, and "original initiator" refers to the
|
||
party who initiated the whole IKE_SA. However, there is some
|
||
potential for confusion because the IKE_SA can be rekeyed by either
|
||
party.
|
||
|
||
To clear up this confusion, we propose that "original initiator"
|
||
always refers to the party who initiated the exchange that resulted
|
||
in the current IKE_SA. In other words, if the "original responder"
|
||
starts rekeying the IKE_SA, that party becomes the "original
|
||
initiator" of the new IKE_SA.
|
||
|
||
(References: Paul Hoffman's mail "Original initiator in IKEv2",
|
||
2005-04-21.)
|
||
|
||
5.10. Comparing Nonces
|
||
|
||
Section 2.8 about rekeying says that "If redundant SAs are created
|
||
though such a collision, the SA created with the lowest of the four
|
||
nonces used in the two exchanges SHOULD be closed by the endpoint
|
||
that created it."
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 27]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
Here "lowest" uses an octet-by-octet (lexicographical) comparison
|
||
(instead of, for instance, comparing the nonces as large integers).
|
||
In other words, start by comparing the first octet; if they're equal,
|
||
move to the next octet, and so on. If you reach the end of one
|
||
nonce, that nonce is the lower one.
|
||
|
||
(References: "IKEv2 rekeying question" thread, July 2005.)
|
||
|
||
5.11. Exchange Collisions
|
||
|
||
Since IKEv2 exchanges can be initiated by both peers, it is possible
|
||
that two exchanges affecting the same SA partly overlap. This can
|
||
lead to a situation where the SA state information is temporarily not
|
||
synchronized, and a peer can receive a request it cannot process in a
|
||
normal fashion. Some of these corner cases are discussed in the
|
||
specification, some are not.
|
||
|
||
Obviously, using a window size greater than one leads to infinitely
|
||
more complex situations, especially if requests are processed out of
|
||
order. In this section, we concentrate on problems that can arise
|
||
even with window size 1.
|
||
|
||
(References: "IKEv2: invalid SPI in DELETE payload" thread, Dec 2005/
|
||
Jan 2006. "Problem with exchanges collisions" thread, Dec 2005.)
|
||
|
||
5.11.1. Simultaneous CHILD_SA Close
|
||
|
||
Probably the simplest case happens if both peers decide to close the
|
||
same CHILD_SA pair at the same time:
|
||
|
||
Host A Host B
|
||
-------- --------
|
||
send req1: D(SPIa) -->
|
||
<-- send req2: D(SPIb)
|
||
--> recv req1
|
||
<-- send resp1: ()
|
||
recv resp1
|
||
recv req2
|
||
send resp2: () -->
|
||
--> recv resp2
|
||
|
||
This case is described in Section 1.4 and is handled by omitting the
|
||
Delete payloads from the response messages.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 28]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
5.11.2. Simultaneous IKE_SA Close
|
||
|
||
Both peers can also decide to close the IKE_SA at the same time. The
|
||
desired end result is obvious; however, in certain cases the final
|
||
exchanges may not be fully completed.
|
||
|
||
Host A Host B
|
||
-------- --------
|
||
send req1: D() -->
|
||
<-- send req2: D()
|
||
--> recv req1
|
||
|
||
At this point, host B should reply as usual (with empty Informational
|
||
response), close the IKE_SA, and stop retransmitting req2. This is
|
||
because once host A receives resp1, it may not be able to reply any
|
||
longer. The situation is symmetric, so host A should behave the same
|
||
way.
|
||
|
||
Host A Host B
|
||
-------- --------
|
||
<-- send resp1: ()
|
||
send resp2: ()
|
||
|
||
Even if neither resp1 nor resp2 ever arrives, the end result is still
|
||
correct: the IKE_SA is gone. The same happens if host A never
|
||
receives req2.
|
||
|
||
5.11.3. Simultaneous CHILD_SA Rekeying
|
||
|
||
Another case that is described in the specification is simultaneous
|
||
rekeying. Section 2.8 says
|
||
|
||
"If the two ends have the same lifetime policies, it is possible
|
||
that both will initiate a rekeying at the same time (which will
|
||
result in redundant SAs). To reduce the probability of this
|
||
happening, the timing of rekeying requests SHOULD be jittered
|
||
(delayed by a random amount of time after the need for rekeying is
|
||
noticed).
|
||
|
||
This form of rekeying may temporarily result in multiple similar
|
||
SAs between the same pairs of nodes. When there are two SAs
|
||
eligible to receive packets, a node MUST accept incoming packets
|
||
through either 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 SHOULD be closed by the endpoint that created
|
||
it."
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 29]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
However, a better explanation on what impact this has on
|
||
implementations is needed. Assume that hosts A and B have an
|
||
existing IPsec SA pair with SPIs (SPIa1,SPIb1), and both start
|
||
rekeying it at the same time:
|
||
|
||
Host A Host B
|
||
-------- --------
|
||
send req1: N(REKEY_SA,SPIa1),
|
||
SA(..,SPIa2,..),Ni1,.. -->
|
||
<-- send req2: N(REKEY_SA,SPIb1),
|
||
SA(..,SPIb2,..),Ni2,..
|
||
recv req2 <--
|
||
|
||
At this point, A knows there is a simultaneous rekeying going on.
|
||
However, it cannot yet know which of the exchanges will have the
|
||
lowest nonce, so it will just note the situation and respond as
|
||
usual.
|
||
|
||
send resp2: SA(..,SPIa3,..),Nr1,.. -->
|
||
--> recv req1
|
||
|
||
Now B also knows that simultaneous rekeying is going on. Similarly
|
||
as host A, it has to respond as usual.
|
||
|
||
<-- send resp1: SA(..,SPIb3,..),Nr2,..
|
||
recv resp1 <--
|
||
--> recv resp2
|
||
|
||
At this point, there are three CHILD_SA pairs between A and B (the
|
||
old one and two new ones). A and B can now compare the nonces.
|
||
Suppose that the lowest nonce was Nr1 in message resp2; in this case,
|
||
B (the sender of req2) deletes the redundant new SA, and A (the node
|
||
that initiated the surviving rekeyed SA) deletes the old one.
|
||
|
||
send req3: D(SPIa1) -->
|
||
<-- send req4: D(SPIb2)
|
||
--> recv req3
|
||
<-- send resp4: D(SPIb1)
|
||
recv req4 <--
|
||
send resp4: D(SPIa3) -->
|
||
|
||
The rekeying is now finished.
|
||
|
||
However, there is a second possible sequence of events that can
|
||
happen if some packets are lost in the network, resulting in
|
||
retransmissions. The rekeying begins as usual, but A's first packet
|
||
(req1) is lost.
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 30]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
Host A Host B
|
||
-------- --------
|
||
send req1: N(REKEY_SA,SPIa1),
|
||
SA(..,SPIa2,..),Ni1,.. --> (lost)
|
||
<-- send req2: N(REKEY_SA,SPIb1),
|
||
SA(..,SPIb2,..),Ni2,..
|
||
recv req2 <--
|
||
send resp2: SA(..,SPIa3,..),Nr1,.. -->
|
||
--> recv resp2
|
||
<-- send req3: D(SPIb1)
|
||
recv req3 <--
|
||
send resp3: D(SPIa1) -->
|
||
--> recv resp3
|
||
|
||
From B's point of view, the rekeying is now completed, and since it
|
||
has not yet received A's req1, it does not even know that these was
|
||
simultaneous rekeying. However, A will continue retransmitting the
|
||
message, and eventually it will reach B.
|
||
|
||
resend req1 -->
|
||
--> recv req1
|
||
|
||
What should B do in this point? To B, it looks like A is trying to
|
||
rekey an SA that no longer exists; thus failing the request with
|
||
something non-fatal such as NO_PROPOSAL_CHOSEN seems like a
|
||
reasonable approach.
|
||
|
||
<-- send resp1: N(NO_PROPOSAL_CHOSEN)
|
||
recv resp1 <--
|
||
|
||
When A receives this error, it already knows there was simultaneous
|
||
rekeying, so it can ignore the error message.
|
||
|
||
5.11.4. Simultaneous IKE_SA Rekeying
|
||
|
||
Probably the most complex case occurs when both peers try to rekey
|
||
the IKE_SA at the same time. Basically, the text in Section 2.8
|
||
applies to this case as well; however, it is important to ensure that
|
||
the CHILD_SAs are inherited by the right IKE_SA.
|
||
|
||
The case where both endpoints notice the simultaneous rekeying works
|
||
the same way as with CHILD_SAs. After the CREATE_CHILD_SA exchanges,
|
||
three IKE_SAs exist between A and B; the one containing the lowest
|
||
nonce inherits the CHILD_SAs.
|
||
|
||
However, there is a twist to the other case where one rekeying
|
||
finishes first:
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 31]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
Host A Host B
|
||
-------- --------
|
||
send req1:
|
||
SA(..,SPIa1,..),Ni1,.. -->
|
||
<-- send req2: SA(..,SPIb1,..),Ni2,..
|
||
--> recv req1
|
||
<-- send resp1: SA(..,SPIb2,..),Nr2,..
|
||
recv resp1 <--
|
||
send req3: D() -->
|
||
--> recv req3
|
||
|
||
At this point, host B sees a request to close the IKE_SA. There's
|
||
not much more to do than to reply as usual. However, at this point
|
||
host B should stop retransmitting req2, since once host A receives
|
||
resp3, it will delete all the state associated with the old IKE_SA
|
||
and will not be able to reply to it.
|
||
|
||
<-- send resp3: ()
|
||
|
||
5.11.5. Closing and Rekeying a CHILD_SA
|
||
|
||
A case similar to simultaneous rekeying can occur if one peer decides
|
||
to close an SA and the other peer tries to rekey it:
|
||
|
||
Host A Host B
|
||
-------- --------
|
||
send req1: D(SPIa) -->
|
||
<-- send req2: N(REKEY_SA,SPIb),SA,..
|
||
--> recv req1
|
||
|
||
At this point, host B notices that host A is trying to close an SA
|
||
that host B is currently rekeying. Replying as usual is probably the
|
||
best choice:
|
||
|
||
<-- send resp1: D(SPIb)
|
||
|
||
Depending on in which order req2 and resp1 arrive, host A sees either
|
||
a request to rekey an SA that it is currently closing, or a request
|
||
to rekey an SA that does not exist. In both cases,
|
||
NO_PROPOSAL_CHOSEN is probably fine.
|
||
|
||
recv req2
|
||
recv resp1
|
||
send resp2: N(NO_PROPOSAL_CHOSEN) -->
|
||
--> recv resp2
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 32]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
5.11.6. Closing a New CHILD_SA
|
||
|
||
Yet another case occurs when host A creates a CHILD_SA pair, but soon
|
||
thereafter host B decides to delete it (possible because its policy
|
||
changed):
|
||
|
||
Host A Host B
|
||
-------- --------
|
||
send req1: [N(REKEY_SA,SPIa1)],
|
||
SA(..,SPIa2,..),.. -->
|
||
--> recv req1
|
||
(lost) <-- send resp1: SA(..,SPIb2,..),..
|
||
|
||
<-- send req2: D(SPIb2)
|
||
recv req2
|
||
|
||
At this point, host A has not yet received message resp1 (and is
|
||
retransmitting message req1), so it does not recognize SPIb in
|
||
message req2. What should host A do?
|
||
|
||
One option would be to reply with an empty Informational response.
|
||
However, this same reply would also be sent if host A has received
|
||
resp1, but has already sent a new request to delete the SA that was
|
||
just created. This would lead to a situation where the peers are no
|
||
longer in sync about which SAs exist between them. However, host B
|
||
would eventually notice that the other half of the CHILD_SA pair has
|
||
not been deleted. Section 1.4 describes this case and notes that "a
|
||
node SHOULD regard half-closed connections as anomalous and audit
|
||
their existence should they persist", and continues that "if
|
||
connection state becomes sufficiently messed up, a node MAY close the
|
||
IKE_SA".
|
||
|
||
Another solution that has been proposed is to reply with an
|
||
INVALID_SPI notification that contains SPIb. This would explicitly
|
||
tell host B that the SA was not deleted, so host B could try deleting
|
||
it again later. However, this usage is not part of the IKEv2
|
||
specification and would not be in line with normal use of the
|
||
INVALID_SPI notification where the data field contains the SPI the
|
||
recipient of the notification would put in outbound packets.
|
||
|
||
Yet another solution would be to ignore req2 at this time and wait
|
||
until we have received resp1. However, this alternative has not been
|
||
fully analyzed at this time; in general, ignoring valid requests is
|
||
always a bit dangerous, because both endpoints could do it, leading
|
||
to a deadlock.
|
||
|
||
This document recommends the first alternative.
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 33]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
5.11.7. Rekeying a New CHILD_SA
|
||
|
||
Yet another case occurs when a CHILD_SA is rekeyed soon after it has
|
||
been created:
|
||
|
||
Host A Host B
|
||
-------- --------
|
||
send req1: [N(REKEY_SA,SPIa1)],
|
||
SA(..,SPIa2,..),.. -->
|
||
(lost) <-- send resp1: SA(..,SPIb2,..),..
|
||
|
||
<-- send req2: N(REKEY_SA,SPIb2),
|
||
SA(..,SPIb3,..),..
|
||
recv req2 <--
|
||
|
||
To host A, this looks like a request to rekey an SA that does not
|
||
exist. Like in the simultaneous rekeying case, replying with
|
||
NO_PROPOSAL_CHOSEN is probably reasonable:
|
||
|
||
send resp2: N(NO_PROPOSAL_CHOSEN) -->
|
||
recv resp1
|
||
|
||
5.11.8. Collisions with IKE_SA Rekeying
|
||
|
||
Another set of cases occurs when one peer starts rekeying the IKE_SA
|
||
at the same time the other peer starts creating, rekeying, or closing
|
||
a CHILD_SA. Suppose that host B starts creating a CHILD_SA, and soon
|
||
after, host A starts rekeying the IKE_SA:
|
||
|
||
Host A Host B
|
||
-------- --------
|
||
<-- send req1: SA,Ni1,TSi,TSr
|
||
send req2: SA,Ni2,.. -->
|
||
--> recv req2
|
||
|
||
What should host B do at this point? Replying as usual would seem
|
||
like a reasonable choice:
|
||
|
||
<-- send resp2: SA,Ni2,..
|
||
recv resp2 <--
|
||
send req3: D() -->
|
||
--> recv req3
|
||
|
||
Now, a problem arises: If host B now replies normally with an empty
|
||
Informational response, this will cause host A to delete state
|
||
associated with the IKE_SA. This means host B should stop
|
||
retransmitting req1. However, host B cannot know whether or not host
|
||
A has received req1. If host A did receive it, it will move the
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 34]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
CHILD_SA to the new IKE_SA as usual, and the state information will
|
||
then be out of sync.
|
||
|
||
It seems this situation is tricky to handle correctly. Our proposal
|
||
is as follows: if a host receives a request to rekey the IKE_SA when
|
||
it has CHILD_SAs in "half-open" state (currently being created or
|
||
rekeyed), it should reply with NO_PROPOSAL_CHOSEN. If a host
|
||
receives a request to create or rekey a CHILD_SA after it has started
|
||
rekeying the IKE_SA, it should reply with NO_ADDITIONAL_SAS.
|
||
|
||
The case where CHILD_SAs are being closed is even worse. Our
|
||
recommendation is that if a host receives a request to rekey the
|
||
IKE_SA when it has CHILD_SAs in "half-closed" state (currently being
|
||
closed), it should reply with NO_PROPOSAL_CHOSEN. And if a host
|
||
receives a request to close a CHILD_SA after it has started rekeying
|
||
the IKE_SA, it should reply with an empty Informational response.
|
||
This ensures that at least the other peer will eventually notice that
|
||
the CHILD_SA is still in "half-closed" state and will start a new
|
||
IKE_SA from scratch.
|
||
|
||
5.11.9. Closing and Rekeying the IKE_SA
|
||
|
||
The final case considered in this section occurs if one peer decides
|
||
to close the IKE_SA while the other peer tries to rekey it.
|
||
|
||
Host A Host B
|
||
-------- --------
|
||
send req1: SA(..,SPIa1,..),Ni1 -->
|
||
<-- send req2: D()
|
||
--> recv req1
|
||
recv req2 <--
|
||
|
||
At this point, host B should probably reply with NO_PROPOSAL_CHOSEN,
|
||
and host A should reply as usual, close the IKE_SA, and stop
|
||
retransmitting req1.
|
||
|
||
<-- send resp1: N(NO_PROPOSAL_CHOSEN)
|
||
send resp2: ()
|
||
|
||
If host A wants to continue communication with B, it can now start a
|
||
new IKE_SA.
|
||
|
||
5.11.10. Summary
|
||
|
||
If a host receives a request to rekey:
|
||
|
||
o a CHILD_SA pair that the host is currently trying to close: reply
|
||
with NO_PROPOSAL_CHOSEN.
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 35]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
o a CHILD_SA pair that the host is currently rekeying: reply as
|
||
usual, but prepare to close redundant SAs later based on the
|
||
nonces.
|
||
|
||
o a CHILD_SA pair that does not exist: reply with
|
||
NO_PROPOSAL_CHOSEN.
|
||
|
||
o the IKE_SA, and the host is currently rekeying the IKE_SA: reply
|
||
as usual, but prepare to close redundant SAs and move inherited
|
||
CHILD_SAs later based on the nonces.
|
||
|
||
o the IKE_SA, and the host is currently creating, rekeying, or
|
||
closing a CHILD_SA: reply with NO_PROPOSAL_CHOSEN.
|
||
|
||
o the IKE_SA, and the host is currently trying to close the IKE_SA:
|
||
reply with NO_PROPOSAL_CHOSEN.
|
||
|
||
If a host receives a request to close:
|
||
|
||
o a CHILD_SA pair that the host is currently trying to close: reply
|
||
without Delete payloads.
|
||
|
||
o a CHILD_SA pair that the host is currently rekeying: reply as
|
||
usual, with Delete payload.
|
||
|
||
o a CHILD_SA pair that does not exist: reply without Delete
|
||
payloads.
|
||
|
||
o the IKE_SA, and the host is currently rekeying the IKE_SA: reply
|
||
as usual, and forget about our own rekeying request.
|
||
|
||
o the IKE_SA, and the host is currently trying to close the IKE_SA:
|
||
reply as usual, and forget about our own close request.
|
||
|
||
If a host receives a request to create or rekey a CHILD_SA when it is
|
||
currently rekeying the IKE_SA: reply with NO_ADDITIONAL_SAS.
|
||
|
||
If a host receives a request to delete a CHILD_SA when it is
|
||
currently rekeying the IKE_SA: reply without Delete payloads.
|
||
|
||
5.12. Diffie-Hellman and Rekeying the IKE_SA
|
||
|
||
There has been some confusion whether doing a new Diffie-Hellman
|
||
exchange is mandatory when the IKE_SA is rekeyed.
|
||
|
||
It seems that this case is allowed by the IKEv2 specification.
|
||
Section 2.18 shows the Diffie-Hellman term (g^ir) in brackets.
|
||
Section 3.3.3 does not contradict this when it says that including
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 36]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
the D-H transform is mandatory: although including the transform is
|
||
mandatory, it can contain the value "NONE".
|
||
|
||
However, having the option to skip the Diffie-Hellman exchange when
|
||
rekeying the IKE_SA does not add useful functionality to the
|
||
protocol. The main purpose of rekeying the IKE_SA is to ensure that
|
||
the compromise of old keying material does not provide information
|
||
about the current keys, or vice versa. This requires performing the
|
||
Diffie-Hellman exchange when rekeying. Furthermore, it is likely
|
||
that this option would have been removed from the protocol as
|
||
unnecessary complexity had it been discussed earlier.
|
||
|
||
Given this, we recommend that implementations should have a hard-
|
||
coded policy that requires performing a new Diffie-Hellman exchange
|
||
when rekeying the IKE_SA. In other words, the initiator should not
|
||
propose the value "NONE" for the D-H transform, and the responder
|
||
should not accept such a proposal. This policy also implies that a
|
||
successful exchange rekeying the IKE_SA always includes the KEi/KEr
|
||
payloads.
|
||
|
||
(References: "Rekeying IKE_SAs with the CREATE_CHILD_SA exhange"
|
||
thread, Oct 2005. "Comments of
|
||
draft-eronen-ipsec-ikev2-clarifications-02.txt" thread, Apr 2005.)
|
||
|
||
6. Configuration Payloads
|
||
|
||
6.1. Assigning IP Addresses
|
||
|
||
Section 2.9 talks about traffic selector negotiation and mentions
|
||
that "In support of the scenario described in section 1.1.3, an
|
||
initiator may request that the responder assign an IP address and
|
||
tell the initiator what it is."
|
||
|
||
This sentence is correct, but its placement is slightly confusing.
|
||
IKEv2 does allow the initiator to request assignment of an IP address
|
||
from the responder, but this is done using configuration payloads,
|
||
not traffic selector payloads. An address in a TSi payload in a
|
||
response does not mean that the responder has assigned that address
|
||
to the initiator; it only means that if packets matching these
|
||
traffic selectors are sent by the initiator, IPsec processing can be
|
||
performed as agreed for this SA. The TSi payload itself does not
|
||
give the initiator permission to configure the initiator's TCP/IP
|
||
stack with the address and use it as its source address.
|
||
|
||
In other words, IKEv2 does not have two different mechanisms for
|
||
assigning addresses, but only one: configuration payloads. In the
|
||
scenario described in Section 1.1.3, both configuration and traffic
|
||
selector payloads are usually included in the same message, and they
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 37]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
often contain the same information in the response message (see
|
||
Section 6.3 of this document for some examples). However, their
|
||
semantics are still different.
|
||
|
||
6.2. Requesting any INTERNAL_IP4/IP6_ADDRESS
|
||
|
||
When describing the INTERNAL_IP4/IP6_ADDRESS attributes, Section
|
||
3.15.1 says that "In a request message, the address specified is a
|
||
requested address (or zero if no specific address is requested)".
|
||
The question here is whether "zero" means an address "0.0.0.0" or a
|
||
zero-length string.
|
||
|
||
Earlier, the same section also says that "If an attribute in the
|
||
CFG_REQUEST Configuration Payload is not zero-length, it is taken as
|
||
a suggestion for that attribute". Also, the table of configuration
|
||
attributes shows that the length of INTERNAL_IP4_ADDRESS is either "0
|
||
or 4 octets", and likewise, INTERNAL_IP6_ADDRESS is either "0 or 17
|
||
octets".
|
||
|
||
Thus, if the client does not request a specific address, it includes
|
||
a zero-length INTERNAL_IP4/IP6_ADDRESS attribute, not an attribute
|
||
containing an all-zeroes address. The example in 2.19 is thus
|
||
incorrect, since it shows the attribute as
|
||
"INTERNAL_ADDRESS(0.0.0.0)".
|
||
|
||
However, since the value is only a suggestion, implementations are
|
||
recommended to ignore suggestions they do not accept; or in other
|
||
words, to treat the same way a zero-length INTERNAL_IP4_ADDRESS,
|
||
"0.0.0.0", and any other addresses the implementation does not
|
||
recognize as a reasonable suggestion.
|
||
|
||
6.3. INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET
|
||
|
||
Section 3.15.1 describes the INTERNAL_IP4_SUBNET as "The protected
|
||
sub-networks that this edge-device protects. This attribute is made
|
||
up of two fields: the first is an IP address and the second is a
|
||
netmask. Multiple sub-networks MAY be requested. The responder MAY
|
||
respond with zero or more sub-network attributes."
|
||
INTERNAL_IP6_SUBNET is defined in a similar manner.
|
||
|
||
This raises two questions: first, since this information is usually
|
||
included in the TSr payload, what functionality does this attribute
|
||
add? And second, what does this attribute mean in CFG_REQUESTs?
|
||
|
||
For the first question, there seem to be two sensible
|
||
interpretations. Clearly TSr (in IKE_AUTH or CREATE_CHILD_SA
|
||
response) indicates which subnets are accessible through the SA that
|
||
was just created.
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 38]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
The first interpretation of the INTERNAL_IP4/6_SUBNET attributes is
|
||
that they indicate additional subnets that can be reached through
|
||
this gateway, but need a separate SA. According to this
|
||
interpretation, the INTERNAL_IP4/6_SUBNET attributes are useful
|
||
mainly when they contain addresses not included in TSr.
|
||
|
||
The second interpretation is that the INTERNAL_IP4/6_SUBNET
|
||
attributes 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. According to
|
||
this interpretation, the attributes are useful mainly when TSr
|
||
contains addresses not included in the INTERNAL_IP4/6_SUBNET
|
||
attributes.
|
||
|
||
It turns out that these two interpretations are not incompatible, but
|
||
rather two sides of the same principle: traffic to the addresses
|
||
listed in the INTERNAL_IP4/6_SUBNET attributes should be sent via
|
||
this gateway. If there are no existing IPsec SAs whose traffic
|
||
selectors cover the address in question, new SAs have to be created.
|
||
|
||
A couple of examples are given below. For instance, if there are two
|
||
subnets, 192.0.1.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(192.0.1.234)
|
||
INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
|
||
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
|
||
TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
|
||
TSr = ((0, 0-65535, 192.0.1.0-192.0.1.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. Another possible reply would have been this:
|
||
|
||
CP(CFG_REPLY) =
|
||
INTERNAL_IP4_ADDRESS(192.0.1.234)
|
||
INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
|
||
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 39]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
|
||
TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)
|
||
|
||
This 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(192.0.1.234)
|
||
INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
|
||
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
|
||
TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
|
||
TSr = (0, 0-65535, 192.0.1.0-192.0.1.63)
|
||
|
||
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 reply could be this:
|
||
|
||
CP(CFG_REPLY) =
|
||
INTERNAL_IP4_ADDRESS(192.0.1.234)
|
||
INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
|
||
INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
|
||
TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
|
||
TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)
|
||
|
||
It is less clear what the attributes mean in CFG_REQUESTs, and
|
||
whether other lengths than zero make sense in this situation (but for
|
||
INTERNAL_IP6_SUBNET, zero length is not allowed at all!). This
|
||
document recommends that implementations should not include
|
||
INTERNAL_IP4_SUBNET or INTERNAL_IP6_SUBNET attributes in
|
||
CFG_REQUESTs.
|
||
|
||
For the IPv4 case, this document recommends using only netmasks
|
||
consisting of some amount of "1" bits followed by "0" bits; for
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 40]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
instance, "255.0.255.0" would not be a valid netmask for
|
||
INTERNAL_IP4_SUBNET.
|
||
|
||
It is also worthwhile to note that the contents of the INTERNAL_IP4/
|
||
6_SUBNET attributes do not imply link boundaries. For instance, a
|
||
gateway providing access to a large company intranet using addresses
|
||
from the 10.0.0.0/8 block can send a single INTERNAL_IP4_SUBNET
|
||
attribute (10.0.0.0/255.0.0.0) even if the intranet has hundreds of
|
||
routers and separate links.
|
||
|
||
(References: Tero Kivinen's mail "Intent of couple of attributes in
|
||
Configuration Payload in IKEv2?", 2004-11-19. Srinivasa Rao
|
||
Addepalli's mail "INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET in
|
||
IKEv2", 2004-09-10. Yoav Nir's mail "Re: New I-D: IKEv2
|
||
Clarifications and Implementation Guidelines", 2005-02-07.
|
||
"Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK" thread,
|
||
April 2005.)
|
||
|
||
6.4. INTERNAL_IP4_NETMASK
|
||
|
||
Section 3.15.1 defines the INTERNAL_IP4_NETMASK attribute and says
|
||
that "The internal network's netmask. Only one netmask is allowed in
|
||
the request and reply messages (e.g., 255.255.255.0) and it MUST be
|
||
used only with an INTERNAL_IP4_ADDRESS attribute".
|
||
|
||
However, it is not clear what exactly this attribute means, as the
|
||
concept of "netmask" is not very well defined for point-to-point
|
||
links (unlike multi-access links, where it means "you can reach hosts
|
||
inside this netmask directly using layer 2, instead of sending
|
||
packets via a router"). Even if the operating system's TCP/IP stack
|
||
requires a netmask to be configured, for point-to-point links it
|
||
could be just set to 255.255.255.255. So, why is this information
|
||
sent in IKEv2?
|
||
|
||
One possible interpretation would be that the host is given a whole
|
||
block of IP addresses instead of a single address. This is also what
|
||
Framed-IP-Netmask does in [RADIUS], the IPCP "subnet mask" extension
|
||
does in PPP [IPCPSubnet], and the prefix length in the IPv6 Framed-
|
||
IPv6-Prefix attribute does in [RADIUS6]. However, nothing in the
|
||
specification supports this interpretation, and discussions on the
|
||
IPsec WG mailing list have confirmed it was not intended. Section
|
||
3.15.1 also says that multiple addresses are assigned using multiple
|
||
INTERNAL_IP4/6_ADDRESS attributes.
|
||
|
||
Currently, this document's interpretation is the following:
|
||
INTERNAL_IP4_NETMASK in a CFG_REPLY means roughly the same thing as
|
||
INTERNAL_IP4_SUBNET containing the same information ("send traffic to
|
||
these addresses through me"), but also implies a link boundary. For
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 41]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
instance, the client could use its own address and the netmask to
|
||
calculate the broadcast address of the link. (Whether the gateway
|
||
will actually deliver broadcast packets to other VPN clients and/or
|
||
other nodes connected to this link is another matter.)
|
||
|
||
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). However, it seems
|
||
that non-empty values for this attribute do not make sense in
|
||
CFG_REQUESTs.
|
||
|
||
Fortunately, Section 4 clearly says that a minimal implementation
|
||
does not need to include or understand the INTERNAL_IP4_NETMASK
|
||
attribute, and thus this document recommends that implementations
|
||
should not use the INTERNAL_IP4_NETMASK attribute or assume that the
|
||
other peer supports it.
|
||
|
||
(References: Charlie Kaufman's mail "RE: Proposed Last Call based
|
||
revisions to IKEv2", 2004-05-27. Email discussion with Tero Kivinen,
|
||
Jan 2005. Yoav Nir's mail "Re: New I-D: IKEv2 Clarifications and
|
||
Implementation Guidelines", 2005-02-07. "Clarifications open issue:
|
||
INTERNAL_IP4_SUBNET/NETMASK" thread, April 2005.)
|
||
|
||
6.5. Configuration Payloads for IPv6
|
||
|
||
IKEv2 also defines configuration payloads for IPv6. However, they
|
||
are based on the corresponding IPv4 payloads and do not fully follow
|
||
the "normal IPv6 way of doing things".
|
||
|
||
A client can be assigned an IPv6 address using the
|
||
INTERNAL_IP6_ADDRESS configuration payload. A minimal exchange could
|
||
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)
|
||
|
||
In particular, IPv6 stateless autoconfiguration or router
|
||
advertisement messages are not used; neither is neighbor discovery.
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 42]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
The client can also 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 will attempt to use the interface identifier
|
||
with some other prefix; if even that fails, the gateway will select
|
||
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 (and indeed, was
|
||
called INTERNAL_IP6_NETMASK in earlier versions of the IKEv2 draft).
|
||
See the previous section for more details.
|
||
|
||
While 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 [IPv6Addr] sense. In particular, they do not
|
||
necessarily have link-local addresses, and this may complicate the
|
||
use of protocols that assume them, such as [MLDv2]. (Whether they
|
||
are called "interfaces" in some particular operating system is a
|
||
different issue.)
|
||
|
||
(References: "VPN remote host configuration IPv6 ?" thread, May 2004.
|
||
"Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK" thread,
|
||
April 2005.)
|
||
|
||
6.6. INTERNAL_IP6_NBNS
|
||
|
||
Section 3.15.1 defines the INTERNAL_IP6_NBNS attribute for sending
|
||
the IPv6 address of NetBIOS name servers.
|
||
|
||
However, NetBIOS is not defined for IPv6 and probably never will be.
|
||
Thus, this attribute most likely does not make much sense.
|
||
|
||
(Pointed out by Bernard Aboba in the IP Configuration Security (ICOS)
|
||
BoF at IETF62.)
|
||
|
||
6.7. INTERNAL_ADDRESS_EXPIRY
|
||
|
||
Section 3.15.1 defines the INTERNAL_ADDRESS_EXPIRY attribute as
|
||
"Specifies the number of seconds that the host can use the internal
|
||
IP address. The host MUST renew the IP address before this expiry
|
||
time. Only one of these attributes MAY be present in the reply."
|
||
|
||
Expiry times and explicit renewals are primarily useful in
|
||
environments like DHCP, where the server cannot reliably know when
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 43]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
the client has gone away. However, in IKEv2 this is known, and the
|
||
gateway can simply free the address when the IKE_SA is deleted.
|
||
|
||
Also, Section 4 says that supporting renewals is not mandatory.
|
||
Given that this functionality is usually not needed, we recommend
|
||
that gateways should not send the INTERNAL_ADDRESS_EXPIRY attribute.
|
||
(And since this attribute does not seem to make much sense for
|
||
CFG_REQUESTs, clients should not send it either.)
|
||
|
||
Note that according to Section 4, clients are required to understand
|
||
INTERNAL_ADDRESS_EXPIRY if they receive it. A minimum implementation
|
||
would use the value to limit the lifetime of the IKE_SA.
|
||
|
||
(References: Tero Kivinen's mail "Comments of
|
||
draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.
|
||
"Questions about internal address" thread, April 2005.)
|
||
|
||
6.8. Address Assignment Failures
|
||
|
||
If the responder encounters an error while attempting to assign an IP
|
||
address to the initiator, it responds with an
|
||
INTERNAL_ADDRESS_FAILURE notification as described in Section 3.10.1.
|
||
However, there are some more complex error cases.
|
||
|
||
First, 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.
|
||
If the initiator requires the assignment of an IP address, it will
|
||
treat a response without CFG_REPLY as an error.
|
||
|
||
A second case is where the responder does support configuration
|
||
payloads, but only for particular type of addresses (IPv4 or IPv6).
|
||
Section 4 says that "A minimal IPv4 responder implementation will
|
||
ignore the contents of the CP payload except to determine that it
|
||
includes an INTERNAL_IP4_ADDRESS attribute". If, for instance, the
|
||
initiator includes both INTERNAL_IP4_ADDRESS and INTERNAL_IP6_ADDRESS
|
||
in the CFG_REQUEST, an IPv4-only responder can thus simply ignore the
|
||
IPv6 part and process the IPv4 request as usual.
|
||
|
||
A third case is where the initiator requests multiple addresses of a
|
||
type that the responder supports: what should happen if some (but not
|
||
all) of the requests fail? It seems that an optimistic approach
|
||
would be the best one here: if the responder is able to assign at
|
||
least one address, it replies with those; it sends
|
||
INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned.
|
||
|
||
(References: "ikev2 and internal_ivpn_address" thread, June 2005.)
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 44]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
7. Miscellaneous Issues
|
||
|
||
7.1. Matching ID_IPV4_ADDR and ID_IPV6_ADDR
|
||
|
||
When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr
|
||
payloads, IKEv2 does not require this address to match anything in
|
||
the TSi/TSr payloads. For example, in a site-to-site VPN between two
|
||
security gateways, the gateways could authenticate each other as
|
||
ID_IPV4_ADDR(192.0.1.1) and ID_IPV4_ADDR(192.0.2.1), and then create
|
||
a CHILD_SA for protecting traffic between 192.0.1.55/32 (a host
|
||
behind the first security gateway) and 192.0.2.240/28 (a network
|
||
behind the second security gateway). The authenticated identities
|
||
(IDi/IDr) are linked to the authorized traffic selectors (TSi/TSr)
|
||
using "Child SA Authorization Data" in the Peer Authorization
|
||
Database (PAD).
|
||
|
||
Furthermore, IKEv2 does not require that the addresses in
|
||
ID_IPV4_ADDR/ID_IPV6_ADDR match the address in the IP header of the
|
||
IKE packets. However, other specifications may place additional
|
||
requirements regarding this. For example, [PKI4IPsec] requires that
|
||
implementation must be capable of comparing the addresses in the
|
||
ID_IPV4_ADDR/ID_IPV6_ADDR with the addresses in the IP header of the
|
||
IKE packets, and this comparison must be enabled by default.
|
||
|
||
(References: "Identities types IP address,FQDN/user FQDN and DN and
|
||
its usage in preshared key authentication" thread, Jan 2005.
|
||
"Matching ID_IPV4_ADDR and ID_IPV6_ADDR" thread, May 2006.)
|
||
|
||
7.2. Relationship of IKEv2 to RFC 4301
|
||
|
||
The IKEv2 specification refers to [RFC4301], but it never clearly
|
||
defines the exact relationship.
|
||
|
||
However, there are some requirements in the specification that make
|
||
it clear that IKEv2 requires [RFC4301]. In other words, an
|
||
implementation that does IPsec processing strictly according to
|
||
[RFC2401] cannot be compliant with the IKEv2 specification.
|
||
|
||
One such example can be found in Section 2.24: "Specifically, tunnel
|
||
encapsulators and decapsulators for all tunnel-mode SAs created by
|
||
IKEv2 [...] MUST implement the tunnel encapsulation and
|
||
decapsulation processing specified in [RFC4301] to prevent discarding
|
||
of ECN congestion indications."
|
||
|
||
Nevertheless, the changes required to existing [RFC2401]
|
||
implementations are not very large, especially since supporting many
|
||
of the new features (such as Extended Sequence Numbers) is optional.
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 45]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
7.3. Reducing the Window Size
|
||
|
||
In IKEv2, the window size is assumed to be a (possibly configurable)
|
||
property of a particular implementation and is not related to
|
||
congestion control (unlike the window size in TCP, for instance).
|
||
|
||
In particular, it is not defined what the responder should do when it
|
||
receives a SET_WINDOW_SIZE notification containing a smaller value
|
||
than is currently in effect. Thus, there is currently no way to
|
||
reduce the window size of an existing IKE_SA. However, when rekeying
|
||
an IKE_SA, the new IKE_SA starts with window size 1 until it is
|
||
explicitly increased by sending a new SET_WINDOW_SIZE notification.
|
||
|
||
(References: Tero Kivinen's mail "Comments of
|
||
draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.)
|
||
|
||
7.4. Minimum Size of Nonces
|
||
|
||
Section 2.10 says that "Nonces used in IKEv2 MUST be randomly chosen,
|
||
MUST be at least 128 bits in size, and MUST be at least half the key
|
||
size of the negotiated prf."
|
||
|
||
However, the initiator chooses the nonce before the outcome of the
|
||
negotiation is known. In this case, the nonce has to be long enough
|
||
for all the PRFs being proposed.
|
||
|
||
7.5. Initial Zero Octets on Port 4500
|
||
|
||
It is not clear whether a peer sending an IKE_SA_INIT request on port
|
||
4500 should include the initial four zero octets. Section 2.23 talks
|
||
about how to upgrade to tunneling over port 4500 after message 2, but
|
||
it does not say what to do if message 1 is sent on port 4500.
|
||
|
||
IKE MUST listen on port 4500 as well as port 500.
|
||
|
||
[...]
|
||
|
||
The IKE initiator MUST check these payloads if present and if
|
||
they do not match the addresses in the outer packet MUST tunnel
|
||
all future IKE and ESP packets associated with this IKE_SA over
|
||
UDP port 4500.
|
||
|
||
To tunnel IKE packets over UDP port 4500, the IKE header has four
|
||
octets of zero prepended and the result immediately follows the
|
||
UDP header. [...]
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 46]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
The very beginning of Section 2 says "... though IKE messages may
|
||
also be received on UDP port 4500 with a slightly different format
|
||
(see section 2.23)."
|
||
|
||
That "slightly different format" is only described in discussing what
|
||
to do after changing to port 4500. However, [RFC3948] shows clearly
|
||
the format has the initial zeros even for initiators on port 4500.
|
||
Furthermore, without the initial zeros, the processing engine cannot
|
||
determine whether the packet is an IKE packet or an ESP packet.
|
||
|
||
Thus, all packets sent on port 4500 need the four-zero prefix;
|
||
otherwise, the receiver won't know how to handle them.
|
||
|
||
7.6. Destination Port for NAT Traversal
|
||
|
||
Section 2.23 says that "an IPsec endpoint that discovers a NAT
|
||
between it and its correspondent MUST send all subsequent traffic to
|
||
and from port 4500".
|
||
|
||
This sentence is misleading. The peer "outside" the NAT uses source
|
||
port 4500 for the traffic it sends, but the destination port is, of
|
||
course, taken from packets sent by the peer behind the NAT. This
|
||
port number is usually dynamically allocated by the NAT.
|
||
|
||
7.7. SPI Values for Messages outside an IKE_SA
|
||
|
||
The IKEv2 specification is not quite clear what SPI values should be
|
||
used in the IKE header for the small number of notifications that are
|
||
allowed to be sent outside an IKE_SA. Note that such notifications
|
||
are explicitly not Informational exchanges; Section 1.5 makes it
|
||
clear that these are one-way messages that must not be responded to.
|
||
|
||
There are two cases when such a one-way notification can be sent:
|
||
INVALID_IKE_SPI and INVALID_SPI.
|
||
|
||
In case of INVALID_IKE_SPI, the message sent is a response message,
|
||
and Section 2.21 says that "If a response is sent, the response MUST
|
||
be sent to the IP address and port from whence it came with the same
|
||
IKE SPIs and the Message ID copied."
|
||
|
||
In case of INVALID_SPI, however, there are no IKE SPI values that
|
||
would be meaningful to the recipient of such a notification. Also,
|
||
the message sent is now an INFORMATIONAL request. A strict
|
||
interpretation of the specification would require the sender to
|
||
invent garbage values for the SPI fields. However, we think this was
|
||
not the intention, and using zero values is acceptable.
|
||
|
||
(References: "INVALID_IKE_SPI" thread, June 2005.)
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 47]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
7.8. Protocol ID/SPI Fields in Notify Payloads
|
||
|
||
Section 3.10 says that the Protocol ID field in Notify payloads "For
|
||
notifications that do not relate to an existing SA, this field MUST
|
||
be sent as zero and MUST be ignored on receipt". However, the
|
||
specification does not clearly say which notifications are related to
|
||
existing SAs and which are not.
|
||
|
||
Since the main purpose of the Protocol ID field is to specify the
|
||
type of the SPI, our interpretation is that the Protocol ID field
|
||
should be non-zero only when the SPI field is non-empty.
|
||
|
||
There are currently only two notifications where this is the case:
|
||
INVALID_SELECTORS and REKEY_SA.
|
||
|
||
7.9. Which message should contain INITIAL_CONTACT
|
||
|
||
The description of the INITIAL_CONTACT notification in Section 3.10.1
|
||
says that "This notification asserts that this IKE_SA is the only
|
||
IKE_SA currently active between the authenticated identities".
|
||
However, neither Section 2.4 nor 3.10.1 says in which message this
|
||
payload should be placed.
|
||
|
||
The general agreement is that INITIAL_CONTACT is best communicated in
|
||
the first IKE_AUTH request, not as a separate exchange afterwards.
|
||
|
||
(References: "Clarifying the use of INITIAL_CONTACT in IKEv2" thread,
|
||
April 2005. "Initial Contact messages" thread, December 2004.
|
||
"IKEv2 and Initial Contact" thread, September 2004 and April 2005.)
|
||
|
||
7.10. Alignment of Payloads
|
||
|
||
Many IKEv2 payloads contain fields marked as "RESERVED", mostly
|
||
because IKEv1 had them, and partly because they make the pictures
|
||
easier to draw. In particular, payloads in IKEv2 are not, in
|
||
general, aligned to 4-octet boundaries. (Note that payloads were not
|
||
aligned to 4-octet boundaries in IKEv1 either.)
|
||
|
||
(References: "IKEv2: potential 4-byte alignment problem" thread, June
|
||
2004.)
|
||
|
||
7.11. Key Length Transform Attribute
|
||
|
||
Section 3.3.5 says that "The only algorithms defined in this document
|
||
that accept attributes are the AES based encryption, integrity, and
|
||
pseudo-random functions, which require a single attribute specifying
|
||
key width."
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 48]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
This is incorrect. The AES-based integrity and pseudo-random
|
||
functions defined in [IKEv2] always use a 128-bit key. In fact,
|
||
there are currently no integrity or PRF algorithms that use the key
|
||
length attribute (and we recommend that they should not be defined in
|
||
the future either).
|
||
|
||
For encryption algorithms, the situation is slightly more complex
|
||
since there are three different types of algorithms:
|
||
|
||
o The key length attribute is never used with algorithms that use a
|
||
fixed length key, such as DES and IDEA.
|
||
|
||
o The key length attribute is always included for the currently
|
||
defined AES-based algorithms (Cipher Block Chaining (CBC), Counter
|
||
(CTR) Mode, Counter with CBC-MAC (CCM), and Galois/Counter Mode
|
||
(GCM)). Omitting the key length attribute is not allowed; if the
|
||
proposal does not contain it, the proposal has to be rejected.
|
||
|
||
o For other algorithms, the key length attribute can be included but
|
||
is not mandatory. These algorithms include, e.g., RC5, CAST, and
|
||
BLOWFISH. If the key length attribute is not included, the
|
||
default value specified in [RFC2451] is used.
|
||
|
||
7.12. IPsec IANA Considerations
|
||
|
||
There are currently three different IANA registry files that contain
|
||
important numbers for IPsec: ikev2-registry, isakmp-registry, and
|
||
ipsec-registry. Implementers should note that IKEv2 may use numbers
|
||
different from those of IKEv1 for a particular algorithm.
|
||
|
||
For instance, an encryption algorithm can have up to three different
|
||
numbers: the IKEv2 "Transform Type 1" identifier in ikev2-registry,
|
||
the IKEv1 phase 1 "Encryption Algorithm" identifier in ipsec-
|
||
registry, and the IKEv1 phase 2 "IPSEC ESP Transform Identifier"
|
||
isakmp-registry. Although some algorithms have the same number in
|
||
all three registries, the registries are not identical.
|
||
|
||
Similarly, an integrity algorithm can have at least the IKEv2
|
||
"Transform Type 3" identifier in ikev2-registry, the IKEv1 phase 2
|
||
"IPSEC AH Transform Identifier" in isakmp-registry, and the IKEv1
|
||
phase 2 ESP "Authentication Algorithm Security Association Attribute"
|
||
identifier in isakmp-registry. And there is also the IKEv1 phase 1
|
||
"Hash Algorithm" list in ipsec-registry.
|
||
|
||
This issue needs special care also when writing a specification for
|
||
how a new algorithm is used with IPsec.
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 49]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
7.13. Combining ESP and AH
|
||
|
||
The IKEv2 specification contains some misleading text about how ESP
|
||
and AH can be combined.
|
||
|
||
IKEv2 is based on [RFC4301], which does not include "SA bundles" that
|
||
were part of [RFC2401]. While a single packet can go through IPsec
|
||
processing multiple times, each of these passes uses a separate SA,
|
||
and the passes are coordinated by the forwarding tables. In IKEv2,
|
||
each of these SAs has to be created using a separate CREATE_CHILD_SA
|
||
exchange. Thus, the text in Section 2.7 about a single proposal
|
||
containing both ESP and AH is incorrect.
|
||
|
||
Moreover, the combination of ESP and AH (between the same endpoints)
|
||
had already become largely obsolete in 1998 when RFC 2406 was
|
||
published. Our recommendation is that IKEv2 implementations should
|
||
not support this combination, and implementers should not assume the
|
||
combination can be made to work in an interoperable manner.
|
||
|
||
(References: "Rekeying SA bundles" thread, Oct 2005.)
|
||
|
||
8. Implementation Mistakes
|
||
|
||
Some implementers at the early IKEv2 bakeoffs didn't do everything
|
||
correctly. This may seem like an obvious statement, but it is
|
||
probably useful to list a few things that were clear in the document,
|
||
but that some implementers didn't do. All of these things caused
|
||
interoperability problems.
|
||
|
||
o Some implementations continued to send traffic on a CHILD_SA after
|
||
it was rekeyed, even after receiving an DELETE payload.
|
||
|
||
o After rekeying an IKE_SA, some implementations did not reset their
|
||
message counters to zero. One set the counter to 2, another did
|
||
not reset the counter at all.
|
||
|
||
o Some implementations could only handle a single pair of traffic
|
||
selectors or would only process the first pair in the proposal.
|
||
|
||
o Some implementations responded to a delete request by sending an
|
||
empty INFORMATIONAL response and then initiated their own
|
||
INFORMATIONAL exchange with the pair of SAs to delete.
|
||
|
||
o Although this did not happen at the bakeoff, from the discussion
|
||
there, it is clear that some people had not implemented message
|
||
window sizes correctly. Some implementations might have sent
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 50]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
messages that did not fit into the responder's message windows,
|
||
and some implementations may not have torn down an SA if they did
|
||
not ever receive a message that they know they should have.
|
||
|
||
9. Security Considerations
|
||
|
||
This document does not introduce any new security considerations to
|
||
IKEv2. If anything, clarifying complex areas of the specification
|
||
can reduce the likelihood of implementation problems that may have
|
||
security implications.
|
||
|
||
10. Acknowledgments
|
||
|
||
This document is mainly based on conversations on the IPsec WG
|
||
mailing list. The authors would especially like to thank Bernard
|
||
Aboba, Jari Arkko, Vijay Devarapalli, William Dixon, Francis Dupont,
|
||
Alfred Hoenes, Mika Joutsenvirta, Charlie Kaufman, Stephen Kent, Tero
|
||
Kivinen, Yoav Nir, Michael Richardson, and Joel Snyder for their
|
||
contributions.
|
||
|
||
In addition, the authors would like to thank all the participants of
|
||
the first public IKEv2 bakeoff, held in Santa Clara in February 2005,
|
||
for their questions and proposed clarifications.
|
||
|
||
11. References
|
||
|
||
11.1. Normative References
|
||
|
||
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
|
||
Protocol", RFC 4306, December 2005.
|
||
|
||
[IKEv2ALG] Schiller, J., "Cryptographic Algorithms for Use in the
|
||
Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
|
||
December 2005.
|
||
|
||
[PKCS1v20] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
|
||
Specifications Version 2.0", RFC 2437, October 1998.
|
||
|
||
[PKCS1v21] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
|
||
Standards (PKCS) #1: RSA Cryptography Specifications
|
||
Version 2.1", RFC 3447, February 2003.
|
||
|
||
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
|
||
the Internet Protocol", RFC 2401, November 1998.
|
||
|
||
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
|
||
Internet Protocol", RFC 4301, December 2005.
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 51]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
11.2. Informative References
|
||
|
||
[Aura05] Aura, T., Roe, M., and A. Mohammed, "Experiences with
|
||
Host-to-Host IPsec", 13th International Workshop on
|
||
Security Protocols, Cambridge, UK, April 2005.
|
||
|
||
[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
|
||
H. Levkowetz, "Extensible Authentication Protocol
|
||
(EAP)", RFC 3748, June 2004.
|
||
|
||
[HashUse] Hoffman, P., "Use of Hash Algorithms in IKE and IPsec",
|
||
Work in Progress, July 2006.
|
||
|
||
[IPCPSubnet] Cisco Systems, Inc., "IPCP Subnet Mask Support
|
||
Enhancements", http://www.cisco.com/univercd/cc/td/
|
||
doc/product/software/ios121/121newft/121limit/121dc/
|
||
121dc3/ipcp_msk.htm, January 2003.
|
||
|
||
[IPv6Addr] Hinden, R. and S. Deering, "IP Version 6 Addressing
|
||
Architecture", RFC 4291, February 2006.
|
||
|
||
[MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility
|
||
Support in IPv6", RFC 3775, June 2004.
|
||
|
||
[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery
|
||
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
|
||
|
||
[NAI] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
|
||
Network Access Identifier", RFC 4282, December 2005.
|
||
|
||
[PKI4IPsec] Korver, B., "Internet PKI Profile of IKEv1/ISAKMP,
|
||
IKEv2, and PKIX", Work in Progress, April 2006.
|
||
|
||
[RADEAP] Aboba, B. and P. Calhoun, "RADIUS (Remote
|
||
Authentication Dial In User Service) Support For
|
||
Extensible Authentication Protocol (EAP)", RFC 3579,
|
||
September 2003.
|
||
|
||
[RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
|
||
"Remote Authentication Dial In User Service (RADIUS)",
|
||
RFC 2865, June 2000.
|
||
|
||
[RADIUS6] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
|
||
RFC 3162, August 2001.
|
||
|
||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", RFC 2119, March 1997.
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 52]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
|
||
Algorithms", RFC 2451, November 1998.
|
||
|
||
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
|
||
April 2001.
|
||
|
||
[RFC3664] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
|
||
Internet Key Exchange Protocol (IKE)", RFC 3664,
|
||
January 2004.
|
||
|
||
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and
|
||
M. Stenberg, "UDP Encapsulation of IPsec ESP Packets",
|
||
RFC 3948, January 2005.
|
||
|
||
[RFC4434] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
|
||
Internet Key Exchange Protocol (IKE)", RFC 4434,
|
||
February 2006.
|
||
|
||
[RFC822] Crocker, D., "Standard for the format of ARPA Internet
|
||
text messages", RFC 822, August 1982.
|
||
|
||
[ReAuth] Nir, Y., "Repeated Authentication in Internet Key
|
||
Exchange (IKEv2) Protocol", RFC 4478, April 2006.
|
||
|
||
[SCVP] Freeman, T., Housley, R., Malpani, A., Cooper, D., and
|
||
T. Polk, "Simple Certificate Validation Protocol
|
||
(SCVP)", Work in Progress, June 2006.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 53]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
Appendix A. 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 or the
|
||
IKEv2 specification, the other text is considered correct.
|
||
|
||
Vendor-ID (V) payloads may be included in any place in any message.
|
||
This sequence shows what are, in our opinion, the most logical places
|
||
for them.
|
||
|
||
The specification does not say which messages can contain
|
||
N(SET_WINDOW_SIZE). It can possibly be included in any message, but
|
||
it is not yet shown below.
|
||
|
||
A.1. IKE_SA_INIT Exchange
|
||
|
||
request --> [N(COOKIE)],
|
||
SA, KE, Ni,
|
||
[N(NAT_DETECTION_SOURCE_IP)+,
|
||
N(NAT_DETECTION_DESTINATION_IP)],
|
||
[V+]
|
||
|
||
normal response <-- SA, KE, Nr,
|
||
(no cookie) [N(NAT_DETECTION_SOURCE_IP),
|
||
N(NAT_DETECTION_DESTINATION_IP)],
|
||
[[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
|
||
[V+]
|
||
|
||
A.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+]
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 54]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
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+]
|
||
|
||
A.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+]
|
||
|
||
first response <-- IDr, [CERT+], AUTH,
|
||
EAP,
|
||
[V+]
|
||
|
||
/ --> EAP
|
||
repeat 1..N times |
|
||
\ <-- EAP
|
||
|
||
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+]
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 55]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
A.4. CREATE_CHILD_SA Exchange for Creating/Rekeying CHILD_SAs
|
||
|
||
request --> [N(REKEY_SA)],
|
||
[N(IPCOMP_SUPPORTED)+],
|
||
[N(USE_TRANSPORT_MODE)],
|
||
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
|
||
[N(NON_FIRST_FRAGMENTS_ALSO)],
|
||
SA, Ni, [KEi], TSi, TSr
|
||
|
||
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)]
|
||
|
||
A.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA
|
||
|
||
request --> SA, Ni, [KEi]
|
||
|
||
response <-- SA, Nr, [KEr]
|
||
|
||
A.6. INFORMATIONAL Exchange
|
||
|
||
request --> [N+],
|
||
[D+],
|
||
[CP(CFG_REQUEST)]
|
||
|
||
response <-- [N+],
|
||
[D+],
|
||
[CP(CFG_REPLY)]
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 56]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
Authors' Addresses
|
||
|
||
Pasi Eronen
|
||
Nokia Research Center
|
||
P.O. Box 407
|
||
FIN-00045 Nokia Group
|
||
Finland
|
||
|
||
EMail: pasi.eronen@nokia.com
|
||
|
||
|
||
Paul Hoffman
|
||
VPN Consortium
|
||
127 Segre Place
|
||
Santa Cruz, CA 95060
|
||
USA
|
||
|
||
EMail: paul.hoffman@vpnc.org
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 57]
|
||
|
||
RFC 4718 IKEv2 Clarifications October 2006
|
||
|
||
|
||
Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (2006).
|
||
|
||
This document is subject to the rights, licenses and restrictions
|
||
contained in BCP 78, and except as set forth therein, the authors
|
||
retain all their rights.
|
||
|
||
This document and the information contained herein are provided on an
|
||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
Intellectual Property
|
||
|
||
The IETF takes no position regarding the validity or scope of any
|
||
Intellectual Property Rights or other rights that might be claimed to
|
||
pertain to the implementation or use of the technology described in
|
||
this document or the extent to which any license under such rights
|
||
might or might not be available; nor does it represent that it has
|
||
made any independent effort to identify any such rights. Information
|
||
on the procedures with respect to rights in RFC documents can be
|
||
found in BCP 78 and BCP 79.
|
||
|
||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||
assurances of licenses to be made available, or the result of an
|
||
attempt made to obtain a general license or permission for the use of
|
||
such proprietary rights by implementers or users of this
|
||
specification can be obtained from the IETF on-line IPR repository at
|
||
http://www.ietf.org/ipr.
|
||
|
||
The IETF invites any interested party to bring to its attention any
|
||
copyrights, patents or patent applications, or other proprietary
|
||
rights that may cover technology that may be required to implement
|
||
this standard. Please address the information to the IETF at
|
||
ietf-ipr@ietf.org.
|
||
|
||
Acknowledgement
|
||
|
||
Funding for the RFC Editor function is provided by the IETF
|
||
Administrative Support Activity (IASA).
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eronen & Hoffman Informational [Page 58]
|
||
|