RE: iSCSI:SRP

[pat_thaler@agilent.com]

Regardless of what problems there have been in the past, Lucent's current
statement - that they will license under reasonable and non-discriminatory
terms with reciprocity - is similar to other statements that we have found
acceptable. Therefore, we should not wait for DH+Chap to go to last call.

To answer David's question 2 about SRP and DH+Chap: SRP is superior because
it is done. The objection to it was based on an IPR uncertainty that has
been resolved. 

Regards,
Pat

-----Original Message-----
From: Paul Koning [mailto:ni1d@arrl.net]
Sent: Wednesday, April 03, 2002 12:26 PM
To: Black_David@emc.com
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI:SRP


Excerpt of message (sent 3 April 2002) by Black_David@emc.com:
> > They asked us to "consider" DH+Chap but it was not a hard requirement,
you
> > told us that they would accept Chap, but wanted us to consider a way to
> > make it more secure.  I think the work that has been done, is clearly
> > considering it, and with the combination of SRP and current Chap clearly
> > meets requirements.

Wasn't that "consider DH+CHAP" in the context of the possible need to
drop SRP down to optional and make CHAP mandatory?
 
> That work is not complete.  There are at least two technical explanations
> missing that have to go into the iSCSI specification in order to
> pursue this course of action:
> 
> (1) Why is CHAP by itself not sufficient?
> (2) Why is SRP preferable to DH-CHAP?
> 
> The second one is crucial as it is the justification to the IESG that
> technology potentially subject to patents needs to be used in preference
> to unencumbered technology. 

I thought the answers to both are obvious already.

1. CHAP is vulnerable to certain attacks that SRP does not suffer
   from, and is one-way.

2. DH-CHAP had not been specified yet, while SRP is a published RFC.

Why isn't (2) sufficient?  Surely, when we're trying to go through the
RFC publication process, we can't be expected to consider a proposal
that is not yet at the "draft 00" stage as a prime contender, can we?
Otherwise no one could ever finish.

> Since some people clearly want to dig into this, here's a one-sentence
> summary of DH+CHAP:
> 
> 	The basic idea is to augment the CHAP challenge with the
> 	key that results from the Diffie-Hellman exchange so that
> 	the CHAP response depends on both of them.
> 
> This is not identical to what I may have discussed with some people
> in the past, as it has now received some expert review and been modified
> accordingly.  For CHAP, see RFC 1994.  ...
> 
> That should be enough to start a discussion of requirements and
> implementation implications in the absence of the complete Internet-Draft;
> I'm sorry that the latter's not available yet ... I will try to get it
> done soon.

That's a fine start for a future I-D, but I really don't understand
why we should entertain the notion of holding up iSCSI and make it
dependent on work that is so far away from completion.

Part of the problem is that this is a security protocol.  Until EVERY
bit of data in EVERY exchange is PRECISELY described, you have
absolutely no way at all to determine whether it is secure or not.  A
minor slip of the pen that would only cause some small annoyances in
an "ordinary" protocol can utterly invalidate all security properties
in a security protocol.  (For some examples, see "A logic of
authentication" by Burrows, Abadi, and Needham, DEC SRC report 39.
That shows the sort of analysis that would need to be done.)  The
burden of proof is high; the time required to meet that burden is
long.

Is there any consensus that iSCSI Last Call should wait for DH-CHAP
Last Call?

	paul