Introduction To ISDN: PAP

Why PAP Is a Core Piece of ISDN Authentication

When two ISDN links are established, the first question that comes to mind is how the routers on either side know they can trust each other. In the world of Cisco IOS, this trust is built using PPP authentication protocols, the most common of which are PAP and CHAP. PAP, short for Password Authentication Protocol, is the older and simpler of the two. It transmits a username and password in clear text over the data link, allowing the remote router to verify the credentials and decide whether to grant access to the network. While sending passwords in plain form is not ideal for production environments, it remains an important part of the ISDN toolbox because it demonstrates the fundamental mechanics of PPP authentication and provides a baseline for testing connectivity.

Unlike many modern authentication methods that emphasize encryption and challenge-response, PAP’s simplicity means that the entire authentication process is a single, straightforward exchange. The client router sends a username and password to the server router; the server then checks those values against its local database. If they match, the link is marked as authenticated and data traffic can flow. If not, the link drops. Because the password travels in the open, any eavesdropper on the line could, in theory, capture it. That is why most Cisco labs and training environments opt for PAP: it keeps the configuration minimal and lets students observe the negotiation steps without the added complexity of cryptographic calculations.

Even though PAP sends credentials in clear text, it still supports both unidirectional and bidirectional authentication. Unidirectional authentication means that router A can prove its identity to router B, while router B does not reciprocate. Bidirectional authentication, on the other hand, forces each side to verify the other. In practice, lab environments almost always use unidirectional authentication because the goal is to demonstrate how a single authentication event works, not to build a secure tunnel. However, understanding that bidirectional authentication is an available option is crucial for candidates preparing for real-world scenarios or advanced exams where both routers must authenticate each other.

The distinction between PAP and CHAP also becomes apparent when you consider how passwords are handled. With PAP, each side can use a different password. Router A might authenticate router B using its own password, and router B can use a separate password to authenticate router A. This flexibility simplifies configuration in asymmetric environments where each router’s local credential set is managed independently. In contrast, CHAP requires that both routers share a common secret. The reason is that CHAP uses a challenge-response mechanism; the server sends a random challenge, the client hashes the challenge together with the shared password, and then the server verifies the hash. Because the hash computation depends on the shared secret, both sides must have the same password for the negotiation to succeed.

Beyond the mechanics of username and password exchange, PAP’s role in ISDN extends to diagnostic visibility. By enabling debug commands such as debug ppp negotiation, network engineers can watch the entire authentication handshake unfold in real time. The debug output reveals the exact packets that carry the credentials, the sequence of events that leads to authentication success or failure, and the error messages that surface when mismatches occur. For students, this level of visibility demystifies the otherwise opaque PPP state machine and equips them with the confidence to troubleshoot authentication issues on live equipment.

Finally, PAP’s place in the certification curriculum is not merely historical. Cisco’s CCNA and CCNP exams still require candidates to configure and troubleshoot PAP on ISDN links. Because PAP is straightforward, it serves as an ideal stepping stone before moving on to the more complex CHAP protocol. Mastering PAP lays a foundation that covers user authentication, PPP encapsulation, interface configuration, and diagnostic debugging - skills that remain relevant across all Cisco certifications.

Configuring PAP on Cisco Routers: From Theory to Practice

Setting up PAP on a BRI interface follows a predictable sequence of commands. First, you must define the username and password pair that the router will use when authenticating a peer. In global configuration mode, the username command creates a local user database entry. The syntax is simple: username [remote-router] password [clear-text]. For example, if you’re configuring Router R1 to authenticate Router R2, you would type username R2 password CCNA. Remember that the username refers to the remote router’s name; it is not the local router’s hostname.

Next, navigate to the interface that connects to the ISDN line. For a BRI interface, this is usually interface bri0. Within this interface configuration mode, enable PPP encapsulation with encapsulation ppp. This command tells the router to use PPP framing on the line. Once PPP is enabled, you must specify the authentication method: ppp authentication pap. This tells the router to attempt PAP authentication whenever a PPP link is established.

Because PAP transmits credentials, the router needs to know what username and password to send to the peer. This is set with the ppp pap sent-username command. The syntax includes the username of the local router and the password it will use for the remote peer. For instance, after entering the interface context, you would enter ppp pap sent-username R1 password CISCO. The local router R1 will send the username “R1” and the password “CISCO” to the remote router R2 during the authentication phase.

Putting it all together, the configuration on Router R1 looks like this:

ppp pap sent-username R1 password CISCO

On Router R2, you would perform analogous steps, swapping the usernames and passwords accordingly. It’s common for lab configurations to use easily remembered strings such as “CCNA” and “CISCO” to avoid mistakes, but remember that in a production environment you should use strong, unique passwords.

After the configuration is complete, you should verify the link’s status with show interface bri0. Look for the Authentication succeeded message in the output. If the authentication fails, the interface will remain in the down state, and the debug output will reveal the cause - perhaps a typo in the username or a mismatch in the password.

To gain deeper insight, launch PPP negotiation debugging before bringing the link up. Execute debug ppp negotiation in privileged EXEC mode, then generate traffic by issuing a command that forces the PPP link to initiate. The debug trace will show the exchange of PAP packets, the server’s challenge, and the client’s response. Watching these packets in real time reinforces the conceptual model: the client sends username/password, the server checks, and the link either authenticates or tears down.

While PAP offers rapid deployment and low overhead, it is not suitable for environments where confidentiality is required. In those cases, CHAP or even EAP (Extensible Authentication Protocol) should replace PAP. However, the skill set gained by configuring PAP - understanding PPP encapsulation, setting authentication methods, managing user databases, and interpreting debug output - directly translates to more advanced protocols. Therefore, even seasoned engineers review PAP configurations periodically to ensure they remain comfortable with the foundational aspects of PPP authentication.