One of the more common authentication requests is around gaining access to something. That may be access to the VTY ports on the router, VPN access between sites or just using a lock and key dynamic ACL.

One of the more common WAN protocols is PPP. Whether it's your home router or some bigger WAN links at the office or in some sort of RAS dial-in service for an ISP we're going to do PPP. Knowing this fact it’s easy to see how common authentication using PPP is, indeed one of the huge benefits of PPP is the fact it allows for authentication...sounds like a match made in heaven. Certainly for certification PPP is a seriously major subject when you consider the features...that may be a hint.

PPP is used in exams to show authentication challenges for AAA in terms of PAP/CHAP etc. IT's used to multilink, circuit backup and that old faithful QoS topic of Multilink PPP with fragmentation and interleave. We see PPP a LOT in certification.
Lets start by looking at PPP authentication

The way we deploy the authentication depends on our requirements (or the question you get). If we are asked to support authentication using a plain text (unencrypted) message then PAP is the one for us. If on the other hand we are asked that the password is not sent unencrypted then we're talking about CHAP or EAP.

So what are the PPP authentication mechanisms we are dealing with?

- PAP
- CHAP
- EAP

In terms of security PAP is weakest followed by CHAP and then EAP. If you are asked to use the 'most secure' and EAP is an option, then you go for that one.

PAP (Password Authentication Protocol) send the password unencrypted over the network and is therefore considered insecure. In the real world we would use PAP only as a last resort or when the remote device doesn't support any other mechanism.

CHAP (Challenge-Handshake Authentication Protocol) unlike PAP is a more secure protocol as it uses a three-way handshake and the password is never sent across the link. Instead an MD5 hash checksum is calculated based on the password and then sent to the authenticator.
EAP (Extensible Authentication Protocol) is an authentication framework and there are numerous EAP 'methods' available such as EAP-FAST and EAP-TLS etc.

Right, lets talk about PPP authentication. When we talk about authentication what are we asking for? We're asking for some sort of 'token' or 'all access pass' to basically allow that remote device (which may be a laptop for a roaming user out on the Internet) full access to us. Would you like someone to have full access to you without authentication? You ask your doctor to prove themselves before they poke about right?

So how do we authenticate these remote access requests? Well we've got two options. The first one is basically saying "You prove to me who you are, I don't trust you until you prove you know me", this is one way authentication. The other one is a mutual respect thing where both sides of the link need to agree they know each other, this is two way authentication.

Here is the topology today - nothing mental I’m sure you’ll agree.

Screen shot 2011-06-15 at 22.56.18

PAP type authentication


Right into the scenario. PPP authentication is a bit of a brain issue because you need to get into your head who is wishing to be authenticated and who is the authenticator. Here is how I think about it. When you dialin to your office using a VPN *you* have a username and password and the VPN device is just basically making sure the details it has in its authentication database match before it lets you in...right?

OK, here we go. R2 is going to be *you* authenticating to the 'VPN' device which is R1. Now remember, we're not saying R1 is actually a VPN service it was just an analogy.

So R2 is *you*, the guy on the road, we need to tell R2 a username and password (you would usually have this in your head). R1 is the termination device so here we are going to bang into the 'authentication database' the remote users allowed to connect.

Here is the configuration on each device. First R2:

Screen shot 2011-06-15 at 22.20.06


Now for R2. Now this router is the authenticator end or the NAS - the device we are trying to authenticate toward. Notice the ‘callin’ keyword at the end of the authentication line? What we are doing here is disabling two way (bi-directional) authentication and going for uni-directional only. After all, we are a road warrior, we don’t need to authenticate R1 we want R1 to authenticate us....we are CALLING IN.

Screen shot 2011-06-15 at 22.20.37

Notice that this configuration has the authentication ‘credentials’ in it using ppp pap sent-username? This is like you banging your username and password into normal authentication processes like your windows machine at the office.

OK, thats all in lets bring up the interfaces and watch the debug on R1 to see the PPP connection establish itself. Here is a debug output...it’s not working...lets try to sort the issue out.

ppp authorization required

Authorzation required? Well apart from being spelt wrong (I am English and I’m sure authorisation doesn’t have a ‘z’ in it ;-) ) the problem here is that we (R2 are sending our credentials but as of this point R1 doesn’t have a ‘database’ of usernames and passwords to lookup.

Screen shot 2011-06-15 at 22.39.39

Thats it? Thats it! We enable pap authentication on the 'called' interface with the ppp authentication pap statement. We provide the username and password information to authenticate the request on the same box. On the calling router we simply add in the ppp pap username and password and hey presto!

CHAP authentication type

If you thought PAP was easy, you'd be right. CHAP is just as easy to grasp but the key difference here is the way CHAP authenticates for uni and bi-directional challenges using a 'three-way handshake'.

During the handshake the 'called' box sends an authentication enquiry to the calling box asking for confirmation of it's username and password - this is the 'challenge'. The calling station then uses an MD5 hash to send it's the HASH of the username/password (REMEMBER: it is NOT the actual username and password). The called box then checks the response hash against what it thinks should be the right response and permits/denies based on that.
Lets take a look at a simple example along the lines we just did for PAP. Notice this time that the username and password challenge are set in global configuration mode not under the interface. Each router has a username and password for the opposite router but the password is the same. Both the username and password as CaSe SeNsItIve...be careful.

So what is going on here with our current setup? Well this way we're doing bidirectional or 'two-way' authentication. Each side has been told to use chap authentication. So we'll have the calling station or 'Client' being authenticated by the called (NAS) station. The NAS will send a chap challenge to R1 asking it to confirm the username and password in the MD5 message response. The calling station (R1) will then itself send a challenge to R2 for the same purpose.

Lets do the config, do a debug, and enjoy the moment....ah

Firstly here is the configuration for R1 including the username setup
Screen shot 2011-06-15 at 22.50.01
Screen shot 2011-06-15 at 22.47.57

Here is R2 - looks very similar doesn’t it.

Screen shot 2011-06-15 at 22.49.12
Screen shot 2011-06-15 at 22.50.43

As soon as we enable the interfaces (no shutdown) the CHAP conversation begins - here is the debug output using ‘debug ppp authentication’ and ‘debug ppp negotiation’

*Mar 1 00:40:03.835: %LINK-3-UPDOWN: Interface Serial0/0, changed state to up
*Mar 1 00:40:03.839: Se0/0 PPP: Using default call direction
*Mar 1 00:40:03.839: Se0/0 PPP: Treating connection as a dedicated line
*Mar 1 00:40:03.839: Se0/0 PPP: Session handle[F300006A] Session id[119]
*Mar 1 00:40:03.839: Se0/0 PPP: Phase is ESTABLISHING, Active Open
*Mar 1 00:40:03.839: Se0/0 PPP: Authorization required
*Mar 1 00:40:03.839: Se0/0 LCP: O CONFREQ [Closed] id 189 len 15
*Mar 1 00:40:03.839: Se0/0 LCP: AuthProto CHAP (0x0305C22305)
*Mar 1 00:40:03.839: Se0/0 LCP: MagicNumber 0x0030B4D6 (0x05060030B4D6)
*Mar 1 00:40:03.851: Se0/0 LCP: I CONFREQ [REQsent] id 67 len 10
*Mar 1 00:40:03.851: Se0/0 LCP: MagicNumber 0x0030B1AA (0x05060030B1AA)
*Mar 1 00:40:03.851: Se0/0 LCP: O CONFACK [REQsent] id 67 len 10
*Mar 1 00:40:03.855: Se0/0 LCP: MagicNumber 0x0030B1AA (0x05060030B1AA)
*Mar 1 00:40:03.855: Se0/0 LCP: I CONFACK [ACKsent] id 189 len 15
*Mar 1 00:40:03.855: Se0/0 LCP: AuthProto CHAP (0x0305C22305)
*Mar 1 00:40:03.855: Se0/0 LCP: MagicNumber 0x0030B4D6 (0x05060030B4D6)
*Mar 1 00:40:03.855: Se0/0 LCP: State is Open
*Mar 1 00:40:03.855: Se0/0 PPP: Phase is AUTHENTICATING, by this end
*Mar 1 00:40:03.855: Se0/0 CHAP: O CHALLENGE id 20 len 23 from "R1"
*Mar 1 00:40:03.871: Se0/0 CHAP: I RESPONSE id 20 len 23 from "R2"
*Mar 1 00:40:03.871: Se0/0 PPP: Phase is FORWARDING, Attempting Forward
*Mar 1 00:40:03.875: Se0/0 PPP: Phase is AUTHENTICATING, Unauthenticated User
*Mar 1 00:40:03.875: Se0/0 PPP: Sent CHAP LOGIN Request
*Mar 1 00:40:03.879: Se0/0 PPP: Received LOGIN Response PASS
*Mar 1 00:40:03.879: Se0/0 PPP: Phase is FORWARDING, Attempting Forward
*Mar 1 00:40:03.879: Se0/0 PPP: Phase is AUTHENTICATING, Authenticated User
*Mar 1 00:40:03.879: Se0/0 PPP: Sent LCP AUTHOR Request
*Mar 1 00:40:03.879: Se0/0 PPP: Sent IPCP AUTHOR Request
*Mar 1 00:40:03.879: Se0/0 LCP: Received AAA AUTHOR Response PASS
*Mar 1 00:40:03.879: Se0/0 IPCP: Received AAA AUTHOR Response PASS
*Mar 1 00:40:03.879: Se0/0 CHAP: O SUCCESS id 20 len 4
*Mar 1 00:40:03.879: Se0/0 PPP: Phase is UP
*Mar 1 00:40:03.879: Se0/0 IPCP: O CONFREQ [Closed] id 1 len 10
*Mar 1 00:40:03.883: Se0/0 IPCP: Address 150.1.12.1 (0x030696010C01)
*Mar 1 00:40:03.883: Se0/0 PPP: Sent CDPCP AUTHOR Request
*Mar 1 00:40:03.883: Se0/0 PPP: Process pending ncp packets
*Mar 1 00:40:03.883: Se0/0 CDPCP: Received AAA AUTHOR Response PASS
*Mar 1 00:40:03.883: Se0/0 CDPCP: O CONFREQ [Closed] id 1 len 4
*Mar 1 00:40:03.891: Se0/0 do IPCP: I CONFREQ [REQsent] id 1 len 10
*Mar 1 00:40:03.891: Se0/0 IPCP: Address 150.1.12.2 (0x030696010C02)
*Mar 1 00:40:03.891: Se0/0 AAA/AUTHOR/IPCP: Start. Her address 150.1.12.2, we want 0.0.0.0
*Mar 1 00:40:03.895: Se0/0 PPP: Sent IPCP AUTHOR Request
*Mar 1 00:40:03.895: Se0/0 CDPCP: I CONFREQ [REQsent] id 1 len 4
*Mar 1 00:40:03.895: Se0/0 CDPCP: O CONFACK [REQsent] id 1 len 4
*Mar 1 00:40:03.895: Se0/0 AAA/AUTHOR/IPCP: Reject 150.1.12.2, using 0.0.0.0
*Mar 1 00:40:03.895: Se0/0 AAA/AUTHOR/IPCP: Done. Her address 150.1.12.2, we want 0.0.0.0
*Mar 1 00:40:03.895: Se0/0 IPCP: O CONFACK [REQsent] id 1 len 10
*Mar 1 00:40:03.895: Se0/0 IPCP: Address 150.1.12.2 (0x030696010C02)
*Mar 1 00:40:03.899: Se0/0 IPCP: I CONFACK [ACKsent] id 1 len 10
*Mar 1 00:40:03.903: Se0/0 IPCP: Address 150.1.12.1 (0x030696010C01)
*Mar 1 00:40:03.903: Se0/0 IPCP: State is Open
*Mar 1 00:40:03.903: Se0/0 CDPCP: I CONFACK [ACKsent] id 1 len 4
*Mar 1 00:40:03.903: Se0/0 CDPCP: State is Open
*Mar 1 00:40:03.907: Se0/0 IPCP: Install route to 150.1.12.2
*Mar 1 00:40:04.879: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to up

The default CHAP direction is bi-directional or two-way. What if we only wanted to authenticate one way? No problem. On the calling router (R1) we change the authentication command slightly to include the 'callin' keyword. This time when R2 receives the inbound it challenges R1 but R2 doesn't challenge R2 in response.

ppp authentication chap callin

What if we want to use a different hostname? No problem, like PAP we can set this under the interface using the 'ppp chap hostname' command. Lets change the hostname being offered to R1, we’ll run a debug and see it fail, then we’ll add the username into R1 and watch it setup again...

First the changed...oooh bad news

R2(config-if)# ppp chap hostname CHANGED

Here is the debug on R1...we’ve broken it for sure...

*Mar 1 00:53:50.763: %LINK-3-UPDOWN: Interface Serial0/0, changed state to up
*Mar 1 00:53:50.767: Se0/0 PPP: Using default call direction
*Mar 1 00:53:50.767: Se0/0 PPP: Treating connection as a dedicated line
*Mar 1 00:53:50.767: Se0/0 PPP: Session handle[4600006C] Session id[122]
*Mar 1 00:53:50.771: Se0/0 PPP: Authorization required
*Mar 1 00:53:50.795: Se0/0 CHAP: O CHALLENGE id 23 len 23 from "R1"
*Mar 1 00:53:50.811: Se0/0 CHAP: I CHALLENGE id 16 len 28 from "CHANGED"
*Mar 1 00:53:50.815: Se0/0 CHAP: I RESPONSE id 23 len 28 from "CHANGED"
*Mar 1 00:53:50.819: Se0/0 PPP: Sent CHAP LOGIN Request
*Mar 1 00:53:50.819: Se0/0 CHAP: Unable to authenticate for peer
*Mar 1 00:53:52.819: Se0/0 PPP: Authorization required
*Mar 1 00:53:54.863: Se0/0 CHAP: O CHALLENGE id 24 len 23 from "R1"
*Mar 1 00:53:54.875: Se0/0 CHAP: I CHALLENGE id 17 len 28 from "CHANGED"
*Mar 1 00:53:54.879: Se0/0 CHAP: Unable to authenticate for peer
*Mar 1 00:53:56.883: Se0/0 PPP: Authorization required
*Mar 1 00:53:56.919: Se0/0 CHAP: O CHALLENGE id 25 len 23 from "R1"
*Mar 1 00:53:56.935: Se0/0 CHAP: I CHALLENGE id 18 len 28 from "CHANGED"
*Mar 1 00:53:56.939: Se0/0 CHAP: I RESPONSE id 25 len 28 from "CHANGED"
*Mar 1 00:53:56.943: Se0/0 PPP: Sent CHAP LOGIN Request
*Mar 1 00:53:56.947: Se0/0 CHAP: Unable to authenticate for peer
*Mar 1 00:53:58.963: Se0/0 PPP: Authorization required
*Mar 1 00:53:58.983: Se0/0 CHAP: O CHALLENGE id 26 len 23 from "R1"
*Mar 1 00:53:59.003: Se0/0 CHAP: I CHALLENGE id 19 len 28 from "CHANGED"
*Mar 1 00:53:59.007: Se0/0 CHAP: I RESPONSE id 26 len 28 from "CHANGED"
*Mar 1 00:53:59.007: Se0/0 PPP: Sent CHAP LOGIN Request
*Mar 1 00:53:59.007: Se0/0 CHAP: Unable to authenticate for peer
*Mar 1 00:54:01.011: Se0/0 PPP: Authorization required

Right lets fix it now by putting the username CHANGED and password into R1.

R1(config)#username CHANGED password cisco

This debug is still running on R1...

*Mar 1 00:55:27.039: Se0/0 CHAP: O CHALLENGE id 58 len 23 from "R1"
*Mar 1 00:55:27.059: Se0/0 CHAP: I CHALLENGE id 51 len 28 from "CHANGED"
*Mar 1 00:55:27.063: Se0/0 CHAP: I RESPONSE id 58 len 28 from "CHANGED"
*Mar 1 00:55:27.063: Se0/0 PPP: Sent CHAP LOGIN Request
*Mar 1 00:55:27.063: Se0/0 CHAP: Using hostname from unknown source
*Mar 1 00:55:27.063: Se0/0 CHAP: Using password from AAA
*Mar 1 00:55:27.063: Se0/0 CHAP: O RESPONSE id 51 len 23 from "R1"
*Mar 1 00:55:27.063: Se0/0 PPP: Received LOGIN Response PASS
*Mar 1 00:55:27.067: Se0/0 PPP: Sent LCP AUTHOR Request
*Mar 1 00:55:27.067: Se0/0 PPP: Sent IPCP AUTHOR Request
*Mar 1 00:55:27.067: Se0/0 LCP: Received AAA AUTHOR Response PASS
*Mar 1 00:55:27.067: Se0/0 IPCP: Received AAA AUTHOR Response PASS
*Mar 1 00:55:27.067: Se0/0 CHAP: O SUCCESS id 58 len 4
*Mar 1 00:55:27.079: Se0/0 CHAP: I SUCCESS id 51 len 4
*Mar 1 00:55:27.083: Se0/0 PPP: Sent CDPCP AUTHOR Request
*Mar 1 00:55:27.083: Se0/0 PPP: Sent IPCP AUTHOR Request
*Mar 1 00:55:27.083: Se0/0 CDPCP: Received AAA AUTHOR Response PASS
*Mar 1 00:55:28.079: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to up

All good now ... right lets rip it out and put EAP in now.

EAP authentication type

EAP is the most secure remote authentication method for PPP and is, as you would hope, relatively simple to implement. Like CHAP we also have to define the local username and password and reflect those credentials into the interface with identity (hostname) and password. The 'ppp eap local' statement informs the authentication process to lookup the username and password from the 'local' database - this is simply the username X password Y global configuration statement. The following configurations will enable the bi-directional setup in the same way as PAP and CHAP have shown. To enable one way either add the ‘callin’ keyword to the end of the ‘ppp authentication’ or else you can use the all powerful ‘ppp direction’ keyword to influence all of these protocols.

R1
username R2 password cisco
int s0/0
encapsulation ppp
ppp authentication eap
ppp eap identity R1
ppp eap password cisco
ppp eap local

R2
username R1 password cisco
int s0/0
encapsulation ppp
ppp authentication eap
ppp eap identity R2
ppp eap password cisco
ppp eap local

Thats the end of this tech article - thanks for reading and good luck in your studies.

View Comments
© 2011 defaultrouteuk.com

Cisco, IOS, CCNA, CCNP, CCIE are trademarks of Cisco Systems Inc.
JunOS, JNCIA, JNCIP, JNCIE are registered trademark of Juniper Networks Inc.