On Feb 19, 2021, at 1:42 PM, Doug Wussler via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
I have an anamoly in TLS Session Resumption using a Windows 10 laptop. I have not been able to reproduce this using other clients. While this appears to be bad behavior by Windows, I'm also asking if this unexpected supplicant behavior might reveal some undesirable behavior on the part of freeradius.
Maybe, maybe not. If it's an issue in Windows, I was just talking today with the team in charge of the Microsoft supplicant, so this is timely.
I deleted all TLS session cache records and restarted the server. In packet (2) you see the supplicant request a cached session, which is not found, so a full authentication takes place in packets (1) through (10).
OK.
I then "forget" the network on the client, which I would expect would also delete any record of a previous TLS session,
Maybe. That all depends on how the internals work. The TLS cache *may* depend on the network configuration, or it may be independent.
and then I reauthenticate to the network, which requires entering a username/password (but, sadly, does not require me to trust the server's certificate).
I suspect that means that the TLS system is caching the certificate & session, even if the network configuration has changed.
At this point I would expect to see a full re-auth but in packet (13) you see the supplicant request a cached session, which is found and restored. In packet (14) the server declares a successful session resumption on its end and sends an Access-Challenge. But in packet (15) we then see:
eap_peap: Client rejected our response. The password is probably incorrect eap_peap: Client rejected session resumption. Re-starting full authentication
Yeah, it's not clear why that happens. You can get logs out of Windows, but they're not always as clear as the FreeRADIUS ones!
We then proceed through the inner-tunnel and do the full re-auth but we are still using the resumed session ID along with the attributes cached from that session. In the final packet (19), we see "&request:EAP-Session-Resumed := 1"
Hmm... that seems like an issue on the FreeRADIUS side. It should definitely *not* set the session to be resumed, and it should likely delete the old cached session.
This all came to my attention because I was originally using Cached-Session-Policy with the += operator. I ended up with duplicate session-state entries for Cached-Session-Policy, and, when that policy happened to change between authentications, one of those Cached-Session-Policy values was wrong.
I'm not clear how it gets *two* Cached-Session-Policy attributes. The debug output doesn't show that it caches that attribute.
We can't do anything about the bad Windows behavior, but do you consider it appropriate for freeradius to handle a rejected session resumption this way?
Nope. I've pushed changes which should help, I think. The PEAP module will now go "this session isn't resumed", and the main TLS cache code will treat the session as starting from scratch. Alan DeKok.