[OPSAWG] EAP configuration metadata draft

Stefan Winter <stefan.winter@restena.lu> Mon, 10 February 2014 12:53 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 3B2071A00BC for <opsawg@ietfa.amsl.com>; Mon, 10 Feb 2014 04:53:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level:
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 JE7Z7m4QWMGA for <opsawg@ietfa.amsl.com>; Mon, 10 Feb 2014 04:53:25 -0800 (PST)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 407761A082F for <opsawg@ietf.org>; Mon, 10 Feb 2014 04:53:25 -0800 (PST)
Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id E763D10589; Mon, 10 Feb 2014 13:53:24 +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 D993910581; Mon, 10 Feb 2014 13:53:24 +0100 (CET)
Message-ID: <52F8CBB6.9000005@restena.lu>
Date: Mon, 10 Feb 2014 13:53:10 +0100
From: Stefan Winter <stefan.winter@restena.lu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "opsawg@ietf.org" <opsawg@ietf.org>
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="e6ENUFIiM6mpIDchb24GrOwXBqLosxa3W"
X-Virus-Scanned: ClamAV
Cc: "'sense@geant.net'" <sense@geant.net>
Subject: [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, 10 Feb 2014 12:53:27 -0000

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

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