PPP Authentication Protocols

Field

Description

Flag

A single byte that indicates the beginning or end of a frame. The flag field consists of the binary sequence 01111110.

Address

A single byte that contains the binary sequence 11111111, the standard broadcast address. PPP does not assign individual station addresses.

Control

A single byte that contains the binary sequence 00000011, which calls for transmission of user data in an unsequenced frame.

Protocol

Two bytes that identify the protocol encapsulated in the information field of the frame. The most up-to-date values of the protocol field are specified in the most recent Assigned Numbers Request for Comments (RFC).

Data

Zero or more bytes that contain the datagram for the protocol specified in the protocol field. The end of the information field is found by locating the closing flag sequence and allowing two bytes for the FCS field. The default maximum length of the information field is 1,500 bytes. By prior agreement, consenting PPP implementations can use other values for the maximum information field length.

Frame Check Sequence (FCS)

Normally two bytes. By prior agreement, consenting PPP implementations can use a 4-byte FCS for improved error detection.

Figure 2-6: The PPP Frame Format

PPP negotiation consists of LCP and NCP negotiation. LCP is responsible for establishing the connection with certain negotiated options, maintaining the connection, and providing procedures to terminate the connection. To perform these functions, LCP is organized into the following four phases:

1. Link establishment and configuration negotiation

2. Link quality determination

3. Network layer protocol configuration negotiation

4. Link termination

To establish communications over a point-to-point link, each end of the PPP link must first send LCP packets to configure the data link during the link establishment phase. After the link has been established, PPP provides for an optional authentication phase before proceeding to the network layer protocol phase. The NCP phase then establishes and configures different network layer protocols such as IP.

By default, authentication before the NCP phase is not mandatory. If authentication of the link is desired, an implementation will specify the authentication protocol configuration option during the link establishment phase. These authentication protocols are intended for use primarily by hosts and routers that connect to a PPP network server through switched circuits or dial-up lines, but can be applied to dedicated links as well. The server can use the identification of the connecting host or router in the selection of options for network layer negotiations.

PPP Password Authentication Protocol

The Password Authentication Protocol (PAP) provides a simple way for a peer to establish its identity to the authenticator using a two-way handshake. This is done only at initial link establishment. There exist three PAP frame types, as shown in Figure 2-7.

After the link establishment phase is completed, the authenticate-request packet is used to initiate the PAP authentication. This packet contains the peer name and password, as shown in Figure 2-8.

Figure 2-8: PPP PAP Authentication Request

This request packet is sent repeatedly until a valid reply packet is received or an optional retry counter expires. If the authenticator receives a Peer-ID/Password pair that is both recognizable and acceptable, it should reply with an Authenticate-Ack (where Ack is short for acknowledge). If the Peer-ID/Password pair is not recognizable or acceptable, the authenticator should reply with an Authenticate-Nak (where Nak is short for negative acknowledge).

Figure 2-9 shows the sequence of PPP negotiations between a branch router (the peer) trying to authenticate to the NAS, the network access server (the authenticator).

PAP is not a strong authentication method. PAP authenticates only the peer, and passwords are sent over the circuit "in the clear." There is no protection from replay attacks or repeated trial-and-error attacks. The peer is in control of the frequency and timing of the attempts.

PPP Challenge-Handshake Authentication Protocol

The Challenge-Handshake Authentication Protocol (CHAP) is used to periodically verify the identity of a host or end user using a three-way handshake. CHAP is performed at initial link establishment and can be repeated any time after the link has been established. Four CHAP frame types exist, as shown in Figure 2-10.

Figure 2-11 shows a scenario in which a branch router (the peer) is trying to authenticate to the NAS (the authenticator).

Security Technologies

CHAP imposes network security by requiring that the peers share a plaintext secret. This secret is never sent over the link. The following sequence of steps is carried out:

Step 1 After the link establishment phase is complete, the authenticator sends a challenge message to the peer. The challenge consists of an identifier (ID), a random number, and either the host name of the local device or the name of the user on the remote device.

Step 2 The receiving peer calculates a value using a one-way hash function; the secret is the input to the one-way hash function.

Step 3 The peer sends the challenge response, which consists of:

• An encrypted version of the ID

• A secret password (the calculated hash value)

• The random number

• Either the host name of the remote device, or the name of the user on the remote device

Step 4 When the authenticator receives the challenge response, it verifies the secret by looking up the name given in the response and performing the same encryption operation. The authenticator checks the response against its own calculation of the expected hash value.

Step 5 If the values match, the authenticator acknowledges the authentication and sends a success message, and the LCP establishes the link.

The secret passwords must be identical on the remote and local devices. These secrets should be agreed on, generated, and exchanged out-of-band in a secure manner. Because the secret is never transmitted, other devices are prevented from stealing it and gaining illegal access to the system. Without the proper response, the remote device cannot connect to the local device.

CHAP provides protection against playback attack through the use of an incrementally changing identifier and a variable challenge value. The use of repeated challenges is intended to limit the time of exposure to any single attack. The authenticator is in control of the frequency and timing of the challenges.

Note Typically, MD5 is used as the CHAP one-way hash function; the shared secrets are required to be stored in plaintext form. Microsoft has a variation of CHAP (MS-CHAP), in which the password is stored encrypted in both the peer and the authenticator. Therefore, MS-CHAP can take advantage of irreversibly encrypted password databases commonly available, whereas the standards-based CHAP cannot.

PPP Extensible Authentication Protocol

The PPP Extensible Authentication Protocol (EAP) is a general protocol for PPP authentication that supports multiple authentication mechanisms. EAP does not select a specific authentication mechanism at the link control phase; rather, it postpones this until the authentication phase so that the authenticator can request more information before determining the specific authen-tication mechanism. This arrangement also permits the use of a "back-end" server, which actually implements the various authentication mechanisms while the PPP authenticator merely passes through the authentication exchange.

Figure 2-12 shows how PPP EAP works. In the figure, the branch router (the peer) is trying to authenticate to the NAS (the authenticator). The sequence of steps is as follows:

Step 1 When the link establishment phase is complete, the authenticator sends one or more requests to authenticate the peer. The request has a type field to indicate what is being requested. Examples of request types include identity, MD5-challenge, S/Key, generic token card, and so on. The MD5-challenge type corresponds closely to the CHAP authentication protocol.

Note Typically, the authenticator sends an initial identity request followed by one or more requests for authentication information. However, an initial identity request is not required and may be bypassed in cases where the identity is presumed (for example, with leased lines, dedicated dial-ups, and so on).

Step 2 The peer sends a response packet in reply to each request. As with the request packet, the response packet contains a type field that corresponds to the type field of the request.

Step 3 The authenticator ends the authentication phase with a success or failure packet.

EAP adds more flexibility to PPP authentication and provides the capability to use new technologies---such as digital certificates---when they become widely available.

PPP Authentication Summary

PPP authentication is required for dial-in connectivity. Any of the three standard mechanisms---PAP, CHAP, and EAP---can be used. Table 2-1 gives a summary of the strengths and weak-nesses of these mechanisms.

Table 2-1: PPP Authentication Summary