[RADIATOR] PEAP internal session resumption breaks some clients

[David Zych]

On 08/27/2015 02:40 AM, Heikki Vatiainen wrote:
> On 27.8.2015 9.32, David Zych wrote:
>> We have a Windows 7 client that in certain locations around campus
>> periodically gets booted off wireless and prompts the user to
>> re-enter his credentials.
>
> Thanks for the information. A couple of questions and comments related
> to this: first, is this just Windows 7 or is it possible/hard to say
> that there might be problems with other clients too?

Hard to say.

We do now have multiple confirmed instances of Win7 systems which were 
having problems before and are perfectly happy now that 
EAPTLS_SessionResumption is disabled.

We spoke to someone who sees a lot of trouble tickets, and he opined 
that Win8 and Win10 may also be affected, but there's a lot of 
uncertainty here because we're battling multiple issues this week and 
it's not always clear from any given trouble ticket which specific issue 
is in play.

Overall, having watched it run for a day, it's clear that disabling 
EAPTLS_SessionResumption has definitely solved problems for a number of 
clients.  I ran a Splunk query to count the number of times we logged an 
Auth OK followed within 5 minutes by a Auth FAIL due to PEAP 
Authentication Failure for the same MAC and same username (which isn't 
guaranteed to be the PEAP resumption problem, but I feel good about 
calling it a decent approximation).  During the previous two days that 
count had peaked at 200 to 300 occurrences per hour; today it peaked at 
a mere 10.  Also, during the past two days, 749 unique MACs appeared at 
least 2 times in that search, and 267 unique MACs appeared at least 5 times.

> It might be a good idea to check the settings on the host that has
> problems and compare them to a host that works. The problem might be
> something that is caused by the settings.

Unfortunately, while I know that some clients were PEAP-resuming 
successfully, I don't know if any of those clients were running Windows 
7, and in any case it would not be easy to gain access to examine them.

> Disabling EAPTLS_SessionResumption is safe to do. In fact, it might be a
> good default option too when one starts to build the authentication
> configuration. Having it off can increase authentication server and
> backend load, but I see no other problem with turning it off.

Thanks for this confirmation, and I agree that it would probably be 
safer for EAPTLS_SessionResumption to default to false.

> What comes to allowing inner authentication after session resumption, I
> think the idea with resumption is that the inner authentication can be
> skipped completely.

Total speculation here: I get the feeling that Microsoft might take a 
different view of this, which might even make sense if we consider that 
MS-CHAP-V2 was intended to provide *mutual* authentication (i.e. just 
because we're willing to give the client a free pass doesn't mean that 
it wants to trust us in return).  If so, perhaps our behavior during 
PEAP resumption would need to vary depending on what EAPType was 
actually used for inner auth.  But I might be totally off base here.

> The log messages indicate it's the client that does not want to continue
> but returns TLS tunnelled failure indication back to Radiator.

Help me out: which specific part of the trace tells you this?  (I stared 
at it for a while trying to determine what was being sent inside the 
tunnel, and didn't figure it out).

> I'll see what we can do to replicate this too, but if you already have
> suitable test hosts, please let us know if you have time to look at them
> in more detail.

At the moment I only have access to one known affected host, but if I 
can figure out how to convince that host to attempt a fast reconnect in 
my dev environment then I'm willing to spend a bit of time experimenting 
with it.

Thanks,
David