Hello,
I'm a bit hazy on "fast reconnect" -- from what I've ready in the list
archives and found on various other sites, it uses cached information
about the state of the TLS dialogue with the server terminating the EAP
connection to reduce the number of messages which must be exchanged as a
supplicant authenticates when moving (say) wireless access point.
Looking at the FreeRADIUS changes, history it seems support for this was
added in 2.1.1 for EAP-TLS (which I assume affects EAP-PEAP and EAP-TTLS,
both of which we're using).
Would I be right in thinking that, if the cached state is NOT found on the
backend RADIUS server (there may be one or more proxies in the way,
especially if the user is logging in over eduroam, but I assume that that
doesn't matter, as they just proxy things through) that the device
authenticating will just start the TLS negotiation from scratch and the
user won't notice anything, except maybe a slightly longer time to roam
between wireless access points (but, in practice, probably so quick, they
won't)?
This would also presumably be the case if the next authentication happened
to take place against a different backend server at our eduroam 'home'
site as there is no way to synchronise these caches.
In other words, the only reason to untick the 'Fast reconnect' box on (for
example) a Windows machine would be if there was a suspicion that this was
either broken, or you wanted to force the full TLS negotiation to restart,
as the user moved access points.
[Does anyone know of a broken wireless NAS which complains if the full TLS
conversation doesn't start from scratch, as you move around.]
I'm just trying to see if there's a reason why anyone should NOT tick this
box on a supplicant device. We're running FreeRADIUS >2.1.1.
Thanks in advance,
- Bob
--
Bob Franklin <[email protected]> +44 1223 748479
Network Division, University of Cambridge Computing Service
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
