[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: key management
On Dec 14, 15:53, Charlie Watt wrote:
% It is not trivial to spoof MaxSix because you cannot connect your
% untrusted system to the network. You would either be shot, or it
would
% be fronted by a crypto box.
The above statement is not true for any environment that I am
aware of that MAXSIX is actually used. I am aware of a number of
actual environments where MAXSIX is in use. People might claim the
above to be true but I know of zero cases where it is actually true.
As such it represents an unreasonable design assumption. Further, no
DoD document on security architecture says anything about "unable to
connect an untrusted system to the network" while many talk about
"keeping uncleared people outside of (some) room". Charlie's
statement and the actual statements in DoD documents are significantly
different in their implications for MAXSIX.
> This above is provably false by an existance proof of a
> BSD-based implementation of IP oriented encryption that does support
> per user keying. Note that user does not equate to any particular
> human in every case, consider the various non-human login ids as one
> example.
% As Ran suggests, you can easily have per-user keying such that the
% "user" you identify has no correlation with the actual user causing
transfer
% of the data. This doesn't sound very useful to me.
Charlie knows full well that is not what I suggested.
I suggested that per user keying is straight-forward because
the OS already provides human-computer I&A using OS-specific
mechanisms, each process has an associated userid, and the stack knows
that userid and so can pick the appropiate key associated with that
userid. My approach is implementable and works. Human-Computer I&A
is outside the scope of this WG's effort.
> Transport-layer encryption (e.g. keyed on a per socket +
> destination-addr basis) is a useful tool in many circumstances because
> it permits strong security services to be provided without having to
> modify any application-layer protocol and without being forced to
> modify every application binary.
% I agree. But remember, an application layer protocol is not
necessarily
% something that is run in the Unix "user space". It is (aside from
being
% poorly defined for the Internet stack) a communications protocol that
% sits above the transport layer. Thus what I suggested, an application
layer
% protocol implemented within the protocol stack as extensions to the
% socket/ TLI/XTI programming interface provides the same benefits.
We have a difference in definitions here, though perhaps not a
difference of substance. I do not believe that anything below the
network API is "application-layer". Charlie does appear to believe
that one can have "application-layer" things below the network API.
The difference in definitions is not especially important, IMHO, other
than to keep straight what each person is actually proposing.
What is important is that we appear to agree that the security
mechanism needs to be below the network API if one needs to have
security provided to application programs without modifying each
application program or apFrom ipsec-request@ans.net Wed Dec 14 21:26:26 1994
Received: from interlock.ans.net by nis.ans.net with SMTP id AA24695
(5.65c/IDA-1.4.4 for <archive-ipsec@nis.ans.net>); Wed, 14 Dec 1994 16:54:37 -0500
Received: by interlock.ans.net id AA08791
(InterLock SMTP Gateway 1.1 for ipsec-out@ans.net);
Wed, 14 Dec 1994 16:51:25 -0500
Received: by interlock.ans.net (Internal Mail Agent-2);
Wed, 14 Dec 1994 16:51:25 -0500
Received: by interlock.ans.net (Internal Mail Agent-1);
Wed, 14 Dec 1994 16:51:25 -0500
Date: Wed, 14 Dec 1994 16:26:26 -0500
From: rubin@faline.bellcore.com (Avi Rubin)
Message-Id: <199412142126.QAA08100@faline.bellcore.com>
To: Ashar.Aziz@eng.sun.com, amir@watson.ibm.com
Subject: Re: Proposal: Perfect forward secrecy a MUST
Cc: ipsec@ans.net, yacov@faline.bellcore.com
Has anyone proposed any protocols for "perfect forward
secrecy"? Is this concept any different than protocols
that are resistant to known-key attacks? Are we worried
about the compromise of both master keys of communicating
parties, or a bunch of session keys being compromised not
leading to compromise of all the others?
Everyone is throwing the term "perfect forward secrecy"
around, but it seems that there is another term already
in the literature for what is being described, and I haven't
seen a formal definition of the requirement that is being
debated. In addition, before the computational feasability
is decided, it would be nice to know exactly what protocols
we are dealing with. Is there a particular protocol that is
under consideration that meets all the requirements, or is
everyone arguing about the concept in general?
Avi
plication protocol separately. Such
application-layer (my definition of application layer here :-)
modifications seem needless in many cases and always increase the cost
of deploying and using security.
> Transport-layer encryption can do this as can network-layer
encryption.
> Application-layer encryption cannot NOT do this because adding
encryption
> at the application-layer cannot be made transparent. Adding it below
> the network API is a requirement if one seeks transparency and below
> that network API it is no longer application-layer.
% Of course I can. We're shipping products that do precisely this. I
% can link a module into most Unix-based stacks that provide strong user
% authentication, integrity and confidentiality transparently to all
% applications. Don't confuse an application with an application layer
% communications protocol.
Again, this appears to be a matter of Charlie having a
different defintion of "application-layer" than I do. I would
characterise his implementation of security below the API as being
below the "application-layer". It appears that he and I are in
violent agreement on most of this but differ in our definitions of
"application layer".
> Agree that session key establishment is necessary but insufficient.
> However it is a reasonable problem to start attacking now.
>
> Authorisation is already widely available in C2-like operating
> systems, so the second claim is relevant only to DOS and MacOS (and
> similar OS) users and not germane here.
% But they do not provide distributed authorizations, without which you
% will wind up with an administrative nightmare in a large-scale
installation.
% This is a problem that needs to be considered.
Distributed authorisation is outside the scope of the IPsec WG
and might even be outside the scope of the IETF (to the extent it is
an OS issue, it is clearly outside the scope of the IETF). Some folks
use Kerberos for this. Others use a combination of techniques, often
including Sun's NIS/YP technology.
While the problem might be interesting, it belongs in fora
other than this mailing list, which is ostensibly focused on packet
encryption and key mangagement techniques being developed by the IETF
for the Internet.
% Is there harm in giving thought to an architecture that meets all of
% our requirements for distributed computing? Or should we just hope
that
% all these little pieces fall magically into place?
There is harm in redefining the problems addressed by this
mailing list from a narrow one that is within the scope of this IETF
working group to one that is beyond the scope of the entire IETF.
Such redefinition and the resulting diffusion of the discussion tend
to significantly impede progress on the narrow technical problems that
really ARE within our scope. The WG is already late in developing our
specifications and we need to stay focused on things within our
charter. There exist other places that the broader issue can be
discussed or such places could be created easily (e.g. a new mailing
list). The issue is not whether ANY discussion is legitimate but
rather WHERE different discussions should live (i.e. its a sorting
problem).
Ran
atkinson@itd.nrl.navy.mil
References: