CCIE TO BE

I had a task this weekend that asked to authenticate PPP via Md5. I did a context sensitive help and saw this:

R2(config-if)#ppp authentication ?
chap Challenge Handshake Authentication Protocol (CHAP)
eap Extensible Authentication Protocol (EAP)
ms-chap Microsoft Challenge Handshake Authentication Protocol (MS-CHAP)
ms-chap-v2 Microsoft CHAP Version 2 (MS-CHAP-V2)
pap Password Authentication Protocol (PAP)

Doesn't look like there is an Md5 option...or is there? I looked up the ppp authentication commands in the DocCD:

-12.4 Mainline
-Master Index
-Cisco IOS Master Command List, All Releases
-ppp authentication MWP-147, SEC-1481

Click the SEC-1481 link

Now is where I used the browser search to look for "Md5." Not sure if this is possible in the lab so you may have to quickly scan with your eyes. The only hit comes up under "ppp eap local" command. You will see this phrase:

"In local mode, the EAP session is authenticated using the MD5 algorithm and obeys the same authentication rules as does Challenge Handshake Authentication Protocol (CHAP)."

Voila!

So now that we know what mode we need everything else is easy, and it works just like CHAP. On both sides:

username R5 password cisco

interface Serial1/1
ip address 150.100.25.2 255.255.255.0
encapsulation ppp
ppp authentication eap
ppp eap password 0 cisco
ppp eap local

Always verify just to make sure it's working:

R2#debug ppp authentication

*Mar 1 00:34:34.779: Se1/1 PPP: Using default call direction
*Mar 1 00:34:34.783: Se1/1 PPP: Treating connection as a dedicated line
*Mar 1 00:34:34.783: Se1/1 PPP: Session handle[9700001A] Session id[32]
*Mar 1 00:34:34.787: Se1/1 PPP: Authorization required
*Mar 1 00:34:34.967: Se1/1 EAP: O REQUEST IDENTITY id 50 len 5
*Mar 1 00:34:35.015: Se1/1 EAP: I REQUEST IDENTITY id 19 len 5
*Mar 1 00:34:35.015: Se1/1 EAP: O RESPONSE IDENTITY id 19 len 7 from "R2"
*Mar 1 00:34:35.123: Se1/1 EAP: I RESPONSE IDENTITY id 50 len 7 from "R5"
*Mar 1 00:34:35.127: Se1/1 EAP: O REQUEST MD5 id 51 len 24 from "R2"
*Mar 1 00:34:35.131: Se1/1 EAP: I REQUEST MD5 id 20 len 24 from "R5"
*Mar 1 00:34:35.147: Se1/1 EAP: Using hostname from unknown source
*Mar 1 00:34:35.151: Se1/1 EAP: Using password from interface EAP
*Mar 1 00:34:35.151: Se1/1 EAP: O RESPONSE MD5 id 20 len 24 from "R2"
*Mar 1 00:34:35.435: Se1/1 EAP: I RESPONSE MD5 id 51 len 24 from "R5"
*Mar 1 00:34:35.451: Se1/1 PPP: Sent CHAP LOGIN Request
*Mar 1 00:34:35.455: Se1/1 EAP: I SUCCESS id 20 len 4
*Mar 1 00:34:35.463: Se1/1 PPP: Received LOGIN Response PASS
*Mar 1 00:34:35.475: Se1/1 PPP: Sent LCP AUTHOR Request
*Mar 1 00:34:35.483: Se1/1 PPP: Sent IPCP AUTHOR Req
*Mar 1 00:34:35.495: Se1/1 LCP: Received AAA AUTHOR Response PASS
*Mar 1 00:34:35.499: Se1/1 IPCP: Received AAA AUTHOR Response PASS
*Mar 1 00:34:35.499: Se1/1 EAP: O SUCCESS id 51 len 4
*Mar 1 00:34:35.507: Se1/1 PPP: Sent CDPCP AUTHOR Request
*Mar 1 00:34:35.519: Se1/1 CDPCP: Received AAA AUTHOR Response PASS
*Mar 1 00:34:35.543: Se1/1 PPP: Sent IPCP AUTHOR Request

*Mar 1 00:34:36.503: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/1, changed state to up

You can see above that we have incoming and outgoing MD5 reposnses and the requests pass.

I didn't have time for any of the security tasks in Mock Lab 1. There were 3 for a total of 9 points. Again, the lab sessions run 7:45 and I had to load initial configs and eat dinner! Had I been able to use the full 8 hours, I am sure I would have gotten 1 or 2 of these tasks.

Here is the gist of the first security task, 9.1:

R9 should accept telnet on port 3005.
It should not allow telnet on port 23.
Configure a local user cisco with password of cisco and privilege level 15.
Telnet should require a login, but console access should not

I am going to use R5 as an example since I already have it up in Dynamips. First, to allow telnet on port 3005 use the rotary command:

R5(config)#username cisco privilege 15 password cisco
R5(config-line)#line vty 5
R5(config-line)#rotary 5
R5(config-line)#login local

Next we create an ACL to block telnet to port 23:

R5(config)#access-list 101 deny tcp any any eq telnet
R5(config)#access-list 101 permit ip any any
R5(config)#line vty 0 ?
<1-935> Last Line number


R5(config)#line vty 0 935
R5(config-line)#access-class 101 in

Let's try from R4:

R4#telnet 141.141.45.5
Trying 141.141.45.5 ...
% Connection refused by remote host

R4#telnet 141.141.45.5 3005
Trying 141.141.45.5, 3005 ... Open


User Access Verification

Username: cisco
Password:
R5#

Now we have already satisfied the last requirement right? "Telnet should require a login, but console access should not." But for some reason the proctor guide goes a step further and creates an aaa method for VTY while console uses the default. Here's what they have:

R5(config)#aaa new-model
R5(config)#aaa authentication login VTY local
R5(config)#aaa authentication login default none
R5(config)#line vty 5
R5(config-line)#login authentication VTY

The first command tells the router to enable the aaa commands. The second command defines a login list called VTY. Note that this is not used anywhere until it is applied in the last command. The third command configures that default login method to be "none" or no authentication. This method is applied to the console by default.

This is scenario 3 dealing with NTP and in this post I will set up NTP authentication. Remember that the purpose is for the client to authenticate the server. First will make sure NTP is synchronized on the client. Next, we will turn on authentication on the client only until the clocks become unsynchronized. Finally, we will configure the server with the appropriate key and make sure the client is synchronized again.

We use the same topology as the other NTP scenarios:
R4, R5 and R6 connected via full mesh frame-relay on subnet 172.12.45.0/24

Let's make sure R6, the master, is synchronized first:

R6#show clock
20:14:37.215 MDT Mon Jun 2 2008

R6#show ntp status | inc Clock is
Clock is synchronized, stratum 2, reference is 127.127.7.1

R4:

R4#show ntp status | in Clock
Clock is synchronized, stratum 3, reference is 172.12.45.6

and R5:

R5#show ntp status | inc Clock
Clock is synchronized, stratum 3, reference is 172.12.45.6

Let's configure authentication on R4:

R4(config)#ntp authenticate
R4(config)#ntp authentication-key 1 md5 cisco
R4(config)#ntp trusted-key 1
R4(config)#ntp server 172.12.45.6 key 1

R4#debug ntp validity
NTP peer validity debugging is on
R4#debug ntp authentication
NTP authentication debugging is on

In a few moments we get these debug messages:

R4(config)#
Jun 3 03:24:49.759: NTP: packet from 172.12.45.6 failed validity tests 10
Jun 3 03:24:49.763: Authentication failed
R4(config)#

What's strange is that R4 is still synchronized with R6:

R4#show ntp status
Clock is synchronized, stratum 3, reference is 172.12.45.6

So I waited about 10 minutes (it seemed that long) and now R4 is unsynchronized:

R4#show ntp status | inc Clock
Clock is unsynchronized, stratum 16, no reference clock

Now let's configure NTP authentication on R6:

R6(config)#ntp authenticate
R6(config)#ntp authentication-key 1 md5 cisco

On R4 I will set up some debugging, a lot of the output doesn't make much sense, but here it is:

R4#debug ntp packets
NTP packets debugging is on

!! HERE R4 TRANSMITS A PACKET WITH AUTHENTICATION-KEY 1

.Jun 3 03:36:10.711: NTP: xmit packet to 172.12.45.6:
.Jun 3 03:36:10.715: leap 3, mode 3, version 3, stratum 0, ppoll 64
.Jun 3 03:36:10.715: rtdel 0D4E (51.971), rtdsp 05CD (22.659), refid AC0C2D06 (172.12.45.6)
.Jun 3 03:36:10.719: ref CBEF37C1.C8A9606E (20:23:45.783 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.719: org CBEF3A6A.BF8D3204 (20:35:06.748 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.723: rec CBEF3A6A.C784D317 (20:35:06.779 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.723: xmt CBEF3AAA.B614DB93 (20:36:10.711 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.727: Authentication key 1

!! HERE R4 RECEIVES A PACKET WITH AUTHENTICATION-KEY 1

.Jun 3 03:36:10.771: NTP: rcv packet from 172.12.45.6 to 172.12.34.4 on FastEthernet0/1:
.Jun 3 03:36:10.775: leap 0, mode 4, version 3, stratum 2, ppoll 64
.Jun 3 03:36:10.779: rtdel 0000 (0.000), rtdsp 0002 (0.031), refid 7F7F0701 (127.127.7.1)
.Jun 3 03:36:10.779: ref CBEF3A89.50E1C8AB (20:35:37.315 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.783: org CBEF3AAA.B614DB93 (20:36:10.711 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.783: rec CBEF3AAA.C3941C78 (20:36:10.763 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.787: xmt CBEF3AAA.C39DD400 (20:36:10.764 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.791: inp CBEF3AAA.C565D38F (20:36:10.771 MDT Mon Jun 2 2008)
.Jun 3 03:36:10.791: Authentication key 1

R4 is now synchronized:

R4#show ntp status
Clock is synchronized, stratum 3, reference is 172.12.45.6
nominal freq is 250.0000 Hz, actual freq is 250.0004 Hz, precision is 2**18
reference time is CBEF3AAA.C565D38F (20:36:10.771 MDT Mon Jun 2 2008)
clock offset is 22.8825 msec, root delay is 59.68 msec
root dispersion is 15897.92 msec, peer dispersion is 15875.02 msec

Let's check R5 to see if it is still synchronized:

R5#show ntp status | inc Clock
Clock is synchronized, stratum 3, reference is 172.12.45.6

As you can see, R5 is still synchronized because it is not requesting authentication from R6. R4 on the other sends the request with an authentication key and requires that the time-source, R6, does so as well.

Well, this lab went okay. I have had many problems with ntp authentication before. Initially, I thought I would have problems again when R4 was not un-synchronizing with R6 when we first set up a key on R4. Well, it took a few minutes, so I guess patience is this key. You can't afford to be too patient though, you only have 8 hours on lab day :)

Atom

Atom