Re: [saag] Improving the CHAP protocol

["Black, David" <[e-mail]>]

Hi Peter,

> > I think many people in this thread are missing the purpose of the exercise.

For clarity, the purpose of this exercise is to register additional hash functions for use by iSCSI, not to prolong the life of CHAP in PPP.  We have no problem asking IANA to restrict the newly registered hashes to be used only with iSCSI (i.e., prohibit their use with PPP).  One of the reasons that this is feasible is that iSCSI uses CHAP as part of an iSCSI-specific negotiation mechanism that is not based on PPP.

> > CHAP is used because umpteen bajillion devices and systems need it, not
> > because it's a very good protocol.  

I'm not sure whether iSCSI is up to a bajillion ;-), but there is a lot of iSCSI out there.  The situation that we can't change is that iSCSI references the IANA PPP CHAP registry for CHAP hash algorithms.  An important historical reason for that registry reference was compatibility with RADIUS verification of CHAP (which was important at the time).

> > Since it needs a one-way function, not a collision-
> > resistant function, any hash function is as good - or bad since CHAP isn't
> > very secure - as any other.  Switching from MD5 to polyquantumresistantind-
> > ccaprovable2048bithash will make no difference whatsoever to its security.

FWIW, iSCSI CHAP is somewhat better than plain CHAP, e.g., checks that prevent reflection attacks are mandatory.

> > What the original poster asked for is something FIPS compliant.  If you want
> > to convince said umpteen bajillion devices to switch, you'd better use the
> > universal-standard FIPS-compliant hash algorithm that everything supports,
> > which is SHA-256, not a bunch of wierdo fashion-statement algorithms that
> > nothing supports, which is most of the other stuff that's been suggested.

SHA-256 makes sense from that running code perspective, no problem.

> > Having said that, if you're going to go with a breaking change in CHAP, you
> > may as well actually fix CHAP rather than just making the hash function FIPS
> > compliant.

I see no little to no current interest in a new iSCSI authentication protocol in either the storage standards community or iSCSI implementer community, whereas there is running iSCSI code for at least one of the new hashes.

Moreover, back when there was interest in iSCSI authentication protocols, what was wanted was a strong password protocol to defend against weak secrets (e.g., passwords).  iSCSI originally specified a version of SRP as optional, but that's not used much.  In 20/20 hindsight, it's unfortunate that IETF & CFRG missed the opportunity to recommend a preferred strong password protocol back around the time that the problematic patents were approaching expiration.

Thanks, --David

> -----Original Message-----
> From: saag <[e-mail]> On Behalf Of Maurizio Lombardi
> Sent: Monday, September 23, 2019 6:30 AM
> To: Peter Gutmann; [e-mail]
> Subject: Re: [saag] Improving the CHAP protocol
> 
> 
> [EXTERNAL EMAIL]
> 
> Hello Peter,
> 
> Dne 21.9.2019 v 19:35 Peter Gutmann napsal(a):
> > I think many people in this thread are missing the purpose of the exercise.
> > CHAP is used because umpteen bajillion devices and systems need it, not
> > because it's a very good protocol.  It's insecure because it's CHAP, not
> > because it uses MD5.  Since it needs a one-way function, not a collision-
> > resistant function, any hash function is as good - or bad since CHAP isn't
> > very secure - as any other.  Switching from MD5 to
> polyquantumresistantind-
> > ccaprovable2048bithash will make no difference whatsoever to its security.
> >
> > What the original poster asked for is something FIPS compliant.  If you want
> > to convince said umpteen bajillion devices to switch, you'd better use the
> > universal-standard FIPS-compliant hash algorithm that everything supports,
> > which is SHA-256, not a bunch of wierdo fashion-statement algorithms that
> > nothing supports, which is most of the other stuff that's been suggested.
> 
> That's correct, what we need is just a FIPS-compliant hash function
> that is very unlikely do be deprecated anytime soon; and we need it
> because the non-compliance of MD5 is breaking iSCSI use cases for our
> customers now.
> 
> The collision resistance of the hash function is not a top priority for us.
> 
> Personally, I would like to see adopted something widely used,
> SHA-256 and SHA3-256 are good candidates IMO.
> 
> Maurizio Lombardi
> 
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag