Re: iSCSI:SRP

[Bill Strahm <bill@strahm.net>]

I am confused John,

The reason we are looking at things beyond SRP is that there MAY be IPR issues
with SRP.  Because of that the WG will consider algorithms that MAY NOT have 
IPR issues such as CHAP.

I am not a fan of SRP from many reasons, but I will say that it is considerably
stronger than CHAP.  For that reason, if I MUST implement it, why should I also
include a weaker algorithm, I all ready have to play the price to licence SRP.

I would argue that CHAP should me the sole MUST implement, because it is open
and free, from there we can have SRP as a SHOULD and don't mention CHAP+DH at 
all because it will have all of the problems that SRP has, until it is vetted.

Bill
On Wed, Apr 03, 2002 at 09:37:53AM -0800, John Hufferd wrote:
> 
> David,
> I think we need to lower our exposure here.  I suggest SRP as Must
> Implement, Chap (as it is today) as Must implement, and a pointer to the
> new draft your are making for DH+Chap, as a MAY implement.
> 
> 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.  If DH+Chap end up with some problems we will not be
> impacted.  And if DH+Chap works, I think it will attract a lot of
> attention, and many folks will use it.  I can even accept DH+Chap as a
> SHOULD implement, as long as it does not hold us up and it looks
> reasonable.  That would at least give us an out if we find an important
> technical hold, etc.
> 
> So, SRP MUST, Chap today as MUST, and DH+CHAP as MAY or if necessary,
> SHOULD --   But we need to put this to bed, right away.
> 
> .
> .
> .
> 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, Cell: (408) 499-9702
> Internet address: hufferd@us.ibm.com
> 
> 
> Black_David@emc.com@ece.cmu.edu on 04/03/2002 07:45:12 AM
> 
> Sent by:    owner-ips@ece.cmu.edu
> 
> 
> To:    marjorie_krueger@hp.com
> cc:    ips@ece.cmu.edu
> Subject:    RE: iSCSI:SRP
> 
> 
> 
> Marjorie,
> 
> > I don't see your reasoning here David, please explain.  As Mallikarjun
> says,
> > it's up to this WG to decide what the authentication reqmts are for iSCSI
> > and choose a protocol.  Why would the IESG second guess that?
> 
> See Section 6.1.2 of RFC 2026 where the IESG is responsible for "technical
> quality" of RFCs, and the discussion of this in my response to Mallikarjun.
> If I replace the word "authentication" with "confidentiality", in the
> above text, I observe that we've been through a worked example of the IESG
> exerting its authority to set security requirements.
> 
> > If that's the case, perhaps there's an unknown, unbounded list of
> > authentication protocols that we haven't considered that the IESG will
> > make us go back and consider?
> 
> I don't believe so - my understanding is that consideration of
> DH-strengthened CHAP will be sufficient.  For example, I see little need
> to investigate the notion of a signed CHAP challenge that was lurking
> in one of Ted Ts'o's posts - if the signing keys are available, one of
> the SPKM methods should be used instead.
> 
> > It's my understanding that DH-strenghthened CHAP is only "proposed", not
> > currently standard (not even a draft)?  So I can't believe the IESG will
> > make us go consider requiring a draft in our proposed standard, that's
> > against their own stated rules?
> 
> Internet-Draft coming soon, I hope, after expert review of the proposal's
> cryptographic soundness.  FWIW, I agree with Paul Koning's concerns:
> 
> > I'm definitely not the world's greatest fan of SRP, but I much prefer
> > a requirement for an existing RFC (even if not yet widely implemented)
> > over a diversion towards a not yet defined, not yet analyzed, new
> > protocol with unknown security properties.
> 
> IMHO, DH-strengthened CHAP will fly only if it is a sufficiently
> straightforward combination of DH and CHAP that reasonable confidence
> can be obtained in it without the need for the years of public scrutiny
> that are required for major new security mechanisms/protocols.  From
> a procedural standpoint, that has to be the case in order to advance
> the definition through this WG as opposed to one in the Security Area.
> 
> At the moment, I'm taking much of the responsibility for writing up
> DH-CHAP because somebody has to do it.  Please keep in mind that the
> last time I wrote this class of thing up (SRP key generation for ESP,
> last summer), the WG decided not to pursue it.  So don't assume that the
> "fix is in" because I'm one of the WG chairs, but please take seriously
> the responsibility to give the proposal a fair hearing when it appears.
> 
> I'd really like to get the DH-CHAP Internet-Draft out this week, but
> that's starting to look dicey; it will appear by the end of next week,
> come h*** or high water.  I'm not 100% thrilled about this situation,
> but I am certain that a procedural battle with the IESG is not the
> best way out of it.
> 
> 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
> ---------------------------------------------------
> 
> 
>