path: root/src/eap_peer/eap_fast.c
diff options
authorJouni Malinen <jouni@qca.qualcomm.com>2011-10-12 17:05:02 (GMT)
committerJouni Malinen <j@w1.fi>2011-10-12 17:05:02 (GMT)
commit88dc899a1babe151bf26a2b9b9de302bebeb83db (patch)
tree0bb8e6b7d751f32e56a7d3e5af645e92e310fafe /src/eap_peer/eap_fast.c
parent4458d91554cce6c8a78916701c2701162cbbfad1 (diff)
EAP-FAST: Allow unprotected EAP-Failure in provisioning case
While EAP-FAST uses protected success notification, RFC 5422, Section 3.5 points out a possibility of EAP-Failure being sent out even after protected success notification in case of provisioning. Change the EAP-FAST peer implementation to accept that exception to the protected success notification. This allows the station to re-connect more quickly to complete EAP-FAST connection in the case the server rejects the initial attempt by only allowing it to use to provision a new PAC.
Diffstat (limited to 'src/eap_peer/eap_fast.c')
1 files changed, 6 insertions, 2 deletions
diff --git a/src/eap_peer/eap_fast.c b/src/eap_peer/eap_fast.c
index 5d3e69d..acaa7fc 100644
--- a/src/eap_peer/eap_fast.c
+++ b/src/eap_peer/eap_fast.c
@@ -1037,11 +1037,15 @@ static struct wpabuf * eap_fast_process_pac(struct eap_sm *sm,
} else {
* This is PAC refreshing, i.e., normal authentication that is
- * expected to be completed with an EAP-Success.
+ * expected to be completed with an EAP-Success. However,
+ * RFC 5422, Section 3.5 allows EAP-Failure to be sent even
+ * after protected success exchange in case of EAP-Fast
+ * provisioning, so we better use DECISION_COND_SUCC here
+ * instead of DECISION_UNCOND_SUCC.
wpa_printf(MSG_DEBUG, "EAP-FAST: Send PAC-Acknowledgement TLV "
"- PAC refreshing completed successfully");
- ret->decision = DECISION_UNCOND_SUCC;
+ ret->decision = DECISION_COND_SUCC;
ret->methodState = METHOD_DONE;
return eap_fast_tlv_pac_ack();