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

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





If the certificate which is used for authenticating the Phase1 SA which
authenticates phase 2 SA,
then you can delete phase 1 and phase 2 SAs. It is not depending on phase 1 SA
exists or not.
I might be missing something here, but for me it looks like an implementation
issue.





"Waters, Stephen" <Stephen.Waters@cabletron.com> on 06/17/99 05:36:30 PM

Sent by:  "Waters, Stephen" <Stephen.Waters@cabletron.com>


To:   Tim Jenkins <tjenkins@TimeStep.com>
cc:   ipsec@lists.tislabs.com (Boby Joseph/MW/US/3Com)
Subject:  RE: Dangling phase 2 SAs (was RE: issues from the bakeoff)





An interesting point that. Since the lifetime on Phase1 takes notice of the
lifetime of the certificate used, the intention is that the certificate user
should not be allowed to connect once the certificate has expired. It does
not seem sensible to allow Phase-2 SA to live past the lifetime of the
certificate either.

If the Phase-1 SA used the 'life-left' value of the certificate when it was
established, should we restrict the Phase-2 SAs negotiated to live no longer
than the parent Phase-1?

Steve.

-----Original Message-----
From: Tim Jenkins [mailto:tjenkins@TimeStep.com]
Sent: Thursday, June 17, 1999 9:06 PM
To: Dan Harkins
Cc: Volpe, Victor;
Subject: 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 3:35 PM
> To: Tim Jenkins
> Cc: Volpe, Victor; ipsec@lists.tislabs.com
> Subject: Re: Dangling phase 2 SAs (was RE: issues from the bakeoff)
>
>
>   "bounds the authenticated lifetime"? Does the
> "authenticatedness" somehow
> get diluted as time goes on? I guess I hadn't realized that.

The RFCs state that the lifetime of a phase 1 SA must be limited, in
addition to local policy requirements when using certificates, to the
lifetime of the certificates involved and the CRL used to verify the
certificates.

This quite clearly is intended to make sure that the phase 1 SA lifetime is
limited to the time that the endpoints can be authenticated. That what I
mean by "bounds the authenticated lifetime".

Once the original phase 1 and phase 2 SAs are created, the fact that they
have different lifetimes means they almost live independently so the phase 1
SA existence is necessary to authenticate the endpoints on a continuous
basis.


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


>
>   What I think is unnecessary is the level of complexity involved in
> doing what's described in draft-jenkins-ipsec-rekeying-01.txt.

Um, you've said that before about the phase 2 re-keying proposal and you've
never said why or pointed out any errors in the logic that lead to that
proposal.

However, this thread is about phase 1 re-keying, and the document simply
proposes that you allow multiple phase 1 SAs to exist and that you always
use the oldest one first until it really does expire.

Is that really that complicated?

(As a side note, if phase 2 re-keying had been done that way in the first
place the complex proposal in draft-jenkins-ipsec-rekeying-01.txt wouldn't
have been necessary.)

Tim

>
>   Dan.
>
> On Thu, 17 Jun 1999 14:34:09 EDT you wrote
> > Phase 1 re-keying is discussed in some detail in
> > <draft-jenkins-ipsec-rekeying-01.txt>.
> >
> > Also, the act of orphaning phase 2 SAs (as described below)
> in my mind is
> > both unnecessary and also insecure, since the phase 1 SA is
> what bounds the
> > authenticated lifetime of the end points. So to leave a
> phase 2 SA up
> > without a valid phase 1 SA is to let it live beyond its
> allowed limits.
> >
> >
> >
> > ---
> > Tim Jenkins                       TimeStep Corporation
> > tjenkins@timestep.com          http://www.timestep.com
> > (613) 599-3610 x4304               Fax: (613) 599-3617
>