Next: The CHAP Secrets File Up: Authentication with PPP Previous: Authentication with PPP

CHAP versus PAP

With PPP, each system may require its peer to authenticate itself using one of two authentication protocols.
These are the Password Authentication Protocol (PAP), and the Challenge Handshake Authentication
Protocol (CHAP). When a connection is established, each end can request the other to authenticate itself,
regardless of whether it is the caller or the callee. Below I will loosely talk of `client' and `server' when I
want to distinguish between the authenticating system and the authenticator. A PPP daemon can ask its peer
for authentication by sending yet another LCP configuration request identifying the desired authentication
protocol.

PAP works basically the same way as the normal login procedure. The client authenticates itself by sending a
user name and an (optionally encrypted) password to the server, which the server compares to its secrets
database. This technique is vulnerable to eavesdroppers who may try to obtain the password by listening in
on the serial line, and to repeated trial and error attacks.

CHAP does not have these deficiencies. With CHAP, the authenticator (i.e. the server) sends a randomly
generated ``challenge'' string to the client, along with its hostname. The client uses the hostname to look up
the appropriate secret, combines it with the challenge, and encrypts the string using a one-way hashing
function. The result is returned to the server along with the client's hostname. The server now performs the
same computation, and acknowledges the client if it arrives at the same result.

Another feature of CHAP is that it doesn't only require the client to authenticate itself at startup time, but
sends challenges at regular intervals to make sure the client hasn't been replaced by an intruder, for instance
by just switching phone lines.

pppd keeps the secret keys for CHAP and PAP in two separate files, called /etc/ppp/chap-secrets and pap-
secrets, respectively. By entering a remote host in one or the other file, you have a fine control over whether
CHAP or PAP is used to authenticate ourselves with our peer, and vice versa.

By default, pppd doesn't require authentication from the remote, but will agree to authenticate itself when
requested by the remote. As CHAP is so much stronger than PAP, pppd tries to use the former whenever
possible. If the peer does not support it, or if pppd can't find a CHAP secret for the remote system in its chap-
secrets file, it reverts to PAP. If it doesn't have a PAP secret for its peer either, it will refuse to authenticate
altogether. As a consequence, the connection is closed down.

This behavior can be modified in several ways. For instance, when given the auth keyword, pppd will require
the peer to authenticate itself. pppd will agree to use either CHAP or PAP for this, as long as it has a secret
for the peer in its CHAP or PAP database, respectively. There are other options to turn a particular
authentication protocol on or off, but I won't describe them here. Please refer to the pppd(8) manual page for
details.

If all systems you talk PPP with agree to authenticate themselves with you, you should put the auth option in
the global /etc/ppp/options file and define passwords for each system in the chap-secrets file. If a system
doesn't support CHAP, add an entry for it to the pap-secrets file. In this way, you can make sure no
unauthenticated system connects to your host.

The next two sections discuss the two PPP secrets files, pap-secrets and chap-secrets. They are located in
/etc/ppp and contain triples of clients, servers and passwords, optionally followed by a list of IP-addresses.
The interpretation of the client and server fields is different for CHAP and PAP, and also depends on whether
we authenticate ourselves with the peer, or whether we require the server to authenticate itself with us.

Next: The CHAP Secrets File Up: Authentication with PPP Previous: Authentication with PPP
Andrew Anderson
Thu Mar 7 23:22:06 EST 1996