FR3 and EAP-TLS session cache

[Alan DeKok]

On Jun 14, 2015, at 8:11 AM, Jyri Palis <jyri.palis at gmail.com> wrote:
> I have been trying to get FR (3.0.4) EAP-TLS session caching to work with ‘check-eap-tls’ virtual server, so far no luck.
> Initial EAP-TLS session is established correctly and Windows 7 clients get access to protected WLAN but requests following initial request fail to utilise data stored TLS session cache data client is force to proceed with full TLS handshake.

  You can do in-memory caching.  I suggest trying that first.  It works in all of my tests.

  As a second step, enable on-disk caching.

> Virtual server 'check-eap-tls’ which is configured to verify client certificates fails when cached TLS session calls this method, variables needed for verification are not propagated correctly.

  What does that mean?

> server check-eap-tls {
>    authorize {
> 
>        if ("%{TLS-Client-Cert-Subject-Alt-Name-Upn}" =~ /^([a-z0-9]|[\w\.-]?)+\@example\.com$/i) {
>            update config {
>                Auth-Type := Accept

  This is in the inner tunnel, right?  

> This is a fragment from log file:

  Why?  We recommend reading the *debug* output.

> Sun Jun 14 14:56:11 2015 : Auth: (44) Login incorrect (eap: Failed continuing EAP TLS (13) session. EAP sub-module failed): [host/xxxxx.example.com/<via Auth-Type = EAP>] (from client wc-s1-01 port 2 cli 00-24-d7-03-2b-38)
> Sun Jun 14 14:56:16 2015 : Error: Couldn't open /var/log/radius/tlscache/c0373a395b8cc8bc3bd2fe453c3f235454b5216a47c1cb66e30580cd697033f1.vps for reading: No such file or directory

  Probably because the TLS data isn't being cached.

> So is there a way to check session status in ‘authorize’ block and accept auth when cached TLS session is detected?

  The server does that automatically.  That's the whole point of the cache,

> This is written to stdout when running in debug mode 

  And... you've only posted part of the debug log.

  How about looking *earlier* in the log, for the first EAP-TLS session?  Does the debug log say it's caching that session?

no? of course caching won't work

yes? something else is going wrong, like the cached sessions are being deleted.

> (15)  eap_tls : Length Included
> (15)  eap_tls : eaptls_verify returned 11
> (15)  eap_tls : (other): before/accept initialization
> (15)  eap_tls : TLS_accept: before/accept initialization
> (15)  eap_tls : <<< TLS 1.0 Handshake [length 007c], ClientHello
>  SSL: Client requested cached session f35d02540a8e9c4faf8620dfe25e4e82941192f8686390ec3591df41ba22f967
> reading pairlist file /var/log/radius/tlscache/f35d02540a8e9c4faf8620dfe25e4e82941192f8686390ec3591df41ba22f967.vps
> Couldn't open /var/log/radius/tlscache/f35d02540a8e9c4faf8620dfe25e4e82941192f8686390ec3591df41ba22f967.vps for reading: No such file or directory

  That would be pretty definitive.  The TLS data wasn't written to the persistent disk cache.

  Alan DeKok.