[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 6:06 PM
> To: Tim Jenkins
> Cc: Paul Koning; ipsec@lists.tislabs.com
> Subject: Re: Dangling phase 2 SAs (was RE: issues from the bakeoff) 
> 
> 
> On Thu, 17 Jun 1999 16:47:56 EDT you wrote
> > 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.
> 
> What if his certificate gets revoked 2 hours into the phase 1 
> lifetime?
> How do you know? Do you constantly recheck CRLs? How often? What if it
> expires in between checks? I don't see how your concern is 
> addressed by
> deleting the IPSec SAs when the IKE SA expires.

The concern is shortening the window of checking. If we assume that the only
checking of certificates is done is when phase 1 is negotiated, then if
dangling SAs are allowed, the next check of the certificate will not occur
until a new phase 1 is generated, which could be as late as just before the
phase 2 SA is going expire.

What I proposed in <draft-jenkins-ipsec-rekeying-01.txt> (NOT in -00.txt, I
changed this after comments from the WG), is that phase 1 SAs be re-keyed
before they expire. Therefore, the certificate is checked before the end of
the phase 1 lifetime. If it fails, the new phase 1 SA never comes up. At
this point an implementation could choose to tear down the old phase 1 SA
and the phase 2 SAs, or just leave them until the old phase 1 SA expires
naturally, and then tear down all SAs.

There are no requirements in the RFCs for interim checks of certificates
that I know of; it seems to me that the RFC requirements of limiting phase 1
SA lifetimes based on CRL next-issue-date and certificate lifetimes (in
addition to local policy) is an attempt to address that.

However, as I said elsewhere, interim checking by implementations may be a
customer requirement anyway.

> 
> And if this is your concern why not limit this 2nd 
> negotiation to 10 min
> then and guarantee that the client will not think his IPSec SAs are
> valid for longer than what you think they are. That would 
> prompt him to...

I don't understand what you're saying here. Just because one end limits his
lifetime to 10 min. doesn't mean the peer will use that lifetime.

> ...renegotiate a phase 1 exchange for you without the obligatory blackout
> period that happens when you delete the IPSec SAs which he thinks are
> still valid. Since your overriding concern is a seconds-based 
> lifetime 
> anyway why do you negotiate a volume based SA which has a hidden, 
> unknown-to-client, life? You're defining some space in which 
> you want to 
> act in (the limit is seconds-based) and then intentionally 
> doing something 
> which is outside that space (negotiating a completely 
> different lifetime
> which could extend beyond the limit). Surprise! It has 
> problems, at least 
> problems as you define them. 

With the current RFCs, there is no binding of phase 2 lifetimes to phase 1
lifetimes. Agreed? Then, there are possible combinations of lifetimes and
traffic used where phase 2 SA's lives will go past phase 1 SA's lives,
right?

What I'm proposing is that when this happens, a phase 1 SA MUST be re-keyed
such that there is always a valid phase 1 SA underneath. In other words,
implementations must support overlapping phase 1 SAs. Is that currently
prohibited? I don't see how it can be, since you don't know you've got
overlapping phase 1 SAs until they're (almost) completely negotiated anyway
(yes, it does depend on the mode).

My overriding concern is not seconds based lifetime. I was asked to provide
a specific example and I did. The point is that with dangling phase 2 SAs
the endpoint identities (and thus indirectly the authorization) is not
checked as soon as it could be.

> 
> Your concern is allowing someone to have an IPSec SA when the 
> certificate
> that was used to (indirectly) authenticate it has been 
> revoked. Deleting
> IPSec SAs when the IKE SA used to generate them expires is 
> not the answer
> (and actually causes other problems). Operating in the bounds 
> you place 
> around yourself-- i.e. don't renegotiate an IPSec SA which could live 
> longer that the underlying IKE SA-- will.

If I understand what you're recommending here, how do you provide a
continuous "tunnel" of SAs even through phase 1 expirations?

Are you suggesting allowing multiple phase 1 SA with their own set of phase
2 SAs that live only within the phase 1 SA, but set up such that the phase 1
SAs overlap and the phase 2 SAs from the different phase 1 SAs have the same
selectors????

That sounds more complicated than what I propose in the re-keying
document...

> longer that the underlying IKE SA-- will. Not everybody shares your>
concern though and the beauty of operating within your self-imposed
> boundaries is that they don't need to.
> 
>   Dan.
> 

The only compatibility issue that I can think between allowing dangling
phase 2 SAs and doing phase 1 re-keying the way I proposed in my draft is
the case where the end that allows dangling SAs to exist has a shorter phase
1 SA lifetime.

In this case, that end will send a delete for the phase 1 SA only
(hopefully, anyway). The other end will see this and delete all its SAs. It
should be self correcting in any case.

However, if the end that doesn't allow dangling phase 2 SAs has the shorter
phase 1 SAs lifetime, it will generate a second phase 1 SA before the first
expires. If this comes up, it really doesn't matter if the other end
immediately sends a delete for the old phase 1 SA; the initiating end will
leave its phase 2 SAs up since the new phase 1 SA is up and valid.

Finally, I'll say it again: with dangling phase 2 SAs, if the eventual phase
1 negotiation later fails, there is no authenticated way to delete the phase
2 SAs cleanly, so the now unauthorized peer may end up with orphaned SAs
without having any idea why.

Finally, I'm not sure I addressed all your (Dan's) comments because, quite
honestly, I didn't understand them; I get the feeling you think I'm
proposing the all SAs must be torn down when a phase 1 expires
unconditionally. That's not what I'm proposing.

Tim



Follow-Ups: