HEllo Stefan and thank you for the email on int-area. Although supposedly the authentication aspects are the most concern to the wide-area roaming contexts you're dealing with - I agree in many respects - I think there may also exist some aspects related to securely accommodating mobility at network layer, as you seem to approach mentioning at the end of the mail.
In no way I'm trying to deviate discussion from the authentication aspects, and I support a get-together in Philadelphia on this topic, I'll probably join it. Let me just reply to one of your last points below. Stefan Winter wrote: > 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. It may also be interesting to look at how network-layer mobility fits the authentication aspects you're dealing with. For example, if a eduroam user uses Mobile IP to maintain ongoing sessions between different campuses (maybe traveling through UMTS in between). This can be achieved by modifying the network layer only (Mobile IP) instead of going up to the application layer, having thus some advantages. However, the authentication problems are also raised, for example: what does the user authenticate - her Home Address or her Care-of Address? Or both? Just some thoughts on mobility and authentication. Thanks for your mail, Alex > > 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 > > > > ------------------------------------------------------------------------ > > > > > _______________________________________________ IETF mailing list > [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
