Re: iSCSI: Public Key Method

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

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
biran@il.ibm.com  972-4-8296253


John Hufferd/San Jose/IBM@IBMUS@ece.cmu.edu on 01/09/2001 10:17:52

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

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


To:   Joshua Tseng <jtseng@NishanSystems.com>
cc:   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 ????
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: hufferd@us.ibm.com


Joshua Tseng <jtseng@NishanSystems.com>@ece.cmu.edu on 08/31/2001 07:21:11
PM

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


To:   ips@ece.cmu.edu
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