>Charles Watt writes: > Internet stack was designed to permit multiplexing above IP. There are > several things out there that do this. User-level authentication within > IPSEC cannot work for these products unless they are substantially > modified. No. Most computers today are single user. Multiplexing above IP does not matter for authentication purposes when all the applications above IP are owned by the same "user". The issues of a "user oriented" IPsec in a compartmentalized workstation is difficult. The CMW market is very different from the "real" world and we should be careful not mix the requirements of the two environments. 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 !!! Last chance, send resumes to: palamber@us.oracle.com !!! --------------------------------------------------------------
-- BEGIN included message
- To: Charles,Watt,<watt@sware.com>
- Subject: Re: "user" and "network layer" security mechanisms.
- From: "Perry E. Metzger <perry@piermont.com>" <ipsec-request@neptune.hq.tis.com>
- Date: 21 Aug 96 08:57:18
- Cc: ipsec@tis.com
- Reply-to: perry@piermont.com
- Sender: ipsec-approval@neptune.hq.tis.com
Charles Watt writes: > Upon review of the spec, you are correct. It appears that my memory is not > immune to age afterall. However, I've looked at the source to our vendor's > RFC 1006 streams module and the basic problem remains. It internally > manages a pool of TCP endpoints, maintaining its own internal binding Thats an implementation issue, not a problem in the spec. > Pick at the specifics all you want, the basic point remains valid. The > Internet stack was designed to permit multiplexing above IP. There are > several things out there that do this. User-level authentication within > IPSEC cannot work for these products unless they are substantially > modified. Look, the fact that you have to store SPIs in the TCBs of most implementations makes for a significant change. No one said this was painless. It is, however, a pretty good solution, architecturally. Perry
-- END included message