Re: [OPSAWG] EAP configuration metadata draft

Stefan Winter <stefan.winter@restena.lu> Mon, 24 February 2014 09:15 UTC

Return-Path: <stefan.winter@restena.lu>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E324B1A083A for <opsawg@ietfa.amsl.com>; Mon, 24 Feb 2014 01:15:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.254
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id At7KLAus3V0H for <opsawg@ietfa.amsl.com>; Mon, 24 Feb 2014 01:15:43 -0800 (PST)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id DAFAB1A0404 for <opsawg@ietf.org>; Mon, 24 Feb 2014 01:15:40 -0800 (PST)
Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 835A910589 for <opsawg@ietf.org>; 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 smtprelay.restena.lu (Postfix) with ESMTPS id 670CA10584 for <opsawg@ietf.org>; Mon, 24 Feb 2014 10:15:39 +0100 (CET)
Message-ID: <530B0D9C.4060706@restena.lu>
Date: Mon, 24 Feb 2014 10:15:08 +0100
From: Stefan Winter <stefan.winter@restena.lu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: opsawg@ietf.org
References: <52F8CBB6.9000005@restena.lu>
In-Reply-To: <52F8CBB6.9000005@restena.lu>
X-Enigmail-Version: 1.6
OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nNMTwVbu8FSUiPQm0mwSvbBXRa9Rh4kUq"
X-Virus-Scanned: ClamAV
Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/Qjoh8EBXNBPryLNGRfLFiQ92zIg
Subject: Re: [OPSAWG] EAP configuration metadata draft
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Feb 2014 09:15:48 -0000

Hello,

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.

https://bugzilla.mozilla.org/show_bug.cgi?id=775499

Greetings,

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 (
> http://datatracker.ietf.org/doc/draft-winter-opsawg-eap-metadata/ ).
> 
> 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
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
> 


-- 
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