reauth-problem with WPA2-tls

[Andreas Hartmann]

Andreas Hartmann schrieb:
> Alan DeKok schrieb:
>> Andreas Hartmann wrote:
>>> I have one basic question:
>>> There are now two different caches: one in eap (based on ssl) and the
>>> extern cache, rlm_caching.
>>
>>   rlm_caching has nothing to do with EAP.
>>
>>> 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?
>>
>>   The EAP configuration explains what you need to do for fast re-auth.
>>
>>> 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.
>>
>>   What is it supposed to do?
>>
>>> 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)?
>>
>>   What do you want to do?
>>
>>   I have no idea why you configured the caching module, and you haven't
>> explained why you configured it.
> 
> Thanks for your reply,
> 
> I configured it, because fast-reauth doesn't work for me.
> 
> - In the wpa_supplicant, fast_reauth is switched to 1.
> - In eap.conf, the cache under tls is enabled.
> 
> Now, wpa_supplicant is started and the client got authenticated. But
> there is a warning nearly at the end of the successfull authentication:
> 
> Fri Jun  4 09:42:11 2010 : Info: [tls] eaptls_verify returned 3
> Fri Jun  4 09:42:11 2010 : Info: [tls] eaptls_process returned 3
> Fri Jun  4 09:42:11 2010 : Info: [tls] Adding user data to cached session
> Fri Jun  4 09:42:11 2010 : Info: [tls] Saving response in the cache
> Fri Jun  4 09:42:11 2010 : Info: [tls] WARNING: No information to
> 				       ^^^^^^^^^^^^^^^^^^^^^^^^^^
> cache: session caching will be disabled for this session.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Meanwhile, I defined a realm (I didn't had any until now). This seems to
make the initial session caching working!


Jun  4 11:12:43 2010 : Info: [tls] ACK handshake is finished
Fri Jun  4 11:12:43 2010 : Info: [tls] eaptls_verify returned 3
Fri Jun  4 11:12:43 2010 : Info: [tls] eaptls_process returned 3
Fri Jun  4 11:12:43 2010 : Info: [tls] Adding user data to cached
				       ^^^^^^^^^^^^^^^^^^^^^^^^^^
session
^^^^^^^

Fri Jun  4 11:12:43 2010 : Info: [tls] Saving response in the cache
Fri Jun  4 11:12:43 2010 : Info: [eap] Freeing handler
Fri Jun  4 11:12:43 2010 : Info: ++[eap] returns ok
Fri Jun  4 11:12:43 2010 : Auth: Login OK: [myuser at mydom] (from client
WAP610N port 0 cli 00-13-....)


But the following fast-reauth doesn't work nevertheless:


Fri Jun  4 11:22:48 2010 : Info: [tls] Done initial handshake
Fri Jun  4 11:22:48 2010 : Info: [tls] <<< TLS 1.0 ChangeCipherSpec
[length 0001]
Fri Jun  4 11:22:48 2010 : Info: [tls] <<< TLS 1.0 Handshake [length
0010], Finished
Fri Jun  4 11:22:48 2010 : Info: [tls]     TLS_accept: SSLv3 read finished A
Fri Jun  4 11:22:48 2010 : Info: [tls]     (other): SSL negotiation
finished successfully
Fri Jun  4 11:22:48 2010 : Debug: SSL Connection Established
Fri Jun  4 11:22:48 2010 : Debug: SSL Application Data
Fri Jun  4 11:22:48 2010 : Info: [tls] eaptls_process returned 3
Fri Jun  4 11:22:48 2010 : Info: [tls] Retrieved session data from
cached session
Fri Jun  4 11:22:48 2010 : Info: [tls] WARNING: No information in
					^^^^^^^^^^^^^^^^^^^^^^^^^
cached session!
^^^^^^^^^^^^^^^

Fri Jun  4 11:22:48 2010 : Info: [eap] Freeing handler
Fri Jun  4 11:22:48 2010 : Info: ++[eap] returns reject
Fri Jun  4 11:22:48 2010 : Info: Failed to authenticate the user.
Fri Jun  4 11:22:48 2010 : Auth: Login incorrect: [myuser at mydom] (from
client WAP610N port 0 cli 00-13-....)
Fri Jun  4 11:22:48 2010 : Info: Using Post-Auth-Type Reject
Fri Jun  4 11:22:48 2010 : Info: +- entering group REJECT {...}
Fri Jun  4 11:22:48 2010 : Info: [attr_filter.access_reject]    expand:
%{User-Name} -> myuser at mydom
Fri Jun  4 11:22:48 2010 : Debug:  attr_filter: Matched entry DEFAULT at
line 11
Fri Jun  4 11:22:48 2010 : Info: ++[attr_filter.access_reject] returns
updated
Fri Jun  4 11:22:48 2010 : Info: Delaying reject of request 11 for 1 seconds


What does it mean: No information in cached session? Couldn't the key be
found (what's the key? The username "myuser" or "myuser at mydom" or
soemthing else - do I have the chance to debug it?) or was the key
found, but there was no data associated?



Kind regards,
Andreas