Hi, > What exactly was the issue with doing PAP over Eduroam ? Was it people > being afraid of passing weakly encrypted passphrases around the > interweb, or home sites just not bothering to implement PAP on their > Radius servers ?
No, the issue is a different one: you will have to enter your credentials on the visited site, and it will either a) be able to see them (using outright PAP) b) send you a beautiful/ugly PHP/JS piece of code to encrypt stuff - but then the user would need to trust that piece of code from an inst he doesn't know Both of these give the visited inst a chance to get hold of your credentials. With EAP and TLS tunnels, this is conceptually not possible and is thus stronger. eduroam security standards don't allow that your password is visible anywhere but at home (if at all). Note that the interweb thingy is not that critical, it can be overcome: visited inst RADIUS server gets PAP credentials, initiates its own EAP-TTLS-PAP session to home, puts user's credentials in it. Authenticates user and relays the outcome as PAP reply. This solves the en-route problem, but cannot overcome the problem that still the visited inst *has* your password. Note also that your problems _can_ be solved quite cleanly, but without RADIUS. Put your captive portal behind a AAI infrastructure such as Shibboleth. Workflow is: - user gets captive portal page - is asked "Where are you from" -> enters realm or selects text box - Firewall for his IP address is opened _only_ for his home AAI place - gets redirected to his own AAI place (can verify TLS cert, connection is encrypted) - authenticates at home, gets cookie / session ID so that captive portal gets informed that he's properly authenticated - firewall opens for all traffic That way, the user only reveals his credentials to home, not the visited inst. There is a nice paper and prototype impl of this for Shibboleth, I can look up the source if you're interested. Why don't we do that then? The wireless link is still unencrypted with this ansatz. Again a violation of our security mimimums. And this problem is a lot harder to solve than authentication above. We would probably need to go to the IEEE asking for a "WPA2-Noauth-JustEncrypt" profile, where the AP just hands out a EAPoL-Key to the client, performing no prior authentication. This would just encrypt the link, and authentication could take palce with the above thing. *Then*, web-redirect is again a viable alternative. But going to the IEEE is not exactly a walk in the park. Greetings, Stefan -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: [EMAIL PROTECTED] Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
signature.asc
Description: This is a digitally signed message part.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
