[RADIATOR] PEAP internal session resumption breaks some clients

[Heikki Vatiainen]

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 <hvn at 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.