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.
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".
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.
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.
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.
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
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).
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:
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].
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.
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.