Subject: Re: iSCSI: Public Key Method

From: "John Hufferd" <[email-masked]>
Date: Sat, 1 Sep 2001 01:17:52 -0700

Joshua,
what is the value of the time stamp in SPKM-2?  Does it make it more
secure, or flexible or ????
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?

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: [email-masked]

Joshua Tseng <[email-masked]>@ece.cmu.edu on 08/31/2001 07:21:11
PM

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  iSCSI: Public Key Method

This message is in response to the action item David Black gave me
at the Interim meeting to investigate the need for a Public Key Method
for iSCSI.

My recommendation is that if we include the Kerberos method in iSCSI,
then we should also include at least one Public Key Method as well.
I don't see any problem with using SPKM-1 and SPKM-2.  The only
difference between them is that SPKM-2 includes a timestamp.

Although Kerberos has been in use for a longer period of time,
public key offers significant scaling advantages.  It is also widely
recognized as the next-generation key distribution method, and
I believe iSCSI should not leave it out.

Some of the key advantages of public key:

1)  Key distribution does not require a secure communication
channel between the communicating principals and the key distribution
authority.  Public keys can be distributed in the clear.  On the
other hand, Kerberos requires an additional set of security associations
between the Kerberos server and every principal, or manual distribution
and configuration of keys, which can be an administrative nightmare.

2)  In Public Key, there is no single point of failure as there is
with a Kerberos Server.  If the Kerberos Server is wiped out in
a DOS attack, no one can access its keys, and no one can talk securely.
Also, if the contents of the Kerberos Server is compromised, anyone
can be impersonated.  On the other hand, if the CA is wiped out,
holders of public keys can still continue to function.  Furthermore,
CA's can be distributed, making them resilient to attacks.

3)  In Public Key, there is no single physical location or device
in the network that can be considered a performance bottleneck.
This is another reason why Public Key is far more scalable than
Kerberos.

4)  Of all the iSCSI authentication methods in the current draft
(KRB5, SRP, CHAP), SPKM-1 and SPKM-2 require the least amount
of manual administration.

Given the above, it makes sense to me that if we include Kerberos,
then we ought to also include Public Key.  We may not need both
SPKM-1 and SPKM-2, but I think we should include at least one of
them.  I believe the current text in the iSCSI document is fine
(good job Ofer!).

Josh

---

From: Michael Eisler <[email-masked]>
Date: Tue, 4 Sep 2001 11:25:38 -0700 (PDT)

> 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.

> 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