RE: iSCSI: Public Key Method

[Joshua Tseng <jtseng@NishanSystems.com>]

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

> -----Original Message-----
> From: John Hufferd [mailto:hufferd@us.ibm.com]
> Sent: Saturday, September 01, 2001 1:18 AM
> To: Joshua Tseng
> 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
> 
> 
> 
>