PPP Security

PPP (Point-to-Point Protocol) is used as the basis for many other security protocols, including VPN (e.g., PPTP), dial-up access, uploading email to your ISP's MTA, etc.  SAs need to understand the basic PPP security mechanisms, configure the most secure mechanism when a choice is possible, and understand the weaknesses of common approaches.  The PPP Protocol is discussed in CTS-2301C.

PPP is a series of protocols that operate in layers and phases.  The initial link is established using LCP, which operates at the lowest layer and is used for the initial phase.  This protocol allows options, some of which require the otherwise optional PPP authentication to be used in one or both directions.  When the option is present, the PPP session next enters the PPP authentication phase, in which the client and server negotiate which authentication mechanism to use, and then use it to authenticate one party to the other (and sometimes in both directions).

Originally PPP provided two authentication protocols only, PAP (Password Authentication Protocol) and CHAP (Challenge Handshake Authentication Protocol).  (Both are documented in PPP Authentication Protocols, RFC-1334.)  Later support was added for vendor-specific additional protocols (RFC-2153), of which MS-CHAP (or MSCHAP) was the most widely used.  MSCHAP contains numerous security flaws which allow an eavesdropper to obtain user's passwords easily.  Microsoft responded with a stronger version called MS-CHAPv2 (or MSCHAPv2), and renamed the original to MS-CHAPv1 (or MSCHAPv1).  (See the MSCHAPv2 standard, RFC-2759).

Rather than continue to modify the PPP standard (RFC-1661) for each new security protocol, PPP now allows the use of EAP to negotiate a much larger and extendable collection of security mechanisms.  See RFC-3748 (EAP) and RFC-5216 (EAP-TLS) (EAP-TLS is the only EAP method required by PPP).  Here we only discuss PAP, CHAP, and MS-CHAPv2.  MS-CHAPv1 is still in use, but any good SA will Just Say No! to using it.

In PPP terminology, the party desiring to authenticate the other is called the authenticator, and the other party is called the peer.  Most SAs refer to these as the server and client instead, but keep in mind with CHAP and EAP either party can demand the other to authenticate or drop the link, so saying client or server may be confusing.

During the link establishment phase the Configuration Option LCP packets provide a method for either party to demand authentication from the other, and to negotiate the use of a specific protocol.  By default, authentication is not required, and the parties can negotiate different (or no) authentication in each direction.

The party sending a Configure-Request LCP packet is indicating that it expects authentication from its peer (the other party).  If a party is willing to use any of several authentication methods, it must attempt to configure the most desirable protocol first.  If that protocol is rejected by the other party (by sending an appropriate NACK packet), then the implementation SHOULD attempt the next most desirable protocol in the next Configure-Request packet.  If all offered protocols are NACK'd then you drop the link or (rarely) continue with no authentication.  Remember both parties can do this to demand authentication.

If a host sends a Configure-Ack packet, it is agreeing to authenticate with the specified protocol.  A party receiving a Configure-Ack SHOULD expect the peer to authenticate with the acknowledged protocol.  Depending on the agreed protocol, the server or client may start sending packets (to which the other party replies).  This is called the authentication phase and must be completed (if used at all) before the next phase of PPP can commence.

With the Password Authentication Protocol, a username and password pair is repeatedly sent by the peer (client) to the authenticator (server) until authentication is acknowledged or the connection is terminated.

PAP is not a strong authentication method!  Passwords are sent over the circuit in the clear, and there is no protection from playback or repeated trial and error attacks.  The peer (client) is in control of the frequency and timing of the attempts.

Any implementations which include a stronger authentication method (such as CHAP, described below) MUST offer to negotiate that method prior to offering PAP.

CHAP is defined as one-way authentication (the peer/client authenticates to the authenticator/server).  However CHAP can be used independently in both directions if desired, in which case both client-to server and server-to-client authentication must be successful to continue.  CHAP is simple:

1. The client agrees to authenticate to the server using CHAP.  After receiving the ACK, the server sends to the client a random Challenge string (of random length, but should be long enough for MD5 to work well).
2. The client concatenates the username + password + challenge.  (The password is often referred to as the shared secret.)
3. The concatenated string is then hashed using MD5 to produce a 16 byte Challenge Response.
4. The Challenge Response value is sent to the server.
5. The server calculates the Challenge Response value the same way as the client, and compares the two.  If identical, the client is authenticated (ACK is sent).  If different a NAK is sent, and typically the server drops the link.

Note that CHAP can have the client also authenticate the server, using a different username and password.  Also, a new and different challenge string can be sent anytime during a PPP session to re-authenticate.

CHAP is much stronger than PAP.  However the passwords must be stored at both ends in plain text, which is a weakness.  Also the server may need to transmit the passwords around its LAN between servers.  This is another weakness if communications are not encrypted.

Both PAP and CHAP requires storing user passwords in clear (plain) text on both the client and server, and that's not usually acceptable.  User's passwords in Windows are stored in a hashed form only.  Since neither party has access to the original plaintext password, the hash becomes the "password" (or "secret") stored on the server end.  MS-CHAPv2 only sends a hash of this hashed password (called the password-hash-hash) across the link.  As with CHAP, sending a hash of the shared secret rather than the actual secret across a network enhances security.

Unlike regular CHAP, MS-CHAPv2 requires both parties to authenticate to the other.  Only one side has to send the MS-CHAPv2 request; if ACK'd then the first party becomes the server/authenticator) and the other the client/peer.  (The new PPP EAP works the same way.)

MS-CHAPv2 also provides a Change Password packet so clients can update their passwords on the server, using the current session.

Here's the MS-CHAPv2 protocol:

1. The client agrees to authenticate to the server using MS-CHAPv2.
2. The server sends a random 16 byte Server Challenge string to the client.
3. The client receives the Server Challenge string.  It now generates its own 16 byte challenge string (used to authenticate the server) called the "Peer Authenticator Challenge" string.
4. The client generates an "8 byte challenge" string these as follows:
   1. Concatenate the 16 byte Peer Authenticator Challenge + the 16 byte Challenge received from server + client's username (ASCII)
   2. Calculate the SHA-1 hash of that.
   3. Use the first 8 bytes of the result as the "8 byte challenge" string.
5. The client uses the 8 byte Challenge and the stored WinNT hash of the user's password to calculate a 24 byte "Challenge Response" as follows:
   1. Pad the 16 byte user password hash by adding five all-zero bytes.
   2. Split the resulting 21 byte value into three 7-byte DES keys (that last key contains the five zero bytes and is weak).
   3. Encrypt the 8 byte challenge string three times, with each of the DES keys, and concatenate the three results into a single 24 byte result called the "Challenge Response".
6. The client sends the 16 byte Peer Authenticator Challenge string, the 24 byte Challenge Response string, and the username string to the server.
7. The server uses the (stored) WinNT hash of the user's password to generate the same three DES keys, and uses them to decrypt the 24 byte challenge response.  The result should be three identical copies of the 8 byte Challenge string as calculated by the client.  The server then calculates what the 8 byte Challenge string should be using the same method as client (in step 4).  If the values match, the client is authenticated.  The server must now authenticate to the client.
8. The server now calculates a 20 byte "Authenticator Response" (to authenticate the server to the client) as follows:
   1. Calculate the MD4 hash of the stored WinNT (hashed) password.  (This is so we don't send the actual WinNT password hash.)  This 16 byte result is called the password-hash-hash.
   2. The password-hash-hash is concatenated with the 24 byte Challenge Response + the literal ASCII string (minus the quotes)
      Magic server to client constant.
   3. The result is then hashed with SHA-1, to produce a 20 byte result string.
   4. The result string from the previous step is then concatenated with the 8 byte challenge string + the literal ASCII string (minus the quotes) Pad to make it do more than one iteration.  This in turn is hashed with SHA-1 to produce the 20 byte authenticator response.
9. The server tells the client its authentication was successful, and sends the 20 byte Authenticator Response to the client.
10. The client also computes the Authenticator Response and compares it to the one received from the server.  If it matches the server is authenticated.

The security of the whole scheme ultimately depends on the security of the RC-4 hash of the user's password.  A weak password can be cracked fairly easily.  While much better than MS-CHAPv1 this scheme is overly complex (with no extra security provided over a simpler version).

EAP is a security mechanism negotiation protocol.  Once both parties have agreed to use TLS, many options must be negotiated using the TLS protocol.  (So we have the PPP protocol used to negotiate the use of EAP, and EAP used to negotiate the use of TLS (or some other security mechanism both sides can support).  Finally the TLS protocol (really EAP-TLS) is used to negotiate session parameters, pass authentication tokens back and forth, and conclude that the peer is who they claim to be.

The EAP-TLS conversation will typically begin with the authenticator and the peer negotiating EAP.  The authenticator will then typically send an EAP-Request/Identity packet to the peer, and the peer will respond with an EAP-Response/Identity packet to the authenticator, containing the peer's user-ID.  Before sending the user's identity, privacy may be requested and an encryption mechanism agreed to, so that the identity is not sent in plain text.

While nominally the EAP conversation occurs between the PPP authenticator and the peer, the authenticator may act as a pass-through device, with the EAP packets received from the peer being encapsulated for transmission to a RADIUS server (or other authentication server).  This doesn't effect the protocol, however to avoid confusion the ultimate authenticator (either a RADIUS server or the PPP authenticator) can be called the EAP server.

After receiving the peer's Identity, the EAP server responds with an EAP-TLS Start packet.  This starts the EAP handshake and mechanism negotiation.  Once both parties agree on TLS, the client_hello message is sent.  This contains the peer's TLS version number, a session-ID, a random number, and a set of cipher-suites supported by the peer.

The EAP server then responds with a EAP Request packet, containing a TLS server_hello handshake message followed by TLS certificate.  (Other messages can be sent too, including server_key_exchange, certificate_request, server_hello_done and/or finished handshake messages, and/or a TLS change_cipher_spec message.)

The interesting part of this is the certificate, which is a PKI certificate that can be verified and validated to prove identity.  Also, the EAP server can send a certificate_request when the server desires the peer to authenticate itself via public key.  So no passwords or even password hashes need be sent between parties, and no password update protocol is ever needed since the authenticator and peer don't need to share passwords.  These features make EAP-TLS the strongest of the PPP security mechanisms discussed here.