[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: keying styles
In article <9606182022.AA22378@secpwr.watson.ibm.com> Pau-Chen wrote:
>Disclaimer: This message is NOT intended to re-ignite the debate on
> per-user keying. Personally, I like to see all communication
> secured with one secure tunnel whose keys are frequently refreshed.
> But I have encountered much more than one request
> for per-user/connection keying (Which means some packets
> can be unprotected.). In any case, I think the
> cost of adding the field is small. So I suggest ISAKMP provide
> this flexibility. A responder can always refuse such a request.
DISCLAIMER: I also do not seek to re-ignite a heated debate
Unlike Pau-Chen, I don't see user-oriented and host-oriented
keying as mutually exclusive. For example, the NRL implementation
has always permitted a system admin to require that all outgoing
traffic be encrypted (e.g. using some keying strategy, with some
traffic possibly using a host-oriented key) while also having
user-oriented keying in use for sessions having such keys.
In other words, an implementation can (and NRL's always has)
permit some sessions on a system to use user-oriented keying
while other sessions on the same system share a host-oriented
key. The keying strategies need not be mutually exclusive.
By mandating that "everything must be encrypted" as a policy
in the "system security level" variable then all packets are
guaranteed to be protected even while some sessions might be
using host-oriented keying and other sessions might be using
user-oriented keying at the same time.
See the NRL implementation for a working example.
Ran
rja@cisco.com
References: