[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: Paul Koning [mailto:pkoning@xedia.com]
> Sent: June 17, 1999 3:46 PM
> To: tjenkins@TimeStep.com
> Cc: vvolpe@altiga.com; ipsec@lists.tislabs.com
> Subject: Re: Dangling phase 2 SAs (was RE: issues from the bakeoff)
>
>
> >>>>> "Tim" == Tim Jenkins <tjenkins@TimeStep.com> writes:
>
> Tim> Phase 1 re-keying is discussed in some detail in
> Tim> <draft-jenkins-ipsec-rekeying-01.txt>.
>
> A very welcome document indeed.
Thank you.
>
> (It should get easier with the proposed addition of acknowledged
> delete.)
Yes. That's basically the same as the delete mode I described, which I stole
from PPP which stole from ...
>
> Tim> Also, the act of orphaning phase 2 SAs (as described below) in
> Tim> my mind is both unnecessary and also insecure, since the phase 1
> Tim> SA is what bounds the authenticated lifetime of the end
> Tim> points. So to leave a phase 2 SA up without a valid phase 1 SA
> Tim> is to let it live beyond its allowed limits.
>
> I'm utterly puzzled by this comment. As far as I've seen,
> there isn't
> a tie-in between the lifespan of phase 1 and phase 2 SAs. I
> thought I
> had seen explicit statements to that effect.
There isn't. That's part of the issue, since there is authentication of the
endpoints, and therefore the phase 2 SAs once they are created.
>
> In particular, I don't understand the assertion that allowing phase 2
> SAs to live past the deletion of the Phase 1 SA is in any way a
> security issue. What does "bounds the authenticated lifetime of the
> end points" mean? Could you describe an attack on a system that is
> made possible by letting the phase 2 SAs live beyond the
> deletion of a
> phase 1 SA?
I tried to explain this in my response to Dan; he had a similar question. If
it's still not clear, please let me know.
>
> Note in particular that the IKE spec says:
>
> To provide Perfect Forward Secrecy of both keys and all identities,
> two parties would perform the following:
>
> o A Main Mode Exchange to protect the identities of the ISAKMP
> peers.
> This establishes an ISAKMP SA.
> o A Quick Mode Exchange to negotiate other security protocol
> protection.
> This establishes a SA on each end for this protocol.
> o Delete the ISAKMP SA and its associated state.
>
> 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?
As far as I know, we got no response.
>
> paul
>
Follow-Ups: