[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freeradius-users
Subject:    Re: Anamoly in TLS Session Resumption
From:       Alan DeKok <aland () deployingradius ! com>
Date:       2021-02-19 21:51:44
Message-ID: 57C75DEA-6596-4218-87D1-56C61D95BF9A () deployingradius ! com
[Download RAW message or body]

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.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


[prev in list] [next in list] [prev in thread] [next in thread]