setup question : mschap + perl authentication

[Arran Cudbard-Bell]

>  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.
>   
Ah yes, I can see that being a problem, damn this means we can't offer 
any JRS authenticated services other than wireless and wired network access.
We were planning on a few kiosks dotted around campus... though in 
theory if those Kiosks supported EAP Based login, the tunnel would be 
between the Kiosk and the users Home RADIUS server... Would this be 
acceptable, Or would the fact that we could still theoretically capture 
the users credentials from the login screen be an issue ?
> Note also that your problems _can_ be solved quite cleanly,
Shibboleth is in no way clean ! It's an evil necessary... actually the 
Idea is good ,Just the WAYF page is just so horribly cludgy.
I think the idea of a pre-login form on the authenticated service would 
be a good idea.
You enter your username string user at domain, this sets a identification 
cookie containing that string and redirects you to your home gateway 
(using a central list of domain->gateway mappings) . You then provide 
your password at your home gateway, which then directs you back to the 
page where you were originally sent from.
No nasty WAYF pages.

Unfortunately this would mean you could be identified, and I know thats 
a big feature of Shibboleth... that Service providers don't know who's 
using their service, just that they've been authorised to do so.

*sigh* there must be a solution , just no ones figured it out yet .
>  but without 
> RADIUS. Put your captive portal behind a AAI infrastructure such as 
> Shibboleth. Workflow is...
>   
Were implementing shibboleth already, due to go live summer 2008...
> 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.
>   
I've read more shibboleth technical documentation than I would care to 
already, but thanks for the offer .
> 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.
>
>   
No, quite. So this would be a kind of walled garden approach using 
shibboleth for authentication ?
> Greetings,
>
> Stefan
>
>   
Regards,
Arran

-- 
Arran Cudbard-Bell (A.Cudbard-Bell at sussex.ac.uk)
Authentication, Authorisation and Accounting Officer
Infrastructure Services | ENG1 E1-1-08 
University Of Sussex, Brighton
EXT:01273 873900 | INT: 3900