Re: iSCSI: Public Key Method

["Ofer Biran" <BIRAN@il.ibm.com>]

Michael,

> A derivative
> is necessary, because there are intellectual property
> issues with at least one of the crypto algorithms specified in
> RFC 2025

Can you specify which algorithm you're referring to ?  I guess
this is less a problem for us since it's only an optional method
(David - please correct me if I'm wrong here...)

Another point - we don't have an identity protection requirement,
so this reason alone should not drive us to derivative.

 Regards,
   Ofer

Ofer Biran
Storage and Systems Technology
IBM Research Lab in Haifa
biran@il.ibm.com  972-4-8296253


Michael Eisler <mre@zambeel.com>@ece.cmu.edu on 04/09/2001 20:25:38

Please respond to Michael Eisler <mre@zambeel.com>

Sent by:  owner-ips@ece.cmu.edu


To:   John Hufferd/San Jose/IBM@IBMUS
cc:   Joshua Tseng <jtseng@NishanSystems.com>, ips@ece.cmu.edu
Subject:  Re: iSCSI: Public Key Method



>
> Joshua,
> what is the value of the time stamp in SPKM-2?  Does it make it more
> secure, or flexible or ????

As the author of a derivative of the original SPKM specification, I
might have some useful input here.

Timestamps, IMHO, are less flexible since they require a time
synchronization protocol. SPKM-2 needs the timestamps to detect
replays during context establishment, and uses sequence
numebrs after the context is established. SPKM-1 doesn't
need timestamps to detect replays, but does incur one
extra message over SPKM-2 during context establishment. Modulo
attacks on the time synchronization service, neither approach
is more secure than the other, but I'm more comfortable
when the dependency on a secure time service is removed.

There are other differences between SPKM-1 and SPKM-2. SPKM-1 supports
unilateral authentication such that the initiator (the client) can be
anonymous while the the target (the server) is authenticated to the
initiator.
SPKM-2 supports unilateral authentication but in the other direction. Also,
SPKM-1 unilateral authentication allows the negotiation of of key
establishment algorithms, whereas SPKM-2 doesn't.

> If you had to chose one (either SPKM-1 or SPKM-2), which one would you
> chose and why?
> What would be the down side to that choice?

When the NFSv4 WG looked at public key, one requirement was to
not require heavy weight public key infrastructure on the client side,
i.e. not require that each end-user have his own private/public key
pair and certificate, and instead allow for a username/password
pair to be encrypted from the client to server, via a key derived from
the server's public key. This models the typical usage model of SSL;
user certificates are rare. Hence SPKM-1, which at the SPKM level
allows the client to be anonymous while authenticating the server,
is more useful than SPKM-2. With SPKM-1, you can use a
session key from the GSS context establishment to encrypt
the username/password.

As a result I updated SPKM-1 into SPKM-3 [RFC2847] for better
support of anonymous initiators (several of the various crypto
alogorithms specified in RFC 2025 did not lend themselves
to true anonymous clients), plus added a thin veneer mechanism called
LIPKEY to take care of the password-based authentication for
those clients that don't have a user certificate.

So for iSCSI, if it is desirable to obviate client certificates,
then SPKM-1 (really, SPKM-3, or a derivative thereof) and not
SPKM-2 is what is needed. If client certificates are not
needed, then a derivative of SPKM-2 is fine. A derivative
is necessary, because there are intellectual property
issues with at least one of the crypto algorithms specified in
RFC 2025.

     -mre