RE: iSCSI: Public Key Method

[Black_David@emc.com]

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:jtseng@NishanSystems.com]
> Sent: Friday, August 31, 2001 10:21 PM
> To: ips@ece.cmu.edu
> 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
>