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

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



Tim Jenkins wrote:
[snip]
> Okay, phase 1 lifetime gets negotiated to 4 hours by a dial-in client. Phase
> 2 lifetimes are set to expire at 5 Mbyte traffic. At 3 hours and 50 minutes
> into the phase 1 lifetime, the phase 2 SAs are re-keyed. At 4 hours, the
> phase 1 SA is deleted. Seems fine so far. A little later the certificate of
> the dial in client gets revoked. So now we have phase 2 SAs up that may be
> used by the person whose certificate has been revoked, and they've got 5
> Mbyte of data they can move before the system will redo phase 1. If the
> presence of phase 1 SAs was required, this would have been detected within 4
> hours (at the next phase 1 re-key time: the phase 1 re-key would fail) and
> the system would know to tear down all SAs.
> 
> Otherwise, you need some other mechanism to know that the phase 2 need to be
> torn down before they would otherwise normally expire. And in this case,
> you'd have to do it unilaterally: no polite delete or anything; they would
> just get removed, and the dial-in client may be hitting you with packets
> with invalid SPIs.
> 
> By overlapping phase 1 SAs, if the re-key fails, the existing SA can be used
> to send deletes for the phase 2 SA and itself, cleaning up the far
> implementation.
> 
> It's far cleaner, and it's really not that complicated.
> 
> Does this help?
> 

Tim,

While I'm attracted to the idea of binding phase 2 SA lifetimes to 
the phase 1 SA lifetimes, I'm not sure that certificate revocation
is a good example of an attack here.  Revocation mechanisms such as
CRLs always have windows where theoretical attacks can occur.

Assume, for instance, that your CRLs are issued weekly.  Then it is
possible that you will be creating SAs for an entire week before you
discover the (potential) security breech.  And it's worse if there
is some period of time before the user notices their key has been
compromised, and even worse if you don't obtain the CRL as soon as
it is issued by your CA.  In this case, the phase 2 SA lifetime starts
looking like a rounding error.

I believe in revocation, but I recognize it is not perfect.  And
no amount of fiddling with SA lifetimes will change that.

If you're really worried about this, you might think about using short
SA lifetimes.  And definitely think about something like OCSP, because
CRLs are not going to give you what you want.

brian
briank@cs.stanford.edu      (play)
briank@network-alchemy.com  (work)


References: