"Fast reconnect"

[Bob Franklin]

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 <rcf34 at cam.ac.uk>              +44 1223 748479
  Network Division, University of Cambridge Computing Service