[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 TimeStep Corporation
tjenkins@timestep.com http://www.timestep.com
(613) 599-3610 x4304 Fax: (613) 599-3617
> -----Original Message-----
> From: Paul Koning [mailto:pkoning@xedia.com]
> Sent: June 17, 1999 4:28 PM
> To: tjenkins@TimeStep.com
> Cc: ipsec@lists.tislabs.com
> Subject: RE: Dangling phase 2 SAs (was RE: issues from the bakeoff)
>
>
> >>>>> "Tim" == Tim Jenkins <tjenkins@TimeStep.com> writes:
>
> >> 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?
>
> Tim> I tried to explain this in my response to Dan; he had a similar
> Tim> question. If it's still not clear, please let me know.
>
> That's the note I was referring to. It's not clear in the least. You
> make a statement "bounds the authenticated lifetime of the end
> points", whose meaning isn't clear. And then you say that there is a
> security problem, but you don't spell out what the nature of the
> problem is.
>
> I see no security problem. At the time you run phase 2, you have a
> phase 1 SA. That has assorted security attributes which you know.
> Based on that knowledge, you accept the phase 2 exchange with all the
> attributes in it. You might modify some of what's proposed (for
> example, you might unilaterally restrict the lifetime of the phase 2
> SA based on the impending expiration of the cert that authenticated
> the phase 1 SA).
>
> So you clearly rely on the security properties of the phase 1 SA to
> establish the security properties of the phase 2 SA. But it does not
> follow that the continuing security of the phase 2 SA relies on the
> continued existence of the phase 1 SA.
>
> I think you need to exhibit a specific attack to support the
> point you
> raised.
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
>
> paul
>
Follow-Ups: