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