[Emu] Short review of draft-friel-tls-eap-dpp-01

Alan DeKok <aland@deployingradius.com> Sun, 18 July 2021 16:39 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1DAE43A117A for <emu@ietfa.amsl.com>; Sun, 18 Jul 2021 09:39:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id MufzZflRIlcT for <emu@ietfa.amsl.com>; Sun, 18 Jul 2021 09:39:42 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 732223A1176 for <emu@ietf.org>; Sun, 18 Jul 2021 09:39:41 -0700 (PDT)
Received: from [] (24-52-251-6.cable.teksavvy.com []) by mail.networkradius.com (Postfix) with ESMTPSA id 5BF1D168 for <emu@ietf.org>; Sun, 18 Jul 2021 16:39:38 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
From: Alan DeKok <aland@deployingradius.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Message-Id: <1FE63FE4-4B23-4E0C-AF06-1372D6DA8869@deployingradius.com>
Date: Sun, 18 Jul 2021 12:39:36 -0400
To: EMU WG <emu@ietf.org>
X-Mailer: Apple Mail (2.3608.
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/Zk4nH0uuYJfZMtK-0DLVXmgvub4>
Subject: [Emu] Short review of draft-friel-tls-eap-dpp-01
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu/>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Jul 2021 16:39:47 -0000

  No major notes here.  There's still a lot of TBD in the document.  :)


  Section 3 says:

  ... For
   unprovisioned devices that desire to take advantage of TLS-POK, there
   is no initial realm in which to construct an NAI (see [RFC4282]) so
   the initial EAP Identity response SHOULD contain simply the name
   "TLS-POK" in order to indicate to the Authenticator that an EAP
   method that supports TLS-POK SHOULD be started.

* RFC 4282 has been deprecated by RFC 7542

* There just might be a user with name "TLS-POK", so using bare names is likely not a good idea.

  After looking at this, EAP-NOOB, and my latest document, there seem to be some overlap with EAP identities.  EAP-NOOB suggests a ".arpa" realm.  It would be good to agree on, and use, a common naming scheme.

  My suggestion is to define "eap.arpa" for EAP purposes.  This realm would be defined to be handled locally at the EAP server.  i.e. never proxied.  And used only for provisioning purposes.

  We can then have:

* noob@eap.arpa for EAP-NOOB

* TLS-POK@eap.arpa for this document

* perhaps "provisioning@eap.arpa for "I want a captive portal / provisioning network".  I have some updates pending to my document which discusses this concept.

  One issue we currently have today is that there's no standard way for an EAP client to say "I want network access, but I don't really care who it's from, and I don't really care to prove who I am".  This kind of authentication-less network access is still useful, as noted in the EAP-TLS 1.3 document.  Similar provisioning is in EAP-FAST and TEAP.

  I suspect that would be useful to have full network capabilities for provisioning.  While it can be nice to push all kinds of provisioning into an EAP method, TBH that seems like re-inventing the wheel.

  Instead, we could just have the EAP client go "I want access as @eap.arp" or maybe "provisioning@eap.arpa"arpa".  It then gets a "captive portal" network, and can rely on the rest of the TCP/IP stack, and the web PKI to download complex provisioning data.

  From an implementation point of view, updating EAP clients and servers is hard.  It takes a long time for changes to be written, tested, and widely deployed.  In contrast, if the client had access to a provisioning network, it can be easier to write a simpler utility which downloads information.  Among other benefits, there is also a clear separation of roles between network access, and configuration changes.

  Alan DeKok.