[RADIATOR] random EAP authentication errors since 4.17

[Heikki Vatiainen]

On 20.1.2017 11.33, Hartmaier Alexander wrote:

> Can you confirm that Radiator stores the information saved by
> eap_save_resume_context for the same duration as OpenSSL is told to do so?
> In Radius/TLS.pm line 818 it looks like EAPTLS_SessionResumptionLimit is
> used to set this timeout too.

Yes, that's correct. The information saved for resume has the same 
lifetime. Also, if it happens that a session is resumed by TLS layer but 
Radiator has no information about the resumed session, the 
authentication will fail.

> Can you please write up how we should persist our custom data set in the
> EAPTLS_CertificateVerifyHook and retrieve it in the PostAuth hook?
> I suggest defining and documenting one key that is persisted and
> restored by eap_save_resume_context / eap_recover_resume_context which
> can then be used by hooks to store data in.

I have attached a short PostAuthHook that does this. During the full 
auth, the hook stores a custom value from EAPContext so that it is 
available when TLS resume is done. When a TLS resume is done, it copies 
the value from resume data to EAPContext. This allows you to always 
access your custom value when the hook has run. You may want to add more 
error checks, etc. but it should work as a sample.

The hook can be configured as PostAuthHook for an AuthBy or a Handler. 
In addition to this, for a demo, use this for EAPTLS_CertificateVerifyHook:

EAPTLS_CertificateVerifyHook sub {my $p = $_[5]; \
    $p->{EAPContext}->{hvn_test} = 'hvn_test set in 
CertificateVerifyHook. Time: '. time(); \
    return $_[0];}

The verify hook sets a custom value that the PostAuthHook stores and 
restores as needed. The timestamp is there to show how the value stays 
the same once it's set during the full authentication.

> Is $p->{EAPContext}->{eap_resume_context} already available in a
> EAPTLS_CertificateVerifyHook or will data I'll write into it be
> overwritten?

No, the resume context is created only when TLS has accepted a new 
session. You need to store the values in EAPContext as you are already 
doing.

> Also in a PostAuth hook when a session has been resumed?

Yes, as seen in the attached hook.

> I've tried using $p->{EAPContext}->{eap_resume_context} instead of
> $p->{EAPContext} for all custom variables but the reply attributes set
> by our PostAuth hook aren't restored from the resume context as it seems.
> Is eap_save_resume_context called before the PostAuth hook is called?

It is, but you may want to see the hook to see if it works better in 
your case.

> What about my suggestion to add a warning to Radius::Context::get if a
> context can't be found?
> Does this make sense as Radiator has one per-auth context and one
> per-resumeable session?

I'd say get() does what it's now expected. In other words, it will 
return the existing value or create a new context. Note that there is 
also find() that returns the existing value, if any, and does not reset 
the timeout. But in any case, the caller needs to see if it got anything 
and act accordingly.

> Just saw that the last paragraph in 4.22.77. PostAuthHook is duplicate.

I have made a ticket about this, 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eap_tls_post_auth_hook_resume.pl
Type: text/x-perl-script
Size: 1079 bytes
Desc: not available
URL: <http://lists.open.com.au/pipermail/radiator/attachments/20170123/9e410a4b/attachment.bin>