[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 McDonald [mailto:danmcd@eng.sun.com]
> Sent: June 17, 1999 4:33 PM
> To: tjenkins@TimeStep.com
> Cc: pkoning@xedia.com; vvolpe@altiga.com; ipsec@lists.tislabs.com
> Subject: Re: Dangling phase 2 SAs (was RE: issues from the bakeoff)
>
>
> > > This doesn't work if executing the last step deletes the
> phase 2 SA
> > > just negotiated...
> >
> > Yes, I know. That's why I asked, and Dan Harkins echoed the
> quesion, why can
> > the phase 1 not be allowed to live on to manage the phase 2
> SA that it just
> > created?
>
> Apart from derivation strengths, do Phase 2 SAs (e.g. the
> IPsec SAs) need to
> be that strongly tied to the Phase 1 SAs?
>
> I might be missing something here, but apart from the Phase 1
> identities
> (critical for per-user keying), and lifetimes, both of which
> can be inherited
> attributes maintained seperately, what else from phase 1 gets
> associated with
> a Phase 2 SA?
>
> Dan McD.
>
I think maybe my explanation of why I want phase 1 SAs always up is weak
since I'm not explicitly saying "authorization". There is implicit
authorization in the ability to authenticate an endpoint, and that only
happens with phase 1.
Part of my concern arises from the independence of phase 1 and phase 2
lifetimes: there is no requirement that phase 2 lifetime be shorter than
phase 1. And even if they were, with phase 2 re-keying it is possible that a
phase 2 SA could live beyond the time that an entity could know the
authorization of the peer.
Yes, there are other ways that could solve this rather than dis-allowing
dangling SAs. However, by doing that, we increase the chances for
interoperability, it reduces the window of uncertainty and allows for better
clean up.