RE: iSCSI: Public Key Method

[Joshua Tseng <jtseng@NishanSystems.com>]

David,
> 
> 
> 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.

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?

> 
> 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.

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

> 
> 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
> > 
>