In this part, we will discuss about PPP authentication.
PPP Authentication – Password Authentication Protocol (PAP):
PPP PAP protocol provides a simple method of authentication using two way hand shake. PAP is not a secured protocol, as the username and password will be sent as clear text.
Configuring “ppp authentication pap” enables the local router to expect the remote device to provide identity before allowing data traffic.
“ppp pap sent-username
R1#sh run int s2/2
Building configuration...
Current configuration : 147 bytes
!
interface Serial2/2
ip address 150.1.13.1 255.255.255.0
encapsulation ppp
ppp authentication pap
ppp pap sent-username R1 password 0 R1 --> This username/password must match the local username database in R1
end
R1#sh run | inc user
username R3 password 0 R3
R1#
|----------------R3 Configs---------------|
R3#sh run int s2/2
Building configuration...
Current configuration : 147 bytes
!
interface Serial2/2
ip address 150.1.13.3 255.255.255.0
encapsulation ppp
ppp authentication pap
ppp pap sent-username R3 password 0 R3
end
R3#sh run | inc user
username R1 password 0 R1
R3#
R3(config-if)#do sh logg
Syslog logging: enabled (0 messages dropped, 1 messages rate-limited, 0 flushes, 0 overruns, xml disabled, filtering disabled)
Console logging: disabled
Monitor logging: level debugging, 0 messages logged, xml disabled,
filtering disabled
Buffer logging: level debugging, 2235 messages logged, xml disabled,
filtering disabled
Exception Logging: size (8192 bytes)
Count and timestamp logging messages: disabled
No active filter modules.
Trap logging: level informational, 96 message lines logged
Log Buffer (1000000 bytes):
01:50:44: %LINK-3-UPDOWN: Interface Serial2/2, changed state to up
01:50:44: Se2/2 PPP: Using default call direction
01:50:44: Se2/2 PPP: Treating connection as a dedicated line
01:50:44: Se2/2 PPP: Phase is ESTABLISHING, Active Open [0 sess, 2 load]
01:50:44: Se2/2 LCP: O CONFREQ [Closed] id 151 len 14
01:50:44: Se2/2 LCP: AuthProto PAP (0x0304C023)
01:50:44: Se2/2 LCP: MagicNumber 0x0172169F (0x05060172169F)
01:50:44: Se2/2 LCP: I CONFREQ [REQsent] id 183 len 14
01:50:44: Se2/2 LCP: AuthProto PAP (0x0304C023)
01:50:44: Se2/2 LCP: MagicNumber 0x007219E6 (0x0506007219E6)
01:50:44: Se2/2 LCP: O CONFACK [REQsent] id 183 len 14
01:50:44: Se2/2 LCP: AuthProto PAP (0x0304C023)
01:50:44: Se2/2 LCP: MagicNumber 0x007219E6 (0x0506007219E6)
01:50:44: Se2/2 LCP: I CONFACK [ACKsent] id 151 len 14
01:50:44: Se2/2 LCP: AuthProto PAP (0x0304C023)
01:50:44: Se2/2 LCP: MagicNumber 0x0172169F (0x05060172169F)
01:50:44: Se2/2 LCP: State is Open
01:50:44: Se2/2 PPP: Phase is AUTHENTICATING, by both [0 sess, 1 load]
01:50:44: Se2/2 PAP: O AUTH-REQ id 11 len 10 from "R3"
01:50:44: Se2/2 PAP: I AUTH-REQ id 11 len 10 from "R1"
01:50:44: Se2/2 PAP: I AUTH-ACK id 11 len 5
01:50:44: Se2/2 PAP: Authenticating peer R1
01:50:44: Se2/2 PAP: O AUTH-ACK id 11 len 5
01:50:44: Se2/2 PPP: Phase is UP [0 sess, 1 load]
01:50:44: Se2/2 IPCP: O CONFREQ [Closed] id 6 len 10
01:50:44: Se2/2 IPCP: Address 150.1.13.3 (0x030696010D03)
01:50:44: Se2/2 CDPCP: O CONFREQ [Closed] id 6 len 4
01:50:44: Se2/2 IPCP: I CONFREQ [REQsent] id 4 len 10
01:50:44: Se2/2 IPCP: Address 150.1.13.1 (0x030696010D01)
01:50:44: Se2/2 IPCP: O CONFACK [REQsent] id 4 len 10
01:50:44: Se2/2 IPCP: Address 150.1.13.1 (0x030696010D01)
01:50:44: Se2/2 CDPCP: I CONFREQ [REQsent] id 4 len 4
01:50:44: Se2/2 CDPCP: O CONFACK [REQsent] id 4 len 4
01:50:44: Se2/2 IPCP: I CONFACK [ACKsent] id 6 len 10
01:50:44: Se2/2 IPCP: Address 150.1.13.3 (0x030696010D03)
01:50:44: Se2/2 IPCP: State is Open
01:50:44: Se2/2 IPCP: Install route to 150.1.13.1
01:50:44: Se2/2 CDPCP: I CONFACK [ACKsent] id 6 len 4
01:50:44: Se2/2 CDPCP: State is Open
01:50:45: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial2/2, changed state to up
R3(config-if)#
Troubleshooting PAP:
When the authentication protocol at either side is PAP and if there is an authentication failure, mostly the reason might be username/password mismatch.
In the below example, we have misconfigured the username database with wrong password
R1(config)#no username R3 password 0 R3
R1(config)#username R3 password r3
R1(config)#int s2/2
R1(config-if)#shut
R1(config-if)#no shut
The below debug output shows, outgoing AUTH-NAK which indicates the local username database doesn’t match the username/password sent by remote router.
It also shows, incoming AUTH-ACK which indicates the username/password sent by local router is being authenticated by remote router.
R1(config-if)#do sh logg
02:19:46: Se2/2 PPP: Using default call direction
02:19:46: Se2/2 PPP: Treating connection as a dedicated line
02:19:46: %LINK-3-UPDOWN: Interface Serial2/2, changed state to up
02:19:46: Se2/2 PAP: I AUTH-REQ id 113 len 10 from "R3"
02:19:46: Se2/2 PAP: O AUTH-REQ id 113 len 10 from "R1"
02:19:46: Se2/2 PAP: Authenticating peer R3
02:19:46: Se2/2 PAP: O AUTH-NAK id 113 len 27 msg is "Authentication failure"Bad password defined for username R3
02:19:48: Se2/2 PAP: O AUTH-REQ id 114 len 10 from "R1"
02:19:48: Se2/2 PAP: I AUTH-REQ id 114 len 10 from "R3"
02:19:48: Se2/2 PAP: Authenticating peer R3
02:19:48: Se2/2 PAP: O AUTH-NAK id 114 len 27 msg is "Authentication failure"Bad password defined for username R3
02:19:50: Se2/2 PAP: O AUTH-REQ id 115 len 10 from "R1"
02:19:50: Se2/2 PAP: I AUTH-REQ id 115 len 10 from "R3"
02:19:50: Se2/2 PAP: I AUTH-ACK id 115 len 5
02:19:50: Se2/2 PAP: Authenticating peer R3
02:19:50: Se2/2 PAP: O AUTH-NAK id 115 len 27 msg is "Authentication failure"Bad password defined for username R3
02:19:52: Se2/2 PAP: O AUTH-REQ id 116 len 10 from "R1"
PPP Authentication – Challenge Handshake Authentication Protocol (CHAP):
CHAP is more secured protocol than PAP as it doesn’t send the password for authentication as such. Instead it sends a challenge message to remote device. The remote device will encrypt the same with shared secret using MD5 function and return the value to authenticator. The authenticator on receiving the value will use the shared secret and encrypt the proginal challenge message and verify if both values matches.
As either side will use a shared secret to encrypt the challenge message, this shared secret should be the same on both router.
R3(config)#do sh run int s2/2
Building configuration...
Current configuration : 135 bytes
!
interface Serial2/2
ip address 150.1.13.3 255.255.255.0
encapsulation ppp
ppp authentication chap
ppp chap password 0 CISCO
end
R3(config)#
R3(config)#do sh run | inc user
username R1 password 0 CISCO
R3(config)#
|-------R1Configs-----|
R1(config-if)#do sh run int s2/2
Building configuration...
Current configuration : 135 bytes
!
interface Serial2/2
ip address 150.1.13.1 255.255.255.0
encapsulation ppp
ppp authentication chap
ppp chap password 0 CISCO
end
R1(config-if)#
R1(config-if)#do sh run | inc user
username R3 password 0 CISCO
R1(config-if)#
R3(config)#do sh logg
No active filter modules.
Trap logging: level informational, 104 message lines logged
Log Buffer (1000000 bytes):
02:37:01: Se2/2 CHAP: O CHALLENGE id 42 len 23 from "R3" --> Challenge message sent to R1
02:37:01: Se2/2 CHAP: I CHALLENGE id 40 len 23 from "R1"
02:37:01: Se2/2 CHAP: O RESPONSE id 40 len 23 from "R3" --> Received the encrypted value from R1 using shared secret
02:37:01: Se2/2 CHAP: I RESPONSE id 42 len 23 from "R1"
02:37:01: Se2/2 CHAP: I SUCCESS id 40 len 4 --> Verify the encrypted value
02:37:02: Se2/2 CHAP: O SUCCESS id 42 len 4
R3(config)#
By default the login name or the hostname sent with the encrypted value to the authenticator will be the hostname of the authenticating router. The authenticator will use this hostname to get the shared key from local username database. If the username database is configured with different username, we need to explicitly configure the authenticating router using “ppp chap hostname
We will modify the username databse of R3 with different hostname for R1 as below,
R3(config)#no username R1 password 0 CISCO
R3(config)#user
R3(config)#username RR1 passw
R3(config)#username RR1 password CISCO
The debug output below shows, incoming CHAP FAILURE from R3.
R1(config-if)#do sh logg
Log Buffer (100000 bytes):
02:48:52: %LINK-5-CHANGED: Interface Serial2/2, changed state to administratively down
02:48:53: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial2/2, changed state to down
02:49:17: Se2/2 PPP: Using default call direction
02:49:17: Se2/2 PPP: Treating connection as a dedicated line
02:49:17: %LINK-3-UPDOWN: Interface Serial2/2, changed state to up
02:49:17: Se2/2 CHAP: O CHALLENGE id 41 len 23 from "R1"
02:49:17: Se2/2 CHAP: I CHALLENGE id 43 len 23 from "R3"
02:49:17: Se2/2 CHAP: O RESPONSE id 43 len 23 from "R1"
02:49:17: Se2/2 CHAP: I RESPONSE id 41 len 23 from "R3"
02:49:17: Se2/2 CHAP: O SUCCESS id 41 len 4
02:49:17: Se2/2 CHAP: I FAILURE id 43 len 26 msg is "Authentication failure"
Now changing the chap hostname in R1 will make the authentication successful.
R1(config-if)#int s2/2
R1(config-if)#ppp chap hostname RR1
R1(config-if)#no shut
R1(config-if)#do sh logg
Log Buffer (100000 bytes):
02:51:08: %LINK-5-CHANGED: Interface Serial2/2, changed state to administratively down
02:51:20: Se2/2 PPP: Using default call direction
02:51:20: Se2/2 PPP: Treating connection as a dedicated line
02:51:20: %LINK-3-UPDOWN: Interface Serial2/2, changed state to up
02:51:20: Se2/2 CHAP: Using alternate hostname RR1
02:51:20: Se2/2 CHAP: O CHALLENGE id 82 len 24 from "RR1"
02:51:20: Se2/2 CHAP: I CHALLENGE id 84 len 23 from "R3"
02:51:20: Se2/2 CHAP: Using alternate hostname RR1
02:51:20: Se2/2 CHAP: O RESPONSE id 84 len 24 from "RR1"
02:51:20: Se2/2 CHAP: I RESPONSE id 82 len 23 from "R3"
02:51:20: Se2/2 CHAP: I SUCCESS id 84 len 4
02:51:20: Se2/2 CHAP: O SUCCESS id 82 len 4
02:51:21: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial2/2, changed state to up
R1(config-if)#
Unidirectional Authentication:
There is a common misunderstanding that PPP authentication should be bidirectional. Both PAP and CHAP supports unidirectional authentication. (i.e.) local router authenticating remote router, but remote router doesn’t authenticate the local router. This is common in dialup scenario where the server will authenticate the client, but the client doesn’t.
In the below example, R1 is act as server and R3 as client.
R1(config-if)#do sh run int s2/2
Building configuration...
Current configuration : 108 bytes
!
interface Serial2/2
ip address 150.1.13.1 255.255.255.0
encapsulation ppp
ppp authentication chap --> This command specifies the router as authenticator
end
R1(config-if)#
R3(config-if)#do sh run int s2/2
Building configuration...
Current configuration : 110 bytes
!
interface Serial2/2
ip address 150.1.13.3 255.255.255.0
encapsulation ppp
ppp chap password 0 CISCO à This command specifies the router as client
end
R3(config-if)#
The debug logs shows that R3 which is the client receives CHALLENGE message from the server (R1). But it doesn’t send any CHALLENGE to R1
R3(config-if)#do sh logg
Trap logging: level informational, 110 message lines logged
Log Buffer (1000000 bytes):
03:00:20: %LINK-3-UPDOWN: Interface Serial2/2, changed state to up
03:00:20: Se2/2 PPP: Using default call direction
03:00:20: Se2/2 PPP: Treating connection as a dedicated line
03:00:20: Se2/2 CHAP: I CHALLENGE id 83 len 23 from "R1"
03:00:20: Se2/2 CHAP: Username R1 not found
03:00:20: Se2/2 CHAP: Using default password
03:00:20: Se2/2 CHAP: O RESPONSE id 83 len 23 from "R3"
03:00:20: Se2/2 CHAP: I SUCCESS id 83 len 4
03:00:21: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial2/2, changed state to up
R3(config-if)#
As it is now clear that authentication need not be bidirectional, it is possible to have different authentication protocol at either direction between routers. (i.e.) R1 authenticate R3 using CHAP and R3 authenticate R1 using PAP.
As R3 is authenticating R1 using PAP, it expects PAP messages from R1
As R1 is authenticating R3 using CHAP, it sends a CHALLENGE message to R3 and will expect the encrypted CHAP value from R3.
R1(config-if)#do sh run int s2/2
Building configuration...
Current configuration : 153 bytes
!
interface Serial2/2
ip address 150.1.13.1 255.255.255.0
encapsulation ppp
ppp authentication chap
ppp pap sent-username ROUTER1 password 0 R1
end
R1(config-if)#do sh run | inc user
username R3 password 0 CISCO
R1(config-if)#
|----------R3 Configs----------------|
R3(config-if)#do sh run int s2/2
Building configuration...
Current configuration : 134 bytes
!
interface Serial2/2
ip address 150.1.13.3 255.255.255.0
encapsulation ppp
ppp authentication pap
ppp chap password 0 CISCO
end
R3(config-if)#do sh run | inc user
username ROUTER1 password 0 R1
R3(config-if)#
In the below logs, It can be noted that R1 sends CHALLENGE message to R3 and R3 using PAP to authenticate R3
R1#show logg
Log Buffer (100000 bytes):
04:22:53: %LINK-5-CHANGED: Interface Serial2/2, changed state to administratively down
04:22:54: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial2/2, changed state to down
04:23:23: %LINK-3-UPDOWN: Interface Serial2/2, changed state to up
04:23:23: Se2/2 PPP: Using default call direction
04:23:23: Se2/2 PPP: Treating connection as a dedicated line
04:23:25: Se2/2 CHAP: O CHALLENGE id 159 len 23 from "R1"
04:23:25: Se2/2 PAP: O AUTH-REQ id 64 len 15 from "ROUTER1"
04:23:25: Se2/2 CHAP: I RESPONSE id 159 len 23 from "R3"
04:23:25: Se2/2 PAP: I AUTH-ACK id 64 len 5
04:23:25: Se2/2 CHAP: O SUCCESS id 159 len 4
04:23:26: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial2/2, changed state to up
04:24:37: %SYS-5-CONFIG_I: Configured from console by console
R1#
|-------------------R3 Logs------------------|
R3#show logg
Log Buffer (1000000 bytes):
04:23:24: Se2/2 PPP: Using default call direction
04:23:24: Se2/2 PPP: Treating connection as a dedicated line
04:23:24: %LINK-3-UPDOWN: Interface Serial2/2, changed state to up
04:23:24: Se2/2 CHAP: I CHALLENGE id 159 len 23 from "R1"
04:23:24: Se2/2 PAP: I AUTH-REQ id 64 len 15 from "ROUTER1"
04:23:25: Se2/2 CHAP: Username R1 not found
04:23:25: Se2/2 CHAP: Using default password
04:23:25: Se2/2 CHAP: O RESPONSE id 159 len 23 from "R3"
04:23:25: Se2/2 PAP: Authenticating peer ROUTER1
04:23:25: Se2/2 PAP: O AUTH-ACK id 64 len 5
04:23:25: Se2/2 CHAP: I SUCCESS id 159 len 4
04:23:26: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial2/2, changed state to up
04:24:57: %SYS-5-CONFIG_I: Configured from console by console
R3#
As per RFC 1994, the disadvantage with CHAP is, it requires the shared secret to be in clear text in username database (in local router). In the above example, if we configure “username R3 secret CISCO” in R1, it will encrypt the password and save in username database which is irreversible. So CHAP will not be able to use this shared secret to verify the response from remote router and authentication will fail.
No comments:
Post a Comment