EAP-pwd and NT-Password
I am looking at testing EAP-pwd [^1] as an alternative to PEAP for wireless authentication. The documentation in FreeRADIUS is unclear as to what authorization attributes are required, but digging into the source it appears to be a cleartext password: pw = fr_pair_find_by_num(fake->control, 0, PW_CLEARTEXT_PASSWORD, TAG_ANY); if (!pw) { REDEBUG("Failed to find password for %s to do pwd authentication", session->peer_id); talloc_free(fake); return RLM_MODULE_REJECT; } Now, RFC 5931 offers three options, and one of them is to use the MSCHAPv2 password hash: " o RFC 2759: The input password string SHALL be processed to produce the output PasswordHashHash, as defined in [RFC2759] ... The Prep field represents the password pre-processing technique (see Section 2.7.2) to be used by the client prior to generating the password seed (see Section 2.8.3). This document defines the following values for the Prep field: o 0x00 : None o 0x01 : RFC2759 o 0x02 : SASLprep" This would be *really* convenient, as then I could use the control:NT-Password that I already use for PEAP. (The user database is FreeIPA and doesn't store cleartext passwords, but does have the NT hash) I see the "prep" field and constant definitions are in the source, e.g. EAP_PWD_PREP_MS, but the code appears to be fixed to EAP_PWD_PREP_NONE at the moment. Is this something which has already been considered? Thanks, Brian Candler. [^1] It seems that EAP-pwd and EAP-EKE have the same goal, of doing strong mutual authentication with a password. I haven't been able to find any comparison of the strengths and weaknesses of these protocols. But EAP-pwd has the advantage of being deployable: it's supported by Android and by FreeRADIUS.
On Oct 6, 2016, at 11:39 AM, Brian Candler <b.candler@pobox.com> wrote:
I am looking at testing EAP-pwd [^1] as an alternative to PEAP for wireless authentication.
The documentation in FreeRADIUS is unclear as to what authorization attributes are required, but digging into the source it appears to be a cleartext password:
Yes.
Now, RFC 5931 offers three options, and one of them is to use the MSCHAPv2 password hash:
" o RFC 2759: The input password string SHALL be processed to produce the output PasswordHashHash, as defined in [RFC2759]
Yes. That isn't implemented.
This would be *really* convenient, as then I could use the control:NT-Password that I already use for PEAP. (The user database is FreeIPA and doesn't store cleartext passwords, but does have the NT hash)
I see the "prep" field and constant definitions are in the source, e.g. EAP_PWD_PREP_MS, but the code appears to be fixed to EAP_PWD_PREP_NONE at the moment.
Is this something which has already been considered?
Not yet. Mostly due to time.
[^1] It seems that EAP-pwd and EAP-EKE have the same goal, of doing strong mutual authentication with a password. I haven't been able to find any comparison of the strengths and weaknesses of these protocols. But EAP-pwd has the advantage of being deployable: it's supported by Android and by FreeRADIUS.
We should have EAP-EKE in v4 some time soon... Alan DeKok.
On 06/10/2016 17:03, Alan DeKok wrote:
I see the "prep" field and constant definitions are in the source, e.g. EAP_PWD_PREP_MS, but the code appears to be fixed to EAP_PWD_PREP_NONE at the moment.
Is this something which has already been considered? Not yet. Mostly due to time.
The patch looked to be pretty simple, here for v3.0.x: https://github.com/candlerb/freeradius-server/commit/ab8ac5c643bad3d5b328f7a... However, when testing with my phone (Android 5.1): it is able to EAP-pwd authenticate with a cleartext password: steve Cleartext-Password := "testing" but not when using the MS hash: steve NT-Password := 0x7c53cfa5ea7d0f9b3b968aa0fb51a3f5 (Note: radtest -t mschap ... localhost:18120 works fine, so I'm pretty sure that NT password is correct and usable) As far as I can tell from the log, the Android phone is abandoning the exchange when challenged. Possibly the Android supplicant doesn't support performing the MS hash of the password - which if true, would make this not very useful :-( A Mac (OSX 10.11.6) doesn't seem to be able to do EAP-pwd at all. I only have an old (ubuntu 14.04) laptop lying around, which also doesn't do EAP-pwd. So even though I *think* this patch is doing the right thing, I can't actually prove it right now. Maybe I should try to force FreeIPA to store cleartext passwords - but it looks like they've intentionally disabled that or made it very difficult. An NT hash is just a cleartext password by another name; they allow you to store that, but not a real cleartext password :-(
[^1] It seems that EAP-pwd and EAP-EKE have the same goal, of doing strong mutual authentication with a password. I haven't been able to find any comparison of the strengths and weaknesses of these protocols. But EAP-pwd has the advantage of being deployable: it's supported by Android and by FreeRADIUS. We should have EAP-EKE in v4 some time soon... Sounds good.
Do you happen to know if EAP-pwd has any important weaknesses which would make EAP-EKE preferable? Regards, Brian.
Hi Brian! Dan Harkins (one of the authors of RFC 5931) is currently working on reference implementations for https://tools.ietf.org/html/draft-harkins-salted-eap-pwd-00 for wpa_supplicant and hostapd which should bring full support for salted and hashed passwords. He also talked about a reference implementation for FreeRADIUS so that should be good news.
However, when testing with my phone (Android 5.1): it is able to EAP-pwd authenticate with a cleartext password:
steve Cleartext-Password := "testing"
but not when using the MS hash:
steve NT-Password := 0x7c53cfa5ea7d0f9b3b968aa0fb51a3f5 It's very likely that wpa_supplicant currently can't deal with this. But I'm not entirely sure what the exact current status of the implementation is.
A Mac (OSX 10.11.6) doesn't seem to be able to do EAP-pwd at all. I only have an old (ubuntu 14.04) laptop lying around, which also doesn't do EAP-pwd. macOS doesn't support EAP-PWD, same goes for iOS (current versions). However, Linux does support it, so does Android. There's also a plugin (it's not a whole supplicant) for the Windows 802.1x stack that supports EAP-PWD (it's included in the eduroam CAT (cat.eduroam.org) and it's provided by Aruba / HP Enterprise). However, I'm not sure what the licensing terms for this plugin are and I'm not aware of an official download link.
Do you happen to know if EAP-pwd has any important weaknesses which would make EAP-EKE preferable? Theoretically, EAP-PWD should be quite robust because it should be immune to the most common attack vectors (see RFC 5931, section 1.3). Dan Harkins is author of the IKE RFC and it's very likely that with his experiences he did a thorough design. Looking at RFC 5931 at least convinced us that it's a secure protocol. But I'm by no means an expert, please don't take my word for it. :) We've been using EAP-PWD for eduroam with Android devices for about half a year now (and we'll be starting to use it for Linux and Windows soon) and we're very happy with it, especially because we can stop juggling with X.509 certs and also because the amount of RADIUS packets that are exchanged for EAP-PWD is much less than for PEAP + MSCHAPv2. This makes it nicer to use in roaming situations.
Kind regards, Christian Strauf -- Dipl.-Math. Christian Strauf Clausthal Univ. of Technology E-Mail: strauf@rz.tu-clausthal.de Rechenzentrum Web: www.rz.tu-clausthal.de Erzstraße 51 Tel.: +49-5323-72-2086 Fax: -992086 D-38678 Clausthal-Zellerfeld
On 06/10/2016 20:09, Brian Candler wrote:
However, when testing with my phone (Android 5.1): it is able to EAP-pwd authenticate with a cleartext password:
steve Cleartext-Password := "testing"
but not when using the MS hash:
steve NT-Password := 0x7c53cfa5ea7d0f9b3b968aa0fb51a3f5
I've been testing this with Linux, and there's lots of brokenness out there. * wpa_supplicant 2.4 does EAP-pwd, but only with PREP_NONE * wpa_supplicant 2.5 does EAP-pwd with PREP_MS (according to the source code). And there is 2.6 too. * Ubuntu 16.04 comes with wpa_supplicant 2.4 * Debian Stretch (alpha 7) includes package wpasupplicant "2.5-2+v2.4-3", which is also 2.4 (confirmed with -v) Its network GUI does however offer PWD, it does generate EAP exchanges to my test RADIUS server, and it connects if I have the Cleartext-Password in the RADIUS server. * Fedora 24 has wpa_supplicant 2.5, and runs from a live CD. However its network config GUI is broken. You can select PWD when you first connect to a network, but nothing happens (I see no radius request from the AP); and when you edit the network security settings, PWD is not included in the list of options at all. * Fedora 25 (alpha 2) also has wpa_supplicant 2.5, and its GUI appears to be identically broken Still on Fedora 25 alpha, I tried configuring wpa_supplicant manually: ---- ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=wheel network={ ssid="RADAUTH" key_mgmt=WPA-EAP proto=WPA2 pairwise=CCMP group=CCMP eap=PWD identity="steve" password="testing" } ---- Result: /usr/sbin/wpa_supplicant -c wpa_supplicant.conf -i wlp3s0 -Dnl80211 ... Line 10: unknown EAP method 'PWD' You may need to add support for this EAP method during wpa_supplicant build time configuration Ah - so they didn't even compile the EAP-pwd functionality. (Same answer with either "pwd" or "PWD") So then I built wpa_supplicant 2.6 from source, back on Ubuntu 16.04 now, and run with the config above. It still works with Cleartext-Password, but with NT-Password I get at the supplicant side: EAP-PWD (peer): confirm did not verify wlp3s0: CTRL-EVENT-EAP-FAILURE EAP authentication failed and hence the supplicant abandons the exchange. So it looks like I'm doing something wrong here. Hmm: back to RFC 5931 - it refers to "PasswordHashHash" from RFC 2759. And: 8.3. NtPasswordHash() NtPasswordHash( IN 0-to-256-unicode-char Password, OUT 16-octet PasswordHash ) { /* * Use the MD4 algorithm [5] to irreversibly hash Password * into PasswordHash. Only the password is hashed without * including any terminating 0. */ } 8.4. HashNtPasswordHash() HashNtPasswordHash( IN 16-octet PasswordHash, OUT 16-octet PasswordHashHash ) { /* * Use the MD4 algorithm [5] to irreversibly hash * PasswordHash into PasswordHashHash. */ } Ah - so maybe Control:NT-Password is "NtPasswordHash" which means it needs running through another iteration of MD4. I'll try that. Regards, Brian.
On 07/10/2016 15:30, Brian Candler wrote:
Ah - so maybe Control:NT-Password is "NtPasswordHash" which means it needs running through another iteration of MD4. I'll try that.
In the end, I got it working. As well as the additional level of hashing: - I wasn't sending the correct password prep type in the initial message. I now made this a module-level configuration. - there was a bug in wpa_supplicant 2.6 where it was always sending back PREP_NONE even if the server asked for PREP_MS With those changes, it works. There is a proof-of-concept patch at: https://github.com/FreeRADIUS/freeradius-server/commit/105968ddaac0c2f259ead... but it needs extending to work with PREP_MS and CLEARTEXT_PASSWORD (it has to convert to UTF16LE and then hash twice) The fix to wpa_supplicant 2.6 is below. Regards, Brian. --- ./src/eap_peer/eap_pwd.c.orig 2016-10-02 19:51:11.000000000 +0100 +++ ./src/eap_peer/eap_pwd.c 2016-10-07 18:01:33.092325628 +0100 @@ -345,7 +345,7 @@ wpabuf_put_u8(data->outbuf, EAP_PWD_DEFAULT_RAND_FUNC); wpabuf_put_u8(data->outbuf, EAP_PWD_DEFAULT_PRF); wpabuf_put_data(data->outbuf, id->token, sizeof(id->token)); - wpabuf_put_u8(data->outbuf, EAP_PWD_PREP_NONE); + wpabuf_put_u8(data->outbuf, id->prep); wpabuf_put_data(data->outbuf, data->id_peer, data->id_peer_len); eap_pwd_state(data, PWD_Commit_Req);
participants (3)
-
Alan DeKok -
Brian Candler -
Christian Strauf