setup question : mschap + perl authentication

[Stefan Winter]

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: stefan.winter at restena.lu     Tel.:     +352 424409-1
http://www.restena.lu                Fax:      +352 422473
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20070710/15166793/attachment.pgp>