[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: key management
On Dec 14, 12:59, Charlie Watt wrote:
% Unfortunately this is incorrect. MaxSix -- the multilevel-secure
% network implementation commonly implemented on Compartmented Mode
% Workstations and other MLS systems -- is an example of a network layer
% security protocol.
The above is greatly misleading.
Neither MAXSIX nor DNSIX specify "network layer security
protocols". Both specify ways to transfer labeled information
(without authentication) between two hosts implementation the same
labelling protocol set. No security is provided by either protocol.
Labels are provided. Host operating systems use those untrustworthy
labels to make Mandatory Access Control decisions.
% The single biggest mistake made in the original version of MaxSix was
% the passing of process-related security attributes (identity
information,
% labels, etc...) at the network layer protocol.
No.
Actually the biggest single mistake continues to be the
omission of any reasonable authentication that the label received and
the label sent are in fact the same or any authentication binding the
data and the label together. It is trivial to spoof either DNSIX or
MAXSIX precisely because neither has authentication.
% The end result is that if you support per-user keys at the IP level,
you
% will need substantial rewrites of:
%
% - at least some transport layer protocols,
% - your file system,
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.
% This can be done. We've been shipping this for 4 1/2 years. But the
% porting and maintenance costs are prohibitive.
They'd probably be A LOT less expensive to maintain if MAXSIX
were less of a random hack than it actually is (CIPSO being a stellar
example of a bad specification included as part of MAXSIX). I believe
that the DNSIX/MAXSIX code is expensive to port and maintain, but
SecureWare seems to do a nicely profitable business doing just that.
Expense of DNSIX/MAXSIX code does not correlate to encryption code
costs, so the statement is largely irrelevant to the current discussion.
% Effective distributed security requires the application of
cryptographic
% security services at two layers of the protocol stack (a big
assumption,
% I know):
I would agree with "more than one layer" but can't agree with "two
layers". For example, email probably does need built-in security
(e.g. PEM) but other applications do not need that and are instead
better served by transport-layer and/or network-layer encryption.
Link/subnet encryption is always needed to protect against traffic
analysis.
% - the application layer in order to support distributed
% applications. But this application layer security protocol
should be
% independent of and transparent to any true application layer
protocol
% such as ftp or telnet.
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.
% - the Network Data Security Enhancement Protocol (NDSEP)
% (currently a variant of SP3, sorry), which uses the negotiated
% per-association key to apply message authentication, data
integrity,
% confidentiality, etc..., as required.
Aside: In retrospect a solid case can be made that this WG should have
simply used SP3D for its packet format and as the basis for further
development. At the time it was not so clear.
% 1) a network layer security protocol cannot provide the universal
% bandaid to fix all security problems.
Agree. There is no magic bullet of any flavour.
% 2) in addition to network layer security, we need support for secure
% distributed applications.
Disagree. Adding security to each application is too costly both in
initial implementation and in operations & maintenance costs.
% 3) it would be a big win if applications could be secured transparently
% and without modification.
Yes.
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.
% 4) the two security layers should be coordinated to minimize both the
% development and processing burdens.
Actually, keeping the layers separate can be a BIG HUGE win in some
systems. The above is not true as a general rule but is sometimes
true.
% 5) for supporting applications within the distributed environment a
"key
% management protocol" by itself is insufficient, for authentication
% without authorization is useless.
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.
% 6) key management, particularly when used for identifying and
% authenticating users, has system implications far beyond network layer
% security.
Disagree. It might have wide spread system implications but it might
well not have such wide spread system implications.
Ran
atkinson@itd.nrl.navy.mil
Follow-Ups:
References: