Re: [radext] PAKEs and secure RADIUS

Alan DeKok <aland@deployingradius.com> Wed, 20 September 2023 15:39 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 BD42EC151070 for <radext@ietfa.amsl.com>; Wed, 20 Sep 2023 08:39:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 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] 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 x9xP6yi4ihxP for <radext@ietfa.amsl.com>; Wed, 20 Sep 2023 08:39:37 -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) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B3E1C151546 for <radext@ietf.org>; Wed, 20 Sep 2023 08:39:36 -0700 (PDT)
Received: from smtpclient.apple (unknown [75.98.136.130]) by mail.networkradius.com (Postfix) with ESMTPSA id E90E243B; Wed, 20 Sep 2023 15:39: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: <24504.1695223881@localhost>
Date: Wed, 20 Sep 2023 11:39:32 -0400
Cc: radext@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <E5C7A9AF-DE9A-4BD3-BDE0-2375556112CB@deployingradius.com>
References: <CAOW+2dtGY8d7rouVh2-o0b7Xbp9HZGWkhZpvt3EBEx9=SiQgnw@mail.gmail.com> <1711BD6E-6461-4E04-A835-DD15F1F8EFF3@deployingradius.com> <24504.1695223881@localhost>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/BHS31Uw9eggGYYukslNfmkwl_MI>
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 15:39:39 -0000

On Sep 20, 2023, at 11:31 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote
> 
> I understood Bernard's message as being about RADIUS<->RADIUS security rather
> than end-device security (EAP).

  Sure.  My thought was that if EAP has a bootstrapping method based on TLS, then RADIUS also needs a bootstrapping method for TLS.

  Why not use a similar mechanism?

>   The connections between various proxies
> being more and more ad-hoc/on-demand as connectivty patterns grow.

  I think that issue can be addressed via dynamic discovery.  Even without that, proxies are complex systems that are already on the net.  They can be managed by admins through various OS tooling.

  However, there's still an issue for NAS -> server bootstrapping.  Right now it is pretty horrific.  If we can define a way to fix that, and then wedge it into various other standards bodies, it will benefit everyone.

  Alan DeKok.