I'll have to look at that in more detail. Can you open a pull request on GitHub? My main concern is interoperability. TEAP is horrible black magic, and that makes it difficult to fix or change without something else breaking.
On Sep 13, 2023, at 6:40 PM, Suriya Shankar <suriya.dshankar@gmail.com> wrote:
Hi Alan,
I was able to make it work by doing couple changes in the eap_teap.c
--- a/src/modules/rlm_eap/types/rlm_eap_teap/eap_teap.c
+++ b/src/modules/rlm_eap/types/rlm_eap_teap/eap_teap.c
@@ -348,7 +348,6 @@ static int eap_teap_verify(REQUEST *request, tls_session_t *tls_session, uint8_t
uint16_t status = 0;
rad_assert(sizeof(present) * 8 > EAP_TEAP_TLV_MAX);
-
while (remaining > 0) {
if (remaining < 4) {
RDEBUG2("EAP-TEAP TLV is too small (%u) to contain a EAP-TEAP TLV header", remaining);
@@ -357,7 +356,6 @@ static int eap_teap_verify(REQUEST *request, tls_session_t *tls_session, uint8_t
memcpy(&attr, data, sizeof(attr));
attr = ntohs(attr) & EAP_TEAP_TLV_TYPE;
-
switch (attr) {
case EAP_TEAP_TLV_RESULT:
case EAP_TEAP_TLV_NAK:
@@ -438,6 +436,10 @@ unexpected:
}
*> Added new flag send_eap_success and set it when client accepts the second authentication*
status = (data[0] << 8) | data[1];
+ if (status == 1) {
+ t->result_intermed = true;
+ if (attr == EAP_TEAP_TLV_RESULT) t->send_eap_success = true;
+ }
if (status == 0) goto unknown_value;
}
@@ -497,6 +499,7 @@ unexpected:
}
break;
case PROVISIONING:
+ RDEBUG("present value is : %d EAP_TEAP_TLV_PAC %d and EAP_TEAP_TLV_RESULT", present, EAP_TEAP_TLV_PAC, EAP_TEAP_TLV_RESULT);
if (present & ~((1 << EAP_TEAP_TLV_PAC) | (1 << EAP_TEAP_TLV_RESULT))) {
RDEBUG("Unexpected TLVs in provisioning stage");
goto unexpected;
@@ -903,9 +906,8 @@ static rlm_rcode_t CC_HINT(nonnull) process_reply(eap_handler_t *eap_session,
eap_teap_append_result(tls_session, reply->code);
eap_teap_append_crypto_binding(request, tls_session, msk, msklen, emsk, emsklen);
-
vp = fr_pair_find_by_num(request->state, PW_EAP_TEAP_TLV_IDENTITY, VENDORPEC_FREERADIUS, TAG_ANY);
*> Noticed the Attribute value pair we are looking for has been sent after we send the identity request, so used result_intermed flag to toggle for sending outer eap_success *
- if (vp) {
+ if (!t->result_intermed) {
RDEBUG("&session-state:FreeRADIUS-EAP-TEAP-TLV-Identity-Type set so continuing EAP sequence/chaining");
/* RFC3748, Section 2.1 - does not explictly tell us to but we need to eat the EAP-Success */
@@ -916,17 +918,18 @@ static rlm_rcode_t CC_HINT(nonnull) process_reply(eap_handler_t *eap_session,
t->username = NULL;
/* RFC7170, Appendix C.6 */
- eap_teap_append_identity(tls_session, vp->vp_short);
*> Hardcoded the cert type here, thinking of maintaining a state and incrementing it *
+ eap_teap_append_identity(tls_session, 1);
eap_teap_append_eap_identity_request(request, tls_session, eap_session);
goto challenge;
}
-
+ t->result_final = true; eap_teap_append_result(tls_session, reply->code);
tls_session->authentication_success = true; *> Sending the inner tunnel success first and wait for client response. Or else we get Unexpected TLV error*
- rcode = RLM_MODULE_OK;
+ rcode = RLM_MODULE_HANDLED;
*> If the send_eap_success is set we are letting the outer tunnel success *
+ if (t->send_eap_success) rcode = RLM_MODULE_OK;
break;
@@ -1406,7 +1409,7 @@ PW_CODE eap_teap_process(eap_handler_t *eap_session, tls_session_t *tls_session)
/* RFC7170, Appendix C.6 */
vp = fr_pair_find_by_num(request->state, PW_EAP_TEAP_TLV_IDENTITY, VENDORPEC_FREERADIUS, TAG_ANY);
- if (vp) eap_teap_append_identity(tls_session, vp->vp_short);
+ eap_teap_append_identity(tls_session, 2);
eap_teap_append_eap_identity_request(request, tls_session, eap_session);
@@ -1434,10 +1437,10 @@ PW_CODE eap_teap_process(eap_handler_t *eap_session, tls_session_t *tls_session)
break;
case PROVISIONING: - if (!t->result_final) { +/* if (!t->result_final) { t->result_final = true; eap_teap_append_result(tls_session, code); - } + }*/
#if 0 if (t->pac.send) { @@ -1483,6 +1486,6 @@ PW_CODE eap_teap_process(eap_handler_t *eap_session, tls_session_t *tls_session) }
tls_handshake_send(request, tls_session); - + RDEBUG("Code being returned from eap_teap_process: %d", code); return code;
}
I have tested with a couple of certificates in my client and tested it which worked fine. Are these changes good or the direction I am proceeding is right. Looking for your suggestion and any recommendation.
Thanks,
Suriya
On Wed, Aug 16, 2023 at 3:27 PM Alan DeKok <aland@deployingradius.com> wrote:
On Aug 16, 2023, at 4:01 PM, Suriya Shankar <suriya.dshankar@gmail.com> wrote:
I am trying to calculate the Compound MAC for EAP-TEAP. But the description in the rfc 7170 is bit confusing
Very much so.
The short answer is that this list is about FreeRADIUS. If you're implementing an EAP type for another piece of software, there are likely other places to go.
The FreeRADIUS source code for the compound MAC calculation is in src/modules/rlm_eap/types/rlm_eap_teap.
Could any please help me in understanding the Compound MAC calculation or guide me in the right direction
Don't read RFC 7170. It's confusing, and substantially wrong.
Read the updated document, which is soon to be published: https://datatracker.ietf.org/doc/draft-ietf-emu-rfc7170bis/11/
It's not only clearer, but it's what Microsoft / FreeRADIUS / Cisco / hostap / etc. have all done.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html