eap-mschapv2: allow using on kernels without CRYPTO_MD4, and deprecate

Commit Message

Dimitri John Ledkov Oct. 14, 2023, 11:54 p.m. UTC

Currently eap-mschapv2 does kernel MD4 check during init time, even
though it is possible to use it with Password-Hash on kernels without
MD4.

Separately, mschapv2 is obsolete, deprecated, and removed even in
Windows 11 22H2 [1][2]. Add an error message stating so encouraging
migration to PEAP-TLS or EAP-TLS. Separately, warnings like these often
don't work, thus likely need to remove this authentication method
completely.

IWD usage of MD4 was brought up on linux-crypto mailing list [3], upon
my attempt to remove CRYPTO_MD4 from the kernel which is no longer used
via crypto API by anything else.

It worries me that internet searches suggest that EDUROAM (a Wi-FI
network spanning 106 territories) seems to still often use
mschapv2. Thus dropping this support may leave millions of people
without connectivity. Given how broken and isecure this authentication
method has been since 2012, I hope that EDUROAM is migrating, or has
migrated to P/EAP-TLS.

[1] https://learn.microsoft.com/en-us/security-updates/securityadvisories/2012/2743314
[2] https://learn.microsoft.com/en-us/windows/security/identity-protection/credential-guard/considerations-known-issues
[3] https://lore.kernel.org/linux-crypto/[e-mail]/
---
 src/eap-mschapv2.c | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

Comments

Denis Kenzior Oct. 16, 2023, 7:45 p.m. UTC | #1

Hi Dimitri,

On 10/14/23 18:54, Dimitri John Ledkov wrote:
> Currently eap-mschapv2 does kernel MD4 check during init time, even
> though it is possible to use it with Password-Hash on kernels without
> MD4.

While this is true, I doubt many users actually use this setting.

> 
> Separately, mschapv2 is obsolete, deprecated, and removed even in
> Windows 11 22H2 [1][2]. Add an error message stating so encouraging
> migration to PEAP-TLS or EAP-TLS. Separately, warnings like these often
> don't work, thus likely need to remove this authentication method
> completely.

Hmm, from this description I think you misunderstand how MSCHAPv2 is used. 
Indeed, just using MSCHAPv2 as the outer authentication protocol in EAP is 
broken.  However, nobody actually uses it this way.  In other words, while 
EAP-MSCHAPv2 does exist, it isn't actually used.

However, EAP-PEAP mandates the use of MSCHAPv2 as the inner authentication 
method inside the outer TLS tunnel. "Migration to PEAP-TLS" already happened, 
but that doesn't mean that MSCHAPv2 isn't used.

> 
> IWD usage of MD4 was brought up on linux-crypto mailing list [3], upon
> my attempt to remove CRYPTO_MD4 from the kernel which is no longer used
> via crypto API by anything else.
> 
> It worries me that internet searches suggest that EDUROAM (a Wi-FI
> network spanning 106 territories) seems to still often use
> mschapv2. Thus dropping this support may leave millions of people
> without connectivity. Given how broken and isecure this authentication
> method has been since 2012, I hope that EDUROAM is migrating, or has
> migrated to P/EAP-TLS.

Yes, exactly.  See above. What this patch accomplishes is breaking EAP-PEAP 
support in iwd :)

Regards,
-Denis

Dimitri John Ledkov Oct. 18, 2023, 4:28 p.m. UTC | #2

On Mon, 16 Oct 2023, 20:46 Denis Kenzior, <[e-mail]> wrote:
>
> Hi Dimitri,
>
> On 10/14/23 18:54, Dimitri John Ledkov wrote:
> > Currently eap-mschapv2 does kernel MD4 check during init time, even
> > though it is possible to use it with Password-Hash on kernels without
> > MD4.
>
> While this is true, I doubt many users actually use this setting.


Ok. :-(



>
> >
> > Separately, mschapv2 is obsolete, deprecated, and removed even in
> > Windows 11 22H2 [1][2]. Add an error message stating so encouraging
> > migration to PEAP-TLS or EAP-TLS. Separately, warnings like these often
> > don't work, thus likely need to remove this authentication method
> > completely.
>
> Hmm, from this description I think you misunderstand how MSCHAPv2 is used.
> Indeed, just using MSCHAPv2 as the outer authentication protocol in EAP is
> broken.  However, nobody actually uses it this way.  In other words, while
> EAP-MSCHAPv2 does exist, it isn't actually used.
>
> However, EAP-PEAP mandates the use of MSCHAPv2 as the inner authentication
> method inside the outer TLS tunnel. "Migration to PEAP-TLS" already happened,
> but that doesn't mean that MSCHAPv2 isn't used.


Sadness.

But also how does the outer TLS tunnel help all the way? Remote site
people sure, but do people enforce using outer TLS tunnels like
internal inside the office network? As in can employees sniff each
others traffic and still impersonate each other? Meaning this
authentication method is still more or less a fig leaf.

>
> >
> > IWD usage of MD4 was brought up on linux-crypto mailing list [3], upon
> > my attempt to remove CRYPTO_MD4 from the kernel which is no longer used
> > via crypto API by anything else.
> >
> > It worries me that internet searches suggest that EDUROAM (a Wi-FI
> > network spanning 106 territories) seems to still often use
> > mschapv2. Thus dropping this support may leave millions of people
> > without connectivity. Given how broken and isecure this authentication
> > method has been since 2012, I hope that EDUROAM is migrating, or has
> > migrated to P/EAP-TLS.
>
> Yes, exactly.  See above. What this patch accomplishes is breaking EAP-PEAP
> support in iwd :)

Booo!

Ok, I still want to drop md4 from the kernel though. Because the
number of users that need this is small, and I would rather compile in
static MD4 implementation in IWD than to carry a kernel config that
builds and turns it all for all.

It seems in Ubuntu we have never had SRU of IWD yet, and we build
multiple kernels every two weeks, meaning on that basis alone
compiling MD4 in IWD versus kernels will save energy costs.

>
> Regards,
> -Denis

Denis Kenzior Oct. 19, 2023, 2:54 a.m. UTC | #3

Hi Dimitri,

> 
> But also how does the outer TLS tunnel help all the way? Remote site
> people sure, but do people enforce using outer TLS tunnels like
> internal inside the office network? As in can employees sniff each
> others traffic and still impersonate each other? Meaning this
> authentication method is still more or less a fig leaf.

The outer TLS tunnel is mandatory for PEAP/TTLS and is very secure, assuming a 
well configured system.  This means that the station (client) side has a CA 
Certificate it can use to validate the AP.  If public CAs are being used, then 
security can be further enhanced by using ServerDomainMask setting.

Think of EAP-PEAP or EAP-TTLS as username/password authentication within HTTPS. 
Its just that EAP-PEAP uses MSCHAPv2(MD4) or EAP-MD5 and EAP-TTLS uses 
MSCHAP(DES)/ MSCHAPv2(MD4), CHAP(MD5), PAP(cleartext).

How the network is configured at the AP is not really our problem.  There are 
ways to separate all clients on the AP from each other via vlans, etc.

>>
>> Yes, exactly.  See above. What this patch accomplishes is breaking EAP-PEAP
>> support in iwd :)
> 
> Booo!
> 
> Ok, I still want to drop md4 from the kernel though. Because the
> number of users that need this is small, and I would rather compile in
> static MD4 implementation in IWD than to carry a kernel config that
> builds and turns it all for all.

Well, you're going to keep coming back and making this argument for DES, MD4, 
MD5, etc.  I don't think it makes sense for iwd to go down that path.  While 
these crypto functions are old and insecure by themselves, they're still being 
used in a secure way.

> 
> It seems in Ubuntu we have never had SRU of IWD yet, and we build
> multiple kernels every two weeks, meaning on that basis alone
> compiling MD4 in IWD versus kernels will save energy costs.

Wasn't Ubuntu going to switch to iwd at some point?

Regards,
-Denis

Dimitri John Ledkov Oct. 21, 2023, 12:33 a.m. UTC | #4

On Thu, 19 Oct 2023 at 03:54, Denis Kenzior <[e-mail]> wrote:
>
> Hi Dimitri,
>
> >
> > But also how does the outer TLS tunnel help all the way? Remote site
> > people sure, but do people enforce using outer TLS tunnels like
> > internal inside the office network? As in can employees sniff each
> > others traffic and still impersonate each other? Meaning this
> > authentication method is still more or less a fig leaf.
>
> The outer TLS tunnel is mandatory for PEAP/TTLS and is very secure, assuming a
> well configured system.  This means that the station (client) side has a CA
> Certificate it can use to validate the AP.  If public CAs are being used, then
> security can be further enhanced by using ServerDomainMask setting.
>
> Think of EAP-PEAP or EAP-TTLS as username/password authentication within HTTPS.
> Its just that EAP-PEAP uses MSCHAPv2(MD4) or EAP-MD5 and EAP-TTLS uses
> MSCHAP(DES)/ MSCHAPv2(MD4), CHAP(MD5), PAP(cleartext).
>
> How the network is configured at the AP is not really our problem.  There are
> ways to separate all clients on the AP from each other via vlans, etc.
>

Ack.

> >>
> >> Yes, exactly.  See above. What this patch accomplishes is breaking EAP-PEAP
> >> support in iwd :)
> >
> > Booo!
> >
> > Ok, I still want to drop md4 from the kernel though. Because the
> > number of users that need this is small, and I would rather compile in
> > static MD4 implementation in IWD than to carry a kernel config that
> > builds and turns it all for all.
>
> Well, you're going to keep coming back and making this argument for DES, MD4,
> MD5, etc.

YES! iwd is right to use crypto code that is in use and provided by
the kernel. But it may not hold up removal of unused dead-code from
the kernel. This is true for any API / Drivers that the kernel has.
Even stuff like network-manager/wpa_supplicant is at the mercy of
openssl legacy providers to be installed and/or enabled on the systems
to get access to those things on regular systems.

And all of these things are optional in the kernel, so IWD already
cannot do this authentication method on any kernels that disable MD4.
Which I will propose for the Ubuntu kernel to disable.

 > I don't think it makes sense for iwd to go down that path.  While
> these crypto functions are old and insecure by themselves, they're still being
> used in a secure way.

The way IWD does it, potentially so, without verifying (or ability to
verify) that the network is setup that way. And the exposure risk is
high and different. Having md4 available in the crypto API allows for
md4 to trivially be used in insecure ways.

The number of IWD users is far less than the total number of kernel
installations. And even among IWD users / a number of networks out
there, this authentication method is popular but with a limited number
of users that is diminishing.

>
> >
> > It seems in Ubuntu we have never had SRU of IWD yet, and we build
> > multiple kernels every two weeks, meaning on that basis alone
> > compiling MD4 in IWD versus kernels will save energy costs.
>
> Wasn't Ubuntu going to switch to iwd at some point?

We did userstudy during peak covid pandemic to consider changing
NetworkManager backend from wpa_supplicant to iwd, whilst keeping
UX/UI/GUI/Configuration via NetworkManager and/or netplan.io

The results and comments over here
https://discourse.ubuntu.com/t/call-for-testing-improved-wifi-via-iwd/17795
and also https://bugs.launchpad.net/ubuntu/+source/iwd

There were improvements for many, but also connectivity regressions
for some - most notably seemingly failing to configure and use
eap-mschapv2 via NetworkManager GUI, or keep existing configuration
working after the switch. I personally do not have eduroam access,
thus cannot retest if this is now working on more recent releases of
Ubuntu / NetworkManager / IWD or not.

Emil Velikov Oct. 24, 2023, 10:26 p.m. UTC | #5

Hello Dmitry, all,

On Sat, 21 Oct 2023 at 01:34, Dimitri John Ledkov
<[e-mail]> wrote:>
> On Thu, 19 Oct 2023 at 03:54, Denis Kenzior <[e-mail]> wrote:

> > Wasn't Ubuntu going to switch to iwd at some point?
>

Was interested in the same question, only to see the somewhat familiar
struggles. Namely, we've battled similar dragons with the SteamDeck so
I thought I'd share the tricks we used.

>... most notably seemingly failing to configure and use
> eap-mschapv2 via NetworkManager GUI,

My debugging over one years ago, indicated that NM was correctly
creating the iwd profile for enterprisy networks, then attempting a
connection _only_ if iwd would advertise it as KnownNetwork.

Which in itself is inherently racy with NM running multiple threads
and communicating with iwd via d-bus. For use I removed that code, so
that NM would issue a connect and if iwd fails with
AlreadyProvisioned, it would then retry to connect with
the-flag-I-do-no-remember-the-name-of flipped.

There was an upstream NM merge request for that, although the
maintainer added additional checking, which only increased the
(re)connection delay without improving the success rate in our tests.

> ... or keep existing configuration
> working after the switch.

The problematic cases we've observed had extra tokens from the
wpa-supplicant based connection profiles. So you can try removing the
following:
mac-address interface-name permissions bssid

In addition, we pruned all files in /var/lib/NetworkManager/

HTH
Emil

Patch

diff --git a/src/eap-mschapv2.c b/src/eap-mschapv2.c
index ef0ce620a8..4f4739717a 100644
--- a/src/eap-mschapv2.c
+++ b/src/eap-mschapv2.c
@@ -437,6 +437,8 @@  static int eap_mschapv2_check_settings(struct l_settings *settings,
 	int r = 0;
 	size_t hash_len;
 
+	l_error("EAP_MSCHAPv2: Obsolete, please switch to P/EAP-TLS");
+
 	snprintf(setting, sizeof(setting), "%sIdentity", prefix);
 	identity = l_settings_get_string(settings, "Security", setting);
 
@@ -479,8 +481,14 @@  static int eap_mschapv2_check_settings(struct l_settings *settings,
 		}
 
 		return 0;
-	} else if (password)
+	} else if (password) {
+		if (!l_checksum_is_supported(L_CHECKSUM_MD4, false)) {
+			l_warn("EAP_MSCHAPv2: Obsolete MD4 not found");
+			l_warn("Please use Password-Hash instead of Password");
+			return -EINVAL;
+		}
 		goto validate;
+	}
 
 	secret = l_queue_find(secrets, eap_secret_info_match, setting2);
 	if (!secret) {
@@ -561,13 +569,6 @@  static struct eap_method eap_mschapv2 = {
 static int eap_mschapv2_init(void)
 {
 	l_debug("");
-
-	if (!l_checksum_is_supported(L_CHECKSUM_MD4, false)) {
-		l_warn("EAP_MSCHAPv2 init: MD4 support not found, skipping");
-		l_warn("Ensure that CONFIG_CRYPTO_MD4 is enabled");
-		return -ENOTSUP;
-	}
-
 	return eap_register_method(&eap_mschapv2);
 }