[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,
 ACFPlIcfsOoFrXilcL+Im06r4mEB6gd7s/BgfdFZbN+6m5Fk55WhPvFqZ84ARZx5
 tRWYJuk8C7BA/M54LohZ5+Q=

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

> Perry Metzger:
>
> Charlie Watt says:
> > 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 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.
> 
> There was no suggestion here that network layer information pass
> process related security information. There was only a suggestion that
> transports should be able to specify that a particular SAID should be
> used for a particular packet -- i.e. that it should be possible to
> specify a SAID be used for a particular socket. There was no stated
> requirement that a particular application need use this capacity.
> 

That's fine.

Forgive the misunderstanding, I misread your requirement:

> 1) They lack a specified method for managing separate keys for
>    separate users; this is an articulated requirement for the IPv6
>    case according to the IPng Directorate.

and the following justification for it:

> ... I can build applications like a secure telnet or a secure NFS service,
> which I cannot do with ANY of the thus far articulated key management
> systems. I would argue that any system that is not more functional
> than Kerberos (in the sense of providing all that kerberos does but
> with public keys and scalability) is not sufficient for our
> purposes. The key management system need not itself provide all the
> Kerberos functionality, but it must have clearly obvious hooks for
> handling naming and user level keying.

- ----------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

to mean that you wished to select keys based upon user identity, and to
use that ability to provide application layer I&A.  If that is an incorrect
interpretation of what you mean, please explain it again, for you lost 
something in the explanation.

The rest of my prior message went on to agree with you:  yes we need these
capabilities, but with the following provisos:

	- application layer support needs to be kept out of a network layer 
	  security protocol.

	- the two need to be coordinated or we will wind up with a big mess.

Charles Watt
SecureWare, Inc.

-----END PRIVACY-ENHANCED MESSAGE-----
Follow-Ups: References: