NMAS supports token-based authentication. So you can use this authentication method with Novell RADIUS Services.
Authentication is the process of determining the identity of a user attempting to access a system. The most common authentication method in use today is the static and reusable password. However, static, reusable passwords have some inherent weaknesses.
A stronger and more effective way of identifying and authenticating remote users is through a token-based authentication mechanism. Token-based authentication implements two-factor authentication making it a much stronger authentication method. In fact, token-based authentication is often called strong authentication. With two-factor authentication, verifying a user requires two factors: something the user knows, such as a personnel identification number (PIN), and something the user has, such as the token device.
Before a user can use a token to authenticate, it must be initialized, assigned to the user, and enabled. The initialization process programs the token with the necessary profile parameters, such as the encryption algorithm and keys, the minimum and maximum PIN length, and the method of operation (synchronous or asynchronous). Once initialized, the token is assigned to a specific user and enabled.
During token authentication, the user submits a PIN to activate the token device. Invalid PINs cause the token to lock up and a special procedure is required to unlock the token. If the PIN is valid, the token uses an encryption algorithm, and a secret encryption key to encrypt a variable and generate a dynamic, one-time-use password. At the network server end, software on an authentication server uses the same encryption algorithm, secret key, and variable to generate and validate the one-time password.
The variable used to generate the one-time password is often called the challenge. There are a variety of approaches for determining the variable used to generate the password. The two main methods are usually categorized as either asynchronous or synchronous.
The asynchronous method is sometimes called the challenge-response method. With this method, the server software sends the token an external challenge---a randomly generated variable--- for the token device to encrypt. The device uses this challenge variable, the encryption algorithm, and the shared secret to respond with the correctly encrypted password.
With the synchronous method, the variable is generated internally by the token. Usually, a time clock counter, a login event counter, or a combination of the two is used as the challenge variable by both the token and the server to generate the password. Because the token and the server each separately and internally determine the challenge variable, it is very important for their time clocks and the event counters to stay synchronized. If the token and server become out of sync, a special procedure is necessary to synchronize them.
Before a user can use a token to authenticate, it must be initialized or programmed with the necessary profile parameters. These parameters include the algorithm and secret keys for encryption, the minimum and maximum PIN length, the language for prompts, and method of operation (synchronous or asynchronous) to be used. This initialization data must also be stored or coordinated with the authentication server. There are two methods to initialize authentication devices and store the data on the authentication server:
When choosing between the two methods, keep the following in mind:
Tokens use a variable as the basis to generate the one-time password. This variable is called the challenge. The two main methods for determining the variable used to generate the password are asynchronous or synchronous.
With the asynchronous or challenge-response method, the server software sends the token an external challenge---a randomly generated variable--- for the token device to encrypt. The token uses this challenge variable, the encryption algorithm, and the shared secret to generate the response---the correctly encrypted password.
With the synchronous method, the challenge variable used to generate the password is determined internally by the token and the server. A time counter, event counter, or time and event counter combination within each device is used as the basis for the challenge variable. Because the token and the server each separately and internally determine the challenge variable from their own counters, it is very important for their time counters and the event counters to stay synchronized. Because it is so easy for the server and the token to get out of sync, most implementations allow for a certain amount of drift between the counters. Usually, a small range or window of these counter values is used to compute the password. However, if the token and server get out of sync beyond this window, a special procedure is necessary to synchronize them.
Both the asynchronous and synchronous methods provide a strong and effective way of authenticating users. To determine whether the synchronous or asynchronous method of operation is appropriate for your implementation, keep the following in mind:
If you need to choose between time-based, event-based, or time- and event-based synchronous methods for your implementation, keep the following in mind:
Hard tokens are hardware-based token-generating devices. There are a variety of hardware implementations of token-generating devices. Regardless of the physical implementation of the hardware device, all hard tokens usually require users to know their PINs. Most tokens require the user to enter the PIN into the token to activate the authentication process and generate the password. Some tokens have the user enter the PIN as part of the password. The following list describes some of the more common implementations of hard tokens:
Soft tokens are software-based token generating devices. The software token is installed on PCs, laptops, and hand-held computers. Once the PIN is activated, the token creates and sends the users's one-time password. The system's memory stores the secrets and the system's CPU is used to generate the password. Although there is some risk associated with storing the secrets on the system's memory, this risk is reduced by having the secrets encrypted. Also, because the token is installed on the system, anyone with physical access to the system can use it to authenticate, but they must know or guess the PIN to use it.
NMAS enables you to use NDS as the central database to manage token authentication. By using ConsoleOne on an administration workstation, you can install a token login method that will allow users to do token authentication to the network either locally or remotely.
See Configuring Login Policy Rules for more information on how to set up token authentication.