Share via

PEAP Phase 2 fragmentation support

  • Article

The Extensible Authentication Protocol (EAP) does not support fragmentation and reassembly. Hence EAP authentication methods generating payloads larger than then minimum EAP MTU need to provide fragmentation support. MS-PEAP is a tunnelling method comprising of multiple phases. The purpose of the first phase is to authenticate the EAP Server and to establish a TLS session. The subsequent phases are used to allow the EAP Server to authenticate the EAP Peer inside the TLS session established in phase 1.

 

MS-PEAP standard has support for fragmentation of PEAP packets. However, MS-PEAP implementation in OS'es prior to Windows 7 supported fragmentation only during phase 1. Starting from Windows 7 MS-PEAP implementation has support for fragmentation in all phases.

 

MS-PEAP implementation in Windows7 with support for fragmentation ensures the following:

 

1. PEAP-Client and PEAP-Server with/without support for fragmentation interoperate with each other for packet size lesser than EAP MTU.

2. WIN7 MS-PEAP Client interoperates with PEAP-Server supporting fragmentation for packet size greater than EAP MTU.

3. PEAP-Client with support for fragmentation interoperates with WIN7 MS-PEAP Server for packet size greater than EAP MTU.

4. WIN7 MS-PEAP Client has diagnostic logs to identity the failure in authentication due to PEAP-Server's inability to process fragmented packets.

5. WIN7 MS-PEAP Server has diagnostic logs to identity the failure in authentication due to PEAP-Clients inability to process fragmented packets.

 

Support for 4) and 5) is provided through a negotiation protocol between the PEAP-Client and PEAP-Server. The negotiation protocol is an enhancement to the MS-Extentions method defined in the PEAP specification. The negotiation protocol will hereafter be referred to as Capabilities Method.

 

After the completion of phase 1, the PEAP-Server will send an EAP-Identity-Request within the TLS tunnel and will receive an EAP-Identity-Response from the EAP peer. After getting the identity response within the tunnel, the server will send Capabilities method request packet. If the client supports the Capabilities method then it will send method response with Capabilities data. If the client does not understand the Capabilities method request from the server, then it will NAK the request assuming that server is proposing this method as part of EAP negotiation. After server

receives either of the above packets it proceeds with normal execution of SOH or Inner EAP negotiation. 

 

For WIN7 MS-PEAP-Client or WIN7 MS-PEAP-Server that talks with 3rd party PEAP-Server or PEAP-Client which already supports fragmentation but does not understand the negotiation method, the MS-PEAP-Client or MS-PEAP-Server can be configured to bypass the negotiation protocol and to force it support fragmentation.

 

The registry keys BypassNegotiation and AssumePhase2Fragmentation can be used to configure the MS-PEAP-Client and Server to bypass the negotiation protocol and force it to support fragmentation. BypassNegotiation and AssumePhase2Fragmentation registry values are present under HKLM\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\25 registry key.

 

Trouble Shooting :

 If Microsoft’s windows7 PEAP client is authenticating with a third party Server that supports fragmentation and the fragmentation is still not happening, then ‘AssumePhase2Fragmentation’ key is not set on the client.

 

 If a third party PEAP client that supports fragmentation is authenticating to Microsoft’s windows7 Server having Microsoft’s PEAP and the fragmentation is still not happening, then ‘AssumePhase2Fragmentation’ key is not set on the server.

 

Note:

PEAP-Client: MS client side implementation of PEAP in OS'es prior to WIN7 or 3rd party client side implementation of PEAP

PEAP-Server: MS server side implementation of PEAP in OS'es prior to WIN7 or 3rd party server side implementation of PEAP

Comments