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

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 26 March 2022 16:01 UTC

Return-Path: <mcr@sandelman.ca>
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 78E793A08CF for <emu@ietfa.amsl.com>; Sat, 26 Mar 2022 09:01:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 1xkpLdurZHEr for <emu@ietfa.amsl.com>; Sat, 26 Mar 2022 09:01:47 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00:e000:2bb::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F31E3A07F6 for <emu@ietf.org>; Sat, 26 Mar 2022 09:01:46 -0700 (PDT)
Received: from dooku.sandelman.ca (ipv6.dooku.sandelman.ca [IPv6:2607:f0b0:f:6::1]) by relay.sandelman.ca (Postfix) with ESMTPS id 971ED1F45A; Sat, 26 Mar 2022 16:01:44 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id E518C1A01DE; Sat, 26 Mar 2022 17:01:41 +0100 (CET)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Alan DeKok <aland@deployingradius.com>, EMU WG <emu@ietf.org>
In-reply-to: <8C03CE4A-B987-4962-9AA3-5DF8FB32ECB5@deployingradius.com>
References: <8C03CE4A-B987-4962-9AA3-5DF8FB32ECB5@deployingradius.com>
Comments: In-reply-to Alan DeKok <aland@deployingradius.com> message dated "Fri, 25 Mar 2022 14:36:50 -0400."
X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sat, 26 Mar 2022 17:01:41 +0100
Message-ID: <69280.1648310501@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/EPxYw68o-q4W60hNAhVblWru51A>
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: Sat, 26 Mar 2022 16:01:53 -0000

Alan DeKok <aland@deployingradius.com> wrote:
    >   EAP implementations are limited to exchanging ~64K of data before
    > supplicant and/or server gives up.  If there is a need to exchange more
    > data than this, it's impossible.  Configuration data tends to grow over
    > time, because of a tendency to just use the existing system, even
    > though it isn't really intended for that use.  People tend to (ab)use
    > existing systems in surprising ways, too.

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.

    >   This method also has a cost.  Administrators now have to set up
    > additional services in order to do provisioning.  This may not always
    > be possible.  As Eliot pointed out, there are also security issues with
    > exposing additional servers (EST, etc.) to unauthenticated users.

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)

I can live with it being trivially encrypted via EAP-TLS with a "well-known"
username/password like we do with the "ietf" network at meetings.

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.

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.


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-