Once a PPP connection has been established and LCP has negotiated which authentication method(s) are available, an authentication protocol must be agreed upon and utilized. Those methods include Password Authentication Protocol (PAP), Challenge Handshake Authentication Protocol (CHAP) and Extensible Authentication Protocol (EAP). Due to the many flavors of EAP, I will not attempt to address those issues here.
PAP uses a simple two-way handshake only performed during the initiation of the connection. Once PPP LCP moves into the authentication phase, PAP passes the ID/Password pair in the clear (unencrypted) continuously until the authentication is acknowledged or the connection is terminated. The handshake may not be repeated during the resulting connection, which does not allow for replay protection. There is no specification in RFC as to how the password is stored on either end of the connection, but it must be available in plain text for both ends. Common implementation encrypts the password database for decryption during the authentication process.
CHAP is a much more robust authentication protocol and should be used whenever possible in place of PAP. Once LCP has negotiated for CHAP authentication, the authenticator (normally considered to be the server or device being connected to) sends a challenge packet consisting of challenge identifier number and a random number often called a “nonce” or just a challenge. The host device will then respond with a hash value created from the identifier, the password (called a “secret”) and the challenge. These three items will be concatenated (written end to end one after another) and hashed. The resultant message digest or hash value, will be returned to the authenticator in a packet that has the same identifier as the challenge. The reason for the identifier is to associate potential multiple unique challenges with this particular response. Upon receiving the response packet containing the message digest, the authenticator hashes the sent challenge identifier, the shared secret, and the sent challenge. The locally created message digest must be identical to the received message digest tin order to authenticate the host.
The creation of the hash value requires that the password be available in plain text to both ends of the authentication process. The secret is never sent across the wire in plain text, but must be maintained by both endpoints in a manner where the plaintext can be resolved i.e. plaintext or two way encrypted.
CHAP may be implemented in such a manner that the challenges may be periodically sent during the NCP phase. These challenges should be responded to by the host device. The random challenge itself prevents replay attacks while the option to resend the challenge is an aid to preventing session hijacking. The CHAP challenge may also be sent by the host device to authenticate the “server” side. This two way authentication could be used to set up a VPN or other communication path requiring mutual authentication, and is the default in many Cisco networking devices.
Cisco routers and other devices have an option to attempt multiple forms of authentication. This is NOT the recommended security setting. Each unique username should be allowed only one form of authentication, in our case either PAP or CHAP. PAP is the weaker and least advised authentication method. If a username is optioned to provide both PAP and CHAP authentication the secrets should be different. Remember CHAP send the password hashed and PAP in the clear. What good is it to use CHAP when other times PAP is used with the same clear text password? Always select CHAP or better yet EAP over PAP when possible.
