Subject: [IPsec] Issue #17: Checking of the other peer's IKE SPI

From: Yaron Sheffer <[email-masked]>
Date: Tue, 3 Mar 2009 20:18:26 +0200

Sec. 2.6:

Unlike ESP and AH where only the recipient's SPI appears in the header of a message, in IKE the sender's SPI is also sent in every message. Since the SPI chosen by the original initiator of the IKE_SA is always sent first, an endpoint with multiple IKE_SAs open that wants to find the appropriate IKE_SA using the SPI it assigned must look at the I(nitiator) Flag bit in the header to determine whether it assigned the first or the second eight octets.

Tero:

Our implementation originally only checked its own SPI half, and didn't verify that the other ends SPI half didn't change. This was found out in the interop, and we fixed it to check the other ends SPI also, but I wonder should we say one way or the other here? Also what SPI should the response have, i.e. the SPIs from the request, or the SPIs from the original IKE SA creation. I think it might be easier to just say, that implementations can use their own SPI to find the IKE SA data, but MUST also check that the other ends SPI matches the SPIs stored with IKE SA data.

Paul: Not done. This is interesting, but should be discussed on the list.

---

From: <[email-masked]>
Date: Wed, 11 Mar 2009 13:12:17 +0100

Yaron and Tero,

Hmm... it seems changing your own IKE SPI during an IKE_SA does not
work anyway, so if you get a packet where the peer's SPI is different
(than what it used for this IKE_SA earlier), it did not come from 
a spec-compliant peer.
 
The question is whether we should require the recipient to check
that the peer's SPI has not changed. To me, it looks like this would
not be an interoperability issue (the peer is doing something outside
the spec, so it can't expect any particular behavior from us)... 
 
Tero, how did you encounter this in the interops? (And was the node
sending this buggy, or did it consider itself to be behaving according
to the spec?)
 
If it's not an interop issue, and not a security issue, then I'm
not sure if mandating such check is needed. But are there some 
security implications?

Best regards,
Pasi

> -----Original Message-----
> From: Yaron Sheffer
> Sent: 03 March, 2009 20:18
> To: [email-masked]
> Subject: [IPsec] Issue #17: Checking of the other peer's IKE SPI
> 
> Sec. 2.6: 
> 
> Unlike ESP and AH where only the recipient's SPI appears in the
> header of a message, in IKE the sender's SPI is also sent in every
> message. Since the SPI chosen by the original initiator of the
> IKE_SA is always sent first, an endpoint with multiple IKE_SAs open
> that wants to find the appropriate IKE_SA using the SPI it assigned
> must look at the I(nitiator) Flag bit in the header to determine
> whether it assigned the first or the second eight octets.
> 
> Tero:
> 
> Our implementation originally only checked its own SPI half, and
> didn't verify that the other ends SPI half didn't change. This was
> found out in the interop, and we fixed it to check the other ends
> SPI also, but I wonder should we say one way or the other here? Also
> what SPI should the response have, i.e. the SPIs from the request,
> or the SPIs from the original IKE SA creation. I think it might be
> easier to just say, that implementations can use their own SPI to
> find the IKE SA data, but MUST also check that the other ends SPI
> matches the SPIs stored with IKE SA data.
>

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 11 Mar 2009 15:30:05 +0200

> sending this buggy, or did it consider itself to be behaving according

The sender was TAHI project IKEv2 tester, and if I remember correctly
they sent that on purpose and they expected the other end to detect
that SPI changed, and not to continue because of that. Our code simply
used our own SPI as that is sufficient to find the IKE SA and we
didn't really care what was in the other ends SPI. I did add
additional check to our code to check the other ends SPI and drop the
packet if it is changed. 

> not sure if mandating such check is needed. But are there some 

I agree that there is no real need to mandate such check, but if
IKEv2 tester implementations are requiring such check that will be
de-facto requirement to add such check, as otherwise you will not pass
their tests.

So for that it is interoperability issue, as you cannot pass their
interoperability tests if you do not check it. So thats why I think it
would be good to say that either it is valid to check only your own
SPI or that you MUST check both spis. 
-- 
[email-masked]

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 20 Mar 2009 14:22:31 +0100

Tero Kivinen wrote:
> de-facto requirement to add such check, as otherwise you will not
> pass their tests.
> 
> interoperability tests if you do not check it. So thats why I think
> it would be good to say that either it is valid to check only your
> own SPI or that you MUST check both spis.

Hmm, I see your point -- if even tester implementors have been
confused, it certainly would be good to say *something* about this in
the specification.

(But since this is about interaction with non-compliant
implementations, I don't really care which way we choose..)

Best regards,
Pasi