RE: iSCSI:SRP

["Herbert, Howard C" <howard.c.herbert@intel.com>]

As I stated in Minneapolis, SRP is the best solution and now it has a clear
IP framework.
We should go back to where we started and make SRP MUST implement and get on
with last call.

I would question the need to complete some "alternatives" analysis given the
IP clarifications.

As I also stated in the plenary, using "open source community likes it" is
not an "official IETF criteria" for making technical decisions (at least I
can not get anyone to write it down anywhere).  The IP language in RFC 2026
provides the official framework for dealing with IP issues.  Best as I can
tell, we have met all of the RFC 2026 criteria regarding use of SRP.

Howard

-----Original Message-----
From: John Hufferd [mailto:hufferd@us.ibm.com]
Sent: Thursday, April 04, 2002 10:15 AM
To: Bill Strahm
Cc: Black_David@emc.com; marjorie_krueger@hp.com; ips@ece.cmu.edu
Subject: Re: iSCSI:SRP



Bill,
At the IETF Plenary meeting in Minneapolis, David, I and some others pushed
the IPR issue.  They said that the Workgroup should define the correct
technical solution, and not take the IPR stuff as a significant issue, (as
long as the Reasonable and Non- discriminatory stuff is part of the
considerations).  We are at that point now that we have Lucent's new
Statements.   The IPR stuff should only be an overt issue when their are no
responsible statements issued by the IPR holders.  Since we can not tell if
the claims are valid, or even apply, or if there is some other IPR issue
that will come out in the future, we should be picking the best technology,
to which we can get consensus.

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

 Therefore, if it is possible that there is a technical reason that a
vendor could not or does not implement a feature, which would otherwise be
a MUST, then the use of SHOULD is acceptable.  If anyone has a technical
reason that SRP may not, or should not be implemented on some vendors
offerings, then SHOULD could be OK.

I could also accept a MUST for CHAP, because of its wide spread install
base.  But I think we should probably have a MAY with DH+CHAP, even if it
is political, in the MAY position I do not believe it can hurt us, and if
it ends up well, it can be a good thing.

Again if we have a technical reason for SRP to be a SHOULD instead of a
Must, we can factor that in.

Without that technical reason for SRP being a SHOULD, I believe, that
because of its stronger security features we should make SRP a MUST.  And
since I still think that CHAP is useful, my above arguments lead me to SRP
MUST, CHAP MUST and DH-Chap as MAY.

It is possible, in the real world that if a vendor, has a problem with
Licensing SRP, that  vendor's product will put an * in their ads and their
product boxes, with marketing words, which state that their product is
iSCSI is compatible with RFC # 123456*, and then they will put in a few
words at the bottom of the package that read as "* except for SRP".   In
that case we still need to interoperate and that will mean that Chap is
required  -- Hence my position on Must implement for Chap.

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.

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.  Then CHAP as a MUST or SHOULD ensures interoperability with all the
systems that currently exploit CHAP and want to require it also for iSCSI
(and with the "*" implementations).  And DH-Chap as MAY, to give us ongoing
additional protection for CHAP implementations that exploit it.

I used SHOULD as an option for CHAP (above), since if there is another
technical superior technique (SRP), a vendor may feel that his products
only sells into the more secure environments, and that CHAP would lower the
products total security, and therefore, have a valid technical reason to
not implement CHAP.  (Unfortunately, I can not make exactly the same case
for SRP, since it is technically superior to CHAP).

Marjorie objects to having CHAP as a (second) MUST, and you, Bill, object
to SRP as a MUST.  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)

I can support 1, 2, 3, or 4.  and favor 4 since that is close to were we
were before, the Lucent issue bit us, and now that it is settled, we can go
back to the previous agreement (plus DH-CHAP). My second choice would be 1,
and my third choice is 3.  However, if we have a technical reason for SRP
being SHOULD, number 2 would jump to the top of my favorite list.

Perhaps some of you folks could vote on your top 3.  (I say top 3 since we
may be able to find a choice that is acceptable by most folks even if not
on the top of most folks' list.)



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


Bill Strahm <bill@strahm.net> on 04/03/2002 11:10:29 AM

To:    John Hufferd/San Jose/IBM@IBMUS
cc:    Black_David@emc.com, marjorie_krueger@hp.com, ips@ece.cmu.edu
Subject:    Re: iSCSI:SRP



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