[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,
BtfNWd0yc+o/5ugko7e5dlvnImnzNGysIme7K/XMhUX5rexzzvN4W3ASDtSnqnAg
C+ztnbUstE9axehnZoFLTwE=
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 E. Metzger" <perry@imsi.com>
>
> > solo@BBN.COM says:
> > In a multi-user environment, providing different identities at the
> > IP level is incompatible with both typical host assurance and with
> > the protocol architecture. Note, by the way, that solving this
> > on the receive end is much more complicated than on the sending end
> > of a datagram.
> >
> > In order meaningfully provide user granularity of separation, a
> > host has to authenticate the user, pass that information down to the
> > IP/IPSEC level, and preserve the integrity of the path. This suggest
> > non-standard application and transport implementations.
>
> You make all this sound difficult. None of it involves any great
> difficulty.
...
> As you can see, this is hardly difficult. It requires some tiny
> modifications to the transport code, a couple of small kernel
> interfaces, and a key management system that understands user level
> credentials.
>
> Perry
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. This caused several subtle
problems. I'll only mention two, for they are representative of the rest:
- - NFS transfers disk blocks on its own volition in order to provide
read-ahead and write-behind. These network transfers:
a) are performed outside of any normal user context.
b) transfer data that may correctly be associated with several
concurrent users -- e.g. a remotely mounted /etc/hosts file.
c) arbitrarily reuse a small pool of network addresses on behalf of
all client processes.
- - A number of transport protocols, and convergence protocols that sit above
the transport, such as RFC 1006 over TCP, will multiplex the data from
several users over a single network "association" -- e.g., within a single
IP packet there may be data originating from several separate users.
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,
in order to maintain the state necessary to determine which user process
is associated with network data, and to segment the network layer data so that
it only pertains to a single user.
This can be done. We've been shipping this for 4 1/2 years. But the porting
and maintenance costs are prohibitive.
In my opinion there is a better solution that meets Perry's requirements --
but not within the current charter of the IPSEC WG. I describe it here
(with apologies) for lack of a better forum. SecureWare is currently working
on its "Extended Global Security Architecture" (EGSA) (blame the marketing
guys for the pretentious name). I will describe it briefly, -- not to suggest
that the WG consider any of this work, but rather:
1) out of fear that the WG will eventually move toward a standard
that I believe to be of limitted utility.
2) to provide an example of why I believe the current focus of the
group is insufficient, and why it cannot be fixed unless the IETF
develops a more clear vision of distributed computing, along with
the means to coordinate the various working groups in order to
reach that vision.
3) to provide a basis for discussion.
Effective distributed security requires the application of cryptographic
security services at two layers of the protocol stack (a big assumption, I
know):
- the network layer to provide host-to-host services. This is
perhaps most appropriate for use within gateways for creating
virtual private networks, but does have some utility within a
local network.
- 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.
The EGSA provides for both layers. In addition, it implements the
application layer security protocol twice:
a) as a true application layer library that can be linked with an
application.
b) as a module within the protocol stack that sits on top of the
transports as a "secure socket" layer. This approach works well
with multiuser operating systems where the protocol stack can be
easily extended (e.g. Unix). It allows for the provision of
security on a per-user basis transparently to the application.
We have a version of this that currently handles TCP and TP0 on
both socket and stream-based versions of Unix. It links directly
into several variants of Unix without requiring modified vendor
source. A five minute operation, ALL applications secured.
As both a) and b) are implementations of the same application layer protocol,
they interoperate. The EGSA also provides a single, common API to the
application layer security services regardless of implementation.
Within the EGSA, these two security layers (network and application) are
implemented using the same two protocols (and the same source base!):
- the Peer Authentication and Key Management Protocol (PAKMP) is
misnamed. It actually provides four distinct services:
1) peer authentication.
2) negotiation of the minimum security services to be
applied to an "association" (authentication, integrity,
confidentiality, labeling/access control).
3) negotiation of a per-association key. At the application
layer this is per-connection. At the network layer this
can be per-host pair, or per application address pair (i.e.
unique key for a specific instance of local IP address/port:
remote IP address/port.
4) exchange of credentials -- where credentials are extended
X.509 certificates signed by an "authority" granting a
set of authorizations (id, roles, command auths, clearance,
etc...) to a principal (user, host, etc...).
The results of this exchange are available to either participant
through the API. E.g., a server application can retrieve the
credentials and authenticated identity of a client in order to make
access control decisions for the resource it manages. A gateway can
retrieve the credentials of a peer in order to make a routing
decision for sensitive information.
- 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.
The minimal set of security services to be provided for an "association" are
specified by the network security officer through a database that controls
which associations are permitted, and what services, protocols and algorithms
should be applied to them. A security-aware application can use the API to
request additional services or alternate protocols/algorithms, if desired.
There a number of other pieces: user I&A is certificate-based using a
Directory Service, user key management ties into the login process for
unitary login, credentials may include configurable security policies,
etc... But this is enough to illustrate what I believe to be the most
important points if we are to evolve towards useful distributed computing:
1) a network layer security protocol cannot provide the universal bandaid
to fix all security problems. If it is overloaded, it will severely
break existing operating systems.
2) in addition to network layer security, we need support for secure
distributed applications.
3) it would be a big win if applications could be secured transparently
and without modification.
4) the two security layers should be coordinated to minimize both the
development and processing burdens.
5) for supporting applications within the distributed environment a "key
management protocol" by itself is insufficient, for authentication without
authorization is useless.
6) key management, particularly when used for identifying and authenticating
users, has system implications far beyond network layer security. These
issues must be handled through a consistent architecture for distributed
operation.
Charles Watt
SecureWare, Inc.
-----END PRIVACY-ENHANCED MESSAGE-----
Follow-Ups:
References: