Re: [radext] PAKEs and secure RADIUS

Alan DeKok <aland@deployingradius.com> Wed, 20 September 2023 01:10 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97ECAC15108A for <radext@ietfa.amsl.com>; Tue, 19 Sep 2023 18:10:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M89J4NvW2nvd for <radext@ietfa.amsl.com>; Tue, 19 Sep 2023 18:10:38 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBD21C151090 for <radext@ietf.org>; Tue, 19 Sep 2023 18:10:37 -0700 (PDT)
Received: from smtpclient.apple (135-23-95-173.cpe.pppoe.ca [135.23.95.173]) by mail.networkradius.com (Postfix) with ESMTPSA id BEE3610D; Wed, 20 Sep 2023 01:10:33 +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 16.0 \(3696.120.41.1.1\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <CAOW+2dtGY8d7rouVh2-o0b7Xbp9HZGWkhZpvt3EBEx9=SiQgnw@mail.gmail.com>
Date: Tue, 19 Sep 2023 21:10:32 -0400
Cc: radext@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1711BD6E-6461-4E04-A835-DD15F1F8EFF3@deployingradius.com>
References: <CAOW+2dtGY8d7rouVh2-o0b7Xbp9HZGWkhZpvt3EBEx9=SiQgnw@mail.gmail.com>
To: Bernard Aboba <bernard.aboba@gmail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/n52Mfx-OX5agI0XwR3D4IfyZwVs>
Subject: Re: [radext] PAKEs and secure RADIUS
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Sep 2023 01:10:42 -0000

On Sep 19, 2023, at 6:04 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> If the goal is to provide a stable roadmap for credentials in secure RADIUS, that seems like more of a "long and winding road" than a straight path that could be implemented and tested as part of a secure RADIUS certification program. 

 There are many proposals for bootstrapping devices with public / private keys.  e.g. https://datatracker.ietf.org/doc/draft-ietf-emu-bootstrapped-tls/

  We could do something similar in RADIUS. 

* device has private key

* device publishes public key via QR code (admin interface, sticker on the side, etc)

* we can use TLS-POK to authenticate client to server, and vice versa

* ??? somehow new credentials are provisioned in the TLS tunnel.

* device uses new credentials / configuration for new RADIUS/TLS conversations.

   The open questions are:

* the device still has to find the server.  This could be manually configured by the administrator (hostname / IP)

* the server still has to get the public key from the device (scan, manual copy, etc.)

* the device has to somehow signal that it wants to do provisioning, and not just RADIUS.  Perhaps ALPN could be used here

* the provisioning data has to be sent to the device in some standard format.  It's 2023... json is everywhere.

  There are a number of provisioning methods being discussed in various places in the IETF.  BRSKI or  EST (RFC7030).  The downside to those is that they generally require something other than RADIUS/EAP.

  i.e. if we have a RADIUS-specific provisioning protocol, then the RADIUS engineering team can implement it.  If instead the provision protocol uses many other protocols, the RADIUS engineering team has to either re-do all that work, or it has to coordinate activities across multiple teams.

  Despite my preference to avoid re-inventing the wheel, doing this work in RADIUS seems to be the most productive approach.


  A simper alternative is perhaps to never provision new credentials.  Instead, the device just keeps using bare public / private keys.  After all, RADIUS administrators don't necessarily care about the format of the device credentials.  They just want to limit RADIUS to known devices.

  So the administrator then just says "use identifier FOO, RADIUS server is at BAR, use internal private key".  The relevant identifier and public key are imported into the RADIUS server, and the device can connect with minimal effort.

  You could make it even simpler by using the device MAC as the default identifier for TLS.

  The RADIUS server could be discovered by doing an MDNS lookup of _radius._tls.local

  This proposal is getting away from PAKE / SRP / PSK / etc.  But it may be worth discussing.

  Alan DeKok.