[RADIATOR] random EAP authentication errors since 4.17

[Hartmaier Alexander]

On 2017-01-19 16:30, Heikki Vatiainen wrote:
> On 19.1.2017 13.00, Hartmaier Alexander wrote:
>
>> we still have an issue with session resumption where the EAP context
>> doesn't contain the custom variables we've stored in the
>> EAPTLS_CertificateVerifyHook of the initial, non-resumed,
>> authentication.
>
> I hope I can clarify this. Please note that EAP context is aimed at
> for short term storage only, as described below.
>
>> How does EAPContextTimeout, which has been reduced from 1000 to 120
>> seconds in version 4.17, interact with EAPTLS_SessionResumptionLimit
>> which defaults to 43200 seconds (12 hours) which we have explictly
>> configured to this value?
>
> EAPContextTimeout is for EAP authentication only. It sets the timeout
> for the client to respond and continue the ongoing EAP authentication.
>
> EAPTLS_SessionResumptionLimit is for OpenSSL as you have correctly
> understood below.
>
>> If I've interpreted the code and OpenSSL docs correctly, OpenSSL would
>> keep the data required for a successful session resumption for
>> EAPTLS_SessionResumptionLimit (12 hours).
>
> Yes.
>
>> If a client sends a session id it would look up the session and find it
>> if < EAPTLS_SessionResumptionLimit but Radiator would have thrown away
>> its context because of > EAPContextTimeout and not return any reply
>> attributes in the accept reply.
>
> Correct partly. Radiator can throw away the EAP current context once
> the authentication has finished. However, it will store information
> required for session resumption. This information is stored and
> retrieved by the functions in EAP.pm. For example, the reply
> attributes, among other information, is stored by
> eap_save_resume_context().
>
> In other words, the information required across resumed sessions has
> its own storage that is separate from the EAP authentication context.
> When a session is resumed successfully, the saved information is
> copied in EAP context so that hooks etc. can continue to use it as
> they have done with earlier releases.
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.
>
>> We've increased EAPContextTimeout to the same 43200 seconds as
>> EAPTLS_SessionResumptionLimit which seems to have fixed the issue.
>
> This will keep the EAP context around so that the custom values you
> save in EAP context are always available. This works even if you don't
> save the custom values to resume storage similar to how EAP.pm
> eap_save_resume_context() does. What you are doing is much like how
> things were working before the separate storage saved by
> eap_save_resume_context() was introduced.
>
> What Radiator saves by default with the above function is the
> information it needs. This includes, for example, the reply attributes
> and information about inner authentication user names for PEAP and
> such. It does not include any custom information since it's now known
> what it might be.
>
> What you would need to save and recover from the resume_context is
> your custom information. As was discussed in the previous messages,
> there's no interface to do it yet, but I can see that it is needed.
Although both timeouts are now identical we still have issues with a
much lower amount of clients than before where the OpenSSL session
resumption works, but $p->{EAPContext} in the PostAuth hook doesn't
contain any of the custom variables.

As previously asked it should be sufficient to skip any PostAuth
processing at the beginning of a PostAuth hook using this code as
Radiator has saved the reply attributes from the initial full
authentication ifself:
return
         if exists $context->{ssl} &&
Net::SSLeay::session_reused($context->{ssl});

exists $context->{ssl} is required because SSL_session_reused in OpenSSL
1.0.2 segfaults when given an invalid pointer (undefined at the Perl level).

This would however lose the custom variables used for logging.

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.

Is $p->{EAPContext}->{eap_resume_context} already available in a
EAPTLS_CertificateVerifyHook or will data I'll write into it be overwritten?
Also in a PostAuth hook when a session has been resumed?

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?
>
>> If you can confirm that our analysis is correct please add something
>> like this to the docs of EAPContextTimeout:
>
> I think we need to include information that describes how to save
> custom information in case, for example, customisation done by hooks
> requires it. That is, document the interface that needs to be
> implemented for saving the custom data.
>
> What you have described below would be for cases when EAP_UseState is
> not enabled. Even then the resumption is not allowed if Radiator does
> not know about the first full authentication.
>
> When State attribute use is enabled, then the context lookup will also
> depend on the State attribute that is created for each EAP
> authentication exchange.
We've disabled EAP_UseState as it increased the failure and added even
more complexity to our already complex setup.
>
>> If the Radiator context timeout for the EAP session is shorter than the
>> OpenSSL session timeout (EAPTLS_SessionResumptionLimit) a session
>> resumption will succeed at the OpenSSL level but Radiator will create a
>> new context which doesn't include any custom data nor the initial Radius
>> reply attributes.
>
> Thanks again for your input on this.
>
> Thanks,
> Heikki
>

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?

Just saw that the last paragraph in 4.22.77. PostAuthHook is duplicate.

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.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*