[RADIATOR] PEAP session resumption on Windows 7, 8.1?

Heikki Vatiainen hvn at open.com.au
Thu May 25 13:13:37 UTC 2017


On 25.05.2017 12:20, Jan Tomasek wrote:

> I'm quoting from release notes Radiator 4.18:

> could you please provide more details?

Sure, in short: MS PEAP document [1] says that a full inner 
authentication is possible after TLS session resumption. Radiator does 
not support this yet. The fix we are planning is to support this.

The other clients we have seen are happy to end PEAP authentication 
successfully after TLS session resumption.

In more detail, if I remember correctly, after a TLS session is resumed, 
the server tunnels a success to the client and client responds with 
success or failure. The current MS PEAP document indicates that failure 
means that the client wants to do a full inner authentication. The 
current implementation in Radiator considers this as a failure 
indication and terminates PEAP with a reject.

Instead of rejecting the client, the server should start inner 
authentication similar to what happens when a TLS session is established 
with a full handshake.

Note: we have not tested this yet, but based on the MS PEAP document 
this seems like the likely cause why Radiator and client sometimes have 
problems with resumed sessions.

[1] https://msdn.microsoft.com/en-us/library/cc238354.aspx

> I've identified several clients 
> running Win7 and one running 8.1 which are occasionally refused because 
> PEAP session resumption. It looks like it is related to situation when 
> clients are changing essid. We are running eduroam and eduroam-cesnet, I 
> was able to identify moments when client tries to jump from one essid to 
> another and in that moment resumption fails.

It might be that the client considers SSID change an event that, while 
using TLS session resumption to get PEAP tunnel up, requires a full 
inner authentication.

You could try this as a workaround for rejects: If your controller adds 
SSID in the requests as an attribute, you could try setting 
EAPTLS_SessionContextId so that it includes the SSID. After the SSID 
change the server should require a full authentication which takes 
longer but should not cause a reject.

https://open.com.au/radiator/ref/EAPTLS_SessionContextId_AuthByxxxxxx.html#EAPTLS_SessionContextId_AuthByxxxxxx

If you try the above, please let me and the list know how it worked.

> I like resumption as it makes reconnect and keeping it enabled as the 
> amount of affected clients is low, but if there is something I can test 
> I would like to volunteer. If you need some testing, please tell me how 
> can I help.

You could help testing when Radiator knows to start inner authentication 
after TLS session resumption. The change required affects PEAP behaviour 
considerably and we did not want to rush it in the current release. Once 
we have something to test, we will let you know.

For example, it will be interesting to see what happens when the 
tunnelled failure from a client really indicates a failure and not a 
request to start inner authentication. Also, how non-MS clients cope if 
this happens. I'm not sure this is an issue since they probably do not 
even complete resumption if there's a problem.

> Could you please provide time plan when this issue will be resolved?

I don't have that yet. However, the issue does affect a number of people 
which raises its priority.

Thanks for your interest in this,
Heikki

-- 
Heikki Vatiainen
hvn at open.com.au


More information about the radiator mailing list