Ariel Eizenberg arielez@cs.huji.ac.il PPP Security Features Ariel Eizenberg arielez@cs.huji.ac.il

Contents Introduction Authentication Encryption

Introduction PPP provides two means for establishing security Authentication Encryption Both methods are not mandatory

Authentication PPP support several authentication protocols. The authentication is asymmetric In each authentication “transaction”, one peer is master and the other is the slave To authentication both sides, the authentication algorithm is ran twice, once in each direction. The authentication algorithm may differ between the two directions.

Algorithm Selection Each side of the PPP channel has a list of supported authentication protocols, listed by priority The authentication protocol is selected during LCP phase by both sides. If no algorithm is selected, the connection is terminated.

Terminology Most RFCs describing PPP authentication protocols define special terms for the authenticating hosts Authenticator – The end of the link requiring the authentication. The authenticator specifies the protocol to be used during LCP. Peer – The other end of the point-to-point link; the end which is authenticated by the authenticator.

RFC1334 The first RFC to define PPP authentication algorithms was RFC 1334. The RFC detailed two protocols: PAP – Password Authentication Protocols CHAP – Challenge Handshake Authentication Protocols

PAP – Password Authentication Protocol A simple two-way handshake protocol for establishing peer identity The protocol: At LCP phase, the authenticator requests PAP authentication. At authentication phase, the peer transmits, in plain text, a username and password. The authenticator responds with a configure-ack or configure-nak.

PAP Authentication

PAP - Security Features PAP is vulnerable to replay attacks. An attacker can record a PAP authentication and then later replay it. The user’s password is transmitted in plain text If the user uses the same password for other services, they become vulnerable as well.

PAP - Extensions The PAP RFC does not state that the password must be fixed or must come from the user: The password can be hashed before being transmitted (does not solve replay) PAP can be used with a token card

CHAP – Challenge Handshake Authentication Protocol A 3-way handshake protocol for establishing peer identity. CHAP was first described in RFC1334, and later amended in RFC1994. CHAP uses a challenge/response scheme for authentication

CHAP – The Protocol At LCP phase, the authenticator specifies CHAP as the authentication protocol. At authentication phase, the authenticator sends the peer a string containing its ID and a random value. The peer concatenates the user’s password to this strings, and performs a one way hash of it. The hash is then sent back to the authenticator. The authenticator responds with a configure-ack or configure-nak.

CHAP Authentication

Challenge/Response The one way hash function can be arbitrary, but both authenticator and peer must agree on it. To be RFC1994 complaint, both sides must at least support MD5. The RFC states that the random challenge value must exhibit global and temporal uniqueness. If the protocol is used twice, to authenticate both sides, the same challenge value must not be used! Otherwise, the second authentication might be a replay of the first!

CHAP vs. PAP CHAP solves PAP’s vulnerabilities by not transmit the password in plain text, and using a random challenge to avoid replay attacks. The CHAP RFC allows CHAP to be repeated several times during a sessions, so CHAP is unpractical with token cards.

MS-CHAPv1, MS-CHAPv2 Microsoft’s variants of CHAP. Instead of performing a one way hash, MS-CHAP performs a DES encryption of the challenge value with the user’s password as a key. MS-CHAP provides new PPP messages that change the stores password in authenticator or peer

CHAP vs. MS-CHAP Using DES to encrypt the challenge does not increase the algorithm’s safety The keys strength is still the same – most user’s passwords contain much less then 56-bits of entropy The password changing mechanism can allow an intruder with a one-time access windows to change the password to his heart’s desire.

EAP – Extensible Authentication Protocol EAP is a new authentication scheme, not yet widely popular Microsoft provides an EAP implementation with Windows 2000/XP/2003. EAP was developed as a response to an increasing demand for authentication based on other devices then the name/password pair. EAP provides a generic and extensible framework for providing any requested authentication scheme. EAP supports generic token cards, OTPs, RSA, KEA, TLS, as well as a CHAP like protocol and many others.

EAP – The Protocol The EAP protocol consists of a series of requests send from the authenticator to the peer. The peer sends a response to each request The authenticator can configure-ack or configure-nak each response.

Example: EAP-TLS

Encryption PPP provides a data encryption layer, called ECP (described in RFC1968). ECP is negotiated like any NCP, but unlike a standard NCP, all further communication, except the negotiation itself, is passed through the ECP layer. ECP provides only data confidentiality: It does not provide any authentication mechanism It does not provide any key distribution mechanism.

ECP Unlike other NCPs, ECP requires the data to be ‘packeted’ on a 64-bit boundary. ECP supports 2 basic encryption algorithms: DES with CBC 3DES with CBC There are two versions of DES encryption, with different data packing guidelines.

DES/3DES Each ciphertext packet is prepended with a 16-bit sequence number used to detect packet loss Since in CBC most each packet depends only exactly one packet before, a loss of a packet will result in the loss of only two packets. In both algorithms, both sides must share a common key. DES uses a 56 bit key 3DES uses a 168 bit key (3x56bit keys) Both algorithms start with a random IV packet to prevent replay attacks.

MPPE Microsoft implemented its own encryption scheme, MPPE. MPPE uses RC4 for encryption, with a 40/128 bit key for security. MPPE is closely integrated with MS-CHAP, and obtains a RC4 key from the MS-CHAP key. Since the MS-CHAP key is usually much less stronger then 40/128 bits, encryption security is lessened.

Summary PPP provides mechanisms for implementing two security features: Authenticity – using authentication Confidentiality – using encryption PPP does not provide Non-repudiation – can be implemented by using IPSEC over PPP Message Integrity – PPP provides a CRC for each packet, but there is no mechanism for signing packets.

The End