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