EAP-TEAP Compound MAC calculation
Suriya Shankar
suriya.dshankar at gmail.com
Wed Sep 13 22:40:01 UTC 2023
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 at deployingradius.com>
wrote:
> On Aug 16, 2023, at 4:01 PM, Suriya Shankar <suriya.dshankar at 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
>
More information about the Freeradius-Devel
mailing list