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

Re: Dangling phase 2 SAs (was RE: issues from the bakeoff)



On Thu, 17 Jun 1999 16:05:54 EDT you wrote
> >   Phase 1 lifetimes are set to prevent too much use of a key. 
> > If it was
> > OK to use the key at X but not a X plus some delta and time 
> > delta ticks
> > off then it's not OK to use the key _any more_ but it doesn't 
> > necessarily
> > mean that delta seconds ago it wasn't. Using the new lifetime that
> > Kivinen came up with (which is a great idea) makes this more apparent.
> > You want to do negotiate N pairs of IPSec SAs. Once you 
> > negotiate that Nth 
> > pair it is not OK to negotiate anymore so you delete the IKE 
> > SA but that 
> > doesn't mean that the Nth pair of IPSec SAs you just 
> > negotiated is somehow 
> > bad or unauthenticated.
> 
> They aren't necessarily bad, but they might be. And if you don't some
> mechanism to verify the authentication of the end points, if it changes,
> you'll never know until you need the phase 1 SA again.

A certificate binds an identity to a key in a verifiable way. You verified
it and created IPSec SAs. If later on the cert expires it doesn't mean
that you did not authenticate that person, only that the CA wants its
pound of flesh again. If I buy a 6pack of beer and use a driver's license
to verify my identity and age and that driver's license expires the next
day it doesn't mean that I have to throw out all the beer I hadn't drank
just because my driver's license is now expired. 

  If you check CRLs every 10 minutes for active sessions and notice that 
a certificate used to establish a session which is currently active has 
been revoked then it seems appropriate to clear the IPSec SAs. But in 
general, and in the case where a certificate is still valid (or you didn't 
even use certificates to authenticate the person) but the IKE SA has just 
gone away for whatever reason, it really doesn't make sense to delete the
IPSec SAs. It just results in temporary blackouts, as Victor Volpe described 
in the note that started this thread. 

  Dan.





References: