Re: iSCSI: SRP vs DH-CHAP

["Mallikarjun C." <cbm@rose.hp.com>]

David,

It was certainly not my intention to trash any company's name,
which is never helpful anyway.  Sorry if you took it that way.

The point was not to comment on EMC/Lucent, but to suggest 
that IESG is likely to approach these IPR claims in a generally
uniform fashion - and along the way, requesting the WG to consider
its preference wrt SRP in the context  of other IPR claims that we 
may have to deal with.

If I understood you right, you have received indications from IESG that a 
reasonable design/review of DH-CHAP is expected of this WG - regardless
of the status of the IPR claims.  Is that a correct understanding?

I realize that a design-team oriented approach may be useful at times
for speed, but it may make sense to post the current set of requirements
being used in designing DH-CHAP.

At any rate, since SRP seems to provide beyond the baseline requirements,
I suppose that SRP can be a "MUST implement" regardless.  This is my
preferred option.

Regards.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668 
Roseville CA 95747
cbm@rose.hp.com

----- Original Message ----- 
From: <Black_David@emc.com>
To: <cbm@rose.hp.com>; <ips@ece.cmu.edu>
Sent: Wednesday, April 03, 2002 7:24 AM
Subject: RE: iSCSI: SRP vs DH-CHAP


> Mallikarjun,
> 
> > - Given that Lucent's new clarification came after Minneapolis, let's 
> >    consider the possibility that several/most WG participants are now
> >    favorably inclined to go with SRP as the "MUST implement".  Can 
> >    folks with continuing concerns on SRP please speak up? [ This is *not*
> >    a legal advice; but HP's lawyers do not see any issues for
> Hewlett-Packard 
> >    in the area of SRP. ]
> 
> That's certainly a reasonable position to take and advocate.
> 
> > - I find the statement that IESG would send back the iSCSI draft if
> >    it thinks that a sufficient analysis hadn't been done on DH-CHAP
> >    to be surprising to say the least.  If SRP meets the needs (more on
> this
> >    in the next bullet) and SRP has an IPR situation that's deemed 
> >    acceptable from IETF's perspective (let's recall that SRP is a 
> >    standards track RFC), why would IESG return the iSCSI spec back?
> 
> RFC 2026 says:
> 
> 6.1.2  IESG Review and Approval
> 
>    The IESG shall determine whether or not a specification submitted to
>    it according to section 6.1.1 satisfies the applicable criteria for
>    the recommended action (see sections 4.1 and 4.2), and shall in
>    addition determine whether or not the technical quality and clarity
>    of the specification is consistent with that expected for the
>    maturity level to which the specification is recommended.
> 
> This whole issue falls into the area of "technical quality".  The IESG
> can apply a higher technical standard than "meets the needs" (e.g., a
> cement mixer "meets the needs" for my personal transportation, but it's
> not a particularly effective solution for that purpose), and I expect
> the IESG to do so in this situation.  We now have the choice of doing
> the analysis, or leaving the IESG to do it for us (and the latter
> will take a *LOT* longer).  I'd love to turn back the clock, but I
> can't.
> 
> >    [ To provide the context for this question, consider that EMC is in 
> >      a similar situation with iSCSI - http://www.ietf.org/ietf/IPR/EMC-IPS
> 
> >    - using generally the same language as we had seen with Lucent. ]
> 
> For the record, EMC never issued a statement remotely resembling the
> following November 30, 2001 statement from Lucent:
> 
> As you are aware, RFC 2945 was neither submitted or proposed by
> Lucent.  Therefore, Lucent's general patent statement to IETF in
> 1999 does not cover RFC 2945.
> 
> Lucent has subsequently revised this statement to adopt a more cooperative
> attitude.  IMHO, applying the words "similar situation" to EMC is misleading
> or worse; I do not recommend trashing my employer's good name as a way
> to influence my thinking ;-).  Lucent was a major factor in creating the
> current situation we find ourselves in and the resulting delays - EMC was
> not.
> 
> > - A procedural question in this regard is the seeming lack of 
> >    documented requirements for the authentication mechanism.  I 
> >    don't really see a list of requirements stated in the security
> >    draft, even though there's general text that discusses some issues.
> >    (BTW, the iSCSI requirements draft (rightly) does not go to the depth
> >    we're seeking here). I am equally to blame for this, but I was under
> >    the impression that we had a list of *documented* requirements to 
> >    evaluate candidates - and we chose SRP.  I was somewhat surprised 
> >    to see that we now seem to be defining/weakening requirements afresh 
> >    in some of the recent email threads I had seen.  I admit that I am not 
> >    a security expert, but I am personally not _yet_ clear on the
> requirements.... 
> 
> To the extent that they're documented, Ofer's presentation from Nashua
> almost a year ago is the place to start:
> 
> http://www.haifa.il.ibm.com/satran/ips/iSCSI-Sec-review-Nashua.pdf
> 
> There's been one very important change since then.  At the time we were
> considering SRP as the basis for all iSCSI security, and some of the
> evaluation criteria (especially Performance) are based on using the session
> keying material that it generates.  Since we are now using IKE to provide
> session keys for IPsec, some things change.  A very important change is
> that one needs to consider the situation in which SRP is used in the
> absence of IPsec - SRP's resistance to active attack loses some of its
> value as an active attacker can wait until the authentication is complete
> and then attack the unprotected TCP connection, although the results are
> of somewhat less value as the password required to re-authenticate is not
> obtained.
> 
> Thanks,
> --David
>