Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03

Alan DeKok <> Sat, 03 July 2021 11:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 79DD83A10D4 for <>; Sat, 3 Jul 2021 04:58:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XC8nIVrjX6oB for <>; Sat, 3 Jul 2021 04:58:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 76AD03A106F for <>; Sat, 3 Jul 2021 04:58:01 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 33FB5113; Sat, 3 Jul 2021 11:57:59 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Alan DeKok <>
In-Reply-To: <>
Date: Sat, 3 Jul 2021 07:57:57 -0400
Cc: Tim Cappalli <>, EMU WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <7332.1624927848@localhost> <> <26359.1625006432@localhost> <> <> <> <> <> <> <> <>
To: Eliot Lear <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 03 Jul 2021 11:58:07 -0000

On Jul 3, 2021, at 7:47 AM, Eliot Lear <> wrote:
> I don't think Tim could be blamed for holding the view that there is a separation between specifications and how they are used. There's good and bad to the practice.  The good is that the spec can be used in ways that the creators didn't intend, and thus perahsp there are fewer unnecessary constraints.
> On the other hand, not having a theory of operation section, as we do have in a good number of our specs, leads to people really not understanding when they are applicable, and perhaps more importantly, when they are not.

  People don't even understand how to use the specs as intended. We're essentially telling people "EAP methods are applicable in these situations, but good luck actually trying to get them deployed, you're on your own".

  Each vendor does randomly different things for UI / credential management / workflow / whatever.  The end result is that the spec is largely theoretical.  In practice, people do any number of hacks to get something to work.  Because the specs don't help here.

  If people can't deploy a spec easily and securely, then I see that as a failure of the specification.  For example, over the last 20+ years, the "Security Considerations" section of RFCs has grown in importance and content.  This is a good thing.

> All of this having been said, perhaps the best way to go forward is to have a requirements discussion in terms of the sorts of operations we would like to see as part of the authentication process – as opposed to elsewhere.
> I see tremendous opportunity here, to be honest.  But it's a lot of work.

  I agree.

  Alan DeKok.