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
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
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.
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.
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,
The debug output below shows, incoming CHAP FAILURE from R3.
Now changing the chap hostname in R1 will make the authentication successful.
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.
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
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.
In the below logs, It can be noted that R1 sends CHALLENGE message to R3 and R3 using PAP to authenticate 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.