Re: [radext] BoF request for IETF 115

"klaas@wierenga.net" <klaas@wierenga.net> Fri, 09 September 2022 15:09 UTC

Return-Path: <klaas@wierenga.net>
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 4BFC9C1522AC for <radext@ietfa.amsl.com>; Fri, 9 Sep 2022 08:09:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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 UN8YhAhkmTLu for <radext@ietfa.amsl.com>; Fri, 9 Sep 2022 08:09:45 -0700 (PDT)
Received: from out26-til-ipv6.surfmailfilter.nl (out26-til-ipv6.surfmailfilter.nl [IPv6:2001:610:1:40ab:195:169:13:26]) (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 3D84EC14F726 for <radext@ietf.org>; Fri, 9 Sep 2022 08:09:43 -0700 (PDT)
X-Halon-ID: 5e1121a3-3051-11ed-bb33-005056a44114
Received: from mail.het.net.je (unknown [2001:610:508:110:192:87:110:20]) by filter2-til.surfmailfilter.nl (Halon) with ESMTPS id 5e1121a3-3051-11ed-bb33-005056a44114; Fri, 09 Sep 2022 17:09:14 +0200 (CEST)
Received: from [52.98.155.29] (helo=AS8P189MB1734.EURP189.PROD.OUTLOOK.COM) by mail.het.net.je with esmtpsa (TLS1.2:ECDHE_ECDSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <klaas@wierenga.net>) id 1oWfVj-0002hF-B0; Fri, 09 Sep 2022 15:01:39 +0000
From: "klaas@wierenga.net" <klaas@wierenga.net>
To: "josh.howlett@gmail.com" <josh.howlett@gmail.com>, 'Stefan Winter' <stefan.winter@restena.lu>, "radext@ietf.org" <radext@ietf.org>
Thread-Topic: [radext] BoF request for IETF 115
Thread-Index: ATA1Zjcz29LZMwlg1uN4MdYttsU82tEd3DmAgAATIsk=
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Fri, 09 Sep 2022 15:09:38 +0000
Message-ID: <AS8P189MB1734648F99B6F4A547A04840FB439@AS8P189MB1734.EURP189.PROD.OUTLOOK.COM>
References: <4bff8903-3f3c-71bb-3df3-70d25ec0de20@restena.lu> <004e01d8c454$54a2c500$fde84f00$@gmail.com>
In-Reply-To: <004e01d8c454$54a2c500$fde84f00$@gmail.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_AS8P189MB1734648F99B6F4A547A04840FB439AS8P189MB1734EURP_"
MIME-Version: 1.0
X-Antivirus: no malware found
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/z-S-GzlWU5vRmZb47baHGvGsYog>
Subject: Re: [radext] BoF request for IETF 115
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: Fri, 09 Sep 2022 15:09:48 -0000

+1

<deleted statements about diameter>

Klaas


From: radext <radext-bounces@ietf.org> on behalf of josh.howlett@gmail.com <josh.howlett@gmail.com>
Date: Friday, 9 September 2022 at 15:59
To: 'Stefan Winter' <stefan.winter@restena.lu>, radext@ietf.org <radext@ietf.org>
Subject: Re: [radext] BoF request for IETF 115
> One thing we struggle with: PKI is really hard to do right; but if one
> doesn't need dynamic discovery as per RFC7585, TLS-PSK can be a drop-in
> replacement for RADIUS shared secrets. The work done here should stress
> that PSK ciphersuites are a perfectly viable option for most deployments
> and provide a low barrier of entry for upgrading to the better protocol.

+1

PSK is a credentialing model that is known to all RADIUS users. TLS-PSK is already supported by FreeRADIUS. This is surely the path of least resistance for operators.

Josh



_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext