[RADIATOR] random EAP authentication errors since 4.17

Heikki Vatiainen hvn at open.com.au
Tue Dec 13 06:40:55 UTC 2016

On 30.11.2016 19.09, Hartmaier Alexander wrote:

> Correct me if I'm wrong but can a resumed session every be not accepted?

It's possible. EAP-TLS can check if the user is still available in the 
user database or has their account been, for example, removed.

PEAP requires the server and client to share a single handshake over the 
resumed TLS tunnel before the PEAP authentication is fully accepted by 
the both peers. This could be thought of one sort of authentication.

In other words, TLS resume tells that the peers can resume a previously 
created session. On the EAP and Radius layer I'd consider a TLS resumed 
EAP-TLS, PEAP, etc. just a quicker way to authenticate where some things 
were skipped since they were already done, for example inner 
authentication, certificate checks.

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

I think the hooks and other processing should be called the same as with 
non-resumed authentication. There could be, for example, an AuthBy GROUP 
where PEAP authby runs first and then another authby does possibly 
authorisation. This next authby may not care if PEAP did a full or 
resumed authentication but it needs to run always.

> It might make sense to differenciate between an authentication and a
> resumption.

This can be made available for hooks. What you can already do is to 
check Net::SSLeay::session_reused(). More about this in another reply.

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

Detecting resumption in a Hook could be the best option here. If the 
hook needs to behave differently, then it can do so.


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,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, 
NetWare etc.

More information about the radiator mailing list