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

From: Stefan Winter <[email-masked]>
Date: Wed, 18 Dec 2013 09:36:18 +0100

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