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 [email protected] _______________________________________________ radiator mailing list [email protected] http://lists.open.com.au/mailman/listinfo/radiator
