Post on 20-Dec-2015
transcript
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