Log InOne-time passwords (OTP) and multi-factor authentication (MFA) are important mechanisms used to improve security. Both these strategies can combine the username and password credentials with a one-time token as part of the sign-in process. The one-time token is usually supplied through an authentication app, or a small separate piece of hardware. In network security, using a one-time token is common practice for activites such as signing into private networks through VPN.
While one-time passwords are useful, the authentication method that is used to transmit the user’s credentials may not be compatible with the use of OTP.
Specifically, only PAP makes it possible to incorporate OTPs or MFA into the authentication process.
This article explains how one-time tokens work, and why PAP is the only authentication protocol which can support them.
How PAP works
When PAP is used, the RADIUS client sends the password to the RADIUS server. The password is, of course, encrypted “on the wire” so that no one else can see it. But the key benefit of PAP is that the RADIUS server gets a copy of the users’ password, and OTP. With all other authentication methods (CHAP, MS-CHAP, etc.) the RADIUS server gets a hashed version of the passwords. This hashed version effectively hides the OTP, meaning that all benefits of using an OTP are lost.
Figure 1: How PAP works
One primary benefit of PAP authentication is that the clear-text password is compatible with all databases and other back-ends. Using PAP allows you to store passwords in the database in salted, encrypted form. i.e. a secure storage method which provides protection against database breaches.
Another significant benefit of PAP authentication is that it is compatible with the use of one-time tokens.
How PAP works with one-time passwords
One-time tokens are typically generated with an authentication app such as Google Authenticator, or a piece of hardware with a small display. These apps cycle through six-digit tokens, which the user reads and then enters along with the password when logging in, for example “123456mypassword”.
Because the password is transmitted via PAP, the RADIUS server can see the entire password field and can split the value “123456mypassword” into two parts. The token part: “123456” is verified against the OTP token server. The password part “mypassword” is verified against the user directory such as LDAP or Active Directory in the usual way. If either check fails, the user is rejected. If both checks pass, the user is authenticated.
Figure 2: How PAP works with one-time passwords
How PAP works with challenge-response authentication
Another implementation of one-time tokens breaks the authentication into two steps, via a challenge-response process.
In this method, the user enters a password such as “mypassword”. For the first step of the authentication, the RADIUS server verifies the password against the user directory as in Figure 1. The only difference in this case, is that if the password is correct, the RADIUS server returns a RADIUS Access-Challenge packet, containing a test such as “Please enter the token:”, rather than an Accept or Reject response.
Figure 3: Two-step challenge-response authentication with PAP (step 1)
The RADIUS client displays this challenge to the user, who enters the token, e.g. “123456”. This token is then passed to the RADIUS server, which verifies it against the OTP token server.
Figure 4: Two-step challenge-response authentication with PAP (step 2)
Will OTPs work with CHAP?
No. CHAP is not compatible with the use of one-time tokens.
With CHAP authentication, the RADIUS client calculates a MD5 hash of a random challenge and the user’s password. Both the challenge and MD5 hash are sent to the RADIUS server. But the password is never sent. Which means that the OTP is never sent to the RADIUS server!
Figure 5: How CHAP works
When the RADIUS server receives the CHAP password, it just sees an opaque hash, and not the OTP value “123456” or the password “mypassword”. If a one-time token is prepended to the password, the RADIUS server has no way to “reverse” the hash in order to see the OTP or the password. This means that RADIUS cannot validate the token with the OTP server.
But what about the 2-step challenge-response process? In this case, the password forwarded by the NAS can be verified by the RADIUS server in the usual way, as in Figure 5. However, when the user supplies the one-time token after the challenge, the RADIUS client once again applies an MD5 hash and random challenge before transmitting it.
When the RADIUS server receives this hashed content, it can only pass the hashed version of the token to the OTP server for validation. The OTP server doesn’t have visibility into the actual value of the token, which means it cannot validate the token, which means RADIUS cannot validate the authentication attempt.
Are MS-CHAP or EAP-MSCHAP compatible with OTPs?
Sadly, no.
The constraints that apply to OTPs and CHAP apply in the case of MS-CHAP and EAP-MSCHAP as well.See our previous article for a detailed description of how these protocols work.
The bottom line
Fundamentally, in order for OTPs to work, the one-time token must be validated separately from the password.
In all protocols other than PAP, this is not possible because the value of the one-time token cannot be extracted from the packet payload received by RADIUS.
In general, we recommend using PAP whenever possible. It is secure, and is compatible with everything.
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.
