Subject: Re: iSCSI: Public Key Method

From: "Ofer Biran" <[email-masked]>
Date: Sat, 1 Sep 2001 14:38:44 +0200

John,

Since I ought to blamed for putting the two of them... SPKM-2 uses
secure timestamp in the initial authentication (i.e., I sign the current
time
with my private key - this authenticates me and prevents replay attack of
that message later).  In SPKM-1 I sign a random challenge sent from the
other party, and this costs another communication round to authenticate
the initiator.  If it's true that some systems (in iSCSI scenarios) might
have
problem with timestamps (and there is also an issue of clocks
synchronization),
and we decide to specify only one of them, then SPKM-1 would be more
reasonable.  For the question of specifying one or two - this is the usual
trade-off
in optional methods between flexibility (more options) and interoperability
(less
options, so whoever chooses to implement SPKM will implement the same one).

   Regards,
      Ofer

Ofer Biran
Storage and Systems Technology
IBM Research Lab in Haifa
[email-masked]  972-4-8296253

John Hufferd/San Jose/IBM@[email-masked] on 01/09/2001 10:17:52

Please respond to John Hufferd/San Jose/IBM@IBMUS

Sent by:  [email-masked]

To:   Joshua Tseng <[email-masked]>
cc:   [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 ????
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: [email-masked]
Date: Sat, 1 Sep 2001 16:19:18 -0400

I have no problem with this discussion in principle.
I'm interested in the practical aspects of this - as
public key infrastructures are being deployed (and this
is happening, albeit slowly), what is being used for
authentication - SPKM-1, -2, both, something else?
Keberos and CHAP are both being used for
authentication in the infrastructures of interest.

I have no problem with wanting to have a way to integrate
with public key infrastructure in principle, but am
concerned that we pick the right protocol in practice.
A quick reminder that this is about what to specify -
both implementation and use would be OPTIONAL.

Thanks,
--David

> -----Original Message-----
> From: Joshua Tseng [mailto:[email-masked]]
> Sent: Friday, August 31, 2001 10:21 PM
> To: [email-masked]

---

From: "Julian Satran" <[email-masked]>
Date: Tue, 4 Sep 2001 08:19:12 +0300

Josh,

Public keys are great and all you said is correct. It would be wrong
however to omit that
the biggest issue with public keys is certificate revocation and the cost
to check for revocation.

If one goes for an all public infrastructure with general purpose CAs the
cost of checking for revocation can be daunting and if you go for private
domains many of the advantages you mentioned are lost.

That was the reason behind our original recommendation for SRP as the
"base" authentication method and  not
SPK.

Julo

Joshua Tseng <[email-masked]>@ece.cmu.edu on 01-09-2001 05:21:11

Please respond to Joshua Tseng <[email-masked]>

To:   [email-masked]
cc:

Josh

---

From: Joshua Tseng <[email-masked]>
Date: Tue, 4 Sep 2001 10:40:44 -0700

David,
> authentication in the infrastructures of interest.

Regarding the question of what is being used for public
key, it seems SSL/TLS is quite common, most notably for
http.  I have no information on how many applications
(if any) are using SPKM-1 and/or SPKM-2.  Perhaps someone
else could comment?

> both implementation and use would be OPTIONAL.

Good, we agree on needing a way to integrate with PKI.
Unfortunately, I'm not going to be much of a help on how
to do it.

It seems to me TLS would be overkill for us at this point,
especially since we already IPSec running underneath.  My
reasoning for SPKM-1 and/or SPKM-2 is that I don't know of
any other public key interface, unless we decide to create
our own for iSCSI.

I'd also like to add that whatever mechanism we decide upon,
mutual authentication using public key certificates should
be an option.  For this reason, we should rule out LIPKEY/SPKM-3.

Josh

---

From: Joshua Tseng <[email-masked]>
Date: Tue, 4 Sep 2001 13:56:38 -0700

John,

Based upon the information that Ofer and Michael have provided,
I would choose SPKM-1 (or SPKM-3).  This also allows the server
the option to force certificate-based authentication of the
client.  Another option would be to create our own interface
for iSCSI, but before we do that I would like someone to explain
why we can't or shouldn't use SPKM-1.

Josh

> From: John Hufferd [mailto:[email-masked]]
> Sent: Saturday, September 01, 2001 1:18 AM
> To: Joshua Tseng
> Cc: [email-masked]