Subject: Re: [OPSAWG] Upcoming I-D: EAP metadata format

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 03 Jan 2014 16:55:11 +0100

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-masked]> 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-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C