FR3 and EAP-TLS session cache

[Jyri Palis]

Hi,

Any ideas what could be wrong with my setup?


Regards,
Jyri

On Sunday, June 14, 2015, Alan DeKok <aland at deployingradius.com> wrote:

> On Jun 14, 2015, at 8:11 AM, Jyri Palis <jyri.palis at gmail.com
> <javascript:;>> 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.
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html