reauth-problem with WPA2-tls

Andreas Hartmann andihartmann at 01019freenet.de
Sun Jun 6 21:48:34 CEST 2010


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



More information about the Freeradius-Users mailing list