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 <h...@open.com.au> 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 radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
