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.
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).
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.
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.
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].
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].
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.
The general layout of the EAP Request and Response packet format is as follows (ref. RFC3748 Section 4.1).
1 for Request
2 for Response
Examples of common types are:
3 Nak (Response only)
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).
3 for Success
4 for Failure
EAP Code = 01, Identifier = XX, Length = YY YY, EAP Type = 25, Flags + Ver = 00
EAP Code = 02, Identifier = XX, Length = YY YY, EAP Type = 25, Flags + Ver = 00
Type = 254 (Expanded Types), Vendor ID = 0x00 01 37, TLV extensions method = 33(MS-Authentication TLV)
TLV Type = 00 07, Length = XX XX, Vendor_ID = 0x00 00 01 37
TLV_Type = 12 = 0x0C, Length = 56 = 0x38
PEAP Phase 2 sequence
Server to Client
Client to Sever
PEAP Header Request + Data
PEAP Header Response + Data
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)
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)
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
PEAP Header Response + SoH EAP Extensions Method Header + Vendor Specific TLV Header + SoH TLV
Result, SoH Response and Cryptobinding TLV
PEAP Header Request + EAP TLV Extension Method Header + Result TLV + SoH Response TLV + Cryptobinding TLV
I hope this helps in troubleshooting or debugging your implementation.
[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