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

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

On Dec 15,  8:56, solo@BBN.COM wrote:

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

I am glad we agree that application I&A is outside the scope of this
effort.  I disagree that per-userid-keying is not useful.

One widely used example is the problem of mutually suspicious users
(Alice, Bob) on some host X where none of those users has special
privileges (in UNIX terms, none of them are root).  In such a case
when per-userid-keying is not provided, then user Alice can create
arbitrary plaintext/ciphertext pairs between its host and another host
Y in order to assist in Alice's cryptanalysis to determine what data
Bob is sending to someone on host Y that Bob does not want Alice to
know about.

Using a separate key per userid will entirely preclude that attack
strategy.  The IPv6 specs say that an _implementation_ must support
per-userid-keying but also specifically says that an implementation
MAY support host-to-host keying as well.  This means that the system
administrator is capable of using per-userid-keying or use
host-to-host keying and can make that choice as a local policy matter.

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

Customers who desire high assurance that some mechanism works will
probably purchase high assurance implementations of that mechanism.
Many customers desire some mechanism but are not very concerned about
the assurance level of the implementation of that mechanism.  More
generally, assurance arguments are outside the legitimate scope of
this WG because the IETF only specifies mechanisms, not assurance of
quality

I consider every version of UNIX I've used or closely examined to be
low-assurance.  The prototyping work we're currently engaged in here
is similarly low-assurance since the original code was low-assurance
That does not make per-userid-keying useless even for the low
assurance implementations.  Contrariwise it means that the separation
between users that is provided by the network has similar assurance
characteristics to the separation between users provided by the
operating system.  It is not economically sensible to have
significantly different assurance for the network separation than for
the computer separation because a chain is only as strong as its
weakest link.

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

I do not have such a model.

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

I am not suggesting per-userid-keying primarily for use in
application-layer I&A and I am not suggesting any particular approach
to application-layer I&A.  I believe application-layer I&A to be
completely outside the scope of this WG's effort.

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