Go to main content

Managing Serial Networks Using UUCP and PPP in Oracle® Solaris 11.4

Exit Print View

Updated: February 2022

PPP Authentication

    Note - PPP was removed in the Oracle Solaris 11.4 SRU 24 release.

    Authentication is the process of verifying that a user is who he or she claims to be. The 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, Oracle Solaris PPP 4.0 does not demand authentication on systems that do not have a default route specified. Thus, a local system without a default route does not authenticate remote callers. Conversely, if a system does have a default route defined, the system always authenticates remote callers.

You might use PPP authentication protocols to verify the identity of callers who are trying to set up a PPP link to your system. Conversely, you must configure PPP authentication information if your local system must call peers that authenticate callers.

Authenticators and Authenticatees

The calling system on a PPP link is considered the authenticatee because the caller 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 system is the authenticatee. The dial-in server is the authenticator. The server has a database in the form of a secrets file. This file 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 systems require remote peers to provide authentication information when responding to the dial-out system's call. Then their roles are reversed: the remote peer becomes the authenticatee and the dial-out system the authenticator.

Note - PPP 4.0 does not prevent authentication by leased-line peers, but authentication is not often used in leased-line links. The nature of leased-line contracts usually means that both participants on the ends of the line are known to each other. Both participants 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 system. 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, PPP authentication does not provide confidentiality of data. For confidentiality, use encryption software, such as IPsec, PGP, SSL, Kerberos, and the Secure Shell.

Note - Oracle Solaris PPP 4.0 does not implement the PPP Encryption Control Protocol (ECP), which 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, such as /etc/passwd, 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 system or networks at either end of the link. Use CHAP authentication for this scenario.