Article Surfing Archive

Introduction To ISDN, Part IV: Configuring PPP CHAP Authentication

In part III of this ISDN tutorial, we learned that PPP has two main methods of authentication that Cisco certification candidates need to know how to configure: PAP and CHAP.

PAP has very few advantages over CHAP. PAP passwords are carried over the line in clear text, which in today's world is a very bad idea. PAP configuration also requires additional configuration with the *ppp pap sent-username* command, so anyone who can see your running configuration can also see the PAP password.

The only advantage PAP has over CHAP is a slim one. With PAP, a different password can be used by the each of the routers involved in the authentication. CHAP requires that the password be the same. Why? We'll see as we examine CHAP authentication.

The First Step to Configuring CHAP

CHAP requires you to configure a username / password combination for any remote device that will be involved in authentication. (We*re assuming that the routers have already been configured with their names via the global hostname command.) Both routers will use the password CISCO.

R1:username R3 password CISCOint bri0    encapsulation ppp    ppp authentication chapR3:username R1 password CISCOint bri0     encapsulation ppp     ppp authentication chap

Why CHAP Authentication Requires The Same Password On Both Routers

Remember how PAP sends the password over the line in clear-text? CHAP does not actually send the password over the line at all. Instead, CHAP runs a hash algorithm using the password and a random number. It is the result of this hash that is passed over the link. The remote router receives the hash result, and runs the exact same algorithm. If the result is the same, the authentication attempt will be successful. If the result is different, the authentication will fail. For this reason, the passwords must be the same.

The random number is just that * random. It cannot be configured at the command-line interface.

Note that there is no *sent-password* command, as we had to use with PAP.

Debug The Connection If Authentication Fails

Since two passwords are involved, the chances of one of the passwords being mistyped doubles. If you configure CHAP and the link dials but drops almost immediately, there's an authentication problem. Run debug ppp negotiation and attempt to dial the line again. The output of this particular debug will show you where the problem is.

Here, we'll run debug ppp negotiation to see what a successful CHAP authentication looks like:

Examining the CHAP authentication process with *debug ppp negotiation*.

R3#debug ppp negotiationPPP protocol negotiation debugging is onR3#ping 172.12.21.1BR0:1 PPP: Phase is AUTHENTICATING, by bothBR0:1 CHAP: O CHALLENGE id 1 len 23 from "R3"BR0:1 CHAP: I CHALLENGE id 1 len 23 from "R1"BR0:1 CHAP: O RESPONSE id 1 len 23 from "R3"BR0:1 CHAP: I SUCCESS id 1 len 4BR0:1 CHAP: I RESPONSE id 1 len 23 from "R1"BR0:1 CHAP: O SUCCESS id 1 len 4

The output of debug ppp negotiation with CHAP is different that the output of the same command when PAP is run. Remember that CHAP stands for Challenge Handshake Authentication Protocol, and by running this vital debug, you can see the challenges being made, responded to, and the success or failure of the negotiation.

Another important ISDN command, show dialer, tells us that the ISDN link is up, what the source and destination packet was that brought it up (*interesting traffic*), the time until disconnect, and what phone number it's connected to.

It's important to remember that while by default, any traffic can cross the link once it's up, only interesting traffic resets the idle-timer.

In the next section of my ISDN tutorial, we'll look at some common ISDN configuration problems, how to debug them, and how to solve them.

To your success,

Chris Bryant
CCIE #12933