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

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


In message <9412150938.ZM2919@sundance.itd.nrl.navy.mil>  you wrote:
> 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.
> 

One has to ask, how is Alice creating this dictionary, she has no "special
privileges" so how is she gathering the ciphertext to match her chosen
plaintext? (another machine on the net, okay) How is she distinguishing
between her encrypted IP datagrams and Bob's? Is it the SAID, if so why give
an attacker this hint, if you only do host based ID's all IPSPgrams look the
same. If we are talking about a vanilla system (i.e., SunOS 4.x) there are
much easier hacks to get access to Bob's stuff than resorting to
cryptanalytic attacks.

This also raises some questions about cryptographic security. If we assume
that the users don't get access to the actual key, Alice is attempting to
perform a chosen plaintext attack through which the key is recovered. What
algorithms are in use, CBC DES is not vulnerable (we are lead to believe)
to such an attack so use of CBC DES (or CBC IDEA for that matter) reduces
Alice's problem to one of cracking DES, which if she can do it doesn't matter
if she uses chosen plaintext or not and the per-userid keying doesn't help.
But per userid keying does allow her to perform some level of traffic
analysis on Bob's traffic with someone on host Y.

At the IETF Phil Karn expressed the opinion that traffic analysis
should be a concern. If we use IPSP to provide per-userid keying (which must
be in cleartext and available to the receiving IPSP) user profiles can be
developed simply by watching the SAIDs. If per-host key is used, all one gets
is the aggregate between hosts (which may still present a problem for the
truly paranoid).


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

I agree completely with this statement. 

With per-user(id) keying you are attempting to provide a high-assurance
(cryptographic) separation between user when their data is on the network but
are more than willing (you have no choice) to live with low-assurance when
the data is in the computer.  Dave's point earlier was just this, protect the
information between hosts as best you can, but let the host worry about
separating users (it is the only thing that can) if you want good assurance,
buy a high assurance O/S.


carl.
References: