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).


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.

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.

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.

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.


Heikki Vatiainen <h...@open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
radiator mailing list

Reply via email to