On the subject of Ipsec "users: >From: "Mitchell C. Nelson" <nelson@mcn.netsec.com> >... > Evidently, I failed to convey the point in an adequately clear way. I agree. I hope it is clear now that - IPsec processing binds an authenticated packet to a Security Association (SA). The information contained in the SA may provide additional authentication information corresponding to one or more IP addresses, one or more DNS names, or one or more "users". I agree that "user" does not cover this felxibilty well and is confusing ... perhaps the documentation could refer to something obtuse like principles or authenticated entities. Paul -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com !!! Still hiring, send resumes to: palamber@us.oracle.com !!! --------------------------------------------------------------
-- BEGIN included message
- To: ipsec@tis.com
- Subject: "user" and "network layer", continuation and reply.
- From: "Mitchell C. Nelson <nelson@mcn.netsec.com>" <ipsec-request@neptune.hq.tis.com>
- Date: 20 Aug 96 08:52:42
- Sender: ipsec-approval@neptune.hq.tis.com
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
-- END included message