[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IKEv2 SA rekeying - naming an initial SA



On Tue, Aug 19, 2003 at 09:02:20PM -0400, Charlie_Kaufman@notesdev.ibm.com wrote:
> 
> 
> 
> 
> 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.

Indeed.  But I'm taking each step one at a time.  The crucial feature we
need for the CCM GSS-API mechanism is cryptographically chained SA
re-keys and an identifier cryptographically bound to the initial SA.

The interface issue is relatively simple to deal with, but it won't help
to have it and not have the above.

Nico
--