"Fast reconnect"

[Alexander Clouter]

Bob Franklin <rcf34 at 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.