[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: key management
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-Certificate:
MIIBwDCCAWoCEQC43J7oZ50NWTRSVBShvvaXMA0GCSqGSIb3DQEBAgUAMFkxCzAJ
BgNVBAYTAlVTMRgwFgYDVQQKEw9TZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNl
Y3VyZVdhcmUgUENBMRcwFQYDVQQLEw5FbmdpbmVlcmluZyBDQTAeFw05NDA0MDUx
NzA2NDJaFw05NTA0MDUxNzA2NDJaMHAxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9T
ZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNlY3VyZVdhcmUgUENBMRcwFQYDVQQL
Ew5FbmdpbmVlcmluZyBDQTEVMBMGA1UEAxMMQ2hhcmxlcyBXYXR0MFkwCgYEVQgB
AQICAgQDSwAwSAJBDNmUqe2+nqg6iuUWzxaXegxki426RzmVNO6VHHYCV4nbo/WL
X9a7Jn/2nWqZUK/l+RXqCHU/21Ur9jFIt4GNHhcCAwEAATANBgkqhkiG9w0BAQIF
AANBAEY6kP5jHqK9B9PhZCCJ9mckYuKMufWr7l61LulXGwUTqFzjFC0MOYwXo5s+
8lqrLQ7YpTzyE74pKR1cl5TAUU4=
MIC-Info: RSA-MD5,RSA,
ClxFW3WX2f1/TALW1+EgV9XNmyoI3kH5xkZ4Nw5Xdcl+TsEwTDVixTX5J6shtI7d
PkcZoHWDTYOmq9Koo5ywgEc=
X-Sensitivity-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED
X-Information-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED
> Ran Atkinson writes:
> % 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.
Ran, in order to judge a solution, you must understand the constraints
of the problem for which it was intended. The DoD's Goal Security
Architecture for which MaxSix was designed specifies that the network media
will be physically protected. Within this constraint the passing of security
attributes between trusted hosts and the enforcement of security policies
based upon those attributes do in fact provide peer authentication, data
integrity and data confidentiality -- and do so at least as reliably as you
are going to get using comparable cryptographic services between insecure
OS's such as Windows. (I won't break your crypto, I'll come in through
the back door and borrow your keys). With the addition of a cryptographic
front end, it will even do so reliably in a more hostile environment.
All-in-all, it is a good solution for a specific problem. Is it an adequate
solution for other environments without a front end? No, of course not. But
then, a dishwasher does a pretty lousy job washing clothes. If you have
a different problem, use a different tool.
>
> % 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.
No. 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 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.
Yes, it is easy to solve the problem by correctly defining your terms.
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. But perhaps you have a
different problem :-).
>
> % - 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.
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.
> % 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.
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.
> % 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.
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.
>
> % 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.
Perhaps. But if you don't think about it up front, what if you're wrong?
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?
>
> Ran
> atkinson@itd.nrl.navy.mil
Charles Watt
SecureWare, Inc.
-----END PRIVACY-ENHANCED MESSAGE-----
References: