[RADIATOR] random EAP authentication errors since 4.17

[Heikki Vatiainen]

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.

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

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

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

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.

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

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