In order for RADIUS authentication to work, user passwords need to be stored in a format that is understood by the authentication protocol used by the client. Unfortunately, not all protocols work with all password storage formats. This can be especially problematic with platforms that use proprietary formats or protocols.
There are many protocols carried inside of RADIUS. They include PAP, CHAP, MS-CHAP, EAP, and a host of additional attributes.
Passwords may be stored in a DB in many forms. Clear-text, MD5 hashed, crypt’d, NT hash, or other methods are all commonly used.
Authentication protocols used in RADIUS are not always compatible with the way the passwords have been stored. The following table shows which protocol is compatible with what kind of password.
Clear-text | NT hash | MD5 hash | Salted MD5 hash | SHA1 hash | Unix Crypt | |
---|---|---|---|---|---|---|
PAP | ||||||
CHAP | ||||||
Digest | ||||||
MS-CHAP | ||||||
PEAP | ||||||
EAP-MSCHAPv2 | ||||||
Cisco LEAP | ||||||
EAP-GTC | ||||||
EAP-MD5 | ||||||
EAP-SIM |
Notes
For EAP-TTLS, EAP-FAST and EAP-TEAP look up the tunneled protocol in the above table. For the purposes of this table, the tunneled session is just another RADIUS authentication request. So for EAP-TTLS, with tunneled PAP, look up PAP in the above table.
Similarly, PEAP normally contains EAP-MSCHAPv2 in the tunneled session, so its row in the table is identical to the EAP-MSCHAPv2 row, which is in turn identical to the MS-CHAP row.
EAP-TLS, EAP-SIM, EAP-AKA and EAP-AKA’ are not mentioned in the above table as they do not use password based credentials. EAP-TLS relies on digital certificates, whilst EAP-SIM uses SIM triplets, and EAP-AKA[’] uses AKA quintuplets.
EAP-PWD supports many more salted hashing schemes than listed above, see RFC8146 for more details.
Gotcha’s
In our experience, many system administrators store passwords in their databases in hashed or encrypted form. They later decide that they need to support an authentication protocol that the above table shows is incompatible with their password storage method.
They then ask:
How can I make authentication protocol X work with passwords stored as Y?
The short answer is:
You can’t.
The incompatibility between the storage format and the protocol is usually intentional by the creators, and there isn’t a magic setting or configuration that will make them play nicely together.
When a storage format is not compatible with a given protocol, you have three choices:
1) Change the authentication protocol you are using to something that is compatible with the storage format
2) Change the password storage format in the database. Unfortunately, this strategy often requires all users to change their passwords.
3) Use an intermediary (such as Samba) to communicate between the database and the authentication client. This is the approach we recommend when Active Directory is used for password storage.
Need more help?
Network RADIUS has been helping clients around the world design and deploy their RADIUS infrastructure for 20 years. We specialize in complex systems and have seen pretty much every variation and problem out there. If you want help from the people who wrote FreeRADIUS, contact us for a customized quote.