Hi Jon (and John)

I agree that there is a concern surrounding spoofing to collect
credentials from a rogue AP broadcasting the eduroam SSID and webpage
redirect.  This is the reason for LIN and eduroam pushing for 802.1X
with EAP/TTLS to create an encrypted tunnel between the client, AP, and
RADIUS servers whereby a properly installed certificate on the client
ensures that only credentials are sent to the correct home organisation
RADIUS server.  This does however require certificates to be installed
on each client device.  

A variety of eduroam-ng architectures are currently being explored by
the eduroam-gwg-sc working group who are considering RADIUS mesh
architectures and the development of a RADIUS server discovery feature
with RADIATOR to overcome hierarchy dependency.  Other work is looking
at finer grained authorisation (e.g. LICHEN) and ways to incorporate
shibboleth into 802.1x (much longer term).  

The reality is that as various solutions develop iteratively and mature
we are beginning to fix weaknesses and develop ways to interoperate
which can only be a good thing.  It is just a bit fluid right now and I
personally believe that we don't have one AAI that confidently covers
everyone's needs.

Best Regards

James Sankar

-----------------------------
Project Leader 
Applications and Services
AARNet Pty Ltd
Canberra, Australia

Tel: 02 6222 3538
Fax: 02 6222 3535
Mobile: 0422 007 466
email: [log in to unmask]
SIP:[log in to unmask]

-----Original Message-----
From: Paschoud,J [mailto:[log in to unmask]] 
Sent: Friday, 21 October 2005 9:49 PM
To: [log in to unmask]
Subject: Re: Shibboleth SP for BlueSocket WLAN access products

If Jon's analysis is correct (I'm not expert on that stuff either), I
think he highlights an important distinction between Web redirect
methods like Shibboleth, and LIN/Eduroam.  
 
It's a notable strength of Shibboleth that usernames, passwords (and
other credentials for 'stronger' AuthN where required) are *only* shared
between the end-user and the host organisation (IdP) with which he
already has a personal trust relationship.
 
I'm sure that LIN when operated by universities will take good care of
such credentials.  But users should still be concerned if they will be
sharing passwords where they shouldn't.
 
John
LSE Library

________________________________

From: Discussion list for Shibboleth developments on behalf of Jon
Warbrick
Sent: Fri 21/10/05 12:10
To: [log in to unmask]
Subject: Re: [JISC-SHIBBOLETH] Shibboleth SP for BlueSocket WLAN access
products



On Wed, 12 Oct 2005, Tim Chown wrote:

> If the site joins the UKERNA LIN, it can use whatever local backend it
> likes - in this case the Bluesocket device would communicate to a
local
> RADIUS server (for local users) or via the national RADIUS proxy to
the
> server in the visiting user's home institution.

What your talk yesterday in Edinburgh (for which many thanks, BTW)
seemed
to confirm to me is that the current LIN approach seems to be limited to
using passwords and to require users to disclose their password on
request
to LIN infrastructure at a site that they are visiting and then to have
it
bounced across the country via a network of RADIUS proxies. I'm
concerned
that users will not be able to correctly judge when they should and
should
not divulge this password (making it vulnerable to theft) nor be able to
evaluate the safety of the forwarding mechanism (though in practise I'd
expect this to be safe). As a result I'm concerned that LIN-based
authentication will be extremely week.

Web-redirect systems, and Shibboleth when using such for the local
authentication, have the advantage that a user should only need to
divulge
their password, or other credentials, to a web site run by their home
institution with which they are probably already familiar. It seems to
me
that this should result in somewhat stronger authentication.

> It's likely the LIN will push early for 802.1x deployment rather than
> web-redirect.

I don't yet know enough about 802.1x, but I think I'm about to have to
learn...

Jon.

--
Jon Warbrick
Web/News Development, Computing Service, University of Cambridge