Share via

3.3.5.4.3 Received PEAP Packet with Inner EAP Type As Identity (Identity Received)

  • Article

If the currentState variable is set to INNER_IDENTITY_REQ_SENT, then the following steps MUST be applied in sequence:

  1. Store the received identity in the InnerIdentity datum.

  2. If the isCapabilitiesSupported field is set to TRUE, then prepare a Capabilities Method Request (section 2.2.8.3.1) packet with the F flag set to one if the PEAP server supports phase 2 fragmentation, otherwise, set the F flag to zero.<17> Change the currentState datum to WAIT_FOR_CAPABILITIES_RESPONSE and proceed to step 6.

  3. Validate the received Identity in an implementation-specific manner. If the Identity validation fails, then prepare an EAP TLV Extensions Method (section 2.2.8.1) packet with Result TLV (section 2.2.8.1.2) (the value field set to 2). Change the currentState datum to FAILURE_TLV_SENT and proceed to step 6.

  4. If the isSoHEnabled field is set to TRUE, then prepare an SoH EAP Extensions Method (section 2.2.8.2) packet with an SoH Request TLV (section 2.2.8.2.1) within it. Change the currentState datum to WAIT_FOR_SOH_RESPONSE and proceed to step 6.

  5. If all of the earlier conditions fail, then prepare an EAP Request packet with the Type field set to InnerEapType to start the inner EAP method negotiation as described in [RFC3748] section 2. Compress the EAP Request packet as specified in section 3.1.5.6. Change currentState to PHASE2_EAP_INPROGRESS.

  6. Send the packet prepared earlier to the TLS layer for encryption using the EncryptMessage method.

  7. Prepare a PEAP packet by keeping the encrypted data returned by the EncryptMessage method as the Data field of the PEAP packet, and send it to the peer (see section 3.1.5.2.2).

If currentState is not set to INNER_IDENTITY_REQ_SENT, then the packet is ignored.