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

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




> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM]
> Sent: June 17, 1999 5:22 PM
> To: Tim Jenkins
> Cc: Volpe, Victor; ipsec@lists.tislabs.com
> Subject: 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. 

I don't think this a valid analogy, because most places don't take away your
privilege to buy beer as you get older, and also, the driver's license
verifies that you have the privilege to buy the beer, not drink it.

A better analogy is a passport. On Canadian passports there is also a
requirement that you not use it if it's going to expire in less than 3
months. The point of this is that you shouldn't be in a foreign country with
an expired passport, and they want to minimize that possibility. Yes, maybe
you are because it expired while you were away, but you better not need it
once it expires.

My argument is about authorization, which I didn't explicitly mention
before. The window of unauthorized use when a certificate becomes revoked
can be reduced by requiring the existence of the phase 1 SA.

> 
>   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. 

Yes, that's correct. But it does make sense to define behaviour where there
are differences that have the potential to reduce either security or
interoperability. And I agree that it would be bad to have different rules
depending on how the phase 1 SA is authenticated.

Am I not correct in assuming that the phase 1 SA lifetime limit is also the
same limit on how long you can verify the authorization of use by the peer?
This is really the crux of the matter, combined with the fact that the
existence of a phase 1 SA allows easy clean up when/if the peer'd
authorization does become removed (because authentication fails).

Let me ask you this: What is wrong with the requirement that a phase 1 SA
always exist? Is there a security risk if it does? Is it significantly more
difficult to implement?

> 
>   Dan.
> 
> 
> 

Tim

Unrecognized Data: application/ms-tnef