Linux Network Administratoramp;#039;s Guide (3rd Edition) [Electronic resources] نسخه متنی

6.8. Authentication with PPP

With PPP, each system may require its peer
to authenticate itself using one of two authentication protocols: the
Password Authentication
Protocol (PAP) or 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. In the description that follows, we will loosely talk
of "client" and
"server" when we want to
distinguish between the system sending authentication requests and
the system responding to them. A PPP daemon can ask its peer for
authentication by sending yet another LCP configuration request
identifying the desired authentication protocol.

6.8.1. PAP Versus CHAP

PAP, which is offered by many
Internet Service Providers, works basically the same way as the
normal login procedure. The client authenticates itself by sending a
username and a (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 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.

CHAP also doesn't require the client to authenticate
itself only at startup time, but sends challenges at regular
intervals to make sure that the client hasn't been
replaced by an intruder, for instance, by switching phone lines or
because of a modem configuration error that causes the PPP daemon not
to notice that the original phone call has dropped out and someone
else has dialed in.

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

By default, pppd doesn't
require authentication from the remote host, but it will agree to
authenticate itself when requested by the remote host. Since 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
refuses to authenticate altogether. As a consequence, the connection
is shut down.

You can modify this behavior in several ways. When given the
auth keyword, pppd requires the peer to
authenticate itself. pppd agrees to use either CHAP or PAP 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 to with PPP 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. That 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.

6.8.2. The CHAP Secrets File

When it has to authenticate itself with a
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 then
looks 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:[8]

[8] The double
quotes are not part of the secret; they merely serve to protect the
whitespace within it.

# 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 "arttoo! arttoo!"     c3po.lucas.com
*                 vlager.vbrew.com "TuXdrinksVicBitter"  pub.vbrew.com

When vlager establishes a PPP
connection with c3po, c3po asks vlager to authenticate itself by sending a
CHAP challenge. pppd on vlager 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
in the example.[9] It then produces the CHAP response from
the challenge string and the secret (Use
The Source
Luke), and sends it off to c3po.

[9] This hostname is taken from the CHAP
challenge.

pppd also 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 way we
discussed, and returns it to vlager.
pppd then 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 arttoo!
arttoo!, encrypts them, and compares the result to
c3po's CHAP
response.

The optional fourth field lists the IP
addresses that are acceptable for the client 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 asks to use an IP address
during IPCP negotiation that is not in this list, the request is
rejected and IPCP is 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 are
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 requirements are that the connecting host must
know the secret and that it must use the IP address associated with
pub.vbrew.com. Entries with wildcard
hostnames may appear anywhere in the secrets file, since
pppd will always use the best match it can find
for the 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 is obtained by calling the
gethostname(2) function by default. If you have
set the system name to your unqualified hostname, you also have to
provide pppd with the domain name using the
domain option:

# pppd domain vbrew.com

This provision
appends 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 as a name instead of a dotted
quad, pppd uses this as the local hostname.

6.8.3. The PAP Secrets File

The PAP secrets file is very similar to
CHAP's. The first two fields always contain a
username and a server name; the third holds the PAP secret. When the
remote host sends its authentication information,
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 it is necessary for us to send our
credentials to the peer, pppd uses the secret
that has a 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 the first column is the
username that we send to c3po. By
default, pppd picks 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 to identify yourself to a
remote host, pppd must know the remote
host's name. As it has no way of finding that out,
you must specify it on the command line using the
remotename keyword followed by the
peer's hostname. To use the above entry for
authentication with c3po, for
example, we must add the following option to
pppd's command line:

# pppd ... remotename c3po user vlager-pap

In the fourth field of the PAP secrets
file (and all following fields), you can specify what IP addresses
are allowed for that particular host, just as in the CHAP secrets
file. The peer will be allowed to request only addresses from that
list. In the sample file, the entry that c3po will use when it dials inthe line
where c3po is the
clientallows it to use its real IP address and no other.

Note that PAP is a rather weak
authentication method, you should use CHAP instead whenever possible.
We will therefore not cover PAP in greater detail here; if you are
interested in using it, you will find more PAP features in the
pppd(8) manpage.