Bob Franklin <rcf34@cam.ac.uk> wrote:
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).
That pretty much sums it up, it also works across administrative domains here too. The 'Bloomsbury Experience' means you can have people doing a full authentication to our system then from the same physical location 'roam' to Birkbeck/IoE/UCL and fast re-auth there....although you have a 1/n of hitting the 'wrong' cache.
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)?
It actually *continues* to go the full hog. SSL (like IPsec) has several phases. You complete phase 1 and then move into phase 2. If you complete the latter your session is cached and so afterwards all you need to do is complete phase 1 and go straight to 'Go'...collecting your £200 :) That's my understanding anyway. It is proxy transparent, as no proxy inbetween the client and the destination RADIUS server can fiddle with the EAP packets.
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.
OpenSSL seems to have the hooks IIRC but FreeRADIUS does not give it the framework to call upon. Fortunately this is not too much of a problem as long as any RADIUS load-balancing done is coupled to Calling-Station-Id; for us, JRS promise to use bog standard fail-over.
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.
Indeed.
[Does anyone know of a broken wireless NAS which complains if the full TLS conversation doesn't start from scratch, as you move around.]
Not that I have seen...
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.
Since the option was made available we have been using it at SOAS and not noticed any problems. My logs show most authentications are now 'EAP' (aka 'session resumed') rather than 'PAP' or 'MSCHAPv2' and of course the lighter load on the LDAP servers (4 runs through 'authorize' rather than 7[1]) is nothing to poo-poo either. I cannot see any reason for it no to be on. If your RADIUS servers do not support it then there is no penalty, if they do support it, then you win. Cheers [1] that was before JANET/Terena added an extra link in our cert chains -- Alexander Clouter .sigmonster says: If you waste your time cooking, you'll miss the next meal.