reauth-problem with WPA2-tls

[Andreas Hartmann]

Andreas Hartmann schrieb:
> Bjørn Mork schrieb:
>> Andreas Hartmann <andihartmann at 01019freenet.de> writes:
>>
>>> 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?
>>
>> I wondered about the same...  You can find the session store and
>> retrieve code in src/modules/rlm_eap/libeap/eap_tls.c :
>>
>> 	} else if (!SSL_session_reused(tls_session->ssl)) {
>> 		RDEBUG2("Saving response in the cache");
>> 		
>> 		vp = paircopy2(request->reply->vps, PW_USER_NAME);
>> 		pairadd(&vps, vp);
>> 		
>> 		vp = paircopy2(request->packet->vps, PW_STRIPPED_USER_NAME);
>> 		pairadd(&vps, vp);
>> 		
>> 		if (vps) {
>> 			SSL_SESSION_set_ex_data(tls_session->ssl->session,
>> 						eaptls_session_idx, vps);
>> 		} else {
>> 			RDEBUG2("WARNING: No information to cache: session caching will be disabled for this session.");
>> 			SSL_CTX_remove_session(tls_session->ctx,
>> 					       tls_session->ssl->session);
>> 		}
>>
>> 		/*
>> 		 *	Else the session WAS allowed.  Copy the cached
>> 		 *	reply.
>> 		 */
>>
>> 	} else {
>> 	       
>> 		vp = SSL_SESSION_get_ex_data(tls_session->ssl->session,
>> 					     eaptls_session_idx);
>> 		if (!vp) {
>> 			RDEBUG("WARNING: No information in cached session!");
>> 			return eaptls_fail(handler, peap_flag);
>> 		} else {
>> 			RDEBUG("Adding cached attributes to the reply:");
>> 			debug_pair_list(vp);
>> 			pairadd(&request->reply->vps, paircopy(vp));
>>
>> 			/*
>> 			 *	Mark the request as resumed.
>> 			 */
>> 			vp = pairmake("EAP-Session-Resumed", "1", T_OP_SET);
>> 			if (vp) pairadd(&request->packet->vps, vp);
>> 		}
>> 	}
>>
>>
>> So I guess the warning means that either SSL_SESSION_set_ex_data() or
>> SSL_SESSION_get_ex_data() failed.  A useful change would be testing the
>> return value of SSL_SESSION_set_ex_data() and print a warning if it
>> fails, possibly using ERR_get_error() and ERR_error_string() or similar
>> to get the actual error.  The latter would also be useful in the
>> SSL_SESSION_get_ex_data() failure case
> 
> Debugging of SSL_SESSION_set_ex_data()
> 
> The returncode of the function is 1 (don't know, if it should be 0 - but
> it could be correct too, if it means, that one pair has been stored).
> 
> vps, which SSL_SESSION_set_ex_data() is given as argument, consists of
> one NULL element.
> 
> request->packet->vps->name gives User-Name, request->reply-vps is null
> (should be PW_USER_NAME). But there cant be any password, because there
> exists no password, because the authentication is done exclusively with
> keys.
> Could this problem be solved by a configuration entry or must it be
> hacked? Is it possible to give wpa_supplicant a dummy password?

Well,
SSL_SESSION_set_ex_data-Error: error:00000000:lib(0):func(0):reason(0) -
SSL couldn't find an error.

> 
> Debugging of SSL_SESSION_get_ex_data()
> 
> At resuming, Index is 2 (eaptls_session_idx). This would be ok. Seems,
> that the returncode 1 from SSL_SESSION_set_ex_data() means, that nothing
> has been saved.

But: no error has been detected:
SSL_SESSION_get_ex_data-Error: error:00000000:lib(0):func(0):reason(0)


Now, I looked at the SSL-session_id.

tls_session->ssl->session->session_id is empty when the data is saved to
the session.

At the time the data is fetched from the session during reauth, the
session_id is not empty (means: there is another id).

I tested to unload the datas after they have been saved - there was no
problem! The data could be retrieved again.

Could there be a problem with the session-handling? There seem to be
different sessions? This would be an explanation why there are no errors
while storing or restoring the data.



Kind regards,
Andreas