Choosing 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 answer is that the NAI is defined for routing inside of an AAA system. That is, when a user logs into your site (e.g. a visited network as with eduroam), that identifier is used to route your login request to the home network. That home network knows who you are, and knows the association between the email address and the person. The home network then authenticates you (or not), and returns success / fail to the visited network.
This routing means that the user identity at my organization is never validated by your organization. Instead, the two organizations trust each other (via RADIUS proxying). My organization can vouch for my user at your organization, and the same goes in reverse. There is no need for your organization to know anything about the person behind the email address. The address is just used as a routing label, not a personal identifier!
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 secret, 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!
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.
Need more help?
InkBridge Networks 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, visit our quote page to contact us for a consultation.
Related Articles
PAP vs. CHAP
There is a lot of confusion around the security of PAP versus CHAP. While there are many web sites which clain to compare the security of these two authentication methods, most of these comparisons are shockingly wrong. It's time to correct the misconceptions around PAP vs CHAP.
Is PAP secure?
A common misconception is that PAP is less secure than other authentication protocols such as CHAP, MS-CHAP, or EAP-MSCHAP(v2). This perception arises because of a misunderstanding of how PAP is actually used.
MS-CHAP is dead
While MS-CHAP has been used since 1998, it uses DES encryption which was deprecated in 2002. Attacks on MS-CHAP itself have been known since 2006, and those attacks have only gotten better over time. New attacks show that it is possible to crack most user-generated passwords in milliseconds.
RADIUS protocol and password compatibility
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.