[RADIATOR] random EAP authentication errors since 4.17

[Heikki Vatiainen]

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 <hvn at 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.