[RADIATOR] random EAP authentication errors since 4.17

Tue Dec 13 10:32:11 UTC 2016

Answers below


On 2016-12-13 07:59, Heikki Vatiainen wrote:
> On 1.12.2016 17.02, Hartmaier Alexander wrote:
>
>> We're fighting duplicate requests due to slow responses because of
>> PEAP-TLS many exchanged packets.
>>
>> Is FarmSize still unusable when enabling EAP_UseState because the EAP
>> context data isn't shared between the forked childs?
>
> This has not changed. EAP_UseState does not change this. Even if EAP 
> context data kept by Radiator could be shared between children, 
> there's still the TLS state that lives within the TLS library that can 
> not be easily shared.
>
>> Can Gossip be used to share this state between the childs or the State
>> attribute to balance all requests of one EAP session always to the same
>> child?
>
> Gossip, or some other method, could be used for sharing EAP context. 
> However, the problem with TLS based EAP methods is the TLS state.
>
>> I've added this line to all PostAuthHooks and everything seems to work
>> as it should:
>>
>> my $self = $p->{AuthBy};
>> my $context = $self->getEAPContext($p);
>
> I strongly advice to get context like this:
> my $context = $p->{EAPContext};
Ok, I've changed our hooks to use this again like before, seems to not 
make a difference both ways.
Can you please add this to the reference guide?
>
>> return
>>         if Net::SSLeay::session_reused($context->{ssl});
>>
>> As I currently don't log if an auth was an EAP auth or a session
>> resumption I can't tell if the session resumption works.
>
> The session_reused() call will tell this.
I've added logging and all resumed sessions are missing the reply 
attributes we're adding with our hooks (mainly vlan id).
Does this check signal a successful resume or just the attempt to do so?

It seems the reply attributes added by the hook code for the first, 
non-resumed authentication aren't stored in the EAP context.
Please advise if it is required to do that manually or if this is a bug 
in 4.17.
>
> Please note that as I wrote earlier, I'd consider EAP authentication 
> that uses TLS session resumption as EAP authentication too.
Of course, just a different way.
>
>> Can you please advice how to log session resumption?
>
> For now I'd use the session_reused() check with the Hook.
This works, but we're not sure if it means the resumption was successful 
or attempted, see above.
>
> For help with hooks, I have thought about the following: Add a resume 
> counter in EAP context. If resume support is off, the counter would 
> always have undefined value. When resume support is enabled, the 
> counter would be initialised to 0 and incremented for each resume. 
> This would allow you to simply check 'if 
> ($context->{eap_tls_resume_count})' to see if a TLS resume was done.
>
> This counter could also be used to enforce policies, for example, an 
> upper for how many times (not just for how long) a session can be 
> resumed. This could also be something that can be logged in 
> authentication log for example for statistics.
>
> When the resume happens and information that needs to be kept over 
> resumed sessions is recovered, a hook can be added to do any local 
> processing that might be required to recover custom information used 
> by the current configuration. In addition to this, a user specific 
> opaque value (could be a simple scalar or reference, for example) can 
> be copied over by the code. The user hooks could then use this as they 
> wish.
>
> In short: we can enhance the support for storing configuration 
> specific data in the resume information and can add a counter that can 
> be used to detect resumption with hooks.
As far as I've understood I'd need to save and resume any additional 
data I'm adding to the EAP context, how to do that?
Is it possible to persist that through server restarts or are reloads 
the only workaround?
SystemD doesn't support reload as far as I know, can this be accomplised 
by sending a signal to the radiator process in a user friendly way?

>
> Thanks,
> Heikki
>
>> Thanks, Alex
>>
>>
>> On 2016-11-30 18:09, Hartmaier Alexander wrote:
>>> On 2016-11-30 17:45, Heikki Vatiainen wrote:
>>>> On 30.11.2016 18.02, Hartmaier Alexander wrote:
>>>>
>>>>> Let me clarify our setup:
>>>>> EAPTLS_CertificateVerifyHook parses the cert issuer and subject and
>>>>> populates
>>>>>     $context->{customer} = $customer;
>>>> [cut]
>>>>
>>>> Thanks, this clarifies the situation. You need to save information
>>>> across resumed authentications.
>>>>
>>>>> I assume that the PostAuthHook is also run for resumed sessions but
>>>>> EAPTLS_CertificateVerifyHook isn't which leads to the lack of the
>>>>> $context contents and thus the failure of the PostAuthHook.
>>>>
>>>> Correct. Certificate verification runs only during full TLS handshake.
>>>> Handler's PostAuthHook runs always when Handler is finishing its work.
>>>> It does not matter if the TLS handshake within an AuthBy was full or
>>>> resumed.
>>>>
>>>> I'll get back to you about how to save custom information across
>>>> resumed authentications. For more about what is saved now, see EAP.pm
>>>> and eap_save_resume_context and its counterpart just below. When
>>>> thinking about possible options would a hook work for you? Another
>>>> possibly might be to automatically save suitably named context
>>>> variables, for example $context->{custom_info} would be automatically
>>>> saved and restored.
>>>>
>>>> The reason for this change was to allow the user of State attribute
>>>> with EAP authentication and more clearly separate information that is
>>>> needed during one EAP authentication dialog from information that
>>>> needs to be kept across resumed authentications.
>>>>
>>>> Thanks,
>>>> Heikki
>>>>
>>> Correct me if I'm wrong but can a resumed session every be not 
>>> accepted?
>>> As it means that a successful auth has happened before.
>>> Should a PostAuth hook, or some of the other hooks, be run at all in
>>> this case?
>>> It might make sense to differenciate between an authentication and a
>>> resumption.
>>>
>>> As the 'last_reply_attrs' are already stored in the context it might be
>>> the easiest option to either use a different hook instead of PostAuth,
>>> continue using PostAuth if you decide to not call PostAuth for resumed
>>> 'auths' or detect the resumption in the Hook and just bail out of it at
>>> the very beginning.
>>>
>>>
>>> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* 
>>>
>>>
>>> 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
>>
>> _______________________________________________
>> radiator mailing list
>> radiator at lists.open.com.au
>> http://lists.open.com.au/mailman/listinfo/radiator
>