EAP-TEAP Compound MAC calculation
Hi, I am trying to calculate the Compound MAC for EAP-TEAP. But the description in the rfc 7170 is bit confusing Section 4.2.13 mentions both the MSK and EMSK Compound MAC is either Server MAC or Client MAC (not sure what exactly are those). Section 5.3 gives the calculation where we have to zero out both MSK and EMSK Compound MAC and apply the MAC function to calculate the Compound MAC. - What's the resultant Compound MAC we get from trying section 5.3 (MSK or EMSK Compound MAC) - What algorithm should we use? The document adds to consider TLS 1.2 rfc 5246 where the recommended algorithm is HMAC 256 that results in 32 octet digest instead of the expected 20 octet one. Could any please help me in understanding the Compound MAC calculation or guide me in the right direction Thanks, Suriya
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.
Hi Alan, Thank you. I am able to bring up the eap_teap module from 3.2.x and the client is happy until the first inner TLS. Intermediate Result Success is being shared with each other. But with the vp = fr_pair_find_by_num(request->state,
PW_EAP_TEAP_TLV_IDENTITY, VENDORPEC_FREERADIUS, TAG_ANY);
is being returned null and before the second certificate exchange, server is sending success and so client rejects the authentication saying Unexpected TLV. Where do we set the request->state with the Attr pair to avoid this? For the same reason EAP_TEAP_TLV_IDENTITY is not being sent even for the first Inner tunnel authentication. As per the documentation the TLV is the hint for the client and I believe it may not essential for the connection to establish. Is 3.2.x the right version for eap_teap? 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
On Aug 21, 2023, at 8:14 PM, Suriya Shankar <suriya.dshankar@gmail.com> wrote:
Thank you. I am able to bring up the eap_teap module from 3.2.x and the client is happy until the first inner TLS. Intermediate Result Success is being shared with each other.
That's good.
But with the vp = fr_pair_find_by_num(request->state,
PW_EAP_TEAP_TLV_IDENTITY, VENDORPEC_FREERADIUS, TAG_ANY);
is being returned null and before the second certificate exchange, server is sending success and so client rejects the authentication saying Unexpected TLV.
You have to configure the Identity-Type correctly. It's all a bit magical.
Where do we set the request->state with the Attr pair to avoid this?
We're working on documentation for TEAP. For now, it's still largely experimental.
For the same reason EAP_TEAP_TLV_IDENTITY is not being sent even for the first Inner tunnel authentication. As per the documentation the TLV is the hint for the client and I believe it may not essential for the connection to establish.
Is 3.2.x the right version for eap_teap?
All of the code is public. If I say TEAP is in v3.2.x, then I'm not trying to mislead you. There is no secret repository of TEAP that you only get access to by asking nicely. Since all of the code is public, you can also walk through the way rlm_eap_teap works, to see what it's doing. Then, configure the server the way the module expects. Alan DeKok.
Hi Alan, I am able to authenticate both the certificates in the inner tunnel. I have hard coded to request the client first User and Machine authentication. I am receiving those certificates as expected , validate those certificates and server sends the EAP-Success in plain text without encryption for some reason the client doesn't respond anything and just says *Can't Connect to this Network* For reference *(51) Login OK: [anonymous/<via Auth-Type = eap_S_94de66e8-556a-4d56-8780-a114620a5c42>] (from client localhost port 0 cli BC-6E-E2-F2-22-CC)* *(51) Sent Access-Accept Id 36 from 0.0.0.0:3000 <http://0.0.0.0:3000> to 100.96.1.28:35488 <http://100.96.1.28:35488> length 183* *(51) MS-MPPE-Recv-Key = 0x456ec819f468acc0c54be0be0b7e5fe301a6842101f2ade041e2da5643acbc54* *(51) MS-MPPE-Send-Key = 0x1a2c3e892943e6955152ce9912c118e070681098a18c9ee4f7e18fbfd52def91* *(51) EAP-Message = 0x03a00004* *(51) Message-Authenticator = 0x00000000000000000000000000000000* *(51) User-Name = "anonymous"* *(51) Framed-MTU = 994* *(51) Acct-Interim-Interval = 7200* *(51) Finished request* I verified all the communication between client and server which is in the exact sequence described in Appendix C.6. Sequence of EAP Methods I checked the Event Viewer from the client and the information is not that clear. It complains* "A fatal error occured while creating a TLS credential. The internal error state is 10013."* Do we have a better way to debug this issue? Thank you so much for your help Regards, Suriya On Mon, Aug 21, 2023 at 5:34 PM Alan DeKok <aland@deployingradius.com> wrote:
On Aug 21, 2023, at 8:14 PM, Suriya Shankar <suriya.dshankar@gmail.com> wrote:
Thank you. I am able to bring up the eap_teap module from 3.2.x and the client is happy until the first inner TLS. Intermediate Result Success is being shared with each other.
That's good.
But with the vp = fr_pair_find_by_num(request->state,
PW_EAP_TEAP_TLV_IDENTITY, VENDORPEC_FREERADIUS, TAG_ANY);
is being returned null and before the second certificate exchange, server is sending success and so client rejects the authentication saying Unexpected TLV.
You have to configure the Identity-Type correctly. It's all a bit magical.
Where do we set the request->state with the Attr pair to avoid this?
We're working on documentation for TEAP. For now, it's still largely experimental.
For the same reason EAP_TEAP_TLV_IDENTITY is not being sent even for the first Inner tunnel authentication. As per the documentation the TLV is the hint for the client and I believe it may not essential for the connection to establish.
Is 3.2.x the right version for eap_teap?
All of the code is public. If I say TEAP is in v3.2.x, then I'm not trying to mislead you. There is no secret repository of TEAP that you only get access to by asking nicely.
Since all of the code is public, you can also walk through the way rlm_eap_teap works, to see what it's doing. Then, configure the server the way the module expects.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On Aug 23, 2023, at 9:04 PM, Suriya Shankar <suriya.dshankar@gmail.com> wrote:
I am able to authenticate both the certificates in the inner tunnel.
That's good.
I have hard coded to request the client first User and Machine authentication. I am receiving those certificates as expected , validate those certificates and server sends the EAP-Success in plain text without encryption for some reason the client doesn't respond anything and just says *Can't Connect to this Network*
It's difficult for us to debug a supplicant. We didn't write the supplicant, and we don't know anything about it.
I checked the Event Viewer from the client and the information is not that clear. It complains* "A fatal error occured while creating a TLS credential. The internal error state is 10013."*
Do we have a better way to debug this issue?
If this is Microsoft, you'll have to ask them what error 10013 means. I don't know anything about that. Alan DeKok.
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
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
Hi Alan, I created the PR https://github.com/FreeRADIUS/freeradius-server/pull/5180 Thank you so much for your help. Regards, Suriya On Thu, Sep 14, 2023 at 4:33 AM Alan DeKok <aland@deployingradius.com> wrote:
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
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
participants (2)
-
Alan DeKok -
Suriya Shankar