[saag] Improving the CHAP protocol - conclusion

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

I'm responding to Maurizio's original message to explain what we (Maurizio and yours truly) are going to do and why.  First of all, we want to thank everyone who contributed to this productive discussion.

The TL;DR conclusion is that we will ask IANA to register SHA-256 (from the SHA2 family) and SHA3-256 (from the SHA3 family).  Peter Guttman stated the fundamental reason for registering these basic members of each hash family better than I could:

> 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 the primary reason to register SHA-256 in preference to SHA-512/256 and to register SHA3-256 in preference to SHAKE256.

For SHA2 hashes, the message extension attack that motivated development of SHA-512/256 does not appear to be relevant to CHAP, at least as used by iSCSI.

For SHA3 hashes, a registration of SHAKE256 would have to include an output size (d), which would be 256 bits.  For a 256 bit output, the difference between SHAKE256 and SHA3-256 turns out to be whether '01' (2 bits) or '1111' (4 bits) is appended to the input before running the core Keccak hash calculation [1], which (while important to distinguish use of those two hashes) seems to lack any serious security or crypto difference.  In addition, the Linux kernel (location of an immediately important iSCSI implementation) has running code for SHA3-256, but not for SHAKE256.

[1] https://en.wikipedia.org/wiki/SHA-3#Instances

Once again, many thanks to everyone who contributed, --David
----------------------------------------------------------------
David L. Black, Senior Distinguished Engineer
Dell EMC, 176 South St., Hopkinton, MA  01748
[phone] New    Mobile: [phone]
[e-mail]
----------------------------------------------------------------

> -----Original Message-----
> From: saag <[e-mail]> On Behalf Of Maurizio Lombardi
> Sent: Wednesday, September 18, 2019 8:25 AM
> To: [e-mail]
> Subject: [saag] Improving the CHAP protocol
> 
> 
> [EXTERNAL EMAIL]
> 
> Hello,
> 
> I am working to solve the problem of FIPS (Federal Information Processing
> Standards)
> compliance with the iSCSI/CHAP authentication protocol.
> CHAP is described in RFC 1994: https://tools.ietf.org/html/rfc1994.
> This email is to start discussion, and look for guidance.
> 
> All the major implementations of CHAP for iSCSI use MD5 as the only
> supported hash function.
> Unfortunately, MD5 is now considered insufficient for FIPS and isn’t allowed
> it to be used on FIPS-enabled systems.
> As a consequence, when FIPS mode is active, the CHAP authentication
> doesn’t work.
> 
> As reported by IANA, the SHA1 algorithm could be used as an alternative to
> MD5:
> https://www.iana.org/assignments/ppp-numbers/ppp-numbers.xml#ppp-
> numbers-9
> but the use of SHA1 on FIPS systems has been deprecated and will soon be
> phased out.
> 
> I therefore proposed to add a more modern hash algorithm (like SHA3-256)
> to the list of approved CHAP authentication algorithms.
> David Black suggested to consider adding SHA-256 and SHA-512/256 in
> addition to SHA3-256
> and asked me to send an email to this mailing list:
> 
> 
> David Black wrote:
> -------------
> My sense of the IETF view on secure hashes is that MD5 and SHA1 are
> broken, whereas \
> the SHA2 algorithms are proving to be longer-lived (more resistant to attack)
> than \
> expected, and the SHA3 algorithms are fine.
> 
> That suggests that registration of codepoints for both SHA2 and SHA3 would
> be a good \
> thing to do, as opposed to only SHA3.  I'd suggest starting with either SHA-
> 256 or \
> SHA-512/256 (both are SHA2 hashes) in addition to SHA3-256, as all three
> have the \
> same 256-bit output size.
> 
> Figuring out exactly what should be done here (e.g., which SHA2 variant to
> register) \
> would benefit from some discussion at IETF.  I would start with the Security
> Area's \
> [e-mail] mailing list.  In addition, as iSCSI falls within IETF's Transport \
> Area, the Transport Area Directors ought to be looped in beforehand.
> -----------
> https://marc.info/?l=target-devel&m=156755533912350&w=2
> 
> 
> 
> Thank you,
> Maurizio Lombardi
> 
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag