Protected Extensible Authentication Protocol, or Protected EAP (PEAP) uses EAP as a transport. The Transport Layer Security (TLS) tunnel established in Phase 1 is utilized to protect messages exchanged (e.g. authentication credentials) in Phase 2 against eavesdropping or man-in-the-middle attacks. Because of the TLS tunnel, analyzing network traces is not trivial when troubleshooting PEAP. Proper analysis of your scenario requires knowledge of the inner packet format and encoding within the outer packet. This blog provides examples of Phase 2 encapsulation for a client authenticating over PEAP with MSCHAPv2 where the server requests statement of heath check on the client.     

Background

Protected EAP adds security services to EAP methods that support client access to a network. The EAP framework works over wired or wireless networks. PEAP is typically deployed in the context of network access servers (NAS), wireless access points or virtual private network gateways.

The client - EAP peer - transmits PEAP messages to the NAS over lower-layer protocols such as the Point-to-Point Protocol (PPP), or [IEEE802.1X]. NAS elements carry PEAP exchange with the Network Policy Server (NPS) over protocols such as the Remote Authentication Dial-In User Service (RADIUS).

Purpose of PEAP Phases

PEAP operates in two phases. In Phase 1, the EAP peer establishes a TLS session and authenticates with the EAP server.

In Phase 2, an inner method is negotiated over the TLS session of Phase 1, and allows the EAP server to authenticate the EAP peer. Examples of inner methods are EAP-MSCHAPv2, and EAP-TLS.

Phase 2 message exchange is encrypted and sent over the TLS tunnel of Phase 1, thus safeguarding passwords and other dictionary attackable user credentials from eavesdropping.

SoH transmission

One security feature of PEAP is the transmission of Statement of Health (SoH) messages. SoH validation occurs in PEAP phase 2, either immediately after Phase 1 completion if no identity request is required, or after identity exchange. The presence of client SoH entities and EAP server components determine whether or not such messages are transmitted.

Cryptobinding

Another security feature of PEAP is the cryptobinding process which enables to protect the PEAP negotiation against man-in-the-middle attacks. The cryptobinding request and response achieve a two-handshake between the peer and the EAP server by using key materials from Phase 1 and Phase 2. More information about the computation of the cryptobinding packet can be found in MS-PEAP, HMAC [RFC2104] and SHA1 [RFC3174].

A look at Phase 1 TLS tunnel

PEAP Phase 1 establishes a TLS session with the option for the server to request a certificate. PEAP supports TLS v1.0 with cipher suites TLS_RSA_WITH_RC4_128_MD5 and TLS_RSA_WITH_RC4_128_SHA. Details on the semantics associated with phase 1 of PEAP are specified in [MS-PEAP].

A look at Phase 2 exchange

  • Except result indications, all subsequent Phase 2 EAP messages are exchanged inside the tunnel established in Phase1.
  • EAP success or the EAP failure packets are result indications, therefore are handled by the PEAP implementation rather than the inner EAP method, thus never exchanged inside Phase 1 tunnel.
  • Inner EAP packet can be compressed, except for EAP TLV Extensions Method, Capabilities Negotiation Method, and SoH EAP Extensions Method. Inner EAP packet compression means Code, Identifier and Length fields are removed before encapsulation.
  • Decompression of the abovementioned inner packet is performed by decrypting the "inner EAP message". The Code and Identifier fields of the inner EAP packet are set to the values stored in the Code and Identifier fields of the outer EAP packet, and the Length field is set to the length of the decrypted inner EAP message plus 4 (Code + Identifier).
  • PEAP implementation supports a single EAP authentication method per session. The EAP TLV Extensions Method can always be used. The SoH EAP Extensions Method is optional.

Phase 2 encapsulation breakdown

PEAP authentication uses EAP as a transport.  We first introduce the general layout of EAP packets. We then show the specific encapsulation details related to PEAP extension methods.

General EAP Packet layout

The general layout of the EAP Request and Response packet format is as follows (ref. RFC3748 Section 4.1).


0


1


2


3


4


5


6


7


8


9

1
0


1


2


3


4


5


6


7


8


9

2
0


1


2


3


4


5


6


7


8


9

3
0


1

Code

Identifier

Length

Type

Type_Data (variable)

...

Code

    1 for Request

    2 for Response

Examples of common types are:

    1       Identity

    2       Notification

    3       Nak (Response only)

    4       MD5-Challenge

    254   Expanded Types

Note that EAP Packet type for PEAP is Type 25 as specified in MS-PEAP.

The layout for the EAP Success and Failure packet format is shown below (ref. RFC3748 Section 4.2).


0


1


2


3


4


5


6


7


8


9

1
0


1


2


3


4


5


6


7


8


9

2
0


1


2


3


4


5


6


7


8


9

3
0


1

Code

Identifier

Length

 Code

      3 for Success

      4 for Failure                    

PEAP Phase 2 packets: Headers and Methods details

  • PEAP Header for Request: 0 1 XX Y Y YY 1 9 0 0

          EAP Code = 01, Identifier = XX, Length = YY YY, EAP Type = 25, Flags + Ver = 00

  • PEAP Header for Response: 02 XX Y Y YY 1 9 0 0

          EAP Code = 02, Identifier = XX, Length = YY YY, EAP Type = 25, Flags + Ver = 00

  • SoH EAP Extensions Method Header: F E 0 0 0 1 3 7 0 0 0 0 0 0 2 1

          Type = 254 (Expanded Types), Vendor ID = 0x00 01 37, TLV extensions method = 33(MS-Authentication TLV)

  • Vendor Specific TLV Header: 0 0 0 7 X X X X 0 0 0 0 0 1 3 7

          TLV Type = 00 07, Length = XX XX, Vendor_ID = 0x00 00 01 37 

  • Cryptobinding TLV = 00 0C 00 38 + Data (56 bytes)

          TLV_Type = 12 = 0x0C, Length = 56 = 0x38

  • EAP Success: 0 3 X X 0 0 0 4

Scenario where Client is non-NAP capable

PEAP Phase 2 sequence 

Server to Client

Client to Sever

Identity

Request/Response

PEAP Header Request + Data

PEAP Header Response + Data

MS-SoH

Request/Response

 

PEAP Header + SoH EAP Extensions Method Header + Vendor Specific TLV Header + SoH Request TLV

PEAP Header Response  + Data: NAK to the MS-SoH Request from Client to Server (Client also proposed inner EAP method:

Type =0x03 (NAK), Type-Data = 0x1a (MS-CHAPv2)

Inner Method

Request/Response

PEAP Header Request + Type-Data with Type-Code = 0x1a (MS-CHAPv2), OpCode = 0x01 (Request)

PEAP Header Response + Type-Data with Type-Code = 0x1a (MS-CHAPv2), OpCode = 0x02 (Response)

Inner Method

Success

PEAP Header Request + Type-Data with Type-Code = 0x1a (MS-CHAPv2), OpCode = 0x03 (Success)

PEAP Header Response + Type-Data with Type-Code = 0x1a (MS-CHAPv2), OpCode = 0x03 (Success)

Result and Cryptobinding TLV

PEAP Header Request + EAP TLV Extension Method Header + Result TLV + Cryptobinding TLV

PEAP Header Response + EAP TLV Extension Method Header + Result TLV + Cryptobinding TLV

EAP Success

EAP Success

 

Scenario where client is NAP capable

PEAP Phase 2 sequence 

Server to Client

Client to Sever

Identity

Request/Response

PEAP Header Request + Data

PEAP Header Response + Data

 

MS-SoH

Request/Response

 

PEAP Header + SoH EAP Extensions Method Header + Vendor Specific TLV Header + SoH Request TLV

PEAP Header Response + SoH EAP Extensions Method Header + Vendor Specific TLV Header + SoH TLV

Inner Method

Request/Response

PEAP Header Request + Type-Data with Type-Code = 0x1a (MS-CHAPv2), OpCode = 0x01 (Request)

PEAP Header Response + Type-Data with Type-Code = 0x1a (MS-CHAPv2), OpCode = 0x02 (Response)

Inner Method

Success

PEAP Header Request + Type-Data with Type-Code = 0x1a (MS-CHAPv2), OpCode = 0x03 (Success)

PEAP Header Response + Type-Data with Type-Code = 0x1a (MS-CHAPv2), OpCode = 0x03 (Success)

Result, SoH Response and Cryptobinding TLV

PEAP Header  Request + EAP TLV Extension Method Header + Result TLV + SoH Response TLV + Cryptobinding TLV

PEAP Header Response + EAP TLV Extension Method Header + Result TLV + Cryptobinding TLV

EAP Success

EAP Success

 

 

I hope this helps in troubleshooting or debugging your implementation.

References:

[MS-PEAP]: Protected Extensible Authentication Protocol (PEAP) Specification

[MS-SOH]: Statement of Health for Network Access Protection (NAP) Protocol Specification

[MS-CHAP]: Extensible Authentication Protocol Method for Microsoft Challenge Handshake Authentication Protocol (CHAP) Specification

[RFC3748] Extensible Authentication Protocol (EAP)

[RFC2716] PPP EAP TLS Authentication Protocol

[RFC1661] The Point-to-Point Protocol (PPP)

[RFC2865] Remote Authentication Dial-In User Service (RADIUS)

NAP Client Architecture

NAP Server-side Architecture