Chapter 10: Managing the RADIUS Servers
Authenticators
227
Asynchronous dynamic password authenticators
A user who has an asynchronous challenge/response authenticator is unable
to determine the proper dynamic password until after they have received a
SafeWord “challenge”. Their RADIUS dialog always has two phases, as in the
example below.
Username: Fred
Password:
Challenge: 1251
Response: 2ap9
In the first phase, a user named Fred types his username and presses the
Enter
button at the Password prompt. A challenge is displayed almost
immediately, which he types into his authenticator. Fred receives a new
password response from his authenticator, and types the password at the
response prompt.
CHAP-encoded encapsulated dynamic passwords
Some RADIUS clients (e.g., Microsoft's Windows NT RAS) always insist on
CHAP-encoding the RADIUS password field, which renders the data inside
that field useless in dynamic password situations such as those generally
desired by customers. (The CHAP authentication algorithm encodes the data
as one-way, which cannot be decoded.)
In order to compensate, a user may type his or her dynamic password adjacent
to their username in the RADIUS username field, separated by a comma. For
example, if Fred’s synchronous dynamic password is 1316, the RADIUS sign
on dialog will look like this:
Username: fred,1316
Password:
If Fred were using an asynchronous, challenge-response dynamic password
authenticator, the dialog would look like this:
Username: fred
Password:
Challenge: 2155
Username: 2900
In the above example, the first comma after “fred” informs the RADIUS Server
that the username field will be used to communicate the dynamic password
after the challenge is displayed.
If the RADIUS Server receives a RADIUS access-request packet containing
only a RADIUS-encapsulated, CHAP-encoded memorized password, which is