reauth-problem with WPA2-tls

Andreas Hartmann andihartmann at 01019freenet.de
Fri Jun 4 00:12:26 CEST 2010


Alexander Clouter schrieb:
> Bjørn Mork <bjorn at mork.no> wrote:
>> Andreas Hartmann <andihartmann at 01019freenet.de> writes:
>>
>>> Yes, you're right - I meant option eap -> tls -> cache -> enable is
>>> switched _on_ and fast_reauth is on too on the supplicant. My wrong :-(.
>>>
>>> You can see it at this log entry at the initial login:
>>> Wed Jun  2 20:29:14 2010 : Info: [tls] Adding user data to cached session
>>> Wed Jun  2 20:29:14 2010 : Info: [tls] Saving response in the cache
>>> Wed Jun  2 20:29:14 2010 : Info: [tls] WARNING: No information to cache:
>>> session caching will be disabled for this session.
>>>
>>> And then the reauth:
>>>
>>> Wed Jun  2 20:39:18 2010 : Info: [tls] Retrieved session data from
>>> cached session
>>> Wed Jun  2 20:39:18 2010 : Info: [tls] WARNING: No information in cached
>>> session!
>>
>> FWIW I've seen exactly the same with FR 2.1.8.  Ended up disabling
>> caching.  But I would like to know the cause of this "No information to
>> cache" warning.  The resulting failure to retrieve cached data is of
>> course to be expected, but the warning itself doesn't make any sense to
>> me.  There must be information to cache since the authentication is
>> sucessful. 
>>
> The 'No information to cache' means you do not have anything useful 
> (for example 'User-Name') in the reply packet.
> 
> In the post-auth of my inner-eap virtual server I have added:
> ----
> post-auth {
>   ...
>   # needed for TTLS cache
>   update reply {
>     User-Name := "%{request:User-Name}"
>   }
>   ...
> }
> ----

Ok, I'm using exclusivly certificates for authorization. Therefore, I
dont't have any inner-eap, if I got it right.

I have one basic question:
There are now two different caches: one in eap (based on ssl) and the
extern cache, rlm_caching.

If I want to use fast_reauth, is it necessary to enable both caches or
must the ssl-cache in eap.conf be disabled to run fast_reauth
successfully with rlm_caching?

Meanwhile, I have a configuration, which does a User-Name-based
rlm_caching at the end of the last fragment of the initial
authentication with an originaly empty database.


The entry is the following in /etc/raddb/modules/caching

caching {
                filename = ${db_dir}/db.cache
                cache-ttl = 1d
                hit-ratio = 1000
                key = "%{User-Name}"
                # post-auth = "%{User-Name}"
                cache-size = 200000
                # cache-rejects = yes
        }

I'm not sure, if User-Name is the best key for this purpose.


In /etc/raddb/sites-enabled/defaults, caching has the following entries:

authorize {
        caching {
            ok = return
            }
....
	}


post-auth {

....
	caching
                if (updated) {
                        update reply {
                                User-Name := "%{User-Name}"
                        }
                }
}


With this config, the key is written to the caching database at the end
of the inital login.


But the problem is:

If the user reconnects or wants to connect initial again, the process is
stopped (with success returned) at the moment, the client sends the
User-Name.
This is wrong. The process can't be interrupted before the key exchange
has been done successfully.
How can this be written in the config-file (authorize-section)?


Kind regards,
Andreas



More information about the Freeradius-Users mailing list