Novell BorderManager 3.7 supports token-based authentication. 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.
Passwords are often simple and recognizable words and are easily guessed. This leaves them vulnerable to online guessing attacks in which an intruder keeps trying to authenticate with different passwords until discovering one that works.
Passwords are rarely changed, resulting in default passwords that are not changed. This means that ex-employees may still have access to the system and intruders may be able to gain access at any time.
Passwords are often shared and can be used by someone other than the assigned user.
Passwords can be electronically stolen off the wire or stolen by rogue software on a workstation the user uses.
Users can be tricked into divulging their passwords by trojan-horse software or a phone call by someone misrepresenting themselves.
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.
Authentication Device Initialization
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:
Factory initialization---Authentication devices or tokens are initialized at the factory and the device images for the tokens are saved to a disk. The initialized device images are copied off the disk and imported into the authentication server's database.
Local/manual initialization---The profile parameters are selected and entered into the local authentication server database. The server generates codes which program the token. These codes are either entered manually at the token keypad or are downloaded to a token placed in a special hardware token device initializer attached locally to the server.
When choosing between the two methods, keep the following in mind:
The factory initialization method is the simplest, easiest, and takes the least amount of administrator effort. You import the device data, assign the devices to users and hand them out. However, with this method you are restricted to the factory configuration. This may not be ideal for your application. Also, you must trust that the factory and distributors have not compromised security either intentionally (an employee making copies of device data) or unintentionally (an intruder breaks into the factory and copies the data).
The local/manual initialization method allows you to program a configuration that best meets your needs. Devices are initialized with random data at your site. The data is stored only in the device object and the device itself. There is no separate media (floppy disk) to protect. The data is not exposed to theft at the factory or by distributors and resellers. However, with this method each device must be programmed individually. This requires either additional hardware or manual data entry into each device.
Password Generation
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:
Synchronous method
The synchronous method can be used in most systems that expect a fixed password, that is, sync passwords can be entered when the GUI prompts for the password. Many of the protocols that deliver passwords to the server for validation can carry a sync one-time password and, therefore, can be used in many existing systems without changing the protocol or the user interface.
Synchronous passwords are easier for the user than asynchronous/challenge-response passwords because the user need not enter the challenge.
The synchronous method is susceptible to attacks by an intermediary who gets a valid password from the user and uses the password to falsely authenticate. The true user thinks the authentication failed and tries again successfully.
Asynchronous/challenge-response method
The asynchronous method does not get out of sync.
The asynchronous method requires UI and protocol support that is not commonly provided in existing systems.
The asynchronous method is more effort for the user since the user must enter the challenge value in the token.
The asynchronous method makes the attack by an intermediary slightly more difficult since the authentication server generates a random challenge that cannot be predicted. Therefore, the intermediary must be more actively involved to falsely authenticate.
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:
Synchronous method using only a time-based variable
As long as the clocks are accurate---don't drift from correct time---systems should remain in synchronization.
Passwords expire automatically and must be used immediately. They can't be written down and used later.
Because the password is time-based, someone can capture the password and reuse it to falsely authenticate during the valid time window. This is known as the replay window.
This method is susceptible to attacks by an intermediary.
It may take several computations on the server side to find the right time.
Synchronous method using only an event-based variable
There is no replay window. Once a password is used, it cannot be reused. The server does not allow the event counter to roll backward.
Someone playing with the token (generating passwords but not communicating with the server) can drive the token out of sync.
Passwords don't need to be used immediately. A user can generate a password, write down a list of passwords, then use the list instead of the token to authenticate. The list isn't PIN-protected and can be lost or duplicated.
Synchronous method using a time and event-based variable
Passwords expire automatically
There is no replay window
Hard Tokens
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:
Hand-held, calculator-sized, token device with a CPU for computing the password, memory for storing the secrets, a keypad for entering the PIN, and an LCD screen for displaying the password.
In-line token devices that plug into the serial port on the user's PC between the PC and the modem. These devices include a CPU, and memory. The password is sent directly to the authentication server and is not displayed to the user. If there is no keypad for entering the PIN, the user must enter the PIN at the PC keyboard.
Plug-in devices with CPU and memory that attach to the PC parallel port. The password is usually sent directly to the authentication server and is not displayed to the user. If there is no keypad for entering the PIN, the user must enter the PIN at the PC keyboard.
Smart cards, or credit card-sized devices containing a CPU and memory. These devices are inserted into a special reader attached to the PC. They relay the passwords directly to the server. The user can enter the PIN from the PC keyboard or from the keyboard on the reader.
Floppy disk-shaped devices that fit into the PC floppy drive. These devices contain a CPU and memory. The user enters the PIN from the PC keypad.
Soft 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.
Token Authentication and NDS or eDirectory
Novell BorderManager 3.7 enables you to use NDS or eDirectory as the central database to manage token authentication. By using the NetWare Administrator utility on an administration workstation, you can create the objects necessary to manage tokens, import a series of preinitialized token device images, initialize tokens, assign tokens, synchronize tokens, and test tokens.
Designing and Planning Token Authentication
Novell BorderManager 3.7 requires the following NDS or eDirectory objects in your NDS or eDirectory tree to implement token authentication:
Authentication Container object
Authentication Device object
Because the authentication device data stored in NDS or eDirectory is critical to system security, this data should be carefully protected and access to it should be restricted to authentication servers and administrators who require access.
Authentication Container Object
The Authentication Container object contains the Authentication Device objects (tokens or smart cards) from a single vendor and manages the common configuration tasks for these objects. All Authentication Device objects must be contained within an Authentication Container object. Therefore, you must create at least one Authentication Container object for each vendor you support. You may create multiple Authentication Container objects if you would like to store the Authentication Device objects from a vendor in more than one location in eDirectory. This object consists of the following pages:
Identification---Identifies the name of the Authentication Container object and the type of tokens (from what vendor) that are contained in the object.
Import Device Images---Lets you to import the device images containing the initialization information of a series of factory- preinitialized tokens. For each device image you import, a device object in eDirectory is automatically created.
Manual Initialization---Lets you to initialize a token by generating and displaying the necessary initialization codes for you to enter manually into the token keypad. When you manually initialize a token, if the device object does not already exist in NDS or eDirectory, one is automatically created.
Local Initialization---Lets you to initialize a token which you have placed in the token initializer hardware attached locally to your administration workstation. When you locally initialize a token, if the device object does not already exist in NDS or eDirectory, one is automatically created.
Token Assignment---Lets you to assign devices to users. You can use this page to assign a single token to a user, or quickly assign a series of serialized tokens to a series of users.
Authentication Device Object
The Authentication Device object contains information about a single token or other device. When you import or initialize a token, an Authentication Device object is created. This object contains the following pages:
Identification---Identifies the name, assigned user, type, and status of the token.
Assignment---Lets you assign the token to a user and enable or disable the token.
Synchronize---Lets you synchronize the token. You have the option of synchronizing the token manually or automatically the next time the token is used. For manual synchronization, you must specify the event, clock value, or both.
Password Tests---Lets you test the token to verify that it can correctly generate a password. You can test both the synchronous and asynchronous methods of password generation.
Protecting Device Data in eDirectory
The authentication device data stored in eDirectory is critical to system security. This data should be carefully protected and access to it should be restricted to authentication servers and administrators who require access.
Sensitive information stored on authentication device objects is encrypted automatically; however, additional measures should be taken to protect this data. We recommend the following:
Create a partition at the authentication device container
Restrict replication of authentication device partitions to a few servers that are well controlled
Ensure that backup copies of authentication device objects are protected
Create access controls to allow administrators and Dial Access System objects to read and write these objects
Block inherited rights and ensure access control lists (ACLs) are only for objects that should have access
