Re: [radext] [OPSAWG] [Technical Errata Reported] RFC2865 (6915)

Alan DeKok <aland@deployingradius.com> Mon, 15 January 2024 14:20 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 CCDE9C14F616; Mon, 15 Jan 2024 06:20:23 -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=unavailable 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 DW26b5_-Mxom; Mon, 15 Jan 2024 06:20:19 -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) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8353C14F60E; Mon, 15 Jan 2024 06:20:17 -0800 (PST)
Received: from smtpclient.apple (unknown [75.98.136.130]) by mail.networkradius.com (Postfix) with ESMTPSA id 10E6F308; Mon, 15 Jan 2024 14:20:14 +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: <LV8PR11MB8536363CB78E015E98EA4D64B56C2@LV8PR11MB8536.namprd11.prod.outlook.com>
Date: Mon, 15 Jan 2024 09:20:13 -0500
Cc: RFC Errata System <rfc-editor@rfc-editor.org>, "warren@kumari.net" <warren@kumari.net>, "opsawg@ietf.org" <opsawg@ietf.org>, radext@ietf.org, Paul Wouters <paul.wouters@aiven.io>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C1D6B782-7C6B-4D16-A5D8-3344673ED026@deployingradius.com>
References: <20220402172325.C4C1D1E65D@rfcpa.amsl.com> <LV8PR11MB8536363CB78E015E98EA4D64B56C2@LV8PR11MB8536.namprd11.prod.outlook.com>
To: "Rob Wilton (rwilton)" <rwilton=40cisco.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/KNJvmo5DQikoVfn4o7uskj8h030>
Subject: Re: [radext] [OPSAWG] [Technical Errata Reported] RFC2865 (6915)
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: Mon, 15 Jan 2024 14:20:23 -0000

On Jan 15, 2024, at 7:14 AM, Rob Wilton (rwilton) <rwilton=40cisco.com@dmarc.ietf.org> wrote:
> Hi RFC 2865 authors, OPSAWG, 

  I've CC'd RADEXT, as that WG is currently active.  I've also removed the 2865 authors email addresses.  I believe those became inactive decades ago.

> I think that this errata may be valid, but given the age of the RADIUS protocol, and the fact that I'm not familiar with it and this is a change to the protocol, then I'm somewhat concerned with verifying this errata, and hence I propose to move it to "Held for Document Update".
> 
> Does anyone have any comments on this proposed resolution?

  I think "hold for document update" is best.

  We've covered these issues in RFC 8044, which defines data types for RADIUS (octets, printable text, IPs, integers, etc).  There are no data types which permit zero-length values.

  The variable-length data types defined in Section 3.4 (printable strings) and 3.5 (binary data) both say:

      Strings of length zero (0) MUST NOT be sent; omit the entire attribute instead.

 There is no _general_ prohibition on attributes having zero length values.  But it is not currently permitted to define an attribute which has a zero-length value.

  As such, "hold for document update" is the reasonable conclusion.

   Alan DeKok.