1

We have deployed Radius server ( Freeradius 3.x ) and connected it to our LDAP database (ForgeRock OpenDJ).

We have successfully configured EAP-TTLS with valid certificates and set it as default connection method. ( almost all other settings are left to default)

However when EAP-TTLS is established, the password is transferred using PAP. I am no network expert but I have read that PAP is not secured and shouldn't be used? (I feel like there is lot of confusing material online)

If I try to log in using any other such as MS-CHAPv2 it fails with various error:

 FAILED: No NT/LM-Password.  Cannot perform authentication'

or

freeradius_1  | (22) eap_md5: ERROR: Cleartext-Password is required for EAP-MD5 authentication

It obviously requires additional configuration.

The question is, is it OK to us PAP when we have EAP-TTLS as of 2019? Or should we look into setting different type as default?

Our LDAP has the passwords hashed (obviously) so do we even have another option? Based on this document which I have found, it seems this is our only option.

2

EAP-TTLS protocol layering diagram

In this instance, provided the certificate presented by the server is validated correctly by the supplicant, confidentiality (protection against snooping) and integrity (protection against modification), are provided by EAP-TLS/TLS.

The key thing here is that the server's certificate is validated correctly. If it's not, then an attacker can set up a honeypot network, present a fake certificate to the supplicant, and harvest the plaintext credentials.

Any organisation serious about security will either implement EAP-TLS (negating the need for a password) or run a dissolvable installer (SecureW2, Cloudpath, eduroamCAT - If this is for eduroam) on their wireless clients to configure the 802.1X authentication settings correctly.

Last time I checked Windows 10, in particular, didn't implement any sort of certificate/SSID pinning, so indicating you trusted the server's cert during the initial authentication attempt didn't actually add any security. For subsequent auth attempts with a different cert, the supplicant would happily present you with the fingerprint of the new certificate without any indication of the mismatch. The only way to fix this is to explicitly set the certificate validation settings (trusted CAs, expected subject name pattern) for the wireless network, either manually or with a dissolvable installer (as mentioned above).

To answer your other question about which TTLS/PEAP inner methods will work with LDAP, if you're using LDAPv3 authenticated binds to authenticate the user, then yes, only PAP or GTC (See PEAPv0/GTC) will work. They both operate in pretty much the same way.

If you're pulling back hashes and doing the comparison locally on the RADIUS server, and store the NT-Password hash of the user's password as well as whatever other hash you're using, then this allows you to do MSCHAPv2.

Honestly, though, the NT-Passwords use extremely weak hashing (MD4), so it's almost as bad as storing cleartext in OpenLDAP. You need to weigh the likelihood of your OpenLDAP installation being compromised, and the risk of all the hashes being stolen/cracked, and the likelihood of someone mounting a MITM attack, and the risk of a subset of passwords being stolen.

As a final note, If you're using EAP-PWD there is some limited support for using hashed copies of the password on both the Supplicant and RADIUS server but this EAP method is not widely supported outside of Linux environments.

I'm pretty dissatisfied with the situation TBH, but getting everyone to adopt a new EAP-Method would require a significant effort from multiple vendors.

The only thing that's implementable on the FreeRADIUS side, is to setup 'spot checks' on cert validation settings, and remediate any users that fail them. How you can do this is by dynamically swapping out the certificate presented to the supplicant with an invalid one, and verifying that the supplicant returns the correct alert (invalid_ca) to the RADIUS server. This will cause an authentication failure (if everything works correctly), but supplicants will also retry fairly quickly, so as long as the spot checks are fairly infrequent it's not too big of a deal.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.