EAP-FAST: authenticated provisioning failure on Cisco ACS 5.4
Nakashima Akihiro
Nakashima.Akihiro
Fri Apr 24 01:52:53 PDT 2015
Hi all,
I found that wpa_supplicant v2.4 cannot be authenticated with Cisco ACS
Secure 5.4 using EAP-FAST, server authenticated provisioning.
I confirmed older wpa_supplicant also have this issue (tested with v0.73).
The ACS say "12152 Rejected PAC provisioning request because supplicant
failed to adhere to protocol".
According to log of wpa_supplicant, EAP-FAST sequence between wpa_supplicant
and ACS is below:
wpa_supplicant authenticator (ACS)
------------------------------------------------------------------------------
<--- EAP-Payload (Request Identity)
EAP-Payload (Response Identity) --->
<--- EAP-Payload (Request Challenge)
EAP-Payload (Response Challenge) --->
<--- Intermediate-Result (Success)
Crypto-Binding
Crypto-Binding --->
Intermediate-Result (Success)
PAC
<--- Result (Failure)
Nak
------------------------------------------------------------------------------
I confirmed RFC 4851 and section [4.2.8. Crypto-Binding TLV] describe below:
The Crypto-Binding TLV MUST be included with the Intermediate-Result
TLV to perform Cryptographic Binding after each successful EAP method
in a sequence of EAP methods.
Therefore, I think wpa_suplicant should add Intermediate-Result TLV first,
and add Crypto-Binding TLV and PAC TLV as additional TLVs of
the Intermediate-Result TLV.
I modified src/eap_peer/eap_fast.c to add Intermediate-Result TLV first
for trial, it worked well.
My trial modification is below:
Signed-off-by: Akihiro Nakashima <Nakashima.Akihiro at exc.epson.co.jp>
---
eap_fast.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff -uprN a/src/eap_peer/eap_fast.c b/src/eap_peer/eap_fast.c
--- a/src/eap_peer/eap_fast.c 2015-03-16 02:30:39.000000000 +0900
+++ b/src/eap_peer/eap_fast.c 2015-04-24 17:06:25.450036279 +0900
@@ -1198,6 +1198,12 @@ static int eap_fast_process_decrypted(st
req->identifier, out_data);
}
+ if (tlv.iresult == EAP_TLV_RESULT_SUCCESS) {
+ tmp = eap_fast_tlv_result(failed ? EAP_TLV_RESULT_FAILURE :
+ EAP_TLV_RESULT_SUCCESS, 1);
+ resp = wpabuf_concat(resp, tmp);
+ }
+
if (tlv.crypto_binding) {
tmp = eap_fast_process_crypto_binding(sm, data, ret,
tlv.crypto_binding,
@@ -1208,12 +1214,6 @@ static int eap_fast_process_decrypted(st
resp = wpabuf_concat(resp, tmp);
}
- if (tlv.iresult == EAP_TLV_RESULT_SUCCESS) {
- tmp = eap_fast_tlv_result(failed ? EAP_TLV_RESULT_FAILURE :
- EAP_TLV_RESULT_SUCCESS, 1);
- resp = wpabuf_concat(resp, tmp);
- }
-
if (tlv.eap_payload_tlv) {
tmp = eap_fast_process_eap_payload_tlv(
sm, data, ret, tlv.eap_payload_tlv,
--
Could you review and merge it if acceptable?
On the other hand, it seems that hostapd's EAP-FAST sequence is also strange.
The EAP-FAST sequence between wpa_supplicant and hostapd is below:
wpa_supplicant authenticator (hostapd)
------------------------------------------------------------------------------
<--- EAP-Payload (Request Identity)
EAP-Payload (Response Identity) --->
<--- EAP-Payload (Request Challenge)
EAP-Payload (Response Challenge) --->
<--- Result (Success)
Crypto-Binding
Crypto-Binding --->
PAC
Result (Success)
<--- Result (Success)
PAC
PAC (Ack) --->
Result (Success)
------------------------------------------------------------------------------
Section [4.2.2. Result TLV] describe that Result TLV format cannot include
additional TLV like Crypto-Binding TLV.
Therefore, I think hostapd should response with Intermediate-Result TLV.
I don't have candidate of good solution for this hostapd issue...
Best Regards,
Akihiro Nakashima
More information about the Hostap
mailing list