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.
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.
Thanks,
Heikki
--
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,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.
_______________________________________________
radiator mailing list
radiator@lists.open.com.au
http://lists.open.com.au/mailman/listinfo/radiator
