демон протокола точка-точка (Point-to-Point Protocol Daemon)
Аутентификация (Authentication)
Authentication is the process whereby one peer convinces the
other of its identity. This involves the first peer sending its
name to the other, together with some kind of secret information
which could only come from the genuine authorized user of that
name. In such an exchange, we will call the first peer the
"client" and the other the "server". The client has a name by
which it identifies itself to the server, and the server also has
a name by which it identifies itself to the client. Generally
the genuine client shares some secret (or password) with the
server, and authenticates itself by proving that it knows that
secret. Very often, the names used for authentication correspond
to the internet hostnames of the peers, but this is not
essential.
At present, pppd supports three authentication protocols: the
Password Authentication Protocol (PAP), Challenge Handshake
Authentication Protocol (CHAP), and Extensible Authentication
Protocol (EAP). PAP involves the client sending its name and a
cleartext password to the server to authenticate itself. In
contrast, the server initiates the CHAP authentication exchange
by sending a challenge to the client (the challenge packet
includes the server's name). The client must respond with a
response which includes its name plus a hash value derived from
the shared secret and the challenge, in order to prove that it
knows the secret. EAP supports CHAP-style authentication, and
also includes the SRP-SHA1 mechanism, which is resistant to
dictionary-based attacks and does not require a cleartext
password on the server side.
The PPP protocol, being symmetrical, allows both peers to require
the other to authenticate itself. In that case, two separate and
independent authentication exchanges will occur. The two
exchanges could use different authentication protocols, and in
principle, different names could be used in the two exchanges.
The default behaviour of pppd is to agree to authenticate if
requested, and to not require authentication from the peer.
However, pppd will not agree to authenticate itself with a
particular protocol if it has no secrets which could be used to
do so.
Pppd stores secrets for use in authentication in secrets files
(/etc/ppp/pap-secrets for PAP, /etc/ppp/chap-secrets for CHAP,
MS-CHAP, MS-CHAPv2, and EAP MD5-Challenge, and
/etc/ppp/srp-secrets for EAP SRP-SHA1). All secrets files have
the same format. The secrets files can contain secrets for pppd
to use in authenticating itself to other systems, as well as
secrets for pppd to use when authenticating other systems to
itself.
Each line in a secrets file contains one secret. A given secret
is specific to a particular combination of client and server - it
can only be used by that client to authenticate itself to that
server. Thus each line in a secrets file has at least 3 fields:
the name of the client, the name of the server, and the secret.
These fields may be followed by a list of the IP addresses that
the specified client may use when connecting to the specified
server.
A secrets file is parsed into words as for a options file, so the
client name, server name and secrets fields must each be one
word, with any embedded spaces or other special characters quoted
or escaped. Note that case is significant in the client and
server names and in the secret.
If the secret starts with an `@', what follows is assumed to be
the name of a file from which to read the secret. A "*" as the
client or server name matches any name. When selecting a secret,
pppd takes the best match, i.e. the match with the fewest
wildcards.
Any following words on the same line are taken to be a list of
acceptable IP addresses for that client. If there are only 3
words on the line, or if the first word is "-", then all IP
addresses are disallowed. To allow any address, use "*". A word
starting with "!" indicates that the specified address is not
acceptable. An address may be followed by "/" and a number n, to
indicate a whole subnet, i.e. all addresses which have the same
value in the most significant n bits. In this form, the address
may be followed by a plus sign ("+") to indicate that one address
from the subnet is authorized, based on the ppp network interface
unit number in use. In this case, the host part of the address
will be set to the unit number plus one.
Thus a secrets file contains both secrets for use in
authenticating other hosts, plus secrets which we use for
authenticating ourselves to others. When pppd is authenticating
the peer (checking the peer's identity), it chooses a secret with
the peer's name in the first field and the name of the local
system in the second field. The name of the local system
defaults to the hostname, with the domain name appended if the
domain option is used. This default can be overridden with the
name option, except when the usehostname option is used. (For
EAP SRP-SHA1, see the srp-entry(8) utility for generating proper
validator entries to be used in the "secret" field.)
When pppd is choosing a secret to use in authenticating itself to
the peer, it first determines what name it is going to use to
identify itself to the peer. This name can be specified by the
user with the user option. If this option is not used, the name
defaults to the name of the local system, determined as described
in the previous paragraph. Then pppd looks for a secret with
this name in the first field and the peer's name in the second
field. Pppd will know the name of the peer if CHAP or EAP
authentication is being used, because the peer will have sent it
in the challenge packet. However, if PAP is being used, pppd
will have to determine the peer's name from the options specified
by the user. The user can specify the peer's name directly with
the remotename option. Otherwise, if the remote IP address was
specified by a name (rather than in numeric form), that name will
be used as the peer's name. Failing that, pppd will use the null
string as the peer's name.
When authenticating the peer with PAP, the supplied password is
first compared with the secret from the secrets file. If the
password doesn't match the secret, the password is encrypted
using crypt() and checked against the secret again. Thus secrets
for authenticating the peer can be stored in encrypted form if
desired. If the papcrypt option is given, the first
(unencrypted) comparison is omitted, for better security.
Furthermore, if the login option was specified, the username and
password are also checked against the system password database.
Thus, the system administrator can set up the pap-secrets file to
allow PPP access only to certain users, and to restrict the set
of IP addresses that each user can use. Typically, when using
the login option, the secret in /etc/ppp/pap-secrets would be "",
which will match any password supplied by the peer. This avoids
the need to have the same secret in two places.
Authentication must be satisfactorily completed before IPCP (or
any other Network Control Protocol) can be started. If the peer
is required to authenticate itself, and fails to do so, pppd will
terminated the link (by closing LCP). If IPCP negotiates an
unacceptable IP address for the remote host, IPCP will be closed.
IP packets can only be sent or received when IPCP is open.
In some cases it is desirable to allow some hosts which can't
authenticate themselves to connect and use one of a restricted
set of IP addresses, even when the local host generally requires
authentication. If the peer refuses to authenticate itself when
requested, pppd takes that as equivalent to authenticating with
PAP using the empty string for the username and password. Thus,
by adding a line to the pap-secrets file which specifies the
empty string for the client and password, it is possible to allow
restricted access to hosts which refuse to authenticate
themselves.
