The login command prompts the user for a name and password.
login then attempts to authenticate the user by looking up the typed user name and password in the password database.
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.
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.
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.
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).
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.
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:
Your company accepts incoming calls from users over the public, switched telephone network.
Your corporate security policy requires remote users to provide authentication credentials when accessing your network through a corporate firewall or when engaging in secure transactions.
You want to authenticate callers against a standard UNIX password database (/etc/passwd, NIS, NIS+, LDAP, or PAM). Use PAP authentication for this scenario.
Your company's dial-in servers also provide the network's Internet connection. Use PAP authentication for this scenario.
The serial line is less secure than the password database on the machine or networks at either end of the link. Use CHAP authentication for this scenario.