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.