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

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


All,

  I've been trying to sort out why so many folks appear to be talking
past each other recently on this list.  I think I might have partly
figured it out -- if I'm correct part of the problem is a
communication gap between several folks (including me) .  I'll make a
stab at clarifying in hopes that will help.  Please bear with me and
don't respond to this note before you've read the entire note.

  I'm excerpting from Dave Solo's email because he has written clearly
enough that I think I understand where he's coming from.  Some of the
other messages from various folks that I've read lately leave me
fairly confused as to the author's point.

Thanks in advance,

	Ran

----------------------------------------------------------------------
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.


% 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.

% 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.

Again, I do not believe that anyone is advocating use of packet
encryption to provide human-computer identification and
authentication.  The above text appears (to me) to be attempting to
argue that it is unwise to attempt to use packet encryption to provide
human-computer identification and authentication.

% 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 read the above as saying that per userid keying is a desirable feature.
If so, I agree fully.

Am I mistaken in my understanding of the quoted text ?

(new context follows)

As I (probably incompletely) understand Perry's discussion about using
Kerberos, he is suggesting using Kerberos as one (of several possible)
way to distribute keys amongst Kerberised systems implementing packet
encryption.  Where I think things got confusing is that Kerberos
currently does also provide human-computer I&A as one of its features,
though perhaps a feature not directly related to implementing packet
encryption.  Within communities already using Kerberos, it seems to me
very sensible to reuse the Needham-Schroeder key management technology
already implemented within Kerberos as a possible way to distribute
packet encryption keys and related data.

(new context follows)
The IPv6 documents do not in any place discuss human-computer I&A.
The "per user keying" discussed there can be accurately described in
very UNIX-centric terms as "per uid keying".  On systems which do not
have the concept of different users (e.g. DOS, MacOS), per-host-keying
and per-user-keying are in fact the same -- but only because that OS
limitation is a special case.

(new context follows)
As a document author, I find it fairly frustrating when people (ASIDE:
I really am speaking generally here, I'm NOT talking about any
particular individual) discuss easily available electronic documents
without having read them before talking about them.  If folks who are
uncomfortable with any part of the per-user-keying discussion or the
IPv6-specific parts of the discussion have not yet actually read the
currently online Internet Drafts, PLEASE read them before commenting
further on the public list.  The IPv6 documents are all online as
Internet Drafts at the I-D archive site near you and all have online
filenames of the form "draft-atkinson-ipng-*.txt".  Thanks.

(I'm now putting on my Asbestos coated clothes and waiting :-)

Regards,

Ran
atkinson@itd.nrl.navy.mil
Follow-Ups: