Log InChoosing an authentication protocol is one of the most important decisions when designing a RADIUS ecosystem.
There are a variety of authentication protocols to choose from, each with their own set of advantages, disadvantages, and constraints. In general, we recommend using PAP whenever possible. It is compatible with all known back-end databases, and it has no known security issues.
This article outlines the most common authentication protocols, how they work, and the implications of using them.
When evaluating authentication protocols, you should consider criteria such as:
- How secure is the authentication protocol?
- Will this authentication protocol be compatible with how passwords are stored in the database?
- Is this authentication protocol able to handle multi-factor authentication?
Overall, PAP performs the best for all of these criteria.
How does PAP authentication work?
RADIUS provides for PAP authentication, in which the RADIUS client sends a clear-text password to the RADIUS server. This clear-text password is encrypted in transit. Despite nearly three decades of analysis, there have been no vulnerabilities found with this encryption.
The benefit of PAP authentication is that the clear-text password is compatible with all password “encryption” methods, databases, and other back-ends. The RADIUS server can use the password in whatever way it needs in order to validate the credentials. For example using LDAP “bind as user” to “log in” to the LDAP server as the user. If the login is successful, the RADIUS server returns “accept”, otherwise it returns “reject”.
The only security issue with PAP is that the RADIUS server sees this password. If the RADIUS server is compromised, then the passwords may “leak”. However, if the RADIUS server is compromised, then leaking passwords is only a small proportion of bad things which can happen. In general we recommend using PAP as much as possible. It is secure, and compatible with everything.
And before anyone says “PAP is insecure”, it’s really not. The reason why is best left as the subject for another article. Just be sure to have a strong shared secert, and leave it at that. Something like secret is bad. Ddq9Dn^bjf82bH8b is better.
How does CHAP authentication work?
RADIUS also supports CHAP authentication. In this authentication method, the RADIUS client calculates a MD5 hash of a random challenge, and the user’s password. Both the challenge and password are sent to the RADIUS server.
The RADIUS server then obtains the user’s clear-text password from a database. The server then performs the same MD5 hash of the random challenge and the clear-text password. If the two hashes are identical, then the password entered by the user is correct, and the RADIUS server returns “accept”. Note that only a clear-text password will work! Any “crypted” password will not work with CHAP.
The security issues with CHAP are largely the same as with PAP. For CHAP, the passwords are never send, even encrypted, and the RADIUS server has access to the users clear-text password. Despite nearly three decades of analysis, there have been no vulnerabilities found with CHAP.
The downside to CHAP authentication is that the RADIUS server must obtain the user’s clear-text password from a database. If that password is not available (e.g. as with Active Directory), then the RADIUS server cannot perform the CHAP calculations necessary to authenticate the user.
How does MS-CHAP authentication work?
MS-CHAP authentication is similar in some respects to CHAP, except that the calculations are done with MD4 and DES instead of MD5. MS-CHAPv2 is slightly different from MS-CHAPv1, but the underlying design principles are the same.
The problem with MS-CHAP is that the underlying design is fundamentally flawed. Both MD4 and DES have been cracked since the protocol was designed. In addition, the way MS-CHAP uses DES makes it almost trivial to reverse engineer the DES keys used. Microsoft has acknowledged this weakness in their web site at their page weaknesses in MS-CHAPv2
Anyone who can observe the MS-CHAP exchange can run easily available “cracking” tools, such as this one on GitHub: https://github.com/moxie0/chapcrack
As of 2012, the authors of the above tool were offering to crack any MS-CHAPv2 exchange for $20, and obtain the users password! Link
We can only assume that the cost of cracking MS-CHAPv2 has dropped significantly since then.
Due to the above issues, we recommend using MS-CHAPv2 only when no other alternatives are available. We also recommend that all RADIUS traffic carrying MS-CHAPv2 be sent over secure, management networks.
How does EAP MS-CHAPv2 authentication work?
EAP-MSCHAPv2 is essentially MS-CHAPv2 carried over the EAP protocol. EAP is an authentication protocol which is little more than a framework for carrying other authentication protocols. It consists of a four (4) byte header which contains a 1-byte identifier that tracks requests and responses, a 1-byte field which identifies the EAP type being carried, and finally 2 bytes which describe the length of the data being carried.
For EAP-MSCHAPv2, the data being carried in EAP is just MS-CHAPv2.
The underlying EAP protocol requires additional packet exchanges over normal MS-CHAPv2. As such, it is more complex to implement.
In the end, EAP-MSCHAPv2 is essentially MS-CHAPv2, but is more complex. EAP-MSCHAPv2 adds no additional security or integrity checks over MS-CHAPv2.
Recommendations
Our recommendation is to use PAP whenever possible. It is compatible with all known back-end databases, and it has no known security issues. The Microsoft MFA (Multi-Factor Authentication) server supports MFA with PAP. FreeRADIUS can do OTP (One Time Passwords) with PAP and Active Directory. For WiFi or 802.1X, we recommend using TTLS with PAP in the “inner tunnel” authentication.
Further, we recommend using passwords where the users password is appended to the OTP token, e.g. 123456mypassword. That form is simple to use for both users and administrators.
If MS-CHAPv2 is required for operational or inter-operability reasons, we recommend running it over a secure management network. The Microsoft MFA server does not support MFA with MS-CHAPv2. Or, running TTLS + MS-CHAPv2. Though it has no benefits (and many drawbacks!) over TTLS + PAP.
We do not recommend using EAP-MSCHAPv2, as it offers no benefits over MS-CHAPv2, and it is more complex to implement.
Still need help?
In our experience with clients and in troubleshooting conversations we manage in the FreeRADIUS mailing list, an unresponsive child error is a symptom of a fundamental underlying issue with the larger infrastructure design. If you have a complex network environment and need expertise from the people who wrote FreeRADIUS, contact us for a consultation.
