Re: [RADIATOR] PEAP internal session resumption breaks some clients
On 08/28/2015 06:35 PM, Ullfig, Roberto Alfredo wrote: > I don't know if this is the same issue we had. It was trivial to get > an 802.1x error on my non-AD laptop (for some reason I could not get > it to fail with my account on an AD connected laptop). Yes, this is the case I was referring to earlier. Did you have time to see if there were any AD policies that may have affected PEAP fast reconnect? In any case, I'll do some testing with the settings too. Thanks, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] PEAP internal session resumption breaks some clients
I don't know if this is the same issue we had. It was trivial to get an 802.1x error on my non-AD laptop (for some reason I could not get it to fail with my account on an AD connected laptop). All I had to do was connect and reconnect quickly a few times in a row. We added "EAPTLS_SessionResumption 0" to our 802.1x handler and the problem went away. --- Roberto Ullfig - [email protected] ACCC Research Programmer -Original Message- From: [email protected] [mailto:[email protected]] On Behalf Of Heikki Vatiainen Sent: Friday, August 28, 2015 6:06 AM To: [email protected] Subject: Re: [RADIATOR] PEAP internal session resumption breaks some clients On 28.8.2015 12.22, Alan Buxey wrote: > I would suspect either wireless controller problems (eg related to > 802.11k or such) or client misconfiguration (do you have a deployment > tool for the 802.1X or do users just click on SSID and enter their > status? ) I plan to dig more into the fast reconnection control behaviour, provided by the checkbox in the GUI, to see what it really does. For example, does it affect the TLS handshake. Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator ___ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] PEAP internal session resumption breaks some clients
On 28.8.2015 12.22, Alan Buxey wrote: > I would suspect either wireless controller problems (eg related to > 802.11k or such) or client misconfiguration (do you have a deployment > tool for the 802.1X or do users just click on SSID and enter their > status? ) I plan to dig more into the fast reconnection control behaviour, provided by the checkbox in the GUI, to see what it really does. For example, does it affect the TLS handshake. Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] PEAP internal session resumption breaks some clients
On 28.8.2015 5.44, David Zych wrote: > 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. PEAP never left internet-draft stage when it was worked on by people involved in IETF activities. Since then Microsoft has maintained their own PEAP documentation. See here: https://msdn.microsoft.com/en-us/library/cc238354.aspx If you see pages 58-59 in the 20150630 document, it shows an example of fast reconnect. This is also where it confirms that no phase2 authentication is done. The old internet-drafts also say that phase2 can be skipped entirely. Also note that MS spec specifies that a success TLV is tunnelled over the resumed TLS tunnel. This seems not to be in the PEAP ineternet-drafts that some implementations are likely to be based on, although the different implementations do seem to support this. In other words, there are a number of possible specifications and for this reason Radiator might be doing something that the recent MS clients do not always expect. One thing you could check is to see if the 'Fast reconnect' option is enabled or disabled on the Windows hosts that have or do not have problems. An interesting thing would be to know what this affects: TLS tunnel setup or the client reaction on the requests tunnelled over the resumed TLS session. I will also take a look at replicating this problem on our Windows clients and go through the MS spec to see what could be the cause. One possibility might be that the windows 'Fast reconnect' setting does not change TLS behaviour, and if the client declines resumption without phase 2 authentication, the server side must trigger it with EAP Identity request. But as I said, I'll take a look at this. If you find out something too, please let us know. >> 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). 'PEAP Authentication Failure' is only logged when client responds with failure instead of success (the EPA Extensions Result TLV on page 59 diagram). Thanks, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] PEAP internal session resumption breaks some clients
Should be no problem with session resumption being on by default. Certainly its a performance impact of you don't have it on. I would suspect either wireless controller problems (eg related to 802.11k or such) or client misconfiguration (do you have a deployment tool for the 802.1X or do users just click on SSID and enter their status? ) alan___ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] PEAP internal session resumption breaks some clients
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 ___ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] PEAP internal session resumption breaks some clients
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? 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. > There are plenty of other clients in our environment that do _not_ > have this problem (i.e. are able to succesfully resume a PEAP session > and get Access-Accept); nonetheless, because it's having a negative > impact on some clients I've had to disable EAPTLS_SessionResumption. 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. > I'm interested to know if anybody else has observed this, or has > suggestions on how to get more information about what exactly is > going wrong (it's clear PEAP doesn't like the supplicant's last > RADIUS request / EAP Response, but it's not clear exactly why). There was a report last month about similar thing where the fix was the same as you did did: disable EAPTLS_SessionResumption. Now that we have two cases, it's starting to look like a non-isolated problem. What comes to allowing inner authentication after session resumption, I think the idea with resumption is that the inner authentication can be skipped completely. The log messages indicate it's the client that does not want to continue but returns TLS tunnelled failure indication back to Radiator. For this reason it would be a good idea to compare the working and non-working settings. 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. Also, thanks for the idea of debugging EAP contexts. A hook with a some code that previously collects information about the request sounds like a good idea. I've made a ticket about this for us to look at too. Thanks, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
