[RADIATOR] random EAP authentication errors since 4.17

[Hartmaier Alexander]

Hi,

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.

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?

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.

We've increased EAPContextTimeout to the same 43200 seconds as 
EAPTLS_SessionResumptionLimit which seems to have fixed the issue.

If you can confirm that our analysis is correct please add something 
like this to the docs of EAPContextTimeout:

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.

I'd also suggest to add a warning log message to Radius::Context::get if 
a context can't be found and a new one is returned.


Thanks, Alex

On 2016-12-19 10:23, Hartmaier Alexander wrote:
>
>
> On 2016-12-16 12:40, Heikki Vatiainen wrote:
>> On 16.12.2016 11.46, Hartmaier Alexander wrote:
>>
>>> Sadly the sh** didn't stop there, OpenSSL segfaults when
>>> Net::SSLeay::session_reused gets passed an undefined value:
>>
>> For Net::SSLeay this is just a pass through call to OpenSSL's
>> respective function. I think the caller is responsible for not handing
>> undef/NULL as the argument.
>>
>> For this reason I'd say this is not a candiate for a ticket against
>> Net::SSLeay and is not something that neither Net::SSLeay or OpenSSL
>> needs to handle.
> I agree with your view regarding Net::SSLeay but not on OpenSSL,
> function args should always be validated.
>>
>>> Is Mike (author of Net::SSLeay) still working for you? I haven't opened
>>> a RT for the module as I'm not sure if this should be handled at the
>>> Perl XS layer or in OpenSSL.
>>
>> Mike is still maintainer for Net::SSLeay, but he is not with us
>> anymore. About the ticket, as I mentioned above, I think we need to do
>> the null check inside Radiator hook.
>>
>>> As a workaround I'll check for exists $p->{EAPContext} && exists
>>> $p->{EAPContext}->{ssl} before calling the function. This was enough 
>>> for
>>> MAC bypass auths (non-EAP) but expired certs crashed Radiator again
>>> today.
>>
>> I'd add && $p->{EAPContext}->{ssl} to the checks too. What likely
>> happens now is that the hash key 'ssl' exists but the value for the
>> key is undef. I'd say this is caused by the code that runs when the
>> expiration was noticed.
> Already done that last week ;) Seems to be stable so far.
>>> Would you advise to use Radius::TLS::contextSessionCheckReuse 
>>> instead of
>>> Net::SSLeay::session_reused directly?
>>
>> I think what could be done in this function is to set something like
>> $context->{eap_tls_session_resumed} to the value returned by
>> Net::SSLeay::session_reused or implement the resume counter which I
>> mentioned earlier. I would not call this function from a hook since
>> its purpose is to check if the session was resumed or not and do
>> what's appropriate based on resumption and configured resumption
>> settings.
> We'd prefer to have a special variable we can use for logging instead of
> having to do the determination ourselves.
>>
>>> Please advise a safe way of determining and logging EAP session
>>> resumption, we seem to stumble from one pitfall to another ourselves.
>>
>> I'd say the above extra check allow session_reused() to work for now
>> until we add the extras/helpers mentioned above and the earlier 
>> messages.
> Ok, thanks!
>>
>> Thanks for your patience,
>> Heikki
>>
>
>
>
> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* 
>
> 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 at lists.open.com.au
> http://lists.open.com.au/mailman/listinfo/radiator