[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "user" and "network layer" security mechanisms.

-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-Certificate:
 MIIBvzCCAWkCEFmOln6ip0w49CuyWr9vDVUwDQYJKoZIhvcNAQECBQAwWTELMAkG
 A1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2Vj
 dXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMB4XDTk1MDUwODIw
 MjMzNVoXDTk3MDUwNzIwMjMzNVowcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1Nl
 Y3VyZVdhcmUgSW5jLjEXMBUGA1UECxMOU2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsT
 DkVuZ2luZWVyaW5nIENBMRUwEwYDVQQDEwxDaGFybGVzIFdhdHQwWTAKBgRVCAEB
 AgICBANLADBIAkEM2ZSp7b6eqDqK5RbPFpd6DGSLjbpHOZU07pUcdgJXiduj9Ytf
 1rsmf/adaplQr+X5FeoIdT/bVSv2MUi3gY0eFwIDAQABMA0GCSqGSIb3DQEBAgUA
 A0EApEjzeBjiSnGImJXgeY1K8HWSufpJ2DpLBF7DYqqIVAX9H7gmfOJhfeGEYVjK
 aTxjgASxqHhzkx7PkOnL4JrN+Q==
MIC-Info: RSA-MD5,RSA,
 AsSicdunBDB1fTEjL203HnnGkWbgyYoI8agZmpGNJme1A5ggVXQAlW24/YM2OhTs
 LU82juyKTXVcoAPbaCHXrE8=

>Perry E. Metzger wrote:
>> Charles Watt writes:
>> Yes IPSEC has a concept of a security association, which could 
>> conceivably be linked to individual users rather than hosts.  But in
>> order for such a mechanism to be useful for user-level authentication
>> with an IP security protocol, there must be an unambiguous way to link 
>> each IP datagram protected by the security protocol to a specific user-level 
>> security association.
>
>The SPI number in the packet is perfectly suitable for this
>purpose. The real issue is being able to negotiate the use of a
>particular SPI for a particular connection -- thats a
>Photuris/Oakley/ISAKMP/Whatever issue.

I think you are missing the point Perry.  For example, if you have six 
concurrent users of an X.400 product that makes use of an RFC 1006 
convergence module for its OSI "transport connections", you wind up with
user data from six user-level security associations multiplexed over a
single TCP connection.  Your IPSEC implementation is sitting at the
network level to secure outgoing data.  It will see a datagram with source 
address X.X.X.X:1014 (or some other dynamic port number chosen by the local 
TSAP module for ALL data to destination host's TSAP module) and a 
destination address of Y.Y.Y.Y:102 (officially assigned tsap port number).  
This same pair of addresses is the same for all six X.400 users.  So which 
of the six SPI numbers do you put in the IPSEC header???  You don't know at 
the IP level.  Worse yet, what if the data segment contains several TP0 
segments from different users?  What SPI do you use when the user level 
data belongs to multiple users?

I have been involved with this ongoing problem for five years now, and have
only found three solutions:

	1) Modify the operating system, protocol stack, and TSAP convergence
	   module to propagate user identity information to the network
	   security layer.  This was the wrong choice.  It cost too much.

	2) Use a higher layer security protocol that has access to user
	   identity.  We got it right the second time.

	3) Don't use TSAP.  This wasn't an option for the billion+ dollar
	   procurement.

>
>> 2) NFS.  Most implementations of the NFS client operate with a fixed pool 
>>    of endpoints dedicated to the service.  As a further complication, for
>>    efficiency, most implementations support read-ahead and write-behind, 
>>    implemented as a daemon process on behalf of the actual user.  Once
>>    again it is not possible at the IP layer to determine which user-level
>>    security association is responsible for a specific datagram.
>
>NFS is a protocol that isn't suited to securing things on a per-user
>basis, but the key problem is that all NFS authentication is done (for
>practical purposes) by the client, with the server trusting that a
>client that has a file handle is allowed to claim to have any user
>credential it wants. There is no way, in NFS, to do the "logical
>thing" and check cryptographic credentials on a per file basis.
>

And how do you get the file handle?  (rhetorical question)  The client
passes the user's UID and GID in an NFS_LOOKUP (in most cases) request.  
Should we just believe the offered ids?  Or should a reasonable user-level 
security protocol allow us to cryptographically verify this identity?

>Michael.Eisler wrote:
>
>> From watt@sware.com Tue Aug 20 08:07:17 1996
>> > > M.C.Nelson <netsec@panix.com> wrote:
>
>> ignoring and explaining away greatly limits the set of services that you can
>		^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>I agree, especially after thinking about how to actually implement
>support for all services, including the two you list...

...

>I am curious if anyone has implemented IPSEC with user-level security
>associations, and whether the associations are bound at the time the
>end-point is open or if they are switchable with each outgoing
>datagram. If the latter, is the I/O framework asynchronous or not?  An
>existance proof might make me less pessimistic about end-user IPSEC.

I have done something similar.  I designed SecureWare's various versions
of MaxSix software for multilevel secure networking.  The single most costly
mistake I have ever made was to include user-level information into the
1.0 MaxSix network layer security protocol.  The implications were enormous.  
Tracking user level information for ALL applications required tremendous 
modifications to the operating system and protocol stack.  This was the 
primary reason we appended our original design to include two layers of 
security -- at the network layer we enforced mandatory access control 
(being data driven a MAC label could be passed without much effort between 
user process and network layer), with all user-level information, such as 
authenticated identity, added to a second layer that effectively sat on top 
of the transport much like the OSI TLSP.  This was MUCH cleaner.

The bottom line:  if you use a network layer security protocol to
propagate user-level information, you can cover perhaps 95% of current
use (you can invent a number just as easily as I) easily, but you will not 
be able to cover everything.  How critical is this shortfall?  Well that's
rather dependent upon what you are doing, isn't it?

Charles Watt
SecureWare

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