RE: iSCSI:SRP

[Black_David@emc.com]

Some important comments and clarifications:

> Now, I personally believe, as you mentioned in your note, that the right
> way to do this is to have the SRP as a SHOULD implement.  But at
> Minneapolis I brought that up and was shot down by the AD, and he told us
> that IPR could not be a valid reason for using the SHOULD word.  "SHOULD"
> we were told should be used for technical reasons.  That is, the following
> statement in RFC2119, is being interpreted as being focused on the
> technical:
> 
> "SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course."

It is not just that statement, and not just an interpretation.  Section
6 of RFC 2119 is quite explicit about this.  It says:

6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmissions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

Needless to say, difficulty in getting a license or a license at
reasonable cost does not fall under "required for interoperation or
to limit behavior that has the potential for causing harm (e.g.,
limiting retransmissions".  The AD who brought this topic up in
Minneapolis is the author of RFC 2119 and was reminding the WG
of this section.

> There is one other worry I have about Chap and DH-Chap.  Though we were
> only asked to "consider" DH-Chap, I think the implication was to consider
> it to solve the MUST problem.  Now that David thinks he has a working
> DH-Chap proposal, I am afraid that the ADs will see the proposal as a
valid
> way to get a stronger Chap, and not let plain Chap be the only MUST.  If
> that happens we will be stuck with an unproven DH-CHAP as the only MUST.
> And that worries me a lot.

I think this sort of speculation about what the ADs might do is uncalled-for
and a complete waste of time.  If we have good technical reasons for what
we do, I don't think we will get shafted in this fashion.

> OK, this was a round about way of saying, SRP as MUST implement since we
> know that is Strong, therefore we can not be compelled to take DH-CHAP as
a
> MUST.

I want to express my continued *strong disapproval* of this sort of
gaming of the process ("we can not be compelled to take DH-CHAP as a
MUST").  I hope John intended "would not need DH-CHAP as a MUST" since
SRP would be equally usable and a superior technical solution.

> We really need to come to closure, so let me offer some
> options:
> 
> 1. SRP MUST, CHAP MUST, DH-CHAP MAY
> 2. SRP SHOULD, CHAP MUST, DH-CHAP MAY (need technical reason for the SRP
> not being MUST)
> 3. SRP MUST, CHAP SHOULD, DH-CHAP MAY (for those folks that do not want
two
> MUSTs)
> 4. SRP MUST, CHAP MAY, DH-CHAP MAY
> 5. SRP MAY, CHAP MUST, DH-CHAP MAY (we must feel comfortable that it will
> not morph into option 5)
> 6. SRP MAY, CHAP MAY, DH-CHAP MUST  (this one worries me the most)

This is unbelievably premature in the absence of a DH-CHAP draft.
Apparently, I cannot stop people from wasting list bandwidth in this
fashion, but it is NOT MAKING ANY PROGRESS towards what we need to
get done, and it is the WRONG WAY to analyze this sort of issue
(i.e., it is wrong to consider RFC 2119 words in the abstract without
reference to the actual technical requirements that motivate the words).

There are some valid technical points in John's post - the strength of
SRP, and the compatibility of CHAP with existing equipment, but they
are surrounded by a great deal of text that attempts to game or end-run
IETF processes, and that is fundamentally unproductive.

In the hopes of getting this back onto a more productive path, let
me toss in a technical issue.  DH-CHAP will be compatible with existing
RADIUS servers (same signature format, and the recipient of the response
can compute the challenge was that the sender should have signed), BUT
... there's a problematic security issue.  Existing RADIUS servers
want the challenge and response sent to them, over connections that
usually aren't encrypted.  If the DH-CHAP response and computed
challenge are sent over such a connection, a passive eavesdropper on
that connection gains the material to mount a dictionary attack as
if she'd monitored a CHAP exchange (i.e., sending the DH-CHAP results
to RADIUS in the clear may negate the DH advantages).  This would be
a major drawback to using DH-CHAP with existing RADIUS (and the like)
servers if one can generally expect an eavesdropper on the IP Storage
connection to also be able to eavesdrop on the connection to the
RADIUS server - do people think that is likely to be or not be the
case in general, and why?

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
black_david@emc.com         Cell: +1 (978) 394-7754
---------------------------------------------------