Re: [Emu] Provisioning, configuration, etc. and EAP

Alan DeKok <aland@deployingradius.com> Sun, 27 March 2022 13:58 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C293A0D61 for <emu@ietfa.amsl.com>; Sun, 27 Mar 2022 06:58:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 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, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OO3qkOMdQlsg for <emu@ietfa.amsl.com>; Sun, 27 Mar 2022 06:58:12 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 143AD3A0D62 for <emu@ietf.org>; Sun, 27 Mar 2022 06:58:11 -0700 (PDT)
Received: from smtpclient.apple (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id F106E379; Sun, 27 Mar 2022 13:58:08 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <69280.1648310501@dooku>
Date: Sun, 27 Mar 2022 09:58:07 -0400
Cc: EMU WG <emu@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BC205D3A-DCDD-4C43-AF88-9031622FCAFA@deployingradius.com>
References: <8C03CE4A-B987-4962-9AA3-5DF8FB32ECB5@deployingradius.com> <69280.1648310501@dooku>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/bysNCo8li5yDT2p-tau3EhNDjsU>
Subject: Re: [Emu] Provisioning, configuration, etc. and EAP
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, 27 Mar 2022 13:58:17 -0000

On Mar 26, 2022, at 12:01 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 64K is plenty to run RFC8995.  Probably we can get away with a total of less
> than 10K exchanged in the worst case situations,  with 2K being more typical.

  That's good, but I still have concerns with the process of using EAP for, well, almost everything.

  Anonymous / unauthenticated EAP-TLS exists.  I'd like to know why that's unacceptable for provisioning general-purpose devices.

  For example, see any number of device management products.  These products download large amounts of configuration, and even applications to end-user devices.  This process is part of provisioning the device, and can't be done via tunnelling that data in EAP.  So if we're not using EAP for most of that complex provisioning, why not just use the same methods for all of it?

> Specifically, my original notion was to have an SSID called "ONBOARDING",
> which was unencrypted.  (I would run on DHCPv4, which makes smartphones give
> up and go away.  IPv6-LL only)

  Similar things are done in the 3G/4G/5G space.  But either via other standards bodies, or vendor-specific means.  i.e. people are laying additional things on top of EAP, because (a) they can, and (b) the IETF won't.

  The result is that there is a "grab bag" of solutions, instead of a unified approach.

> The cost is that it has to be setup and available across a potentially large
> enterprise situation.  At the small scale of one or two home routers, it's
> just not a problem.

  I'm not clear how a large enterprise causes any issues.  For my proposal, just put records into DNS, and various data into web pages.  Anyone with corporate credentials can then get on the secure WiFi network.

> We will have to give up on WPA-PSK for the home, because RCM (Madinas) just
> can't cope with maintaining policies for different devices when the devices
> all have the same PSK.

  I agree.

  It's 2022... why is it difficult to get onto a friends WiFi network, securely, and easily?

  The answer I see is that the products are a collection of things from different standards bodies, who often don't communicate well with each other.

  Alan DeKok.