Hi Stefan, in my view, this is a useful work. My (user's) experience from eduroam is that configuring the authentication has often been the most difficult step.
I think though you should consider using YANG (RFC 6020) for the configuration data model specification. Lada Stefan Winter <[email protected]> writes: > Hello, > > I'm currently in the process of writing an -00 I-D on an aspect of > network management which has IMHO been neglected standards-wise so far: > Configuration of EAP authentication, particularly in the IEEE > 802.1X/WiFi space (but also relevant for other EAP-based network access > control and ABFAB) - on the end-user device (i.e. EAP peer). > > The issue is that the IETF has produced EAP and EAP methods; they have > many properties which need to be setup on the EAP server and matched as > configuration items on the EAP peer. Deploying EAP is a complex task > both for an EAP server operator *and for the users who have to setup > everything correctly on their machine*. > > EAP is being used for WiFi, and there in an increasing manner in the > buzzwordy "BYOD" scenarios; and a further use case comes up in "Hotspot > 2.0" where the user does not have any particular relationship to the EAP > server operator besides the desire for internet connectivity. > > In these scenarios, the EAP server operator does not have full > administrative control over the end-user device; yet, a complex > configuration task needs to be carried out on that device to make the > EAP setup > * functional (i.e. the end user must have set up enough parameters > correctly to be able to authenticate to an EAP server at all) > * secure (i.e. the end user must have set up all the parameters which > ensure unambiguous mutual authentication to *only* his EAP server) > * privacy-preserving (i.e. the end user is able to conceal his username > from the EAP pass-through authenticator) > > In our EAP-based "eduroam" WiFi roaming consortium, we meanwhile have > millions of users, thousands of EAP servers and thus just as many > different EAP settings for users of those EAP servers. IOW, we have the > operational capacity and enough real-life experience to credibly assert > that initial EAP setup is a tough job if having to be done manually by > the user. To alleviate the problem, it would be desirable to be able to > convey the configuration information in a machine parseable way so that > all the gory details need not be known/understood by the user. > > There is currently no standard way of communicating configuration > parameters about an EAP setup to the EAP peer. > > Device manufacturers sometimes have developed their own proprietary > configuration formats, e.g. Apple's "mobileconfig" (MIME type > application/x-apple-aspen-config). > Other devices at least provide an API for such configuration; if there > were a standard way to communicate the settings to such a device, an > application could consume the configuration information and create the > necessary settings automatically. Android 4.3+ (API level 18) is one > such example. > Yet other devices do not have an API nor good UI for a manual setup. At > least one device type developer base has communicated to us that if > there were a standard way of getting EAP configuration data for WiFi > OTA, they would likely make use of it. > > To overcome this proprietary/mixed-capability situation, we would like > to propose that the IETF develops a metadata format which can > communicate EAP settings and EAP method deployment details; with the > eventual goal that EAP peer devices would be enabled to consume the > file, act on it, and set up EAP in a complete, secure and (if so > desired) privacy-preserving way. > > I have talked to the OPS ADs in Berlin, who encouraged me to go ahead > with the specification and gave the advice that the place to take this > to is opsarea/opsawg - hence this mail. > > We have already developed a preliminary XML specification which is rich > enough to convey most if not all EAP deployment details, and which I > hope serves as a good starting point for IETF work. I'll assemble an > accompanying I-D which explains the current schema and documents the > design decisions we've taken so far. > > I would appreciate discussion on the topic here in opsawg; and as soon > as I've pushed out the draft itself, I'll be more than happy to receive > comments and bashing ;-) > > (And if discussion does happen on the list, I'd also like to request a > talking slot in the London meeting) > > Greetings, > > Stefan Winter > > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et > de la Recherche > 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg > > Tel: +352 424409 1 > Fax: +352 422473 > > PGP key updated to 4096 Bit RSA - I will encrypt all mails if the > recipient's key is known to me > > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
