wpa_supplicant PEAPv1 TLS/ACK on receiving EAP-Failure - interoperability with Cisco ISE RADIUS server
benes at networksys.cz
Mon May 15 05:14:40 PDT 2017
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 =====
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|
The Identifier field is one octet and aids in matching
responses with requests.
25 - PEAP type
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?
Senior Systems Engineer
More information about the Hostap