EAP-TEAP Compound MAC calculation

Thu Sep 14 11:32:51 UTC 2023

  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 at 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 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
>> 
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html