Re: [OPSAWG] EAP configuration metadata draft

Stefan Winter <> Mon, 24 February 2014 09:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E324B1A083A for <>; Mon, 24 Feb 2014 01:15:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.254
X-Spam-Status: No, score=0.254 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.547, WEIRD_PORT=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id At7KLAus3V0H for <>; Mon, 24 Feb 2014 01:15:43 -0800 (PST)
Received: from ( [IPv6:2001:a18:1::62]) by (Postfix) with ESMTP id DAFAB1A0404 for <>; Mon, 24 Feb 2014 01:15:40 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 835A910589 for <>; Mon, 24 Feb 2014 10:15:39 +0100 (CET)
Received: from [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7] (unknown [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7]) by (Postfix) with ESMTPS id 670CA10584 for <>; Mon, 24 Feb 2014 10:15:39 +0100 (CET)
Message-ID: <>
Date: Mon, 24 Feb 2014 10:15:08 +0100
From: Stefan Winter <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
OpenPGP: id=8A39DC66; url=
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nNMTwVbu8FSUiPQm0mwSvbBXRa9Rh4kUq"
X-Virus-Scanned: ClamAV
Subject: Re: [OPSAWG] EAP configuration metadata draft
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OPSA Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 Feb 2014 09:15:48 -0000


my draft does not involve writable MIB modules, so it seems to be hard
to get some attention.

So, let me just add another data point to this, hoping I can stir up
some responses:

Firefox OS is showing interest in a) a standard way of configuring EAP;
b) our spec in particular; so there is real-world demand out there.

There's a (long) bug report on the whole topic of
Enterprise-Wifi-or-not; and if yes, how to do it right.


Stefan Winter

On 10.02.2014 13:53, Stefan Winter wrote:
> Hello,
> I would like to draw your attention to my submission of
> draft-winter-opsawg-eap-metadata-00 (
> ).
> I would like to ask the community how they feel about this work - is it
> needed, are we on the right track, etc.
> As a teaser for why our group thinks this piece of work is important and
> useful, please see the beginning of the Problem Statement section,
> pasted here for your convenience:
> "The IETF has produced the Extensible Authentication Protocol (EAP,
>    [RFC3748] and numerous EAP methods (for example EAP-TTLS [RFC5281],
>    EAP-TLS [RFC5216] and [RFC5931]); the methods have many properties
>    which need to be setup on the EAP server and matched as configuration
>    items on the EAP peer for a secure EAP deployment.
>    Setting up these configuration items is comparatively easy if the
>    end-user devices which implement the EAP peer functionality are under
>    central administrative control, e.g. in closed enterprise
>    environments.  Group policies or device provisioning by the IT
>    department can push the settings to user devices.
>    In other environments, for example "BYOD" scenarios where users bring
>    their own devices which are not under enterprise control, or in EAP-
>    based WISP environments (see e.g. [HS20] and
>    [I-D.wierenga-ietf-eduroam]) where it is not desired neither for the
>    ISP nor for his user that the device control is in the ISPs hands,
>    configuration of EAP is significantly harder as it has to be done by
>    potentially very non-technical end users."
> There's plenty of proprietary approaches, they all vary in richness of
> expressability, most don't have complete public schemas or are even in
> binary with no explanations on how to construct them as an outsider.
> We find the lack of a public specification disturbing.
> It leads to duplication of efforts in numerous organisations,
> incompatiblities between the produced formats, and sometimes simply
> leads to bad quality specs.
> BTW, I have teased the list earlier (see my posting on 18 Dec 2013), and
> already got an on-list response (as well as offline).
> I believe this warrants allocation of slot time in London, and I would
> at this point ask the chairs if it's possible to get 5 mins (more if you
> have plenty :-) ) to discuss the problem itself and the solution we've
> put together in this first draft.
> Greetings,
> Stefan Winter
> _______________________________________________
> OPSAWG mailing list

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