ICND2 200-105

ICND2 200-105

PPP authentication. PAP vs CHAP

Which PPP sub protocol provides us with authentication? You have a 50-50 chance for getting it right. It's either NCP or LCP, which one is it? It's LCP. And there are 2 types of authentication we can implement, Password Authentication Protocol, or PAP and Challenge Handshake Authentication Protocol, or CHAP. PAP, first point says, passwords sent in plain text. At this point in time, I just want to tell everybody, let's move on. It's not even worth discussing PAP if passwords are sent in plain text over the network. Somebody captures the authentication process that is happening, they will get your password and your username on top of that.

And there is no periodic mechanism in place that's going to check to make sure that you're still connected to the correct device at the other end. So somebody could have intercepted or injected the current connection that had happened. So it's not acceptable to use and we can see here. We're sending the username and password, and we're either accepting or rejecting it. So PAP, let's put it aside, it's not very secure. What do we want to use?

Well it sounds like a pretty friendly protocol, CHAP, Challenge Handshake Authentication Protocol is really what that stands for. So they sound kind of funny, right? PAP and CHAP. CHAP has this word challenge in it and that really is the interesting thing about it.

Hash values, what that means is, it's not encrypted. Encryption is different than hashing. When I hash something, it's like a cyclical redundancy check, but it's password protected also. And so, it's just a number that we spit out of an algorithm and that number tells us the validity of the information. We can also repeat this during an established conversation. Instead of just authenticating once when we form the conversation, we could say, hey, I've been talking to you for 24 hours, there is still a trusted router. You could do that, it's pretty amazing, it's pretty cool. So authentication on the fly in an established session. And now, let's get into the four or, excuse me, the three-step process. PAP is a two-way process, CHAP is three-way.

CHAP Authentication

Both routers can challenge each other and that's usually how we set this up, set up both routers to challenge each other. We're only showing one side of this. Challenge sent across, just a numeric value, say answer me this question based on this number, which is non-repeating. The response is the output of the hash algorithm that takes a few inputs: the username, the password, and the challenge spits him or puts him in through the grinder of the hash algorithm, spits out a response. The challenging router already knew the answer, and it validates the response against its predicted answer. And if that response is correct, we accept, if it's wrong, we reject. And then, our link goes up/up, by the way, if it's accepted. We stay up/down if it is rejected.

Configuring CHAP for PPP authentication

So configuring CHAP for PPP, these are the steps we'll have to go through. First and foremost, PPP has to be running on both devices. We're going to need appropriate host names. We'll have to setup usernames and passwords for the authentication process and then, turn on PPP authentication.

By default, what's the hostname of our routers? It's Router with capital R. Why is it important that I change my hostname here? Well there are so many reasons to change your hostname. Network documentation, so you don't get confused when you secure shell into a router and you're like, which router am I on? They're all "Router". But we also do that because this is used when the router identifies itself using a router-to-router authentication protocol. That's what we talked about here, CHAP, router-to-router authentication protocol over PPP on a serial link. So we should have that agree with the expected name on the far side's database of attaching users. Even though this is a device, we build a user that points to the far side router that is going to be authenticating against each other. So name your routers something that makes sense and keep it consistent, have a good documentation scheme, and it applies to authentication.

PPP with CHAP Configuration

RouterA(config)#hostname RouterA
RouterA(config)#username RouterB password C1sco123
RouterA(config)#interface Serial 0/0/0
RouterA(config-if)#ip address
RouterA(config-if)#encapsulation ppp
RouterA(config-if)#ppp authentication chap

RouterB(config)#hostname RouterB
RouterB(config)#username RouterA password C1sco123
RouterB(config)#interface Serial 0/0/0
RouterB(config-if)#ip address
RouterB(config-if)#encapsulation ppp
RouterB(config-if)#ppp authentication chap

So notice that next line of output that starts with username. username RouterB password C1sco123. What are we doing here? We're setting up a username and password inside of our local username and password database on router A, we're also doing that on router B. But you see that username, what is that specifically? Well it says RouterB, that's the hostname of router B. Any character strings that are not like a command or a named parameter of a command, any character strings are case sensitive in this Cisco operating system, whether those are passwords, names of things. So it is important here, don't goof that up.

Now the password, I'm looking at that for a second. I'm noticing they're the exact same on router A and B. Do they have to be the exact same on A and B? This is a shared password, shared key between them, okay, so they do have to match.

All right so, so far, so good. We still have to make sure that we are using PPP encapsulation and we're not using the default of HDLC. So encapsulation ppp, and then, we have to turn on ppp authentication. How do we do that? ppp authentication and then we specify whether we want to use pap or chap. In this case, we're configuring chap. So we specify chap explicitly.

Do we have to be on the same subnet? We certainly do, and that should be something you would want to look at if you ever had to troubleshoot WAN connections, yes there, they've got a chasm between them, but they're in the same subnet. That's how it needs to be. If authentication had failed, line protocol would be down. It's really the only new information from this output as we walk you through all of the key sections.

Verifying CHAP configuration

We really haven't spent much time looking at debugs at all in any of our discussions. But here, it's a great way for us to see that challenge and response process that is happening. Look at the beginning of this output, they're showing us that our interface is up right?

RouterA#show interfaces Serial 0/0/0
Serial0/0/0 is up, line protocol is up
  Hardware is GT96K Serial
  Internet address is
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
      reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation PPP, LCP Open
  Open: IPCP, CDPCP, loopback not set
  Keepalive set (10 sec)
  CRC checking enabled
  Last input 00:00:21, output 00:00:03, output hang never
  Last clearing of "show interface" counters 00:00:47
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: weighted fair
  Output queue: 0/1000/64/0 (size/max total/threshold/drops)
      Conversations 0/1/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 1158 kilobits/sec

We're up at layer 1, we're not up at layer 2. We're not up at layer 2 until we see line protocol on the interface is up. So right now, we just have that physical connectivity. Now we are going through the authentication process, and which sub protocol for PPP is responsible for that? LCP - Link Control Protocol. So we're in the link control protocol phase right now of establishing our connection for PPP, but we have to authenticate right now.

Let's look down at this. We have multiple challenges, we have multiple challenges. Why multiple challenges here? I notice an O and an I for these multiple challenges, what are those about, what's happening?

Feb 23 10:08:10.642: %LINK-3-UPDOWN: Interface Serial0/0/0, changed state to up
Feb 23 10:08:10.642: Se0/0/0 PPP: Using default call direction
Feb 23 10:08:10.642: Se0/0/0 PPP: Treating connection as a dedicated line
Feb 23 10:08:10.642: Se0/0/0 PPP: Session handle[CC000003] Session id[5]
Feb 23 10:08:10.642: Se0/0/0 PPP: Authorization required
Feb 23 10:08:10.674: Se0/0/0 CHAP: 0 CHALLENGE id 4 len 28 from ''RouterX''
Feb 23 10:08:10.718: Se0/0/0 CHAP: I CHALLENGE id 1 len 28 from ''RouterY''
Feb 23 10:08:10.718: Se0/0/0 CHAP: Using hostname from unknown source
Feb 23 10:08:10.718: Se0/0/0 CHAP: Using password from AAA
Feb 23 10:08:10.718: Se0/0/0 CHAP: 0 RESPONSE id 1 len 28 from ''RouterX''
Feb 23 10:08:10.722: Se0/0/0 CHAP: I RESPONSE id 4 len 28 from ''RouterY''
Feb 23 10:08:10.722: Se0/0/0 PPP: Sent CHAP LOGIN Request
Feb 23 10:08:10.726: Se0/0/0 PPP: Received LOGIN Response PASS
Feb 23 10:08:10.726: Se0/0/0 PPP: Sent LCP AUTHOR Request
Feb 23 10:08:10.726: Se0/0/0 PPP: Sent IPCP AUTHOR Request
Feb 23 10:08:10.726: Se0/0/0 LCP: Received AAA AUTHOR Response PASS
Feb 23 10:08:10.726: Se0/0/0 IPCP: Received AAA AUTHOR Response PASS
Feb 23 10:08:10.726: Se0/0/0 CHAP: 0 SUCCESS id 4 len 4
Feb 23 10:08:10.742: Se0/0/0 CHAP: I SUCCESS id 1 len 4
Feb 23 10:08:10.746: Se0/0/0 PPP: Sent CDPCP AUTHOR Request
Feb 23 10:08:10.746: Se0/0/0 CDPCP: Received AAA AUTHOR Response PASS
Feb 23 10:08:10.746: Se0/0/0 PPP: Sent IPCP AUTHOR Request-if)#
Feb 23 10:08:10.742: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/0, changed state to up

We got an out, we got an in and this is that two-way CHAP, both sides are challenging each other. So it's a two bidirectional three-step process that's the first, can see the challenge. Here's the cool thing about that. You might be able to detect like a case insensitivity problem here. If you're not succeeding, you could look at the character strings and you could go, well, wait a minute those don't match up, right? You could see maybe one person lowercased an X or a Y or an R, something that is more likely to occur in a real-world network. We've got our challenge, you can see the response, it's the answer, the mathematical answer to the challenge and then, I can see SUCCESS on both sides. Looks good, on protocol comes up after that point. And if we're addressed correctly, we'll be able to ping the other side and if we have routing setup, we'll know the networks that are beyond that point, and we will begin routing to the other side as well.