Hi Jouni and all, we found an interoperability issue while troubleshooting a wpa_supplicant PEAPv1/MS-CHAPv2 "bad password" authentication scenario against Cisco Identity Services Engine (ISE) RADIUS server. While discussing the issue with Cisco technical support (TAC) we found that the root cause is different implementation of PEAPv1 in Cisco Identity Services Engine, which is the successor of Cisco Access Control System (ACS) RADIUS server. According to TAC "Cisco's implementation" of PEAPv1 in ISE is based on IETF draft "draft-zhou-pppext-peapv1-00", which differs from the last PEAPv1 IETF draft "draft-josefsson-pppext-eap-tls-eap-05" (https://tools.ietf.org/html/draft-josefsson-pppext-eap-tls-eap-05) in the following way (the complete Cisco's "draft-zhou-pppext-peapv1-00" draft was provided by TAC to me and I can forward it to anyone if needed; was not able to find it online): ===== BEGIN excerpt from draft-zhou-pppext-peapv1-00 ===== 1. Introduction Cisco's implementation of PEAP Version 1 differs in the following ways from the protocol specified in [PEAP]. PRF string used to generate the master session key TLS message length field Acknowledgement of protected success and failure Each of these differences is explained in the sections that follow. 1.1. PRF String Used to Generate the Master Session Key The [PEAP] specification requires "client PEAP encryption" being used as the PRF string to generate the master session keys. The Cisco implementation uses "client EAP encryption" instead, the same PRF string as defined in the [RFC2716] specification. This applies to both Cisco's client and server implementation. 1.2. TLS Message Length Field Cisco implementation of PEAP requires the L bit and four octet TLS message length field always present during the first part of PEAP while establishing the TLS tunnel, even if the TLS packets fits within a single TLS fragment. This is different than the TLS protocol as specified in [RFC2716], which stated the L bit MUST be set for the first fragment of a fragmented TLS message or set of messages. Please note this only applies to the first part of PEAP. After TLS tunnel has been established, Cisco PEAP implementation is not expected to see the TLS L bit and Message Length Field, as most of the exchanges within EAP-GTC are short and within one single fragment. 1.3. Acknowledgement of Protected Success and Failure The [PEAP] termination mechanism (sending an encrypted EAP Success or EAP Failure packet) does not function correctly with Authenticators implementing [IEEE8021X]. Since IEEE 802.1X authenticators "manufacture" a clear-text EAP Success based on receipt of a RADIUS Access-Accept, or a clear-text EAP Failure based on receipt of a RADIUS Access-Reject, unless an acknowledged success/failure indication is used, the PEAP Supplicant may never receive a protected success/failure indication. This leaves the PEAP Supplicant open to attack. As a result, Cisco PEAP implementation supports acknowledged and protected success/failure indications, using the approach described below: 1. After the authentication method in the second part of PEAP finishes authenticating the user, it will send back an EAP-Success or EAP-Failure encrypted within the TLS channel. 2. Peer MUST send back a PEAP packet with empty TLS data field to acknowledge the receipt of success or failure. TLS channel will be torn down. The acknowledge packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Flags |Ver| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 2 Identifier The Identifier field is one octet and aids in matching responses with requests. Length 6 Type 25 - PEAP type Flags 0 Ver 1 - PEAP Version 1 3. EAP server would send back a clear text EAP-Success or EAP-Failure to finalize the EAP process. While the [PEAP] specification permits a tunneled EAP Success or Failure packet to be sent as the last message, this is not possible within the Cisco implementation. Since the [IEEE8021X] specification requires that the switch or access point "manufacture" a clear-text EAP Success packet when an Access-Accept is received from the back end authentication server, and a clear-text EAP Failure packet when an Access-Reject is received. As a result, a tunneled EAP Success or Failure packet, if sent as the last message, would be thrown away by conformant [IEEE 8021X] implementations, and replaced with clear-text. This problem is being addressed within the IEEE 802.1aa revision to IEEE 802.1X, but the fix may take a while to move through the standards process and be implemented in commercial products. 4. Normative References [PEAP] Andersson, H., et al. "Protected EAP Protocol", Internet draft (work in progress), draft-josefsson-pppext-eap-tls- eap-02.txt, February 2002. ===== END of excerpt from draft-zhou-pppext-peapv1-00 ===== While analyzing the requirements it seems to me that the requirements are partially implemented in the current code: Requirement 1.1 is fulfilled by "peaplabel=0" option in phase1 section of wpa_supplicant config file, which is also the default, so it can be omitted from config. Requirement 1.2 is fulfilled by "include_tls_length=1" option in phase1 section of wpa_supplicant config file. Requirement 1.3 is partially fulfilled by "peap_outer_success=2" option in phase1 section of wpa_supplicant config file, which is also the default, so it can be omitted from config. But wpa_supplicant sends a TLS ACK only on successful authentication (while receiving a tunneled EAP-Success) and not in the case of failed authentication (while receiving a tunneled EAP-Failure). This leads to error messages in ISE logs, which assumes that the supplicant behaves incorrectly. Can someone validate that the above is correct and if yes, would it be possible to implement "send PEAP TLS/ACK on receiving EAP-Failure" to wpa_supplicant in order to be fully compliant with ISE? Best Regards, Jiri Benes Senior Systems Engineer Networksys a.s. _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
