[RADIATOR] random EAP authentication errors since 4.17

[Hartmaier Alexander]

On 2016-12-13 14:45, Heikki Vatiainen wrote:
> On 13.12.2016 12.32, Hartmaier Alexander wrote:
>
>>> 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.
>
> 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?
>
>> Can you please add this to the reference guide?
>
> Good idea. I think this discussion means we need to create an example
> how to keep custom data that persists across resumed authentications.
Thanks!
>
>>> 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?
>
> I am not sure if this has been strictly defined by the OpenSSL API. To
> be sure, I would only check this after the TLS session has been
> accepted. I'd check first that, for example, PostAuthHook result is
> ACCEPT before continuing. Radiator only does this check for TLS
> sessions that have been successfully established.
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;

>
>> 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.
>
> You need to do it manually. This is why it got a special mention in
> the release history.
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?
>
> What you could do is to write your custom attributes in the
> resume_context when the authentication was successfully and
> session_reused() indicates it was not a resumed. See
> eap_save_resume_context in EAP.pm for an example.
>
> The next time around when session_reused() indicates TLS did resume,
> you can once again get the resume_context like above, but now just
> verify the values are there and then use them.
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.
>
> When the next Radiator release is done, see the change history for the
> possible helpers that you could consider using in your hooks instead.
> One of the helpers could be the resume count I wrote about earlier.
>
>>> 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.
>
> As I mentioned above, I would only check this if the result indicates
> authentication success.
>
> What comes to reliably saving state information across server restarts
> and reloads, that is not currently supported. Saving the resume
> context required by Radiator is doable. SQL, Redis and similar could
> be used for this. Storing and and reloading TLS library's TLS sessions
> seems to be possible, from a quick look at the openssl docs. As a
> downside, doing this would not still help with FarmSize without more
> work there.
>
> If you need to split load, maybe you could consider a front end proxy
> that uses, for example, AuthBy HASHBALANCE to forward messages to a
> number of workers where each worker is bound to its own port, as
> opposed one port with FarmSize.
>
> Thanks,
> Heikki
>
Cheers, 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.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*