2.6 Authentication Methods

RADIUS supports a variety of different protocol mechanisms to transmit sensitive user -specific data to and from the authentication server. The two most common are the Password Authentication Protocol (PAP) and the CHAP. RADIUS also allows for more attributes and methods developed by vendors , including support for features peculiar to Windows NT, Windows 2000, and other popular network operating systems and directory services. The following section explores the two most common methods in greater detail.

2.6.1 PAP

The User-Password attribute in a requesting packet signals to the RADIUS server that the PAP protocol will be used for that transaction. It's important to note that the only mandatory field in this case is the User-Password field. The User- Name field does not have to be included in the requesting packet, and it's entirely possible that a RADIUS server along a proxy chain will change the value in the User-Name field.

The algorithm used to hide the original user's password is composed of many elements. First, the client detects the identifier and the shared secret for the original request and submits it to an MD5 hashing sequence. The client's original password is put through the XOR process and the result coming from these two sequences is then put in the User-Password field. The receiving RADIUS server then reverses these procedures to determine whether to authorize the connection. The very nature of the password-hiding mechanism prevents a user from determining if, when the authentication fails, the failure was caused by an incorrect password or an invalid secret. Most commercial RADIUS servers, though, include logic that looks at the series of packets previously transmitted from the same client. If a number passes through the connection correctly, most likely the few packets that failed did so because of an incorrect password.

2.6.2 CHAP

CHAP is based on the premise that the password should never be sent in any packet across a network. CHAP dynamically encrypts the requesting user's ID and password. The user's machine then goes through its logon procedure, having obtained a key from the RADIUS client equipment of at least 16 octets in length. The client then hashes that key and sends back a CHAP ID, a CHAP response, and the username to the RADIUS client. The RADIUS client, having received all of the above, places the CHAP ID field into the appropriate places in the CHAP-Password attribute and then sends a response. The challenge value originally obtained is placed in either the CHAP-Challenge attribute or in the authenticator field in the headerthis is so the server can easily access the value in order to authenticate the user.

To authenticate the user, the RADIUS server uses the CHAP-Challenge value, the CHAP ID, and the password on record for that particular user and submits it to another MD5 hashing algorithm. The result of this algorithm should be identical to the value found in the CHAP-Password attribute. If it's not, the server must deny the request; otherwise , the request is granted.

The fact that the password in a CHAP transaction is never passed across the network is just one reason why CHAP is an appealing authentication protocol. How does this work? The user data against which the hashing routine is run returns a one-way value that does not contain the password. So the server must have the current user's password stored in clear text in its own records in order to create a hash with which to compare. CHAP IDs are also non-persistent, which reduces the possibility of a third party sniffing or otherwise intruding on the transaction. Additionally, the CHAP protocol supports challenging the client anytime during the user's session, which increases the likelihood that invalid users are kept out of the system.

Using Strong, Secure Passwords

The security of CHAP and the integrity of transactions initiated using CHAP depends heavily on the strength of the user's password. In PAP authentication, the shared secret is used in conjunction with the MD5 hash to conceal the password. The actual password is used in much the same way with CHAP authentication. Despite the fact that the password itself is never transmitted, a weak, easily guessable password is fodder for crackers. This is because the values submitted to the MD5 hashing algorithm can be easily replicated or "backtracked."

Good passwords use words or phrases that can't be easily guessed, that aren't found in a dictionary, and that are of a length to make brute-force cracking impractical or impossible . To use passwords that don't meet these criteria is to place in jeopardy the security and integrity of the entire CHAP authentication mechanism itself.

2.6.3 Selecting PAP, CHAP, or Other Protocols

There is a school of thought on either side of using CHAP or PAP in a network that requires authorization. Some systems administrators think that because CHAP's security cannot be enforced when authorization requests must travel outside their realm of control, PAP is a more appropriate method. This is because with PAP, the strength of the shared secret used in the transmissions between the machines is under the direct control of the original administrator. As well, any particular administrator cannot be guaranteed that one authentication protocol will be used throughout any environment in which requests are passed through a proxy chain. In this case, the final authorizing sequence decides the authentication protocol.

RADIUS isn't limited at all to PAP or CHAP authentication. The limits on authenticator protocols are inherent to the operating system. For instance, RADIUS can support a domain attribute when logging into a Windows NT or Windows 2000 system. The key factor in supporting RADIUS authentication is that the password be available somehow to the host system. The most common way to do this is to use a Unix password file, but that particular file only works with PAP authentication. Passwords can also be retrieved from a directory service (such as Microsoft's Active Directory, Novell's eDirectory, or a generic LDAP directory store), from an encrypted file, or by some other means. All of this is to say that support for various authenticator protocols depends entirely on the configuration of a particular RADIUS environment.