RE: iSCSI:SRP

[Black_David@emc.com]

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