[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: key management




solo@BBN.COM says:
> In a multi-user environment, providing different identities at the
> IP level is incompatible with both typical host assurance and with
> the protocol architecture.  Note, by the way, that solving this
> on the receive end is much more complicated than on the sending end
> of a datagram.
> 
> In order meaningfully provide user granularity of separation, a
> host has to authenticate the user, pass that information down to the
> IP/IPSEC level, and preserve the integrity of the path.  This suggest
> non-standard application and transport implementations.

You make all this sound difficult. None of it involves any great
difficulty.

Imagine using Kerberos (as a strawman) for key management, and an
interface that allows you to set SAIDs to be used on a per-socket
basis. The kernel must enforce a mechanism to only allow you to set a
SAID that you "own" on a socket.

At this point, the problem becomes trivial. Implementation-wise
(pardon the BSD orientation), you just support some sort of SAID
structure in your kernel that includes a user id (for authorization
checking) and have the TCB or the equivalent for the transport in
question have a pointer to an SAID if security is on. The transport
interface to the network layer code passes along the SAID to use --
the network layer need not understand anything about which user is
which, only about SAIDs. On the receive side, the network layer passes
the SAID up with the (decrypted) packet so that the transport can
compare the SAID against the one it is supposed to be using for the
socket in question.

Per user key management stuff is handled by having the kerberos system
stash shared service keys in new SAIDs in the kernel owned by the
given user.

As you can see, this is hardly difficult. It requires some tiny
modifications to the transport code, a couple of small kernel
interfaces, and a key management system that understands user level
credentials.

Perry


Follow-Ups: References: