System Administration Guide: Resource Management and Network Services

PPP Authentication

Authentication is the process of verifying that a user is who he or she claims to be. The classic UNIX login sequence is a simple form of authentication:

  1. The login command prompts the user for a name and password.

  2. login then attempts to authenticate the user by looking up the typed user name and password in the password database.

  3. If the database contains the user name and password, then the user is authenticated and given access to the system. If the database does not contain the user name and password, the user is denied access to the system.

By default, Solaris PPP 4.0 does not demand authentication on machines that do not have a default route specified. Thus, a local machine without a default route does not authenticate remote callers. Conversely, if a machine does have a default route defined, by default it does authenticate remote callers.

If necessary, you can use PPP authentication protocols to verify the identity of callers who are trying to set up a PPP link to your machine. Conversely, you must configure PPP authentication information for your local machine if it needs to call peers that must authenticate callers.

Authenticators and Authenticatees

The calling machine on a PPP link is considered the authenticatee because it must prove its identity to the remote peer. The peer is considered the authenticator. The authenticator looks up the caller's identity in the appropriate PPP files for the security protocol and authenticates or does not authenticate the caller.

You typically configure PPP authentication for a dial-up link. When the call begins, the dial-out machine is the authenticatee. The dial-in server is the authenticator. The server has a database in the form of a secrets file, which lists all users who are granted permission to set up a PPP link to the server. Think of these users as trusted callers.

Some dial-out machines require remote peers to provide authentication information when responding to the dial-out machine's call. Then their roles are reversed: the remote peer becomes the authenticatee and the dial-out machine the authenticator.

Note –

PPP 4.0 does not prevent authentication by leased-line peers, but it is not often used. The nature of leased-line contracts usually means that both participants on the ends of the line are known to each other and often are trusted. However, because PPP authentication is not that difficult to administer, you should seriously consider implementing authentication for leased lines.

PPP Authentication Protocols

The PPP authentication protocols are Password Authentication Protocol (PAP) and Challenge-Handshake Authentication Protocol (CHAP). Each protocol uses a secrets database that contains identification information, or security credentials, for each caller that is permitted to link to the local machine. For a detailed explanation of PAP, see Password Authentication Protocol (PAP). For a CHAP explanation, see Challenge-Handshake Authentication Protocol (CHAP).

Why Use PPP Authentication?

Providing authentication on a PPP link is optional. Moreover, though authentication does verify that a peer is to be trusted, it does not provide confidentiality of data. For confidentiality, use encryption software, such as IPsec, PGP, SSL, and the Solaris secure shell.

Note –

Solaris PPP 4.0 does not implement the PPP Encryption Control Protocol (ECP) that is described in RFC 1968.

Consider implementing PPP authentication in the following situations: