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

Alan DeKok <> Tue, 27 July 2021 17:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 245913A0E00 for <>; Tue, 27 Jul 2021 10:50:59 -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 mL6yD30m9oJI for <>; Tue, 27 Jul 2021 10:50:52 -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 774793A0DEE for <>; Tue, 27 Jul 2021 10:50:52 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id E2C2533D; Tue, 27 Jul 2021 17:50:49 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Alan DeKok <>
In-Reply-To: <>
Date: Tue, 27 Jul 2021 13:50:47 -0400
Cc: EMU WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: "Owen Friel (ofriel)" <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Emu] Short review of draft-friel-tls-eap-dpp-01
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: Tue, 27 Jul 2021 17:51:07 -0000

On Jul 27, 2021, at 1:23 PM, Owen Friel (ofriel) <> wrote:
> [ofriel] the goal here is to push the provisioning info (e.g. CA roots, peer identity certs) inside TEAP using existing TEAP mechanisms e.g. Trusted Server Root, PKCS#7 TLVs.

  That presumes everyone uses TEAP, all of the time.  This is likely to not be the case for a while, if ever.

  TEAP also has the issue of bootstrapping.  RFC 7170 Section 3.8.3 described an unauthenticated provisioning mode, but suggests that Phase 2 still has mutual authentication.  It's not clear how the parties can identify each other in that case.  The document appears to be silent on the topic.

  This draft solves that issue, among others.

  For example, what about the use-case of Eduroam?  10,000 students show up to a university which uses a private CA.  Assuming that all of the devices support TEAP, they are still unable to perform "mutual authentication, and TEAP becomes ToFU.   Similarly, DPP may work, but that requires creation and distribution of new keys

  In contrast, the user work flow here is "connect to Eduroam, log in with your username and password".  It really can't get simpler than that.

  The first stage of this proposal requires no changes to existing supplicants.  A simple client-side utility can perform the requisite actions, and configure the supplicant.  Running code is available:

  The core of the work is a ~300 line Python script.  OS vendors could ship this today.  Network administrators could add a few records to DNS/WWW.  Getting EAP connectivity then becomes trivial.  It requires minimal coordination, and minimal new software.

> We are trying to avoid wheel reinvention. The novel bit here is the mutual authentication in the TLS stack based on the already defined Wi-Fi Alliance DPP bootstrap key.

  The spec doesn't require (or use) DPP bootstrapping.

  This draft is different from a number of related issues in that it solves a different problem, and in a different way:

* it leverages web PKI to bootstrap TLS-based EAP methods

* it does provisioning over standard internet protocols, instead of extending the supplicant.

  I think both of the above are useful.  Using EAP as a generic transport layer for provisioning seems like a poor choice.

  Alan DeKok.