[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Phase 1 Re-keying Implementation Identification
I don't think this is really a security issue. If the certificate expires,
it doesn't stop the user from being who they were when they negotiated the
phase 2s (there's no retroactive MitM attack). The SAs will go away by
themselves if the deletes are not sent (and we can't currently guarantee
that they get there anyway). Although, the deletes are nice from a recovery
perspective (and they are user-friendly).
This is more of an issue from a speed/latency vs. memory usage perspective.
Some of us would like to have the advantage of being able to send Isakmp
packets at any time during the phase 2 lifetime without having to negotiate
a new phase 1 (especially if this requires user intervention). And ifo ur
products are memory hogs because of this strategy then so be it.
There are many reasons for wanting a continuous channel besides for sending
deletes: premature phase 2 rekeys (e.g. due to kb lifetime expiry),
negotiating different phase 2 SAs with the same endpoints (for whatever
conceivable reason), heartbeat/keep-alive protocols, legacy authentication
protocols (e.g. periodic reauthentication), configuration protocols (e.g.
private address renewal), the ability to carry information across a phase 1
rekey, lifetime notifies or other informational messages, other protocols
that we haven't even imagined yet.
If you don't want to support continuous channel mode, you don't have to.
However, we find it useful.
Andrew
_______________________________________________
Beauty without truth is insubstantial.
Truth without beauty is unbearable.
Follow-Ups: