PEAP - Protected EAP Protocol

PEAP - Protected EAP Protocol

One of the major security vulnerabilities from the EAP perspective is that the some of the initial EAP message exchanges, such as EAP-Request/Identity and EAP-Response/Identity, are sent in cleartext. PEAP leverages EAP-TLS (EAP Transport Layer Security) where the initial EAP message exchanges are done over a secure tunnel built between the Client and the Server using TLS. The entire EAP negotiation is protected.

EAP-TLS requires client-side certificate also, while PEAP exempts this requirement. PEAP requires only server-side certificate, uses TLS for the secure tunnel, and goes beyond EAP-TLS adding client authentication and key-exchange.

The PEAP protocol has two phases- the first phase is to establish a secure tunnel using EAP-TLS with Server authentication. The second phase implements the Client authentication based on EAP methods.

The following flow diagram shows all the messages exchanged between the Client and the Server.

PEAP Phase 1

Like in regular EAP negotiation, the phase 1 starts when the Authenticator sends an EAP-Request/Identity message. Unlike regular EAP where the Client replies with an EAP-Response/Identity message, in PEAP, the Client can reply with an anonymous identity, for example user@anonymous.com. The Client's real identity is sent in Phase 2. It is likely that the Client can send its identity partly, like user@company_name.com, so that the Authenticator can choose a proper Authentication Server based on Company name.

After the Client EAP-Response/Identity is forwarded to the Authentication Server using RADIUS by the Authenticator, the EAP-TLS starts. The process is same as SSL Connection Setup.

The EAP Server becomes aware of the Client when it receives RADIUS Access-Request message forwarded by the Authenticator. The Server sends an empty EAP-TLS request with the Start flag set and Type field set to 25 (PEAP); EAP-TLS uses Type=13.. Only this message has the Start flag set. The Client sends a Client-Hello message containing all the ciphersuites it supports including a Client-Random ID with Session ID set to 0.

The Server replies with a Server-Hello message containing a Server-Random ID, a Session ID and the agreed ciphersuite. The Server also sends a Certificate including its Public key in a Server Certificate message. It can request a Client Certificate from the Client. This is followed by a Server Hello Done message and waits for the Client to take the next step.

The Client in response sends a Client Key Exchange message after computing the pre_master secret. The Client generates a random number (48 bytes) which is called the pre-master secret, encrypts it using Server's public key and sends to the Server. Only Server can decrypt this message as it holds the Private key. Both, Client and Server, now have the pre-master secret.

The Client and the Server now generate the Master Session Key (MSK) from the Client-Random ID, Server-Random ID and the pre_master secret.

Finally, the Server sends an EAP-Success message to complete the EAP Handshake.

PEAP Phase 2

Phase 2 begins with an EAP Server sending an (optional) EAP-Request/Identity message to the Client, protected by the TLS ciphersuite negotiated in Phase 1. The Client responds with an EAP-Response/Identity message containing its user-id.

The Server will then select an authentication method (aka EAP Type like EAP-MD5, EAP-TLS or EAP-MSCHAPv2, etc) for the Client, and will send an EAP-Request message with the proposed authentication method. The Client can reply with a NAK or accept the authentication method. EAP methods are always encapsulated within EAP Payload TLV.

Before completing negotiation of EAP method, the Client and the Server must use Crypto Binding TLV. The success or failure of EAP method negotiation is done using EAP Result TLV.

The Client and the Server now derive the Extended Master Session Key (EMSK) and subsequently the Compound Session Key (CSK). The CSK is 128 bytes which is concatenation of MSK and EMSK. Then the Server sends its CSK and the EAP Success message to the Authenticator.

The Client can then send data to the Authenticator using the derived CSK.