Content

| 4.6 |  | PPP and Layer 2 Considerations for Routed and Routing Protocols |
| 4.6.2 |  | Troubleshooting PPP authentication PAP |

Point-to-Point Protocol (PPP) currently supports two authentication protocols: Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP). Both are specified in RFC 1334 and are supported on synchronous and asynchronous interfaces.

PAP provides a simple method for a remote node to establish its identity using a two-way handshake. After the PPP link establishment phase is complete, a username and password pair is repeatedly sent by the remote node across the link (in clear text) until authentication is acknowledged, or until the connection is terminated.

PAP is not a secure authentication protocol. Passwords are sent across the link in clear text and there is no protection from playback or trail-and-error attacks. Another important consideration is that the remote node is in control of the frequency and timing of the login attempts.

Despite its shortcomings, PAP may be used in the following environments:

- A large installed base of client applications that do not support CHAP.
- Incompatibilities between different vendor implementations of CHAP.
- Situations where a plaintext password must be available to simulate a login at the remote host.

As with most types of authentication, PAP supports bi-directional, two way, and unidirectional, one way, authentication. With unidirectional authentication, only the side receiving the call authenticates the remote side (client). The remote client does not authenticate the server.

With bi-directional authentication, each side independently sends an Authenticate-Request (AUTH-REQ) and receives either an Authenticate-Acknowledge (AUTH-ACK) or Authenticate-Not Acknowledged (AUTH-NAK). These can be seen with the debug ppp authentication command.

In the debug output, the authentication was bi-directional. However if unidirectional authentication had been configured, only the first two debug lines would be shown.

Use the global configuration command username <username> password <password> to match a remote host. This is the username and password used by the local router to authenticate the PPP peer. When the peer sends its PAP username and password, the local router will check whether that username and password are configured locally. If there is a successful match, the peer is authenticated.

The function of the username command for PAP is different than its function for CHAP. With CHAP, this username and password are used to generate the response to the challenge, but PAP only uses it to verify that an incoming username and password are valid.

For one-way authentication, this command is only required on the called router. For two-way authentication this command is necessary on both sides.

Use the global configuration command PPP pap sent-username <username> password <password> to enable outbound PAP authentication. The local router uses the username and password specified by the ppp pap sent-username command to authenticate itself to a remote device. The other router must have this same username and password configured using the username command described above.

If one-way authentication is used, the command is only necessary on the router initiating the call. For two-way authentication this command must be configured on both sides.

To debug a PPP PAP issue use the debug ppp negotiation and debug ppp authentication commands. There are two main issues that must be considered:

- Do both sides agree that PAP is the method of authentication?
- If so, does the PAP authentication succeed?

Refer to the debugs in Figures and for an annotated, successful debug from the client and server side.

In certain configurations it may observed that the two sides do not agree on PAP as the authentication protocol, or instead agree on CHAP when PAP was desired. Use the following steps to troubleshoot these issues.

Verify that the router receiving the call has one of the following authentication commands:

- ppp authentication pap
- ppp authentication pap chap
- ppp authentication chap pap

Verify that the router making the call has ppp authentication pap callin configured when uni-directional authentication is desired.

Verify that the calling side has the command ppp pap sent-username username password password correctly configured. The username and password must match the one configured on the receiving router.

Use the interface configuration command ppp chap refuse on the calling router.

By default, Cisco routers will accept CHAP as the authentication protocol. In a situation where the client wishes to do PAP but the access server can do PAP or CHAP, the ppp chap refuse command can be used to force the client to accept PAP as the authentication protocol.

> Router(config)#interface BRI 0/0
> Router(config-if)#ppp chap refuse

If the two sides agree on PAP as the authentication protocol but the PAP connection fails, it is most likely a username and password issue:

Verify that the calling side has the command ppp pap sent-username username password password correctly configured, where the username and password match the one configured on the receiving router.

For two-way authentication, verify that the receiving side has the command ppp pap sent-username username password password correctly configured, where the username and password match the one configured on the calling router.

When doing two-way authentication, if the command ppp pap sent-username username password password were not present on the receiving router and the PPP client attempts to force the server to authenticate remotely, the output of debug ppp negotiation or debug ppp authentication would indicate:

> *Jan 3 16:47:20.259: Se0:1 PAP: Failed request for PAP credentials. Username maui-nas-06

This error message is an indication of a configuration issue and not necessarily a security breach.

Verify that the username and password matches the one configured in the command ppp pap sent-username username password password on the peer.

If they do not match the following message will be output:

> *Jan 3 17:18:57.559: Se0:3 PAP: I AUTH-REQ id 25 Len 18 from "PAPUSER"
> *Jan 3 17:18:57.559: Se0:3 PPP: Phase is FORWARDING
> *Jan 3 17:18:57.559: Se0:3 PPP: Phase is AUTHENTICATING
> *Jan 3 17:18:57.559: Se0:3 PAP: Authenticating peer PAPUSER
> *Jan 3 17:18:57.559: Se0:3 PAP: O AUTH-NAK id 25 Len 32 msg is
> "Password validation failure"

This is an outgoing AUTH-NAK. This means that the mismatch occurred on this router. Verify that the username and password configured locally is identical to that on the peer.