Compartir a través de


3.1.5.6 Phase 2 (EAP Encapsulation)

Once phase 1 successfully completes, all subsequent EAP messages are exchanged inside the tunnel established in phase 1. The exceptions are the EAP success or the EAP failure packets (as specified in [RFC3748] section 4.2), which are never sent within the tunnel because result indications are handled by the PEAP implementation itself instead of the inner EAP method (via the Result TLV (section 2.2.8.1.2)).

PEAP can compress an inner EAP packet prior to encapsulating it within the Data field of a PEAP packet by removing its Code, Identifier, and Length fields. This compression scheme MUST be applied to all inner method types except for the EAP TLV Extensions Method, the Capabilities Negotiation Method, and the SoH EAP Extensions Method; in these cases, the compression scheme MUST NOT be applied.

Likewise, PEAP can decompress an EAP packet before passing it to an inner EAP method for processing. It does this by setting the Code and Identifier fields of the inner EAP packet to the values stored in the Code and Identifier fields of the outer EAP packet, and by setting the Length field of the inner EAP packet to the length of the decrypted inner EAP message plus 4. This decompression scheme MUST be applied to all inner EAP method types except for the EAP TLV Extensions Method, the Capabilities Negotiation Method, and the SoH EAP Extensions Method; in these cases, the decompression scheme MUST NOT be used.

PEAP implementations MUST only support a single EAP authentication method per session with a type greater than or equal to 4, in addition to supporting EAP TLV Extensions Method (and optionally SoH EAP Extensions Method) in the same session.