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 username 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. There are other options to turn a particular authentication protocol on or off, but I won't describe them here.
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. 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 triplets 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.
When it has to authenticate itself with some server using CHAP, pppd searches the chap-secrets file for an entry with the client field equal to the local hostname, and the server field equal to the remote hostname sent in the CHAP challenge. When requiring the peer to authenticate itself, the roles are simply reversed: pppd will then look for an entry with the client field equal to the remote hostname (sent in the client's CHAP response), and the server field equal to the local hostname.
The following is a sample chap-secrets file for vlager: 
 The double quotes are not part of the password; they merely serve to protect the white space within the password.
# CHAP secrets for vlager.vbrew.com # # client server secret addrs #---------------------------------------------------------------------- vlager.vbrew.com c3po.lucas.com "Use The Source Luke" vlager.vbrew.com c3po.lucas.com vlager.vbrew.com "riverrun, pasteve" c3po.lucas.com * vlager.vbrew.com "VeryStupidPassword" pub.vbrew.com
When establishing a PPP connection with c3po, c3po asks vlager to authenticate itself by sending a CHAP challenge. pppd then scans chap-secrets for an entry with the client field equal to vlager.vbrew.com and the server field equal to c3po.lucas.com,  and finds the first line shown above. It then produces the CHAP response from the challenge string and the secret (Use The Source Luke), and sends it off to c3po.
 This hostname is taken from the CHAP challenge.
At the same time, pppd composes a CHAP challenge for c3po containing a unique challenge string and its fully qualified hostname vlager.vbrew.com. c3po constructs a CHAP response in the manner we just discussed, and returns it to vlager. pppd now extracts the client hostname (c3po.vbrew.com) from the response and searches the chap-secrets file for a line matching c3po as a client and vlager as the server. The second line does this, so pppd combines the CHAP challenge and the secret riverrun, pasteve, encrypts them, and compares the result to c3po's CHAP response.
The optional fourth field lists the IP addresses that are acceptable for the clients named in the first field. The addresses can be given in dotted quad notation or as hostnames that are looked up with the resolver. For instance, if c3po requests to use an IP address during IPCP negotiation that is not in this list, the request will be rejected, and IPCP will be shut down. In the sample file shown above, c3po is therefore limited to using its own IP address. If the address field is empty, any addresses will be allowed; a value of ``-'' prevents the use of IP with that client altogether.
The third line of the sample chap-secrets file allows any host to establish a PPP link with vlager because a client or server field of * is a wildcard matching any hostname. The only requirement is that it knows the secret and uses the address of pub.vbrew.com. Entries with wildcard hostnames may appear anywhere in the secrets file, since pppd will always use the most specific entry that applies to a server/client pair.
pppd may need some help forming hostnames. As explained before, the remote hostname is always provided by the peer in the CHAP challenge or response packet. The local hostname will be derived by calling the gethostname(2) function by default. If you have set the system name to your unqualified hostname, you have to provide pppd with the domain name in addition using the domain option:
# pppd ... domain vbrew.com
This will append the Brewery's domain name to vlager for all authentication-related activities. Other options that modify pppd's idea of the local hostname are usehostname and name. When you give the local IP address on the command line using local:remote, and local is a name instead of a dotted quad, pppd will use this as the local hostname.
The PAP secrets file is very similar to that used by CHAP. The first two fields always contain a username and a server name; the third holds the PAP secret. When the remote sends an authenticate request, pppd uses the entry that has a server field equal to the local hostname, and a user field equal to the username sent in the request. When authenticating itself with the peer, pppd picks the secret to be sent from the line with the user field equal to the local username, and the server field equal to the remote hostname.
A sample PAP secrets file might look like this:
# /etc/ppp/pap-secrets # # user server secret addrs vlager-pap c3po cresspahl vlager.vbrew.com c3po vlager DonaldGNUth c3po.lucas.com
The first line is used to authenticate ourselves when talking to c3po. The second line describes how a user named c3po has to authenticate itself with us.
The name vlager-pap in column one is the username we send to c3po. By default, pppd will pick the local hostname as the username, but you can also specify a different name by giving the user option followed by that name.
When picking an entry from the pap-secrets file for authentication with the peer, pppd has to know the remote host's name. As it has no way of finding that out, you have to specify it on the command line using the remotename keyword followed by the peer's hostname. For instance, to use the above entry for authentication with c3po, we have to add the following option to pppd's command line:
# pppd ... remotename c3po user vlager-pap
In the fourth field (and all fields following), you can specify what IP addresses are allowed for that particular host, just as in the CHAP secrets file. The peer may then only request addresses from that list. In the sample file, we require c3po to use its real IP address.
Note that PAP is a rather weak authentication method, and it is suggested you use CHAP instead whenever possible. We will therefore not cover PAP in greater detail here; if you are interested in using PAP, you will find some more PAP features in the pppd(8) manual page.
Configuring a PPP Server
General Security Considerations