Re: reauth-problem with WPA2-tls
Andreas Hartmann wrote: > Problem is fixed! Your missing a ssl-option when setting up SSL. Since > SSL version 0.9.8j, openssl supports stateless session resumption. This > means, no session_id is created in the server, if both, client and > server, support it. > > I'm using on both sides openssl 0.9.8k, the server generates no > session-key (which you need for saving resume-data). > > See: http://www.mail-archive.com/openssl-us...@openssl.org/msg56976.html. All I can say is that is one of the *worst* poorly documented changes in behavior I have ever seen. They could have made the default to be no change in behavior, but no... > Setting > > ctx_options |= SSL_OP_NO_TICKET ; > > in rlm_eap_tls.c I've added the fix, thanks. > is needed, to get a working sessionhandling in freeradius with openssl > > 0.9.8i. > > It was good to have a lot of comments in the code and to have a lot of > debug messages. So I could follow what's going on in detail. That's good to hear. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: reauth-problem with WPA2-tls
Hello! Problem is fixed! Your missing a ssl-option when setting up SSL. Since SSL version 0.9.8j, openssl supports stateless session resumption. This means, no session_id is created in the server, if both, client and server, support it. I'm using on both sides openssl 0.9.8k, the server generates no session-key (which you need for saving resume-data). See: http://www.mail-archive.com/openssl-us...@openssl.org/msg56976.html. Setting ctx_options |= SSL_OP_NO_TICKET ; in rlm_eap_tls.c is needed, to get a working sessionhandling in freeradius with openssl > 0.9.8i. It was good to have a lot of comments in the code and to have a lot of debug messages. So I could follow what's going on in detail. Kind regards, Andreas - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: reauth-problem with WPA2-tls
Andreas Hartmann wrote: > That's right. But: > > 1. There could be a security issue with parallel handled users during > initial login, because they probably have all the same empty session > id's at the same time. Well... that's an OpenSSL bug. We can check for it and try to avoid the issue. But as I said, the session_id is managed by OpenSSL. > 2. Session handling does definitely not work at this point (I tried to > find the reason today but couldn't get it yet). Uh... for *you*. It works for me, and others. > Why should I believe that it works error free at the other places in > freeradius? I have no idea what you mean by that. It really sounds like a veiled accusation that the server is somehow broken in unknown ways. > 3. You are right, that there are probably no security issues with > rejected users. But why are you sure, that every session-id you get, > does belong to the user you think that it belongs to? It could be the > data from another user too. Blame OpenSSL. I really can't be any clearer than that. When *I* use OpenSSL, the session key isn't empty. > 4. I can't say, if it's an exploitable scenario. May be - may be not. FUD. > The session-handling in freeradius does not allways work as expected and > until now the cause for the not allways working session-handling is unknown. Nonsense. It's an OpenSSL bug, and you have been told repeatedly it's an OpenSSL bug. Calling it "unknown" is being stupid. > Or in other words: The session-handling works not predictable (sometimes > it works as expected - sometimes not - but you can't define "sometimes" > - or I didn't found it yet). Unpredictable behavior and security is a > contradiction. You're repeating your fears to the point of being ridiculous. > It's your application that suffers - it's not openssls one. > Therefore I can't understand why you don't set everything to get a real > solution? Because no one else has reported this, and I don't want to track down bugs in OpenSSL. It's really not my problem. > And no, I don't want to bash you. I'm willing to help, but I need your > support to try to understand what's going on. What part of my message is unclear? It's an OpenSSL bug. > I am willing to help you > to find and fix the problem - even if it is not a bug in freeradius. > It is all the same to me, if it's a bug in openssl or in freeradius. I > do have just one goal: freeradius should work predictable in that case. > That's all and this goal can't be bad for you! Thanks for thinking of our goals. > I can't file a bug for openssl. What should I wrote? The session > handling in openssl does not work with freeradius? And I can file a bug with more information? I can't reproduce the problem, so I have *less information than you. Stop being lazy, and go file an OpenSSL bug. If you care to fix the problem, this is the *only* way to solve it. > They will say: ok, openssl has been patched for EAP Nonsense. > or they will ask > detailed things about the handling of SSL in freeradius. I think that > you are the best person to answer these questions! Nonsense. I can't reproduce the problem, and the code is publicly available. *You* are the best person to reproduce the problem. > BTW: > During my investigations today, I detected, that the defined callback > cbtls_new_session never gets called during an initial session. That > corresponds to the thing, that I can't see any session-ID during initial > login. Well... the callback is controlled by oh... let me guess.. *OPENSSL*. > I would like to know, why the client suddenly has a session-ID at > resumption time? Where do they come from? Perhaps you should try asking *THE OPENSSL PEOPLE* ? If you have a patch for FreeRADIUS, supply it. But it is inappropriate to ask *us* to track down and fix an *OpenSSL* issue that only *you* can see. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: reauth-problem with WPA2-tls
Alan DeKok schrieb: > Andreas Hartmann wrote: >> See http://bugs.freeradius.org/bugzilla/show_bug.cgi?id=81 > > Where you file a bug against FreeRADIUS for an OpenSSL issue. > > I understand that FreeRADIUS is affected. But... > >> It does not work for me. There seem to be problems with the >> session-handling, which should be checked, explained and, if necessary, >> fixed. > > FreeRADIUS does not create, update, or maintain the "session_id" > variable. It's created by OpenSSL. If has different values for the > "same" session, then file a bug against OpenSSL. > >> Until I don't have a comprehensibly explanation for the reported >> session-ID behavior, the current version (and 2.1.8) of freeradius is >> highly insecure. > > I have no idea why you think that's true. Failing to find a previous > session means that the new request will be rejected. There are no > security issues with rejecting users. That's right. But: 1. There could be a security issue with parallel handled users during initial login, because they probably have all the same empty session id's at the same time. 2. Session handling does definitely not work at this point (I tried to find the reason today but couldn't get it yet). Why should I believe that it works error free at the other places in freeradius? 3. You are right, that there are probably no security issues with rejected users. But why are you sure, that every session-id you get, does belong to the user you think that it belongs to? It could be the data from another user too. 4. I can't say, if it's an exploitable scenario. May be - may be not. The session-handling in freeradius does not allways work as expected and until now the cause for the not allways working session-handling is unknown. Or in other words: The session-handling works not predictable (sometimes it works as expected - sometimes not - but you can't define "sometimes" - or I didn't found it yet). Unpredictable behavior and security is a contradiction. It's your application that suffers - it's not openssls one. Therefore I can't understand why you don't set everything to get a real solution? And no, I don't want to bash you. I'm willing to help, but I need your support to try to understand what's going on. I am willing to help you to find and fix the problem - even if it is not a bug in freeradius. It is all the same to me, if it's a bug in openssl or in freeradius. I do have just one goal: freeradius should work predictable in that case. That's all and this goal can't be bad for you! I can't file a bug for openssl. What should I wrote? The session handling in openssl does not work with freeradius? They will say: ok, openssl has been patched for EAP or they will ask detailed things about the handling of SSL in freeradius. I think that you are the best person to answer these questions! BTW: During my investigations today, I detected, that the defined callback cbtls_new_session never gets called during an initial session. That corresponds to the thing, that I can't see any session-ID during initial login. I would like to know, why the client suddenly has a session-ID at resumption time? Where do they come from? Kind regards, Andreas - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: reauth-problem with WPA2-tls
Andreas Hartmann wrote: > See http://bugs.freeradius.org/bugzilla/show_bug.cgi?id=81 Where you file a bug against FreeRADIUS for an OpenSSL issue. I understand that FreeRADIUS is affected. But... > It does not work for me. There seem to be problems with the > session-handling, which should be checked, explained and, if necessary, > fixed. FreeRADIUS does not create, update, or maintain the "session_id" variable. It's created by OpenSSL. If has different values for the "same" session, then file a bug against OpenSSL. > Until I don't have a comprehensibly explanation for the reported > session-ID behavior, the current version (and 2.1.8) of freeradius is > highly insecure. I have no idea why you think that's true. Failing to find a previous session means that the new request will be rejected. There are no security issues with rejecting users. The patch you suggested in the bug report *bypasses* this session checking, and *CREATES A SECURITY PROBLEM*. You should not use it in any production system. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: reauth-problem with WPA2-tls
Alan DeKok schrieb: > Andreas Hartmann wrote: >> well, I thought about the problem with reauth: Why must there be passwords >> in the session? > > There shouldn't be passwords in the session. There should be a *name* > in the session. > >> That's why it shouldn't be necessary to have these Keys in the Session or >> in the response (the client didn't send any password, too). >> >> At the moment of adding the Password to the session, the handshake has been >> done already. > > I have no idea why you think it's adding passwords to the session. > It's not. I derived it from the PW_ prefix of the variable name, which is wrong. I know it meanwhile. >> Therefore, I did the following change (-> for testing only >> This should be used only with EAP/tls for testing - no warranty!): > > That change removes the fix added in 2.1.8. It *will* break your system. I know that it was added because of another reported bug. And I know, that my test-change can't be a solution (as I wrote myself). The problem seems to be much deeper. Kind regards, Andreas - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: reauth-problem with WPA2-tls
Alan DeKok schrieb: > Andreas Hartmann wrote: >> 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). > > OpenSSL is weird. > > The fast re-auth worked when I tested it with TTLS && PEAP. Others > have tested it to work. See http://bugs.freeradius.org/bugzilla/show_bug.cgi?id=81 It does not work for me. There seem to be problems with the session-handling, which should be checked, explained and, if necessary, fixed. Until I don't have a comprehensibly explanation for the reported session-ID behavior, the current version (and 2.1.8) of freeradius is highly insecure. Kind regards, Andreas - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: reauth-problem with WPA2-tls
Andreas Hartmann wrote: > 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). OpenSSL is weird. The fast re-auth worked when I tested it with TTLS && PEAP. Others have tested it to work. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: reauth-problem with WPA2-tls
Andreas Hartmann wrote: > well, I thought about the problem with reauth: Why must there be passwords > in the session? There shouldn't be passwords in the session. There should be a *name* in the session. > That's why it shouldn't be necessary to have these Keys in the Session or > in the response (the client didn't send any password, too). > > At the moment of adding the Password to the session, the handshake has been > done already. I have no idea why you think it's adding passwords to the session. It's not. > Therefore, I did the following change (-> for testing only > This should be used only with EAP/tls for testing - no warranty!): That change removes the fix added in 2.1.8. It *will* break your system. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: reauth-problem with WPA2-tls
Hello, well, I thought about the problem with reauth: Why must there be passwords in the session? EAP/TLS doesn't need any passwords to be exchanged. The passphrase stays local. That's why it shouldn't be necessary to have these Keys in the Session or in the response (the client didn't send any password, too). At the moment of adding the Password to the session, the handshake has been done already. from src/modules/rlm_eap/libeap/eap_tls.c (original): - } 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); } } --- Therefore, I did the following change (-> for testing only This should be used only with EAP/tls for testing - no warranty!): --- } 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) { // here should be a check for the authentication type EAP/tls, // because I'm not sure, if this code is used exclusively for eap/tls RDEBUG("WARNING: No information in cached session!"); vp = pairmake("EAP-Session-Resumed", "1", T_OP_SET); if (vp) { pairadd(&request->packet->vps, vp); RDEBUG("WARNING: Missing session-data ignored!"); } else { RDEBUG("WARNING: Couldn't set EAP-Session-Resumed data!"); return eaptls_fail(handler, peap_flag); } } else { RDEBUG("Adding cached attributes to the reply:"); debug_pair_list(vp); pairadd(&request->reply->vps, paircopy(
Re: reauth-problem with WPA2-tls
Andreas Hartmann schrieb: > Bjørn Mork schrieb: >> Andreas Hartmann 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: [myu...@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} -> myu...@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 "myu...@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::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::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 d
Re: reauth-problem with WPA2-tls
Andreas Hartmann wrote: >> >> 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? > > 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. > > I would be happy to get some more hints :-). > This all sounds horribly familiar and related to: git log -n1 -p 2377012692e22532ed1c1e1e852d843861ce5367 https://bugs.freeradius.org/bugzilla/show_bug.cgi?id=15 http://rt.openssl.org/Ticket/Display.html?id=2036 I prodded Alan as I noticed that openssl would occasionally claim that the session was a resumed one when in fact it was not. FreeRADIUS interpreted this as a successful login regardless and so you could run into the situation where you would get an Access-Accept with no user credentials being sent or used at all! The solution was, as it seems to be an OpenSSL bug the maintainers refuse to acknowledge, to reject the 'resumption' if no cached data is returned at all[1] and force the client to go the whole hog and do a full authentication run. Cheers [1] as if there is data, it's obviously from somewhere Cheers -- Alexander Clouter .sigmonster says: Don't get to bragging. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: reauth-problem with WPA2-tls
Bjørn Mork schrieb: > Andreas Hartmann 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: [myu...@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} -> myu...@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 "myu...@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? 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. I would be happy to get some more hints :-). Kind regards, Andreas - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: reauth-problem with WPA2-tls
Andreas Hartmann 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: [myu...@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} -> myu...@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 "myu...@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 Bjørn - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: reauth-problem with WPA2-tls
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: [myu...@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: [myu...@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} -> myu...@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 "myu...@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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: reauth-problem with WPA2-tls
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. Fri Jun 4 09:42:11 2010 : Info: [eap] Freeing handler Fri Jun 4 09:42:11 2010 : Info: ++[eap] returns ok Fri Jun 4 09:42:11 2010 : Auth: Login OK: [myu...@mydom] (from client WAP610N port 0 cli 00-13-.) Fri Jun 4 09:42:11 2010 : Info: +- entering group post-auth {...} Fri Jun 4 09:42:11 2010 : Info: ++[exec] returns noop Sending Access-Accept of id 238 to 192.168 port 2048 Some time later, the fast_reauth follows, which breaks, because of missing datas in the cache. My question is: How must the client or the server be configured, that there are cached datas in order to get a working fast_reauth? rad_recv: Access-Request packet from host 192.168.1.9 port 2048, id=240, length=177 User-Name = "myu...@mydom" NAS-Port = 0 Called-Station-Id = "00-25-...:mywlan" Calling-Station-Id = "00-13-" Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 Connect-Info = "CONNECT 11Mbps 802.11b" EAP-Message = 0x0217016e6f7465626f6f6b31406d6179612e6f7267 Message-Authenticator = 0xc7d7831bf74eb29cc2862fbf9c1164f8 Fri Jun 4 10:05:37 2010 : Info: +- entering group authorize {...} Fri Jun 4 10:05:37 2010 : Info: ++[preprocess] returns ok Fri Jun 4 10:05:37 2010 : Info: [suffix] Looking up realm "mydom" for User-Name = "myu...@mydom" Fri Jun 4 10:05:37 2010 : Info: [suffix] No such realm "mydom" Fri Jun 4 10:05:37 2010 : Info: ++[suffix] returns noop Fri Jun 4 10:05:37 2010 : Info: [eap] EAP packet type response id 0 length 23 Fri Jun 4 10:05:37 2010 : Info: [eap] No EAP Start, assuming it's an on-going EAP conversation Fri Jun 4 10:05:37 2010 : Info: ++[eap] returns updated Fri Jun 4 10:05:37 2010 : Info: ++[unix] returns notfound Fri Jun 4 10:05:37 2010 : Info: [files] users: Matched entry myu...@mydom at line 203 Fri Jun 4 10:05:37 2010 : Info: ++[files] returns ok Fri Jun 4 10:05:37 2010 : Info: ++[expiration] returns noop Fri Jun 4 10:05:37 2010 : Info: ++[logintime] returns noop Fri Jun 4 10:05:37 2010 : Info: Found Auth-Type = EAP Fri Jun 4 10:05:37 2010 : Info: +- entering group authenticate {...} Fri Jun 4 10:05:37 2010 : Info: [eap] EAP Identity Fri Jun 4 10:05:37 2010 : Info: [eap] processing type tls Fri Jun 4 10:05:37 2010 : Info: [tls] Requiring client certificate Fri Jun 4 10:05:37 2010 : Info: [tls] Initiate Fri Jun 4 10:05:37 2010 : Info: [tls] Start returned 1 Fri Jun 4 10:05:37 2010 : Info: ++[eap] returns handled Sending Access-Challenge of id 240 to 192.168 port 2048 EAP-Message = 0x010100060d20 Message-Authenticator = 0x State = 0xbc40ebedbc41e6950bd358ee7ea3ba57 Fri Jun 4 10:05:37 2010 : Info: Finished request 9. Fri Jun 4 10:05:37 2010 : Debug: Going to the next request Fri Jun 4 10:05:37 2010 : Debug: Waking up in 4.9 seconds. rad_recv: Access-Request packet from host 192.168. port 2048, id=241, length=1516
Re: reauth-problem with WPA2-tls
Bjørn Mork writes: > while updating the outer.reply list gave: > > Thu Jun 3 17:00:07 2010 : Info: [ttls] Got tunneled Access-Accept > Thu Jun 3 17:00:07 2010 : Info: [ttls] Saving response in the cache But it still doesn't seem to work: Fri Jun 4 07:09:03 2010 : Info: [ttls] eaptls_process returned 3 Fri Jun 4 07:09:03 2010 : Info: [ttls] Skipping Phase2 due to session resumption Fri Jun 4 07:09:03 2010 : Info: [ttls] WARNING: No information in cached session! Fri Jun 4 07:09:03 2010 : Info: [eap] Freeing handler Fri Jun 4 07:09:03 2010 : Info: ++[eap] returns reject Fri Jun 4 07:09:03 2010 : Info: Failed to authenticate the user. Fri Jun 4 07:09:03 2010 : Auth: Login incorrect: [lu...@realm/] (from client ap1.example.com port 60 cli 0016deadbeef) Maybe I should tune the reauth time down a bit while debugging this. Or maybe just let it be... It doesn't really matter much to me. Bjørn - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: reauth-problem with WPA2-tls
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. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: reauth-problem with WPA2-tls
Alexander Clouter schrieb: > Bjørn Mork wrote: >> Andreas Hartmann 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 = 20 # 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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: reauth-problem with WPA2-tls
Bjørn Mork wrote: > >> The 'No information to cache' means you do not have anything useful >> (for example 'User-Name') in the reply packet. > > Makes sense. > >> 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}" >> } >> ... >> } >> >> >> That should fix your problem. > > Thanks. Looks like something for the default config/documentation with > that comment included. > To make things more interesting, depending on you situation[1] you might want to then strip the User-Name attribute from your reply traffic on the outer layer. We do this as in the 'eduroam' world when our lusers are roaming away from their home institution we want to protect the guilty and give them some degree of anonymity. This means the remote organisation the user is visiting only sees the username in the initial request packet...which for TTLS *should* be '@example.com' and *not* 'lu...@example.com'. Of course when our users are onsite we pass on the User-Name in the Access-Accept so that the accounting packets from the NAS have the inner username present making grepping/SELECTing your accounting logs that much easier. Cheers -- Alexander Clouter .sigmonster says: You are so boring that when I see you my feet go to sleep. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: reauth-problem with WPA2-tls
Bjørn Mork writes: > Alexander Clouter writes: > >> The 'No information to cache' means you do not have anything useful >> (for example 'User-Name') in the reply packet. > > Makes sense. > >> 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}" >> } >> ... >> } >> >> >> That should fix your problem. > > Thanks. Looks like something for the default config/documentation with > that comment included. Hmm, well I found that this needed to be update outer.reply { User-Name := "%{request:User-Name}" } like the example that's already there... Not that I pretend to understand any of this. But the first version left me with still having Thu Jun 3 16:53:30 2010 : Info: [ttls] Got tunneled Access-Accept Thu Jun 3 16:53:30 2010 : Info: [ttls] Saving response in the cache Thu Jun 3 16:53:30 2010 : Info: [ttls] WARNING: No information to cache: session caching will be disabled for this session. while updating the outer.reply list gave: Thu Jun 3 17:00:07 2010 : Info: [ttls] Got tunneled Access-Accept Thu Jun 3 17:00:07 2010 : Info: [ttls] Saving response in the cache Bjørn - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: reauth-problem with WPA2-tls
Alexander Clouter writes: > The 'No information to cache' means you do not have anything useful > (for example 'User-Name') in the reply packet. Makes sense. > 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}" > } > ... > } > > > That should fix your problem. Thanks. Looks like something for the default config/documentation with that comment included. Bjørn - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: reauth-problem with WPA2-tls
Bjørn Mork wrote: > Andreas Hartmann 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}" } ... } That should fix your problem. Cheers -- Alexander Clouter .sigmonster says: Money is the root of all evil, and man needs roots. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: reauth-problem with WPA2-tls
Andreas Hartmann 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. See also the thread that https://lists.freeradius.org/pipermail/freeradius-users/2010-January/msg00181.html is part of. Don't think there was any solution presented although there are claims that session caching is working. Bjørn - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: reauth-problem with WPA2-tls
Andreas Hartmann wrote: > >>> If fast_reauth in wpa_supplicant is disabled, the reauthentication >>> >> works fine, but the connection between the AP and the supplicant >>> ist interrupted for about 20 seconds - much to long :-). >>> >>> Do you have any idea how to solve this problem? >> >> Find out why the supplicant is taking 20s for authentication. > > How much time should be ok for the full reauthentication? > As far as I know, we *all* get sub-second re-auths, however our actual full authentications (seven LDAP queries included) also take a similar amount of time. Fast re-auth results in fewer packets needing to be passed back and forth. For a full authentication for us about 10 EAP packets need to be exchanged between the client and RADIUS server, re-auth means for us only about three or so need to be passed. > I traced the authentication and could see, that the part with the > radiusserver takes less than a second. Most of the time is needed until > the AP sends the new keys for the encryption of the session. > Ok, sometimes it's a little bit faster (9 seconds). > I could have this wrong, but it is the RADIUS server that sends the encryption keys, not the AP. It might be worth running tcpdump/wireshark on the client workstation and compare that to what you are seeing at the RADIUS server end. Cheers -- Alexander Clouter .sigmonster says: BOFH excuse #35: working as designed - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: reauth-problem with WPA2-tls
Andreas Hartmann schrieb: > David Mitchell schrieb: >> Alan DeKok wrote: >>> Andreas Hartmann wrote: In eap.conf, the option eap -> tls -> cache -> enable is switched off and fast_reauth in wpa_supplicant is enabled. >>> >>> Uh... that makes no sense. >>> >>> You've disabled caching (i.e fast re-auth) on the server, and enabled >>> it on the client. Why are you surprised that fast re-auth isn't working? >> >> I've seen similar problems between FreeRadius and wpa_supplicant both >> with and without the cache enabled. Getting wpa_supplicant to restart >> seems to clear it temporarily. > > Well, I took your realization to implement the following workaround: > > Caching is enabled in freeradius, fast_reauth is switched on in > wpa_supplicant. > > I set the reauth-timeout of the AP to 2 hours. On the supplicant, I > started a cronjob, which HUP's the supplicant each 59 minutes. That's > the way how the supplicant is prevented to do a fast reauth (which > doesn't really work). A full reauth isn't necessary too, because of the > sig hup all 59 minutes, which is done like this: > > rad_recv: Accounting-Request packet from host 192.168.1.9 port 2049, > id=112, length=177 > Acct-Session-Id = "001B-0007" > Acct-Status-Type = Stop > Acct-Authentic = RADIUS > User-Name = "myu...@mydom" > NAS-Port = 0 > Called-Station-Id = "00-25-...:mylan" > Calling-Station-Id = "00-13-..." > NAS-Port-Type = Wireless-802.11 > Connect-Info = "CONNECT 11Mbps 802.11b" > Acct-Session-Time = 358 > Event-Timestamp = "Jan 1 1970 02:26:18 CET" Hmmm, where does this funny Event-Timestamp comes from? All my times of client and server are ok. Otherwise, I can't find any way to set the time at the AP (linksys WAP610N)? Is there any way? clueless ... Kind regards, Andreas - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: reauth-problem with WPA2-tls
David Mitchell schrieb: > Alan DeKok wrote: >> Andreas Hartmann wrote: >>> In eap.conf, the option eap -> tls -> cache -> enable is switched off >>> and fast_reauth in wpa_supplicant is enabled. >> >> Uh... that makes no sense. >> >> You've disabled caching (i.e fast re-auth) on the server, and enabled >> it on the client. Why are you surprised that fast re-auth isn't working? > > I've seen similar problems between FreeRadius and wpa_supplicant both > with and without the cache enabled. Getting wpa_supplicant to restart > seems to clear it temporarily. Well, I took your realization to implement the following workaround: Caching is enabled in freeradius, fast_reauth is switched on in wpa_supplicant. I set the reauth-timeout of the AP to 2 hours. On the supplicant, I started a cronjob, which HUP's the supplicant each 59 minutes. That's the way how the supplicant is prevented to do a fast reauth (which doesn't really work). A full reauth isn't necessary too, because of the sig hup all 59 minutes, which is done like this: rad_recv: Accounting-Request packet from host 192.168.1.9 port 2049, id=112, length=177 Acct-Session-Id = "001B-0007" Acct-Status-Type = Stop Acct-Authentic = RADIUS User-Name = "myu...@mydom" NAS-Port = 0 Called-Station-Id = "00-25-...:mylan" Calling-Station-Id = "00-13-..." NAS-Port-Type = Wireless-802.11 Connect-Info = "CONNECT 11Mbps 802.11b" Acct-Session-Time = 358 Event-Timestamp = "Jan 1 1970 02:26:18 CET" Acct-Terminate-Cause = User-Request Thu Jun 3 05:41:43 2010 : Info: +- entering group preacct {...} Thu Jun 3 05:41:43 2010 : Info: ++[preprocess] returns ok Thu Jun 3 05:41:43 2010 : Info: [acct_unique] Hashing 'NAS-Port = 0,Client-IP-Address = 192.168.1.9,NAS-IP-Address = 192.168.1.9,Acct-Session-Id = "001B-0007",User-Name = "myu...@mydom"' Thu Jun 3 05:41:43 2010 : Info: [acct_unique] Acct-Unique-Session-ID = "aba6339d45d8fab1". Thu Jun 3 05:41:43 2010 : Info: ++[acct_unique] returns ok Thu Jun 3 05:41:43 2010 : Info: [suffix] Looking up realm "mydom" for User-Name = "myu...@mydom" Thu Jun 3 05:41:43 2010 : Info: [suffix] No such realm "mydom" Thu Jun 3 05:41:43 2010 : Info: ++[suffix] returns noop Thu Jun 3 05:41:43 2010 : Info: ++[files] returns noop Thu Jun 3 05:41:43 2010 : Info: +- entering group accounting {...} Thu Jun 3 05:41:43 2010 : Info: [detail] expand: /var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d -> /var/log/radius/radacct/192.168.1.9/detail-20100603 Thu Jun 3 05:41:43 2010 : Info: [detail] /var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d expands to /var/log/radius/radacct/192.168.1.9/detail-20100603 Thu Jun 3 05:41:43 2010 : Info: [detail] expand: %t -> Thu Jun 3 05:41:43 2010 Thu Jun 3 05:41:43 2010 : Info: ++[detail] returns ok Thu Jun 3 05:41:43 2010 : Info: ++[unix] returns ok Thu Jun 3 05:41:43 2010 : Info: [radutmp] expand: /var/log/radius/radutmp -> /var/log/radius/radutmp Thu Jun 3 05:41:43 2010 : Info: [radutmp] expand: %{User-Name} -> myu...@mydom Thu Jun 3 05:41:43 2010 : Info: ++[radutmp] returns ok Thu Jun 3 05:41:43 2010 : Info: [attr_filter.accounting_response] expand: %{User-Name} -> myu...@mydom Thu Jun 3 05:41:43 2010 : Debug: attr_filter: Matched entry DEFAULT at line 12 Thu Jun 3 05:41:43 2010 : Info: ++[attr_filter.accounting_response] returns updated Sending Accounting-Response of id 112 to 192.168.1.9 port 2049 Thu Jun 3 05:41:43 2010 : Info: Finished request 111. Thu Jun 3 05:41:43 2010 : Info: Cleaning up request 111 ID 112 with timestamp +5054 Thu Jun 3 05:41:43 2010 : Debug: Going to the next request Thu Jun 3 05:41:43 2010 : Info: Ready to process requests. rad_recv: Accounting-Request packet from host 192.168.1.9 port 2049, id=113, length=159 Acct-Session-Id = "001B-0008" Acct-Status-Type = Start Acct-Authentic = RADIUS User-Name = "myu...@mydom" NAS-Port = 0 Called-Station-Id = "00-25-...:mylan" Calling-Station-Id = "00-13-..." NAS-Port-Type = Wireless-802.11 Connect-Info = "CONNECT 11Mbps 802.11b" Thu Jun 3 05:41:44 2010 : Info: +- entering group preacct {...} Thu Jun 3 05:41:44 2010 : Info: ++[preprocess] returns ok Thu Jun 3 05:41:44 2010 : Info: [acct_unique] Hashing 'NAS-Port = 0,Client-IP-Address = 192.168.1.9,NAS-IP-Address = 192.168.1.9,Acct-Session-Id = "001B-0008",User-Name = "myu...@mydom"' Thu Jun 3 05:41:44 2010 : Info: [acct_unique] Acct-Unique-Session-ID = "efac47a366ac188f". Thu Jun 3 05:41:44 2010 : Info: ++[acct_unique] returns ok Thu Jun 3 05:41:44 2010 : Info: [suffix] Looking up realm "mydom" for User-Name = "myu...@mydom" Thu Jun 3 05:41:44 2010 : Info: [suffix] No such realm "mydom" Thu Jun 3 05:41:44 2010 : Info: ++[suffix] returns noop Thu Jun 3 05:41:44 2010 : Info: ++[files] returns noop Thu Jun 3 05:41:44 2010 : Info: +
Re: reauth-problem with WPA2-tls
Alan DeKok schrieb: > Andreas Hartmann wrote: >> In eap.conf, the option eap -> tls -> cache -> enable is switched off >> and fast_reauth in wpa_supplicant is enabled. > > Uh... that makes no sense. 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! Wed Jun 2 20:39:18 2010 : Info: [eap] Freeing handler Wed Jun 2 20:39:18 2010 : Info: ++[eap] returns reject Wed Jun 2 20:39:18 2010 : Info: Failed to authenticate the user. Wed Jun 2 20:39:18 2010 : Auth: Login incorrect: [myu...@mydom] (from client WAP610N port 0 cli 00-13-...) Wed Jun 2 20:39:18 2010 : Info: Using Post-Auth-Type Reject Wed Jun 2 20:39:18 2010 : Info: +- entering group REJECT {...} Wed Jun 2 20:39:18 2010 : Info: [attr_filter.access_reject]expand: %{User-Name} -> myu...@mydom Wed Jun 2 20:39:18 2010 : Debug: attr_filter: Matched entry DEFAULT at line 11 Wed Jun 2 20:39:18 2010 : Info: ++[attr_filter.access_reject] returns updated Wed Jun 2 20:39:18 2010 : Info: Delaying reject of request 13 for 1 seconds Wed Jun 2 20:39:18 2010 : Debug: Going to the next request Wed Jun 2 20:39:18 2010 : Debug: Waking up in 0.9 seconds. Wed Jun 2 20:39:19 2010 : Info: Sending delayed reject for request 13 Sending Access-Reject of id 55 to 192.168.1.9 port 2048 EAP-Message = 0x040c0004 Message-Authenticator = 0x It's strangely, that the supplicant couldn't be authorized but the AP doesn't lock the connection anyway :-). I would have resoected, that the connection would have been locked afterwards. Instead of, the supplicant reauths from now on every minute, using this broken fast reauth. If I do a full reauthentication, the authentication succeeds, but I'm getting locked anywhere - that makes no sense to me. >> If fast_reauth in wpa_supplicant is disabled, the reauthentication >> works fine, but the connection between the AP and the supplicant ist >> interrupted for about 20 seconds - much to long :-). >> >> >> Do you have any idea how to solve this problem? > > Find out why the supplicant is taking 20s for authentication. How much time should be ok for the full reauthentication? I traced the authentication and could see, that the part with the radiusserver takes less than a second. Most of the time is needed until the AP sends the new keys for the encryption of the session. Ok, sometimes it's a little bit faster (9 seconds). Thanks for your help, Andreas - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: reauth-problem with WPA2-tls
Alan DeKok wrote: > Andreas Hartmann wrote: >> In eap.conf, the option eap -> tls -> cache -> enable is switched off >> and fast_reauth in wpa_supplicant is enabled. > > Uh... that makes no sense. > > You've disabled caching (i.e fast re-auth) on the server, and enabled > it on the client. Why are you surprised that fast re-auth isn't working? I've seen similar problems between FreeRadius and wpa_supplicant both with and without the cache enabled. Getting wpa_supplicant to restart seems to clear it temporarily. My reading of Andreas's message was that he has tried it both ways. I haven't yet dug into it enough to try and pin down where the problem is. It does seem that problems with the cache should just result in a slow authentication taking place, not a total failure of authentication. -David Mitchell > >> If the reconnect takes place, the missing cache-data seems to be the >> problem -> the user cannot be authenticated: > > That's what you told the server to do. > >> If fast_reauth in wpa_supplicant is disabled, the reauthentication works >> fine, but the connection between the AP and the supplicant ist >> interrupted for about 20 seconds - much to long :-). >> >> >> Do you have any idea how to solve this problem? > > Find out why the supplicant is taking 20s for authentication. > > Alan DeKok. > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- - | David Mitchell (mitch...@ucar.edu) Network Engineer IV | | Tel: (303) 497-1845 National Center for | | FAX: (303) 497-1818 Atmospheric Research | - - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: reauth-problem with WPA2-tls
Andreas Hartmann wrote: > In eap.conf, the option eap -> tls -> cache -> enable is switched off > and fast_reauth in wpa_supplicant is enabled. Uh... that makes no sense. You've disabled caching (i.e fast re-auth) on the server, and enabled it on the client. Why are you surprised that fast re-auth isn't working? > If the reconnect takes place, the missing cache-data seems to be the > problem -> the user cannot be authenticated: That's what you told the server to do. > If fast_reauth in wpa_supplicant is disabled, the reauthentication works > fine, but the connection between the AP and the supplicant ist > interrupted for about 20 seconds - much to long :-). > > > Do you have any idea how to solve this problem? Find out why the supplicant is taking 20s for authentication. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html