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

Alan DeKok <> Wed, 28 July 2021 12:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8DAF73A0BFF for <>; Wed, 28 Jul 2021 05:07:05 -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 EDfPtjS7ojlX for <>; Wed, 28 Jul 2021 05:07:00 -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 D98CC3A0BAE for <>; Wed, 28 Jul 2021 05:06:39 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 49DEB33D; Wed, 28 Jul 2021 12:06:34 +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: Wed, 28 Jul 2021 08:06:32 -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: Wed, 28 Jul 2021 12:07:06 -0000

On Jul 27, 2021, at 1:50 PM, Alan DeKok <> wrote:
>> 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 novel bit in the EAP-DPP draft, yes.

  My leaning is more and more towards just using EAP for authentication, and doing provisioning via standard networking protocols.

  For example, the Wi-Fi Alliance Passpoint R3 defines unauthenticated EAP.  It's essentially EAP-TLS, but using the extended EAP types with the Wifi Alliance enterprise number.  This requirement means that all supplicants and servers have to be updated to support this method.

  Multiple that by more standards bodies, vendors, IETF working groups, and we end up with a massive amount of EAP types.  All trying to get similar things done.  This is already happening.

  Or, we define unauthenticated EAP as using ""arpa".  The supplicants need to be updated once to support that.  Different use-cases can just request different methods via changing the username portion.   And once they have network access, run separate utilities to do their magic provisioning.

  Mashing everything into EAP seems just... wrong.

  Alan DeKok.