[RADIATOR] random EAP authentication errors since 4.17

[Hartmaier Alexander]

Hi Heikki,


On 2017-01-23 14:35, Heikki Vatiainen wrote:
> On 20.1.2017 11.33, Hartmaier Alexander wrote:
>
>> Can you confirm that Radiator stores the information saved by
>> eap_save_resume_context for the same duration as OpenSSL is told to
>> do so?
>> In Radius/TLS.pm line 818 it looks like EAPTLS_SessionResumptionLimit is
>> used to set this timeout too.
>
> Yes, that's correct. The information saved for resume has the same
> lifetime. Also, if it happens that a session is resumed by TLS layer
> but Radiator has no information about the resumed session, the
> authentication will fail.
I can't confirm that behaviour. For us the (by OpenSSL) successfully
resumed session was accepted without any reply attributes leading to
clients not getting in the correct vlan. That's why I've assumed that
the resume context wasn't saved or restored correctly.
>
>> Can you please write up how we should persist our custom data set in the
>> EAPTLS_CertificateVerifyHook and retrieve it in the PostAuth hook?
>> I suggest defining and documenting one key that is persisted and
>> restored by eap_save_resume_context / eap_recover_resume_context which
>> can then be used by hooks to store data in.
>
> I have attached a short PostAuthHook that does this. During the full
> auth, the hook stores a custom value from EAPContext so that it is
> available when TLS resume is done. When a TLS resume is done, it
> copies the value from resume data to EAPContext. This allows you to
> always access your custom value when the hook has run. You may want to
> add more error checks, etc. but it should work as a sample.
>
> The hook can be configured as PostAuthHook for an AuthBy or a Handler.
> In addition to this, for a demo, use this for
> EAPTLS_CertificateVerifyHook:
>
> EAPTLS_CertificateVerifyHook sub {my $p = $_[5]; \
>    $p->{EAPContext}->{hvn_test} = 'hvn_test set in
> CertificateVerifyHook. Time: '. time(); \
>    return $_[0];}
>
> The verify hook sets a custom value that the PostAuthHook stores and
> restores as needed. The timestamp is there to show how the value stays
> the same once it's set during the full authentication.
>
>> Is $p->{EAPContext}->{eap_resume_context} already available in a
>> EAPTLS_CertificateVerifyHook or will data I'll write into it be
>> overwritten?
>
> No, the resume context is created only when TLS has accepted a new
> session. You need to store the values in EAPContext as you are already
> doing.
That explains why my change from $p->{EAPContext}->{hvn_test} to
$p->{EAPContext}->{eap_resume_context}->{hvn_test} in
EAPTLS_CertificateVerifyHook didn't work at all, Radiator overwrote
->{eap_resume_context} without checking that it's already there assuming
noone fiddled with it in a hook.
>
>> Also in a PostAuth hook when a session has been resumed?
>
> Yes, as seen in the attached hook.
>
>> I've tried using $p->{EAPContext}->{eap_resume_context} instead of
>> $p->{EAPContext} for all custom variables but the reply attributes set
>> by our PostAuth hook aren't restored from the resume context as it
>> seems.
>> Is eap_save_resume_context called before the PostAuth hook is called?
>
> It is, but you may want to see the hook to see if it works better in
> your case.
>
>> What about my suggestion to add a warning to Radius::Context::get if a
>> context can't be found?
>> Does this make sense as Radiator has one per-auth context and one
>> per-resumeable session?
>
> I'd say get() does what it's now expected. In other words, it will
> return the existing value or create a new context. Note that there is
> also find() that returns the existing value, if any, and does not
> reset the timeout. But in any case, the caller needs to see if it got
> anything and act accordingly.
To summarize, your suggested solution is:
- store custom variables in $p->{EAPContext} in EAPTLS_CertificateVerifyHook
- move them from $p->{EAPContext} to
$p->{EAPContext}->{eap_resume_context} in a PostAuthHook which can be
both in the EAP enabled AuthBy or the Handler for full authentications
(non-resumed). This is something I've never tried.
- access the stored variables in $p->{EAPContext}->{eap_resume_context}
when resuming. Is there a need to copy them to $p->{EAPContext} if I
only need their values in the PostAuthHook?
- set the reply attributes based on the variables. Here I'd unsure if I
only need to set them for full authentications, because Radiator
persists them $p->{EAPContext}->{eap_resume_context} automatically or if
I need to do that myself because PostAuthHook is after Radiator has done
that already?
>
>> Just saw that the last paragraph in 4.22.77. PostAuthHook is duplicate.
>
> I have made a ticket about this, thanks!
> Heikki

Our findings from Friday and yesterday where that only PEAP-TLS fails,
EAP-TLS works fine.
We've disabled session resumption for all PEAP-TLS authentications, both
wired and wireless to work around the missing reply attributes on
resumption which lead to duplicate request errors.
I did a packet capture on the radius server and saw that the first
packet after the (PEAP) TLS tunnel establishment never gets replied by
radiator (radius packet id 57 in our capture) but it's retransmission by
the Cisco WLC after 5 seconds still gets logged as 'Duplicate request id
57 received from ...'. Do you have any idea why this could be happening?

Further as Radiator 4.13 changelog states that it handles
EAPTLS_MaxFragmentSize of the inner EAP method automatically we've
commented our inner EAPTLS_MaxFragmentSize 1200 which lead to a non
working auth for certificates from two of our three CAs.
We had issues when we onboarded that CA and had to reduce both the outer
PEAP as well as the inner EAP-TLS EAPTLS_MaxFragmentSize by 50 to get it
working.
May there be an edge case that some auths hang because of a too large
packet (for which no error is logged by Radiator) which leads to not
replied requests which IDs are still remembered as already received by
Radiator?

Thanks, Alex


*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*