PPP Security Features

Ariel Eizenberg

arielez@cs.huji.ac.il

2

Contents

• Introduction

• Authentication

• Encryption

3

Introduction

• PPP provides two means for establishing security

– Authentication

– Encryption

• Both methods are not mandatory

4

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.

5

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.

6

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.

7

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

8

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.

9

PAP Authentication

Peer Authenticator

Configure-request, auth-protocol=PAP

Configure-ack

Authenticate-request,name=username,

password=userpassword

Authenticate-ack (or nack)with text message

Tim

e

10

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.

11

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

12

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

13

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.

14

CHAP Authentication

Peer Authenticator

Configure-request, auth-protocol=CHAP

Configure-ack

Authenticate-response,[peer ID, H(auth ID, secret, challenge)]

Authenticate-success (or failure)with text message

Tim

e

Authenticate-challenge,[authenticator ID, challenge]

15

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!

16

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.

17

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

18

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.

19

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.

20

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.

21

Peer Authenticator

Configure-request, auth-protocol=EAP

Configure-ack

PPP EAPResponse Identity (UserID)

PPP EAPRequest EAP-TYPE=EAP-TLS (TLS Start)

Tim

ePPP EAPRequest Identity

PPP EAPResponse EAP-TYPE=EAP-TLS(TLS client_hello)

PPP EAP: Request EAP-TYPE=EAP-TLS(server_hello, certificate, server_key_exchange,

certificate_request, server_hello_done)

PPP EAP: Response EAP-TYPE=EAP-TLS(certificate, client_key_exchange, certificate_verify,

changer_cipher_spec, finished)

PPP EAP: Request EAP-TYPE=EAP-TLS(change_cipher_spec, finished)

PPP EAPResponse EAP-TYPE=EAP-TLS

PPP EAP-Success

Example: EAP-TLS

22

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.

23

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.

24

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.

25

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.

26

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.

27

The End

28