[Top] [All Lists]

Discussion about Federated Roaming

2008-03-01 08:27:03

My name is Stefan Winter of the National Research and Education Network in 
Luxembourg, RESTENA. We are an ISP for academia and take the lead in research 
and development of a global academic wireless LAN federated roaming 
consortium: "eduroam". This is based on EAP and 802.1X exclusively.

In the course of development, prototyping and rollout of eduroam, we have 
discovered that some areas of the relevant standards required some tweaking 
or workarounds. After following IETF work for some time, we also saw that 
some of the efforts exclude roaming use cases from their agenda.

So far I've heard that we are by far the biggest federated 802.1X roaming 
consortium at all, and I wonder if we are the only ones seeing some items 
that could use a second thought when considering roaming between independent 
administrative domains.

I will be at IETF71, and would like to invite anyone who is interested in 
federated roaming scenarios for an informal get-together to exchange ideas. I 
was planning to do this on Monday evening, at a location that is still TBD, 
I'll follow up. 

Below I've put together the most prominent items that are on our radar right 
now to give you a glimpse of the issues we in eduroam are dealing with.

The most prominent issue is the uneasy fact that RADIUS doesn't provide a 
reliable transport and only basic security, while Diameter has no 
implementations and NAS support in the wireless LAN area. With an EAP 
conversation requiring multiple, usually around eight, roundtrips, and a 
packet path that may literally span the whole world, this is a major concern. 
It also didn't particularly help that in a recent discussion on dime, it was 
stated that Diameter doesn't offer significant advances regarding roaming 
compared to RADIUS. 
We tried to mitigate this by proposing RadSec, RADIUS over TCP+TLS [1], and 
are pursuing this in the radext wg right now.

Another thing is that we have no sufficient signalling mechanism to reach the 
end user if the 802.1X login couldn't be completed because of an intermediary 
RADIUS proxy being down - due to the lack of possibility to provide error 
messages in the 802.1X protocol, most supplicants provide the unhelpful 
advice that "Probably the password is wrong", which is wrong and generates 
user frustration. Some kind of "hijacking" the EAP conversation by the last 
responsive proxy to inject EAP-Notifications would be needed probably, but 
this is not thought through in its entirety yet. I'm aware that there is a 
security argument: not disclosing the reason for a failure may make attacks 
more difficult, but still: it would then be desirable to at least have the 
*option* of providing the info - right now it is impossible.

Then, encapsulating EAP in RADIUS may sometimes lead to RADIUS packets being 
so big that they have to be fragmented - not a conceptual problem, but a 
practical one, because out-of-order fragements, or even even in-order UDP 
fragments generate problems on unclever firewalls more often than not. 
Especially EAP-TLS, where both server and supplicant need to send large 
amounts of (certificate) data turned out to be a real challenge. A draft 
about that problem and a sketch of a possible solution is in the works.

Another thing that bugged us about RADIUS is the inability to contact new auth 
servers "on the fly", for example when a new user realm is observed. So far, 
we stacked together RADIUS servers in a realm-based aggregation hierarchy. A 
better approach, in combination with the TCP+TLS nature of RadSec, would be 
to use a dynamic lookup mechanism (e.g. DNS NAPTR/SRV) that allows to 
discover the authoritative home server for a user's realm and to verify that 
server's eligibility by examining the certificate. This is a concept we will 
try out in semi-production use in eduroam soon, but it may have implications 
also out of the eduroam community, since it will allow arbitrary service 
providers to create an authentication fabric very easily on the technical 
side - making the *paperwork* of bootstrapping a roaming consortium the only 
big challenge.

We have been looking at the work of the NEA wg with a bit of concern, since 
its charter excludes the federated roaming case deliberately. For example, 
putting posture information into EAP will always convey the posture info to 
the home server, while it is the service provider that needs the posture 
information to make its admission decision. We understand though that there 
is work going on to make the use of NEA roaming-agnostic, which we would very 
much like to see.

Finally, there is a more exotic area in connection to roaming scenarios: 
converging roaming on the network layer (802.1X+EAP) with Single-Sign On on 
the application layer (SAML et al), with the ultimate goal that using a set 
of credentials to log into the network also generates an application layer 
token to use for signing into services - without the need to re-authenticate.

I realise that some of the points above may not fit perfectly into the IETF 
scope, either interfacing downwards to layer 2 and IEEE work (EAPoL) or 
upwards to the application layer. Still, these are points not tackled 
sufficiently so far and they at least have partial relevance to the IETF 
work, so I hope that there are some folks out there to discuss this over a 
beer or two, in a "bar BoF" style.


Stefan Winter



RESTENA Foundation - Réseau Téléinformatique de l'Education Nationale et de 
la Recherche
R&D Engineer

6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
email: stefan(_dot_)winter(_at_)restena(_dot_)lu     Tel.:     +352 424409-1               Fax:      +352 422473

Attachment: signature.asc
Description: This is a digitally signed message part.

IETF mailing list
<Prev in Thread] Current Thread [Next in Thread>
  • Discussion about Federated Roaming, Stefan Winter <=