[OPS-AREA] EAP configuration metadata draft

Stefan Winter <stefan.winter@restena.lu> Tue, 11 February 2014 11:05 UTC

Message-ID: <52FA03FD.6070308@restena.lu>
Date: Tue, 11 Feb 2014 12:05:33 +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: "ops-area@ietf.org" <ops-area@ietf.org>
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="bbsi3ndEF7XE6icn1B4J3Dc3r5woWbd46"
Subject: [OPS-AREA] EAP configuration metadata draft
Precedence: list

Hello (adding ops-area@),

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

Attachment: 0x8A39DC66.asc
Attachment: 0x8A39DC66.asc
Attachment: signature.asc

[OPS-AREA] EAP configuration metadata draft Stefan Winter

[OPS-AREA] EAP configuration metadata draft

Attachment: 0x8A39DC66.asc

Attachment: 0x8A39DC66.asc

Attachment: signature.asc