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

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

> From perry@piermont.com Tue Aug 20 10:31:38 1996
> 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.

NFS implementations have been checking cryptographic credentials a per
file, user, and NFS request basis for nearly 10 years. That is
what NFS on AUTH_DES (rechristened AUTH_DH in a oncrpc wg draft of
an informational RFC) does. Ditto NFS on AUTH_KERB (Kerberos v4), 
since 1992. 

> From mcr@milkyway.com Tue Aug 20 10:16:17 1996
>> Two very specific examples where the proposed mechanisms fail:
>> 
>> 1) Implementations of RFC 1006 - ISO transport on top of TCP.  This is
>>    heavily used within the DMS infrastructure.  It allows multiple users
>>    of an OSI application, such as X.500 or X.400, to make OSI transport
>>    connections over TCP.  For efficiency, most implementations of this 
>>    service will multiplex all concurrent sessions over a single TCP 
>>    connection, so there is no way to tell which IP datagram corresponds
>>    to which user-level "security association" of the service.

>  I see. This sounds like an application problem. Why is it more efficient
> to multiplex all sessions over a single TCP session? You've built a tunnel
> with TCP. Thus, you are reimplementing the network layer, and you will
> have to implement security there.

It is more efficient because additional TCP connections take up more resources.
Multiple TCP connections between the same client and server will unnecessarily
introduce scalability problems. For example, in a multithreaded environment,
where creating a new connection may require getting the write side of
a multi-reader/single write lock. As the # of connections grows, so does
the latency for creating the connection. Finally, using a single TCP connection
reduces congestion over slow/lossy routes.

> > 2) NFS.  Most implementations of the NFS client operate with a fixed pool 
> >    of endpoints dedicated to the service.  As a further complication, for
> 
>   NFS is inherently node-to-node as currently *implemented*, not 
> user-to-server. You can not do user level security associations with currently

see my previous comments on AUTH_DH and AUTH_KERB.
 
> implemented NFS. I suggest you look at AFS. I do not know enough about 
> Sprite's file sharing to comment where it would stand.
>   I wish NFS would go away, but I do not have a better solution yet. Further,
> NFS doesn't have be implemented the way it is: we *could* push a user-server

NFS and AFS make use of the same vnode interfaces to access security
associations. The vnode interfaces all take a credential pointer that
has UNIX uid, gid, gid array etc. information.  When NFS uses AUTH_DES
and AUTH_KERB, it simply takes the UNIX uid and maps to the security
association via one stored in an in-kernel cache, or if not cached, via
an upcall to the user-level helper daemon.  AFS implementations go one
step futher to note that a particular UNIX user may want to assume more
than one "role". So the cred is either extended to contain the role
identfier, or a gid array entry is overloaded to contain the role
identifier.

> SA down the through the vnode interface. The write-behind/read-ahead is
> implemented by "processes" because of the way Unix works. It is implemented
> as kernel threads on many systems.

Simply attaching the UNIX credential or the security association to
each enqueued asynchornous NFS read-ahead or write-behind solves this,
regardless whether one uses threads or processes.

	-mre