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.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
_______________________________________________
radiator mailing list
radiator@lists.open.com.au
http://lists.open.com.au/mailman/listinfo/radiator
