[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "user" and "network layer" security mechanisms.
In a galaxy far, far away, Charles Watt <watt@sware.com> says:
> Mr. Nelson is quite correct, in spite of the assertions otherwise.
> 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. Mr. Nelson's point was simply that UDP and TCP port
> numbers are not a sufficient mechanism to make this link, unless you are
> willing to limit the set of applications that you plan to support. As he
Huh?
Who said anything about UDP or TCP?
IPsec has an SPI. *That* is the unambiguous link between packets and
*all* security associations, whether they be user or node ones.
One of my major problems with SKIP is that it effectively kills the SPI
as a useful concept.
> 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.
> 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
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
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.
To: Charles Watt <watt@sware.com>
Cc: ipsec@TIS.COM
Subject: Re: "user" and "network layer" security mechanisms.
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Tue, 20 Aug 1996 12:13:41 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9608201241.aa07866@neptune.TIS.COM>
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.
> 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.
Perry
Date: Tue, 20 Aug 1996 09:00:24 -0700
From: "Michael R. Eisler" <Michael.Eisler@eng.sun.com>
Message-Id: <199608201600.JAA28800@dfs-1.eng.sun.com>
To: perry@piermont.com, watt@sware.com
Subject: Re: "user" and "network layer" security mechanisms.
Cc: nelson@mcn.netsec.com, ipsec@TIS.COM, netsec@panix.com
X-Sun-Charset: US-ASCII
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> From watt@sware.com Tue Aug 20 08:07:17 1996
> > > M.C.Nelson <netsec@panix.com> wrote:
> > >
> > > There is no concept of "user" at the IP layer (i.e. the network layer).
> > > [A:] Moreover, there is no clean and reliable way to map from IP
datagram to
> > > user. Any such code will be problematic unless the functionality of
> > > IP is severely altered. [B:] For example, consider a transport protocol
> > > that combines service to several users simultaneously.
> Mr. Nelson is quite correct, in spite of the assertions otherwise.
> 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. Mr. Nelson's point was simply that UDP and TCP port
> numbers are not a sufficient mechanism to make this link, unless you are
> willing to limit the set of applications that you plan to support. As he
> stated quite clearly, the Internet protocol stack permits higher layer
> protocols to multiplex multiple logical channels across a single IP:port #
> association.
>
> 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.
>
> 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.
Note that even with connection-oriented NFS (NFS on TCP), NFS client
implementations typically multiplex traffic from diffrent users to the
over the same connection to an NFS server. Some implementations go
further and multiplex all traffic, regardless of the number of mounted
file systems between a client/server pair over the same connection.
Moreover when using TCP, it is possible for the same *datagram* to
contain multiple NFS requests, each from different users.
> There are many more examples where Internet services multiplex data from
> several users across a single IP:port # association. As Perry would say,
> read the RFCs. Perhaps some of them can be ignored as "not mainstream".
> Attempts can be made to explain away others, such as the argument that NFS
^^^^
> really only works when the client system is fully trusted as part of the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> same distributed system as the server, so just do host-host authentication
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> and trust the client system to get the user. But in total, all of this
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is the case when NFS operates over the AUTH_SYS oncrpc
authentication flavor. However, nothing in the NFS architecture
precludes a using a flavor that supports a user security association
that does not depend on trusting the client host. The ID
draft-oncrpc-rpcsec_gss-00.txt proposes a new onc rpc security flavor
that uses GSS-API security associations ("contexts" in the parlance
used by the CAT working group).
> 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. In thinking about
how to implement user security associations on operation systems that
use asynchronous network I/O, such as Streams, I realize that it
introduces several implementation difficulties. Considering the Streams
model, one would have to tag each Streams buffer (an mblk) with an
identifier that is unique to each user security association. This in
theory could be done automatically at the Stream head. I am ignoring
the issue of multiple security associations per mblk or what ahppens
when one wishes to link mlbks with different tags together for the
purpose of transnsmission as one IP datagram.
Streams supports a dynamic plumbing model ... applications are free to
push and pop modules and link streams at will. Each Streams module
would have to agree to copy security association the tag whenever they
copy data from one mblk to another. If the modules used Streams APIs
like copyb(), and copymsg(), this would not be an issue. But it is not
infrequent for modules to allocate mblks and copy them using methods
outside the Streams API. One could certainly extend the Streams
framework such that it could be sure that all modules on the stack
apprehend the notions of the security association tag. But then there
is a binary compatibility issue whenever an application pushes a module
that hasn't been "IPSECized". Either the framework allows the push, and
risks untagged mblks be generated, or it refuses the push. Either way,
the application stops working.
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.
> offer over a secure IP that supports user-level associations. These quite
> rightly belong at a higher layer.
>
> Charlie Watt
> SecureWare, Inc.
Mike Eisler
SunSoft, Inc.
Follow-Ups:
References: