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 header—this 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.
|
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.
|
