Re: iSCSI: Public Key Method

["Julian Satran" <Julian_Satran@il.ibm.com>]

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 <jtseng@NishanSystems.com>@ece.cmu.edu on 01-09-2001 05:21:11

Please respond to Joshua Tseng <jtseng@NishanSystems.com>

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