[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SPIs and SKIP (was "user" and "network" ..)
>From: Michael Richardson <mcr@milkyway.com>
> To: ipsec@TIS.COM
> Subject: Re: "user" and "network layer" security mechanisms.
> 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.
An SPI essentially provides the implementation with a
handle to process an ipsec packet. Conceptually, one
can visualize this as a table, indexed by the SPI,
where the table entry contains the attributes (crypto
variables like keys, algorithms, principal ids, etc.)
for processing the packet. There is no constraint on
what this table entry can contain.
With SKIP, one can visualize the table entry for the
SKIP SPI to essentially say: look in another place
for some of the attributes you need; namely the buffer that
contains the received packet. Essentially, all the
same information that one obtains directly from the
contents of the table entry can be obtained from this
other location in system memory.
Keep in mind that some of the crypto-variables are
contained in the packet header, even with alternative
approaches (e.g. IVs). The distinction then essentially
becomes which part of memory some of the attribute
information is obtained from. I don't view this as killing
the SPI as a useful concept. This is merely another
(legitimate) way of using the SPI in order to get different,
and in certain important application scenarious, highly
desirable protocol properties both from a cryptographic
and a network point of view.
Ashar.
To: Derek Atkins <warlord@mit.edu>
Cc: Charles Watt <watt@sware.com>, ipsec@TIS.COM
Subject: Re: "user" and "network layer" security mechanisms.
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Wed, 21 Aug 1996 10:58:25 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9608211058.aa14732@neptune.TIS.COM>
Derek Atkins writes:
> Huh? The fact that authentication is done at the client is an
> implementation detail. It is implement that way, IMHO, because there
> is no "secure" way for the server to know what access rights the
> client has. However, that is in no way a requirement of the NFS
> protocol.
You could, of course, change that, but then it wouldn't be NFS, it
would be a new protocol.
> You could easily change the RPC Security flavor to do something
> different and implement the server such that access checks are
> performed there as well.
However, the complexity you would have to add to the RPC Security
flavor would be sufficient that you really wouldn't have a right to
call it NFS any more -- it would be "NFS plus a whole lot of extra
stuff". You need more than IPSEC -- you end up needing a fairly
complex security handshake on top, and THEN your NFS stuff would be
secured.
> So, your statement about there being "no way" is just plain wrong.
> OTOH, it would take a lot of programming to change the
> implementation to "do the logical thing". But I believe it is
> possible.
I'm not saying that you can't build secure file systems, or that they
can't even look nearly like NFS. However, when you are done, it isn't
going to be NFS any longer. This is very much unlike, say, Telnet,
where just by making the server understand SPIs a bit you could
implement per user authentication.
Perry
To: Charles Watt <watt@sware.com>
Cc: ipsec@TIS.COM
Subject: Re: "user" and "network layer" security mechanisms.
In-Reply-To: Your message of "Tue, 20 Aug 1996 14:14:08 EDT."
<9608201814.AA01416@mordred.sware.com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Wed, 21 Aug 1996 11:03:26 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9608211104.aa14983@neptune.TIS.COM>
Charles Watt writes:
> >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.
>
> I think you are missing the point Perry. For example, if you have six
> concurrent users of an X.400 product that makes use of an RFC 1006
Ah, unless I've lost my brain this week, X.400 is a mail
protocol. Mail systems need to secure the messages, not the links. You
could argue that IPSEC is unsuitable for the user level securing of
SMTP transmissions, and I'd agree. Protocols like that need to have
the underlying messages encrypted -- the transport doesn't matter. No
need to couch this in complex OSI protocol terms.
People often miss this point. Securing the link is suitable for
protocols like Telnet. Protocols like SMTP need the DATA secured, not
the link, although to add some traffic analysis protection one might
want to secure the link too. Protocols like FTP fall somewhere in
between, where one often has a desire to get a signature on the DATA,
but in which there will probably be benefits to assuring that the
control link has been kept secure.
Perry
Date: Wed, 21 Aug 1996 09:27:59 -0700
From: "Michael R. Eisler" <Michael.Eisler@eng.sun.com>
Message-Id: <199608211627.JAA29477@dfs-1.eng.sun.com>
To: warlord@mit.edu, perry@piermont.com
Subject: Re: "user" and "network layer" security mechanisms.
Cc: watt@sware.com, ipsec@TIS.COM
X-Sun-Charset: US-ASCII
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> From perry@piermont.com Wed Aug 21 08:40:30 1996
> Derek Atkins writes:
> > Huh? The fact that authentication is done at the client is an
> > implementation detail. It is implement that way, IMHO, because there
> > is no "secure" way for the server to know what access rights the
> > client has. However, that is in no way a requirement of the NFS
> > protocol.
>
> You could, of course, change that, but then it wouldn't be NFS, it
> would be a new protocol.
The NFS protocol speciification doesn't mandate host-centric security
and access control.
> > You could easily change the RPC Security flavor to do something
> > different and implement the server such that access checks are
> > performed there as well.
>
> However, the complexity you would have to add to the RPC Security
> flavor would be sufficient that you really wouldn't have a right to
> call it NFS any more -- it would be "NFS plus a whole lot of extra
huh? Have you been paying attention to my earlier e-mail message on AUTH_DH,
and AUTH_KERB. Are you claiming that people who run NFS over either of
those two RPC security flavors are in fact not running NFS? A brief lesson:
NFS runs on onc rpc. rpc headers contain (among other things), a flavor #
following by credential information that can used for crypto authentication.
NFS (and other onc applications) treats RPC security as a protocol
layer. Claiming that NFS on on flavor other than AUTH_SYS is no
longer NFS would be like saying that NFS on a transport other
UDP, a network other than IP, or a media other than 10baseT, is no longer
NFS.
> stuff". You need more than IPSEC -- you end up needing a fairly
> complex security handshake on top, and THEN your NFS stuff would be
> secured.
Proven wrong by existance proof.
-mre
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: Wed, 21 Aug 1996 11:57:18 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9608211227.aa17069@neptune.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
Message-Id: <199608211640.JAA27077@puli.cisco.com>
From: Ran Atkinson <rja@cisco.com>
Date: Wed, 21 Aug 1996 09:40:02 PDT
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: ipsec@TIS.COM
Subject: Re: "user" and "network layer" security mechanisms.
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
I'm glad there is now general agreement that user-oriented keying is not
particularly hard to implement in an MLS system and that folks understand
the practicality of implementing this inside BSD. I've never worked inside
STREAMS, but people with STREAMS clue tell me it can also be done there,
albeit using different implementation strategies.
On Aug 21, 10:37am, Charles Watt wrote:
% And then again, there are services that manage a pool of sockets within the
% kernel, such as any kernel RPC service and many implementations of the TSAP.
% These sockets are opened and initialized by daemon helpers when the service
% is initialized. They are used by whichever process requests access to the
% service. The approach Ran gives above will authenticate the user of the
% service as if he/she were the daemon process, unless, of course, the
% application is modified to understand the kernel hacks required for IPSEC
% user authentication.
There are a relatively small number of such cases in a typical UNIX system.
The needed modifications are, IMO, not terribly difficult or terribly
time-consuming to make, based on my examination of ONC RPC specifications and
the freely distributable TI-RPC sources a bit over a year ago. Had I remained
at my previous job, I would have been building this sometime in 1997 because
it was in my Statement of Work from ARPA to do precisely that.
As it happens, I think the big hurdle here would be agreement on what the
appropriate API extensions would look like. I suspect that GSS-API could be
used, though some might argue that is too heavyweight an API for this purpose.
I suspect that API extensions based on BSD Sockets would be most widely
useful.
Ran
rja@cisco.com
--
To: "Michael R. Eisler" <Michael.Eisler@eng.sun.com>
Cc: warlord@mit.edu, perry@piermont.com, watt@sware.com, ipsec@TIS.COM
Subject: Re: "user" and "network layer" security mechanisms.
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Wed, 21 Aug 1996 13:54:28 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9608211358.aa19218@neptune.TIS.COM>
Michael R. Eisler writes:
> huh? Have you been paying attention to my earlier e-mail message on AUTH_DH,
> and AUTH_KERB. Are you claiming that people who run NFS over either of
> those two RPC security flavors are in fact not running NFS? A brief lesson:
> NFS runs on onc rpc. rpc headers contain (among other things), a flavor #
> following by credential information that can used for crypto authentication.
I think we are having a semantic argument. I believe we both agree on
what the NFS spec contains and how NFS gets transported. I believe the
difference of opinion is about what we are calling things.
Yes, there are hooks in NFS that let you do lots of stuff that would
let you secure file access with various flavors of secure
RPC. However, I think of ONC RPC as being part and parcel of NFS -- it
is the major application of ONC RPC -- and a secure RPC that hooks
into the IPSEC stuff and provides user granularity file access is
nontrivial. Therefore, permit me to say that within these semantic
constraints NFS *as it stands* could not be made user granularity
secure using IPSEC in the trivial manner that, say, Telnet can (that
is, with no protocol additions other than IPSEC and Photuris or Oakley
or what have you, and with minimal source changes to the
server). However, certainly you could extend the secure RPC mechanisms
do things analagous to the AUTH_KERB hacks with IPSEC. I'm just
arguing that this is no longer NFS in the sense that a machine that
had IPSEC and a key management system added to it is still going to
require extensive hacking to get the NFS security working. Its not
"vanilla NFS".
Perry
Date: Wed, 21 Aug 1996 10:27:54 -0700
From: "Michael R. Eisler" <Michael.Eisler@eng.sun.com>
Message-Id: <199608211727.KAA29531@dfs-1.eng.sun.com>
To: ipsec@TIS.COM, dpkemp@missi.ncsc.mil
Subject: Re: "user" and "network layer" security mechanisms.
X-Sun-Charset: US-ASCII
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
> From dpkemp@missi.ncsc.mil Wed Aug 21 07:37:18 1996
> The other viewpoint is top-down: there is a huge universe of applications
> running on real customer networks that need to be "secured". We could do
> it by modifying every single application and every application protocol to
> provide security services at the highest layer, or we could recognize that
> application protocols fall into classes, and that for some classes (those
> that don't multiplex services for multiple "users" through a single
> connection or process), a common IP-layer mechanism can be used without
> modifying the higher layer protocols. Therefore it is reasonable to
> provide the mechanism (an SPI field in the IP packet) that can in some
> cases be used to achieve separation between "users" at the network layer.
Seems reasonable to me.
For those of us who are "securing" application protocols that aren't
members of the class that can use IP-layer user-oriented security, it
would be most helpful to have IPSEC "officially" recognize the position
that David succinctly stated above.
-mre