reauth-problem with WPA2-tls

[Alan DeKok]

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.