IETF Logo Mail Archive

Re: [radext] Review of draft-ietf-radext-radius-v11-03

Alan DeKok <aland@deployingradius.com> Thu, 07 December 2023 20:00 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 88884C2395F2 for <radext@ietfa.amsl.com>; Thu, 7 Dec 2023 12:00:26 -0800 (PST)
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 oYLL1x5FKLwS for <radext@ietfa.amsl.com>; Thu, 7 Dec 2023 12:00:22 -0800 (PST)
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 813D3C490E9E for <radext@ietf.org>; Thu, 7 Dec 2023 12:00:05 -0800 (PST)
Received: from smtpclient.apple (unknown [75.98.136.130]) by mail.networkradius.com (Postfix) with ESMTPSA id 471F54EF; Thu, 7 Dec 2023 20:00:03 +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: <9a827a18-72a1-4d82-a75b-09630715f5fd@dfn.de>
Date: Thu, 07 Dec 2023 15:00:01 -0500
Cc: radext@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <DA586ECE-7464-41C2-A4FB-18318D806F8B@deployingradius.com>
References: <07d1f63a-b31e-4828-984b-441cb11a0660@dfn.de> <900EEA30-BD14-486A-8B67-5DE32A4958C9@deployingradius.com> <9a827a18-72a1-4d82-a75b-09630715f5fd@dfn.de>
To: Jan-Frederik Rieckers <rieckers@dfn.de>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/jH-FMklFr5-9GDvkf0ewFdSa9w0>
Subject: Re: [radext] Review of draft-ietf-radext-radius-v11-03
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: Thu, 07 Dec 2023 20:00:26 -0000

> On Dec 7, 2023, at 2:46 PM, Jan-Frederik Rieckers <rieckers@dfn.de> wrote:
> 
> One change that may not be what we wanted:
> 
> In the introduction:
> 
> "Systems which implement this standard are mandated to fall back to historic RADIUS/TLS if no ALPN signaling is performed."
> 
> Even though this is not BCP14 keyword, I think it is not what we want to say.
> If I understood it correctly then it should be perfectly fine for a software to only implement RADIUS/1.1. This is the only way that we can truly achieve the goal of getting rid of MD5.

  Yes, that was added in the recent set of changes, and should likely be:

Systems which implement this standard can fall back to historic RADIUS/TLS if no ALPN signaling is performed, and the local configuration permits such fallback.

  Alan DeKok.

v2.23.0 | Report a Bug | By Email