3.1.5.1 Status and Error Handling
If a PEAP implementation receives a packet that does not satisfy the MUST clauses of this specification, the packet MUST be silently discarded.
PEAP supports TLS alert messages (as specified in [RFC2246] section 7.2) from phase 1 (see section 1.3), but does not have its own error messaging capabilities.
PEAP implementations MUST support the EAP Extensions Methods for the communication of authentication status between the PEAP peer and the PEAP server.
In EAP, success or failure packets are sent as the last packet in a conversation. However, these packets are not protected, and they can be forged by an attacker. Also, success and failure packets are not retransmitted and, therefore, might be lost. As a result, PEAP provides its own protected and reliable success/failure indications via the EAP Extensions Methods. A PEAP peer implementation MUST consider authentication successful only if it receives both an EAP success packet and an EAP TLV extensions result TLV with the Value field set to 1 (which indicates success, as specified in section 2.2.8.1.2). This behavior is also evident in the processing rules specified in sections 3.2.5.4.7, 3.2.5.4.8, and 3.2.5.4.9.