[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: key management
"Housley, Russ" says:
> Perry:
>
> I have a real problem with your list of requirements, especially number 1.
> Your list is:
>
> 1) They lack a specified method for managing separate keys for
> separate users; this is an articulated requirement for the
> IPv6 case according to the IPng Directorate.
>
> Number 1 requires the IPSP implementation to be tightly integrated with the
> transport layer implementation.
No, it doesn't, although it does require that the transport layer have
the ability to tell the network layer which SAID to use.
> I hope that we are desigining a solution
> that will work with ANY transport layer protocol, including TCP, UDP, TP4,
> and even TP0/RFC1006/TCP.
I see no reason why requirement 1 can't be met and permit the use of
any transport. I already have a design that does this.
> I strongly recommend that we leave authentication of users to the
> application that already has a model for representing them.
There are very good reasons that the IPng directorate made the
decision they did. I wouldn't discard the recommendation without
extremely serious thought.
1) The application CANNOT be trusted to represent users. Neither, for
that matter, can a host -- see the documents on Kerberos for why this
is the case. Although a user must trust a host for brief periods, it
seems like a very bad idea to trust a random host sitting in an public
area to be telling the truth when it claims a particular identity is
using an application on the host. Kerberos-like systems have the
advantage that they require that a user demonstrate his identity by
showing that the host is in temporary posession of information known
only to the user. Such information is necessarily cryptographic. Given
this, why not go all the way and use just one system for cryptographic
key negotiation? Why use more than one?
2) Mutually distrustful users on a single host CANNOT be trusted to
know each others keys. Systems that use host keying conflate
different users cryptographic keys, making all sorts of unfortunate
attacks possible. Preventing seperate users from using each others
keys is necessary.
There are other reasons, too...
Perry
Follow-Ups:
References: