Subject: [saag] Improving the CHAP protocol

From: Maurizio Lombardi <[email-masked]>
Date: Wed, 18 Sep 2019 14:25:23 +0200

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 \
[email-masked] 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

---

From: "Mark D. Baushke" <[email-masked]>
Date: Wed, 18 Sep 2019 08:48:05 -0700

Hi Maurizio,

Summary: SHA2-512/256 looks good to me. You may also wish to consider
         SHAKE128(M,256) or SHAKE256(M,256) generating 256 bits.

Long reply:

See "Comparing Hardware Performance of Round 3 SHA-3 Candidates using
Multiple Hardware Architectures in Xilinx and Altera FPGAs" 
https://pdfs.semanticscholar.org/20e2/3a26384b0edc4a218d2d180f0658c1c9a05f.pdf
and look for Keecak vs SHA-2 results.

Doing SHA3 in hardware is going to be faster than doing SHA2 in
hardware.

Doing SHA3 in software is going to be much slower than doing SHA2 in
software.

Comparing SHA2-256 to SHA2-512/256 in software depends on the native
size of a CPU word.

On a 64bit CPU, I beleve that doing a SHA2-256 will be slower than
doing a SHA2-512/256 on the order of 30% (best to run your own
benchmarks using something like 'openssl speed').

Per FIPS Publication 202, for SHA3, to get 256-bits of hash, there are
alternatives: SHA3-256, and the two Extendable-Output Functions (XOF):
SHAKE128 and SHAKE256. (There is no definition for SHA3-512/256.)

I have not done any software performance analysis of SHA3 functionality,
however, the https://keccak.team/2017/is_sha3_slow.html shows that using
the XOF functions are on performance part with SHA-2 on common
processors.

Considering longer term safety of the 256-bit hashes...

The SHA2-512/256 keeps an internal state of 1024 bits and displays only
256 bits of the finished hash. While SHA2-256 keeps an internal state of
512 bits and displays half of it (256 bits), so from a data hiding point
of view is should be more secure to use SH2-512/256.

As the intention is cryptographic agility, I think that adding
SHA2-512/256 is a good idea.

It may also be desirable to consult with your FIPS experts to determine
if SHAKE{128,256} is acceptable to generate the 256-bits needed and be
FIPS 140-2 compliant.

	-- Mark

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 18 Sep 2019 12:22:29 -0400

Maurizio,

This is the right place to start the discussion.  If you pull together a
draft before the deadline and want a slot to present at SecDispatch, send a
message there as well.  SecDispatch will help find a home for the draft,
even if that is an AD sponsored draft (if there's not WG that is a fit).

Best regards,
Kathleen

On Wed, Sep 18, 2019 at 11:48 AM Mark D. Baushke <mdb=
[email-masked]> wrote:

> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

-- 

Best regards,
Kathleen

---

From: "Black, David" <[email-masked]>
Date: Wed, 18 Sep 2019 19:31:28 +0000

Hi Mark,

Thank you very much for your comments and explanation - it seems that SHA2-512/256 is the better choice of SHA-2 hash (than SHA2-256) on both security and performance grounds.  My 0.02 is that fewer options are better here, so I'd register only SHA2-512/256 for SHA2, in addition to registering SHA3-256.

The registration procedure for the PPP Authentication Algorithms registry (https://www.iana.org/assignments/ppp-numbers/ppp-numbers.xhtml#ppp-numbers-9) [iSCSI uses this by reference] is Expert Review, so we can submit the registration requests directly to IANA (e.g., don't need an Internet-Draft).  That said, I'd be happy to bring these requests to secdispatch in Singapore if there's a sense that more "eyes" should take a look at the requests (including the choice of algorithms) before the requests are submitted to IANA.

Thanks, --David
----------------------------------------------------------------
David L. Black, Senior Distinguished Engineer
Dell EMC, 176 South St., Hopkinton, MA  01748
+1 (774) 350-9323 New    Mobile: +1 (978) 394-7754
[email-masked]
----------------------------------------------------------------

> -----Original Message-----
> From: saag <[email-masked]> On Behalf Of Mark D. Baushke
> Sent: Wednesday, September 18, 2019 11:48 AM
> To: Maurizio Lombardi
> Cc: [email-masked]
> Subject: Re: [saag] Improving the CHAP protocol
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi Maurizio,
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 19 Sep 2019 06:11:41 -0400

Sent from my mobile device

> On Sep 18, 2019, at 3:31 PM, Black, David <[email-masked]> wrote:
> 
> Hi Mark,
> 

That shouldn’t be necessary, I should have looked at the registration policy.

Thank you,
Kathleen

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 21 Sep 2019 17:35:35 +0000

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.

Having said that, you'll have to accept that the vast majority of users will
keep going with MD5 more or less forever since there's no motive apart from
FIPS to change, so perhaps it'd be best to pitch the update RFC as "FIPS
compliance for CHAP" or something similar.

Peter.

---

From: Yoav Nir <[email-masked]>
Date: Sat, 21 Sep 2019 20:56:11 +0300

FIPS is one advantage. The other is that MD5 is getting scarce in crypto libraries, while SHA-256 is everywhere.  Not everything is devices — there’s still software out there.

But yes, it’s still CHAP.

> On 21 Sep 2019, at 20:35, Peter Gutmann <[email-masked]> wrote:
>

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 21 Sep 2019 18:04:14 +0000

Yoav Nir <[email-masked]> writes:

>FIPS is one advantage. The other is that MD5 is getting scarce in crypto
>libraries, while SHA-256 is everywhere.

Sure, and thus my argument to use SHA-256 and not something obscure.  As you
say, it's everywhere, so a switch is relatively straightforward.

Peter.

---

From: Alan DeKok <[email-masked]>
Date: Sun, 22 Sep 2019 09:51:18 -0400

> FIPS is one advantage. The other is that MD5 is getting scarce in crypto libraries, while SHA-256 is everywhere.  Not everything is devices — there’s still software out there.

  MD5 will be used forever.  As will MD4.  Crypto library authors can complain, but the market has spoken.

  Every end user device ships with support for CHAP (using MD5) and MS-CHAP (using MD4).  These protocols are widely used as part of 802.1X authentication.

  The EMU WG spent years standardizing TEAP (RFC 7170, May 2014), which is only getting implemented now (!).  That method could have forbidden the use of insecure methods such as EAP-MD5 (CHAP) or EAP-MSCHAPv2.  It did not.  Even if it had deprecated MD5 / MD4 methods, no one implemented TEAP.

  In the mean time, people have been using EAP-TTLS and PEAP as "de facto" standards.  Which use MS-CHAP and/or CHAP.  The use of MD5 / MD4 is inside of a TLS tunnel so it's not all bad.  But the usage still makes it difficult to remove MD5 / MD4 entirely.

  It may take 3 years to get a new standard which deprecates the use of MD4 / MD5 in authentication methods.  It will then take another 10 years before the new standard is wide-spread.  Only then can these insecure authentication methods be disabled on authentication servers.

  I see deprecating MD5 / MD4 as "pie in the sky" wishful thinking.  It's definitely *required*, but entirely *impractical*.  Crypto libraries *will* ship with them for the next 15 years.  If they are removed from crypto libraries, vendors will add their own MD5 / MD4 implementations to every end-user device.

  If we wanted to fix this, we should have been done it years ago.  Maybe we can start the process now.  But to be realistic, I will be in retirement long before MD5 / MD4 are removed from common usage.

  Alan DeKok.

---

From: John Mattsson <[email-masked]>
Date: Sun, 22 Sep 2019 16:44:06 +0000

Hi,

I fully agree that it should have been done a long time ago and that it will take a very long time to achieve. To me that just means we need to start as soon as possible.

When it comes to crypto profiling, IETF is often very slow and very focused on whether some system will continue the weak algorithms in questions. For an example take the otherwise excellent RFC 7525 that has several super soft statements like:

"Curves of less than 192 bits SHOULD NOT be used."

I have met several implementors in different companies that read "SHOULD NOT" as "NO REASON TO CHANGE ANYTHING".

I think IETF in general need to be much more pro-active when it comes forbidding weak algorithms and also use much more "MUST NOT".

Cheers,
John

-----Original Message-----
From: saag <[email-masked]> on behalf of Alan DeKok <[email-masked]>
Date: Sunday, 22 September 2019 at 15:51
To: Yoav Nir <[email-masked]>
Cc: Security Area Advisory Group <[email-masked]>
Subject: Re: [saag] Improving the CHAP protocol

    

    

    
      Alan DeKok.

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 22 Sep 2019 19:53:38 +0000

Alan DeKok <[email-masked]> writes:

>In the mean time, people have been using EAP-TTLS and PEAP as "de facto"
>standards.

Yup.  Doesn't matter how bad the auth protocol actually is because it's
tunneled over TLS everywhere where it matters.

>I see deprecating MD5 / MD4 as "pie in the sky" wishful thinking.  It's
>definitely *required*, but entirely *impractical*.

Definitely.  And that's why I proposed having the replacement RFC titled as
"FIPS compliance for CHAP", because moving to SHA-256 won't make it more
secure, it'll just make it more FIPS compliant.

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.  There's a rather nice mutual auth protocol from Kaufman, Perlman,
and Speciner which is something like:

Challenge ->
<- Enc( Challenge )
Enc( Response ->

using the universally-available AES, so the whole protocol is two crypt
operations on each side.  It's one more message than CHAP, but provides mutual
auth in the process.  Downside is that for low-entropy keys/authenticators
it's open to a brute-force attack, but it is a starting point.

Peter.

---

From: Maurizio Lombardi <[email-masked]>
Date: Mon, 23 Sep 2019 12:29:42 +0200

Hello Peter,

> 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

---

From: "Black, David" <[email-masked]>
Date: Mon, 23 Sep 2019 19:28:31 +0000

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.

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

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

> > nothing supports, which is most of the other stuff that's been suggested.

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

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

> From: saag <[email-masked]> On Behalf Of Maurizio Lombardi
> Sent: Monday, September 23, 2019 6:30 AM
> To: Peter Gutmann; [email-masked]

---

From: Alan DeKok <[email-masked]>
Date: Tue, 24 Sep 2019 09:52:06 -0400

On Sep 23, 2019, at 3:28 PM, Black, David <[email-masked]> wrote:
> 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).

  I don't see that as necessary.  It should be fine to use new methods with PPP.  Using the new methods in other protocols requires standards actions.  So by default they won't be used unless someone steps up to write those standards.

  Alan DeKok.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 24 Sep 2019 14:53:50 +0000

Black, David <[email-masked]> writes:

>The situation that we can't change is that iSCSI references the IANA PPP CHAP
>registry for CHAP hash algorithms.

So would the simplest solution then be just to add SHA-256 to the registry?

Peter.

---

From: "Black, David" <[email-masked]>
Date: Wed, 25 Sep 2019 17:03:47 +0000

Yes, and SHA3-256  while we're in there ... I plan to submit the request to IANA to do that by early next week.

Thanks, --David

> From: Peter Gutmann <[email-masked]>
> Sent: Tuesday, September 24, 2019 10:54 AM
> To: Black, David; [email-masked]
> Cc: Maurizio Lombardi

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 25 Sep 2019 17:19:47 +0000

Just do one.

On 9/25/19, 1:05 PM, "Black, David" <[email-masked]> wrote:

    Thanks, --David

---

From: Jim Schaad <[email-masked]>
Date: Wed, 25 Sep 2019 10:35:13 -0700

If you do that, I don't know if you want SHA3-256 or SHAKE.  SHAKE seems to
be used more from what I have seen so far.

Jim

-----Original Message-----
From: saag <[email-masked]> On Behalf Of Black, David
Sent: Wednesday, September 25, 2019 10:04 AM
To: Peter Gutmann <[email-masked]>; [email-masked]
Subject: Re: [saag] Improving the CHAP protocol

Yes, and SHA3-256  while we're in there ... I plan to submit the request to
IANA to do that by early next week.

Thanks, --David

> >The situation that we can't change is that iSCSI references the IANA 
> >PPP CHAP registry for CHAP hash algorithms.
>

---

From: "Black, David" <[email-masked]>
Date: Wed, 25 Sep 2019 18:07:54 +0000

I strongly prefer two, as none of the current hashes in the registry (MD5, SHA1) ought to be used for new development, so registering two good hashes would provide a fallback just in case unexpected crypto progress occurs in attacks on SHA2 or SHA3.

Thanks, --David

> From: Jim Schaad <[email-masked]>
> Sent: Wednesday, September 25, 2019 1:35 PM
> Subject: RE: [saag] Improving the CHAP protocol
> 
> 
> [EXTERNAL EMAIL]
>

---

From: "Mark D. Baushke" <[email-masked]>
Date: Wed, 25 Sep 2019 12:11:09 -0700

Jim Schaad <[email-masked]> writes:

> If you do that, I don't know if you want SHA3-256 or SHAKE. SHAKE
> seems to be used more from what I have seen so far.

I think SHAKE256 is the better entry in my opinion if you want something
for the future.

I believe you will find implementations in popular crypto libraries
(provided in alphabetical order) such as Bouncy Castle, Crypto++,
Libgcrypt, and OpenSSL.

	-- Mark

---

From: John Mattsson <[email-masked]>
Date: Thu, 26 Sep 2019 07:45:24 +0000

I would also prefer SHAKE compared to SHA3-256. I think SHAKE128 offer enough security for the foreseeable future, but just SHAKE256 may be better if we want a single algorithm to fulfil 256-bit security requirements from e.g. governments. Do/will any constrained IoT devices use CHAP? Then their requirements should be taken into account.

/John

-----Original Message-----
From: saag <[email-masked]> on behalf of "Mark D. Baushke" <mdb=[email-masked]>
Date: Wednesday, 25 September 2019 at 21:11
To: Jim Schaad <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [saag] Improving the CHAP protocol

    

    	-- Mark