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

Re: Human I&A, IPsec, and their non-relationship


Ran,

> Date:    Wed, 14 Dec 94 16:20:52 EST
> From:    Ran Atkinson <atkinson@sundance.itd.nrl.navy.mil>
> Subject: Human I&A, IPsec, and their non-relationship
> ----------------------------------------------------------------------
> On Dec 13, 16:31, solo@BBN.COM wrote:
> % Subject: 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.
> 
> 	I do not believe that anyone has proposed or is currently
> advocating use of network-layer or transport-layer encryption to
> provide human--computer identification or authentication.
> 
> % In a multi-user environment, providing different identities at the
> % IP level is incompatible with both typical host assurance and with
> % the protocol architecture.
> 
> 	To my understanding of what you mean by "providing different
> identities", I disagree with the statement quoted above (details
> immediately follow).
> 
> 	One straight-forward way to implement this in UNIX on the
> sending side is for the upper layer to either (1) pick the SAID value
> based on source uid and destination IP address and pass down that SAID
> as part of the socket information to the lower layer or (2) for the
> encrypting layer to obtain source uid from socket state directly and
> destination IP address in the existing manner, use those two data
> points to call a function returning the needed key, algorithm, and
> other security data for the outgoing packet.  Other methods can be
> devised.  These 2 are just examples -- I'm not making any assertions
> about which implementation strategy would be best.
> 
> 	On the receive side, the receiver gets an encrypted/
> authenticated packet containing a plain-text SAID.  It feeds that SAID
> into a function and gets the key, algorithm and other security
> association data as the return from that function.  It then processes
> the packet using the data returned from that call and (if successful
> in decrypting/authenticating) passes the received upper layer data to
> the upper layer in the usual manner (possibly including a flag
> indicating the data was received encrypted or that authentication
> succeeded).
> 
> 	Each side maintains a logical table (implemented however one
> likes) that is indexed by SAID and the Destination Address (because
> SAIDs in IPv6 are receiver-oriented to be compatible with IP
> multicast).  That table contains all of the security association
> parameters (e.g. key, algorithm, algorithm mode, maybe a sensitivity
> level, etc).
> 
> 	Please note the absence of ALL human-computer
> Identification/Authentication in the above process description.

The problem I have with this scenario and with Perry's example is
understanding what services/advantages you are getting by
having multiple security associations between the hosts at the
IP layer.  In both cases, you are saying that you will rely on
the transport and application layers to accurately convey uid/SAID
information to be used by the IPSP layer.  If you trust those
protocol layers, why not have a single "secure pipe" (based on
host oriented keying material) between the system and rely
on the applications to perform user I&A (a conclusion I agree
with).  If you don't trust thos layers, then per-user security
associations at the IP layer aren't useful.

Typically, providing distinct security associations (either explicitly
or by carrying protected demultiplexing information) is useful only
when secure (de)multiplexing takes place immediately following the
security protocol processing - either via trusted protocol
implementations or by having multiple instantiations of the protocols
(in this case xport and above) separated by a high assurance operating
system.  Since neither of these situations applies in most cases you
are discussing, I have a hard time seeing what the goals of per-user
security associations at the IP layer are (vs. seeing how you can
implement it).  That's why I am arguing against a "requirement" for a
mechanism, rather than a service.

> 
> % Note, by the way, that solving this
> % on the receive end is much more complicated than on the sending end
> % of a datagram.
> 
> Please explain, preferably using the above process as a discussion
> point.

This comment depends on how the IPSP and km functions fit into a
series of exchanges.  If you had a model which expected the
applications to negotiate security association information (as part of
an I&A and access control process) prior to creating the IP security
association, then you could end up in a situation where you want IPSP
to perform decisions (whether to allow unprotected datagrams through,
access control for datagrams, etc.) based on the state of higher layer
protocols.  Such a situation isn't too bad on the sending side since
the sending process can communicate this information but is 
harder on the receiving end where the information IPSP has to work
with is limited.  This issue applies only in certain cases but I
haven't seen a complete proposal of how someone plans to use 
per-user keying as part of integrated solution.


Dave
References: