Re: iSCSI:SRP

["Julian Satran" <[e-mail]>]

Andre,

Neither SRP nor CHAP are about securing content - they are about 
authenticating end-points although this should be solid too.

Julo




Andre Hedrick <[e-mail]>
Sent by: [e-mail]
04/11/2002 11:46 AM
Please respond to Andre Hedrick

 
        To:     John Hufferd/San Jose/IBM@IBMUS
        cc:     Bill Strahm <[e-mail]>, [e-mail], 
[e-mail], [e-mail]
        Subject:        Re: iSCSI:SRP

 


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