Sam Critchley wrote:
Interesting post (and thread) on TTLS. Sounds like what Surfnet is doing (along with Twente, Hogeschool Amsterdam and a couple of others in the NL academic community, right?) is pretty interesting. I hope TTLS makes it to Freeradius soon....
I hope so.
Hey, I wondered if you had time to answer a couple of TTLS behaviour questions I have. I/we have been working on some stuff with EAP-TLS and Freeradius, but have not yet tried TTLS at all (partly because we can't find a free RADIUS server to test it on), but I'm interested about the behaviour for the user.
Indeed. No free Radius servers support it yet as far as I know. (Radiator is used mostly at Surfnet at this moment).
So, here we go - no problem if you don't have any time to answer:
1. Let's say I'm using an XP laptop with an EAP-TTLS supplicant installed. I log into to an EAP-TTLS-capable 802.11b AP (for example), which performs the
Well, the AP (as for any authenticator) must only have EAP support: only the authentication server and the supplicant need TTLS support :-) (And even proxy-ing authentication-servers don't need TTLS support; just EAP)
usual access requests against an EAP-TTLS-capable RADIUS server. I get a pop-up on my screen asking for my username/password, temp certificates are then installed, and I am authenticated and allowed access. Great, no problem.
- What then happens every time 802.1x reauthentication takes place (when the 802.1x state machine reaches the end of the reauth period)? - Do I get another username/password prompt? Or does reauthentication take place against the temporary certificate until I turn the XP machine off? - Can I set a RADIUS server so that it prompts the user for his/her username and password after a period of, say, 6 hours, even if the 802.1x reauth period is set to 10 minutes?
No, the username/password is entered (at least with the client used at SURFnet) after installing the client (a DLL), in a simular window to the TLS configuration window and stored for future use (as with the certificate used with TLS). When the first connection is made and the server certificate can't be verified (this can occur when there is a new certificate installed as well, and it is not known by the client) there is an popup with the details about this certificate. After trusting it (if you want to: permanently) you won't see this popup again as long as the same server certificate is used.
So re-authenticating works seemless: within sessions as well between AP's.
2. Second, I move from the existing AP I am connected to, cycle across town, and connect to another AP. - Do I get another popup username/password box, or am I automatically authenticated on this other AP as well?
If the other AP uses the (same) RADIUS infrastructure, where it can use your realm in the same way, authentication goes seemless as described above: when once filled in all correct options roaming works fine. After a while you won't even know you where using TTLS.
3. Do you know of any good webpages explaining in a step-by-step fashion how EAP-TTLS works, and what the user experiences?
Hmm, the TTLS draft is maybe the best way to start ;-)
http://www.ietf.org/internet-drafts/draft-ietf-pppext-eap-ttls-02.txt
What the user experiences depends on the supplicant-implementation mostly. I personally haven't looked close enough to other supplicants, I'm about to do that in a few weeks.
I guess having password-based authentication makes things a lot simpler for users than worrying about where to install certificates etc.
Sure thing! Imagine rolling out certificates for hundereds of students, dealing with (expiring) CA's and certificates, revoking certificates that has been "stolen" or when access is disallowed (leaving employees or students)...
TTLS is not that strong as TLS is (you don't need to /have/ anything, just to /know/), but it's secure, and RADIUS can authenticate to any method/backend it knows about (when PAP is used).
Regards, Paul
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
