When using CHAP authentication, the access server
sends a challenge message to the remote node after the PPP link is
established, as shown in Figure .
The remote node responds with a value calculated by using a
one-way hash function (typically Message Digest 5 [MD5]). The access
server checks the response against its own calculation of the
expected hash value. If the values match, the authentication is
acknowledged. Otherwise, the connection is immediately terminated.
CHAP provides protection against playback
attack through the use of a variable challenge value that is unique
and unpredictable. The use of repeated challenges every two minutes
during any CHAP session is intended to limit the time of exposure to
any single attack. The access server (or authentication server, such
as TACACS+) controls the frequency and timing of the challenges. A
major advantage of the constantly changing challenge string is that
the line cannot be sniffed and played back later to gain
unauthorized access to the network.
The following shows the series of events that
occur during a CHAP authentication between two routers.
Placing the Call
Figure
(Call) represents the following three steps:
- The call comes in to 3640-1. The
incoming interface is configured with the
ppp authentication
chap
command.
LCP negotiates CHAP and MD5.
A CHAP challenge from 3640-1 to
the calling router is required on this call.
Sending a Challenge
Figure
(Challenge) illustrates the following steps in the CHAP authentication between
the two routers:
- A CHAP challenge packet is built
with the following characteristics:
- 01 -- Challenge packet type
identifier
- id -- Sequential number that
identifies the challenge
- random -- A reasonably random
number
- 3640-1 -- The authentication name
of the challenger
- The id and random values are
kept on the access server.
- The challenge packet is sent to
the caller.
The answering router maintains a list
of outstanding challenges.
Processing the Challenge
Figure
(Response) illustrates the receipt and MD5 processing of the challenge packet
from the server.
The calling router processes the CHAP
challenge packet in the following manner:
- The id value is fed into the MD5
hash generator.
- The random value is fed into the
MD5 hash generator.
- The name 3640-1 is used
to look up the password.
- The password is fed into the MD5
hash generator.
The result is the one-way MD5-hashed
CHAP challenge that will be sent back in the CHAP response. As
mentioned in RFC 1334, no matter what number you process through the
MD5 algorithm, the result is always 128 bits long!
Answering the Challenge
Figure
(Response, continued)
illustrates the building of the CHAP response packet that will be
sent to the access server:
- The response packet is assembled
from the following components:
- 02 -- CHAP response packet type
identifier
- id -- Copied from the challenge
packet
- hash -- The output from the MD5
hash generator (the hashed information from the challenge
packet)
- 766-1 -- The authentication name of
this caller
- The response packet is then sent
to the challenger.
The Verification
Figure
(Verification) shows the response-packet processing that occurs on the challenger.
The CHAP response packet is processed
in the following manner:
- The id is used to find the
original challenge packet.
- The id is fed into the MD5 hash
generator.
- The original challenge random
value is fed into the MD5 hash generator.
- The name 766-1 is used to
look up the password from one of the following sources:
- Local database
- RADIUS server
- TACACS server
(Note that with Cisco IOS Release
11.1 and earlier, TACACS is used for the password check only. With
Cisco IOS Releases 11.2 and later, TACACS is used to verify the hash
value.)
- The password is fed into the MD5
hash generator.
- The hash value received in the
response packet is then compared to the calculated MD5 hashed value.
CHAP authentication succeeds if the
calculated and received hash values are equal.
The Result
Figure
(Result) illustrates the success message being sent to the calling router.
If authentication was successful, a
CHAP success packet is built from the following components:
- 03 -- CHAP success message type
- id -- Copied from the response packet
- Welcome in
is
simply a text message of some kind, meant to be a user-readable
explanation.
If authentication failed, a CHAP
failure packet is built from the following components:
- 04 -- CHAP failure message type
- id -- Copied from the response packet
- Authentication failure
or a similar text message is meant to be a user-readable
explanation.
The success or failure packet is then
sent to the caller.
|