Re: iSCSI:SRP

[Andre Hedrick <[e-mail]>]

Sorry to be a lurker in the back ground, but we are talking about digital
security and access to what one would assume to be sensitive content.

The senerio of flashed based laptops with mobile radio IP transport, aka
cell-technology et al., and off site access to home office content is
highly desired.  However, laptops or pda's can be lost of borrowed without
permission, and a simple CHAP could be hacked by joe-six-pack.

Now who wants there secure content crackable?

SRP is a stronger lock, and locks only keep honest people honest.

Regardless, of what product I will ship, SRP will be in the matrix of
solutions.  Those who fail this point may be discounted as a risk, I would
question the product.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Thu, 4 Apr 2002, John Hufferd wrote:

> 
> 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 [phone], Tie: 276-0403,  eFax: [phone]
> Home Office [phone], Cell: [phone]
> Internet address: [e-mail]
> 
> 
> Bill Strahm <[e-mail]> on 04/03/2002 11:10:29 AM
> 
> To:    John Hufferd/San Jose/IBM@IBMUS
> cc:    [e-mail], [e-mail], [e-mail]
> 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 [phone], Tie: 276-0403,  eFax: [phone]
> > Home Office [phone], Cell: [phone]
> > Internet address: [e-mail]
> >
> >
> > [e-mail]@ece.cmu.edu on 04/03/2002 07:45:12 AM
> >
> > Sent by:    [e-mail]
> >
> >
> > To:    [e-mail]
> > cc:    [e-mail]
> > 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
> > [phone] *NEW*      FAX: [phone]
> > [e-mail]         Cell: [phone]
> > ---------------------------------------------------
> >
> >
> >
> 
> 
>