Authentication with PPPLinux Network Administrators GuidePrevChapter 8. The Point-to-Point ProtocolNextAuthentication with PPP
With PPP, each system may require its peer to authenticate itself
using one of two authentication protocols: 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. 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.PAP Versus CHAPPAP, 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.[1]
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
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.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:[2]
# 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.comWhen 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.[3]
It then produces the CHAP response from the challenge string and the secret
(Use The Source Luke), and sends it off to
c3po.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.comThis 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.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.comThe 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 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 us 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-papIn 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 in—the line where c3po is the client—allows 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) manual page.
Notes[1]“Secret” is just the PPP name for passwords. PPP secrets
don't have the same length limitation as Linux login passwords.[2]The double quotes are not part of the secret; they merely serve to protect the
whitespace within it.[3]This hostname is taken from the CHAP challenge.PrevHomeNextGeneral Security ConsiderationsUpDebugging Your PPP Setup
Wyszukiwarka
Podobne podstrony:
x 087 2 ppp optionsx 087 2 pppPPP HOWTO pl 6 (2)x 087 2 accounting zeroing counterPPP HOWTO pl 9 (2)x 087 2 cnews miscx 087 2 cnews nfs1 PPP APP Wprowadzenie do zarz środowiskppp faqppp howto 16 apegkq3qoslfyofnhhe5ali6gbxmebdc2e2vdwappp faq 2ppp faq 13x 087 2 mail delivery002 Informacja dla Rodziców – Lista dokumentów na wizytę w PPPx 087 2 masq namelookupsx 087 2 firewall filteringmethodswięcej podobnych podstron