Re: IKEv2 SA rekeying - naming an initial SA

[Charlie_Kaufman@notesdev.ibm.com]

I believe this functionality was added as a side effect of addressing
Issue #64 (though it's a little different and might not address all
imaginable cases). When an SA is rekeyed, the SPI of the old SA is
now specified, so there is no ambiguity. The binding between the old
SA and the new is not cryptographic, but in every case I could think of
the assertion of the SPI by the trusted IKE association defeats the
same attacks.

      --Charlie

p.s. There remains the problem - inherent to the layering in IPsec - that
there is no specified API by which an app receiving packets can ask IPsec
whether this packet is coming from the same authenticated entity as
another packet with the same source address received in the past.

> I'm glad to see that there is some SA rekeying functionality in IKEv2
> that is somewhat like the rekeying functionality in SSHv2, that is, that
> a new SA can be established under the protection of and bound to a
> previous (still live) SA.
>
> Now, if only there was a concept similar to the SSHv2 session ID.  (Or
> is it there and I just missed it?)
>
> If there is no IKEv2 equivalent to the SSHv2 session ID, I would like to
> have one defined.
>
> We have a need for a way to name a [transport mode] SA and its rekeyed
> replacements where the name is cryptographically bound to the initial SA
> key exchange.