Subject: Re: iSCSI: Public Key Method

From: "Ofer Biran" <[email-masked]>
Date: Wed, 5 Sep 2001 01:00:35 +0200

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
[email-masked]  972-4-8296253

Michael Eisler <[email-masked]>@ece.cmu.edu on 04/09/2001 20:25:38

Please respond to Michael Eisler <[email-masked]>

Sent by:  [email-masked]

To:   John Hufferd/San Jose/IBM@IBMUS
cc:   Joshua Tseng <[email-masked]>, [email-masked]
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

---

From: Michael Eisler <[email-masked]>
Date: Tue, 4 Sep 2001 16:42:09 -0700 (PDT)

> Can you specify which algorithm you're referring to ?  I guess

Ofer,

The md5WithRSAEncryption and sha1WithRSAEncryption integrity  algorithms.
However, it looks like the IP issues were around the RSA algorithm itself,
which according to http://www.ietf.org/ietf/IPR/RSA, has expired. (In my
defense, at the time  the LIPKEY/SPKM-3 RFC was written/published the patent
hadn't expired, and I was asked by the WG chair to make the algorithm not
mandatory). Assuming the IP issues are now moot, I would expect RFC 2847 to be
updated someday to REQUIRE sha1WithRSAEncryption, and make id-dsa-with-sha1
OPTIONAL.

There may however, be other reasons to make an SPKM-2 derivative,
relating to, for example, weaknesses discovered in MD5 that weren't
known when RFC 2025 (SPKM) was published. I went through the effort of
looking for these deficiencies in SPKM-1, but didn't bother to
make the analysis in SPKM-2, since I had no immediate use for it.

> (David - please correct me if I'm wrong here...)

Unless it is envisioned that both the iSCSI client and server will often
come from the same vendor, making SPKM, Kerberos V5, etc. optional
to implement is unlikely to result in a high frequency of situations
where these methods get used.

	-mre