Re: [perpass] perpass: what next?

[Stefan Winter <[e-mail]>]

Hi,

> The biggest issue that I see in the perpass space has been persistent market
> failures of some of our key technologies.  Not entirely our problem, but each
> time I see an industry "consortia" write a specification behind closed doors
> that is more than a list of RFCs, I think we have failed. [..]

> This is very much a case where there has been a significant gap between what
> we specify, and what there are resources to actually implement *AND*
> deploy.

I have one example where we have left spec-writing to third parties and
thus seem to neglect the "deploy" part of the value chain to some
extent, and one which leads to security and privacy problems.

My main focus of work is secure enterprise wireless networks. The medium
is of course IEEE's "problem", but the secure authentication part brings
in EAP, which is an IETF spec.

EAP is a really complex protocol and needs server *and* client side
config to deliver its security properties. Two short examples:

a) the end-user device /can/ configure an anonymous outer identity for
authentication routing purposes (concealing the local part of the
username); but that's extra config. If neglected, the end-device leaks
the actual username of the person trying to authenticate across the AAA
infrastructure.

b) the end-user device /can/ be configured to verify the X.509
certificate of its EAP server before it sends the user credentials; but
the user needs to install CAs and whatnot. If neglected, the end-user
device will send passwords to random third parties (and we have some
anecdotal evidence suggesting the rate of such "don't care" configs is
>>50%).

EAP asks much from a server operator and the end user trying to
configure it. Assuming that everybody will just get it right is delusional.

A variety of (non-interoperable) third-party approaches to
automated/better/more convenient EAP configuration has blossomed,
creating a mess of config formats / sane defaults / insane defaults
landscape.

I've tried to bring work to the IETF to create a config file format for
EAP; the basic idea being that if IETF created EAP, we should also
create a means to communicate EAP *configuration*.

I didn't find a spot-on working group to take this to and presented it
to opsarea / opsawg instead.

There was only a rather mild interest in the draft, it hasn't led to
much review activity or a motion to adopt it as a WG draft at this
point. I find that a bit disappointing. I'm considering to go AD
shopping to publish this in the ISE stream for the lack of a better path
to publication.

But really... this is privacy (and security!) relevant work, it's about
an IETF technology, it is about a technology which is in active use out
there, and it obviously is a piece of work that needs standardisation
because there are so many non-interoperable approaches. So... why does
such an item gain so little traction? I don't know the answer; if anyone
does...

BTW, the current draft is here; as it happens, it expires today, and
honestly I'm wondering if it's worth refreshing it:

https://tools.ietf.org/html/draft-winter-opsawg-eap-metadata-01

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: [phone]
Fax: [phone]

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