[RADIATOR] random EAP authentication errors since 4.17

[Hartmaier Alexander]

On 2016-12-15 13:46, Heikki Vatiainen wrote:
> On 15.12.2016 14.04, Hartmaier Alexander wrote:
>
>>> If you get context from $p, it does not matter if, for example,
>>> EAP_UseState was enabled or note. It's easier and more reliable to get
>>> it from $p.
>> I've removed EAP_UseState from our config since everything works as
>> before. Can the nested auth of PEAP-TLS cause this in conjunction with
>> the state ID generation?
>
> I'd say in your case the call to get EAP worked fine because it simply
> returned the context that was retrieved earlier. In other words, it
> did the same as getting the context with $p->{EAPContext}.
>
>> Our PostAuthHook already has this at the very top since the beginning.
>> Is this the correct way to check?
>>
>> my $p      = ${$_[0]};
>> my $rp     = ${$_[1]};
>> my $result = $_[2];
>> my $reason = $_[3];
>>
>> return
>>         unless $$result == $main::ACCEPT;
>
> Yes. This looks fine. The reason you are given a reference to result
> is that you can also change it in case you need to modify the result
> with your hook.
Yes, we already have several $$reason assignments ;)
>
>> Yes, but it only points to EAP.pm which didn't change much since 4.16.
>> How should they be persisted after writing to $context?
>
> I hope this is clarified below. Now when I look at the notes, I can
> see that a mentioned of eap_save_resume_context and
> eap_recover_resume_context could have been included.
>
>> So basically write to and read from
>> $context->{eap_resume_context}->{foo} instead of $context->{foo}?
>> As this doesn't use an accessor method I'd like it at least documented
>> somewhere so we can be sure it doesn't break without notice on one of
>> the next updates.
>
> Yes, that's correct. eap_resume_context points to the context that is
> saved across resumed sessions. You are correct that there are no
> accessors yet. These would be among the helpers for hooks that I wrote
> about earlier.
>
Sadly the sh** didn't stop there, OpenSSL segfaults when
Net::SSLeay::session_reused gets passed an undefined value:

gdb --args perl -E 'use Net::SSLeay; my $foo = {foo => bar};
Net::SSLeay::session_reused($foo->{EAPContext}->{ssl});'

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.
BTW this happens on Debian stable (8) 64bit with all packages updated,
OpenSSL 1.0.1t-1+deb8u5.

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.

Would you advise to use Radius::TLS::contextSessionCheckReuse instead of
Net::SSLeay::session_reused directly?
EAP_25.pm line 219 is the only place where Net::SSLeay::session_reused
is called directly outside of Radius::TLS::contextSessionCheckReuse.

Please advise a safe way of determining and logging EAP session
resumption, we seem to stumble from one pitfall to another ourselves.

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.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*