Hello!
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.
Greetings,
Stefan Winter
[1] http://www.ietf.org/internet-drafts/draft-winter-radsec-01.txt
--
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
http://www.restena.lu Fax: +352 422473
signature.asc
Description: This is a digitally signed message part.
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf