[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,
BVIkGz4BmKij6ZtnUyFpDF6s9eXCX+6ZtMa+5csK4aBxc0BXSfEnQm2Racglqkav
c4vxdH4Iyt7nYMMSrkkgtxw=
> > 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.
>
> David Kemp wrote:
>
> IP datagrams can, however, be associated unambiguously with src and dst
> addresses and port numbers, which (must necessarily) map unambiguously to
> processes, which in turn can map to users on those systems which support
> the notion of users. Your example B above is proof that assertion
> A is incorrect.
>
>
> Perry E. Metzger wrote:
>
> You seem to have missed the point, which is that IPSEC has this notion
> of "security association" (actually, now its called "Security
> Parameters" and has the associated "Security Parameters Index").
>
> Why don't you go through the archives instead of making guesses about
> what you think IPSEC does?
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.
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
ignoring and explaining away greatly limits the set of services that you can
offer over a secure IP that supports user-level associations. These quite
rightly belong at a higher layer.
Charlie Watt
SecureWare, Inc.
-----END PRIVACY-ENHANCED MESSAGE-----
Date: Tue, 20 Aug 1996 11:52:42 -0400
From: "Mitchell C. Nelson" <nelson@mcn.netsec.com>
Message-Id: <199608201552.LAA00215@mcn.netsec.com>
To: ipsec@TIS.COM
Subject: "user" and "network layer", continuation and reply.
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Continuing and responding to comments on
my email `"user" and "network layer" security':
The IP layer as presently defined, is not conditionalized to any next
or higher layer protocol. It is defined to provide "connectionless",
"unreliable", service between Internet hosts identified by IP address,
with fragmentation of datagrams as needed, unless otherwise flagged.
These are the basic facts of IP architecture. Most of the discussion
group seems to understand the significance of these facts very well.
At present (i.e. absent IPSEC), an IP datagram is defined only in terms
of src and dst IP addresses, a number representating a next layer
protocol, parameters for fragmentation, and a data payload. There is
nothing in the definition of the IP layer that is conditionalized to
the next layer protocol or to the contents of the data payload.
IPSEC deviates from the present network architecture by requiring the
IP layer to deal with an additional parameter, the security parameters
index (SPI) (more precisely, security parameters and headers
principally characterized by an SPI). The extent and consequences of
this deviation are related to the extent to which the SPI deviates
from directly mapping onto the values already available at the network
layer, i.e. <src,dst,prot>.
If SPI does not map onto <src,dst,prot>, there are three general types
of implementations. The cleanest, and closest to present architecture
is that the protocol layer at which the SPI is mapped passes the SPI
downward through the stack, to the IP layer. The IP layer then
processes the packet using the parameters indicated by the SPI.
(As consequences go, this might seem manageable. The basic packet
format can still be consistent with much of the presently installed
network infrastructure. However, one is entitled to question a
network layer security scheme that requires the participation of
upper layer entities (other than a key mgt daemon). For example,
what security services or benefits can be provided by such a scheme
that could not be provided by upper-layer code directly?)
To the point at hand, nothing in the network layer architecture even
with the added SPI, requires the network layer to deal in the
parameters of upper layer protocols. The extension simply requires
upper layer protocols to specify an SPI along with addresses, numeric
protocol, fragmentation flags, and data. What upper layer parameters
the SPI maps to is not information that is needed or dealt with by the
network layer. We do not deal with "user" at the network layer.
"User" is the business of upper layer protocols.
-------------
The following is offered by way of response to some specific points
contained in the replies to my posting.
(1) From mcr@milkyway.com:
"I can see several ways to discuss user based security within
current stacks."
Evidently, I failed to convey the point in an adequately clear way.
(2) From dpkemp@missi.ncsc.mil
"IP datagrams can, however, be associated unambiguously with src
and dst addresses and port numbers"
and,
"... IP doesn't need to interpret the entire contents of the
blob, just the parts it's interested in."
IP doesn't know anything about a "port". "Port" is a parameter
defined within *some* transport protocol headers.
Regarding the "blob", IP doesn't process the "blob" at all, except
to copy it to/from the datagram.
(3) xxx@xxx.com writes:
"You seem to have missed the point, which is that IPSEC has this
notion of "security association" (actually, now its called
"Security Parameters" and has the associated "Security Parameters
Index").
Why don't you go through the archives instead of making guesses
about what you think IPSEC does?"
My coments are based on familiarity with the archives, documents,
current discussions, and experience.
(4) Robert Moskowitz writes:
"xxx, people should not have to 'read the archives' for so
basic a concept. Maybe it really is too obscure in the
architecture RFC. Going to have to reread it :(
Yes, Mitchell, IPsec has a concept of a user. This is for
setting up security associations between two IP addresses,
potentially at the transport layer (rather than as a tunnel).
The description of the security association in the RFC documents
seems very clear.
My point is that the term "user" does not belong in a discussion
of network layer security mechanisms. If the SPI is to relate
to parameters outside of the network layer, the details of that
relationship should still be irrelevant to network layer mechanisms.
(The merit of supporting SPI = SPI(...,upper-layer-parameter) in
network layer mechanisms, is a related but seperate question.)
Regards,
Mitch Nelson
netsec@panix.com
Follow-Ups: