wpa_supplicant PEAPv1 TLS/ACK on receiving EAP-Failure - interoperability with Cisco ISE RADIUS server

[Beneš Jiří]

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.