[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: key management
Satisfying user granularity identification, authentication, and access
control at the IP layer seems to be one of those issues where desired
capabilities and feasibility clash. It is very reasonable to imagine,
for single user hosts, assigning an authenticated host identity of
the flavor "David Solo's workstation" Because I am the only user,
a peer host or application can reasonably conclude that it is me and
make a corresponding authorization decision. Another user who
uses the same machine might instantiate a different host identity but
still operates in a single user configuration.
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.
On the receive side, the problem is worse. An IP datagram arrives
with an SAID. At the time IP/IPSEC per datagram processing takes place,
including a reliable access control decision, there is no way to control
the subsequent processing of the information, let alone communicating
that data through the transport layer and to a subsequent application.
At a minimum, this requires some change to the transport processing and
application.
While an IP level user authentication architecture might be feasible
in a high assurance operating system intended to provide reliable
separation, it is far less realistic in common, lower assurance
configurations. Further, if you are going to create special
applications to handle this processing, why not directly handle user
authentication at the application level.
I don't doubt that the IPv6 and other communities would like to see
the general user I&A problem solved at the network layer, but this
is mostly inconsistent with protocol layering and certainly
inconsistent with low assurance operating systems.
On the other hand, I do agree that IKMP, as distinct from IPSP,
should be capable of creating security associations based on
a variety of granularities. My objection is to the notion of
providing user based separation via IPSP on multi-user systems.
I would be happy to see someone describe a feasible architecture to
provide reliable user I&A, separation, and access control at both the
sending and receiving end for low assurance, multi-user hosts.
Dave
> Date: Tue, 13 Dec 94 15:12:10 EST
> From: Ran Atkinson <atkinson@sundance.itd.nrl.navy.mil>
> Subject: Re: key management
>
>
> On Dec 13, 14:12, Paul A. Karger wrote:
> } Subject: Re: key management
>
> % Mutually suspicious users can only share the same host if you
> % have a trusted operating system of some kind to separate them.
>
> It isn't clear to me what you mean by "trusted operating system".
>
> If you mean an OS with Mandatory Access Controls (e.g. B1 or better
> per Orange Book), then I disagree. A C2 operating system with
> Discretionary Access Controls permits user A to configure permissions
> such that user B does not have access to user A's data and resources.
> If user A is on such a system and does not trust user B, then user A
> can configure its permissions accordingly. MAC is needed when one is
> trying to enforce some kind of multi-level security policy, not merely
> to separate mutually suspicious users.
>
> Ran
> atkinson@itd.nrl.navy.mil
>
>
>
Follow-Ups:
References: