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.winter@xxxxxxxxxx Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf