Re: [radext] draft-ietf-opsawg-ucl-acl: User Access Control Group ID RADIUS Attribute

Alan DeKok <> Tue, 26 September 2023 12:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1A451C151991; Tue, 26 Sep 2023 05:37:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Status: No, score=-1.906 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_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Udn3ypfsgzGM; Tue, 26 Sep 2023 05:37:26 -0700 (PDT)
Received: from ( []) (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 (Postfix) with ESMTPS id BCED2C151990; Tue, 26 Sep 2023 05:37:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id 2200E24B; Tue, 26 Sep 2023 12:37:20 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.\))
From: Alan DeKok <>
In-Reply-To: <>
Date: Tue, 26 Sep 2023 08:37:19 -0400
Cc: "" <>, opsawg <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: "<>" <>
X-Mailer: Apple Mail (2.3696.
Archived-At: <>
Subject: Re: [radext] draft-ietf-opsawg-ucl-acl: User Access Control Group ID RADIUS Attribute
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Sep 2023 12:37:30 -0000

On Sep 26, 2023, at 8:00 AM, wrote:
> FWIW, the document specifies the following new RADIUS attribute:
> Your review of that part of the spec is appreciated.

  My $0.02 as someone jumping on these kinds of things.  Mostly nits.

> The value fields of the Attribute are encoded in clear and not encrypted as, for example, Tunnel- Password Attribute [RFC2868].

  This text isn't necessary and can be omitted.

> The User-Access-Group-ID Attribute MAY appear in a RADIUS Accounting- Request packet.

  What is the interpretation of the attribute there?

  i.e. in Access-Request, it's a hint / request.  In Accounting-Request, it means... ?

  I think the requirement here is that if the User-Access-Group-ID attribute appears in an Accounting-Request packets, it MUST have the same value as given in the Access-Accept.

  That is, the value in Accounting-Request is an acknowledgment by the NAS that it has received the attribute in the Access-Request, and is enforcing that policy.

> The User-Access-Group-ID Attribute is structured as follows:

  I would suggest following the attribute definition format suggested in 8044:

  It's only a minor change from what is there now.  Add a "data type" field, and remove the "extended type" field.

> The User-Access-Group-ID Attribute is associated with the following identifier: 241.TBA1.

  This text isn't necessary and can be omitted.  Just leave a "TBD" in the Type field as recommended by 8044.

> The following table provides a guide as what type of RADIUS packets that may contain User-Access-Group-ID Attribute, and in what quantity.

  It's not necessary to list the attribute number here.  Just omit that column.  Identifying the attribute by name is enough

  I'll also note that this table allows for multiple copies of the attribute to exist (i.e. "0+").  The rest of the text in the section doesn't mention that more than one attribute are allowed.  The text should be updated to explain what that means.

  Perhaps something like "If more than one copy of the User-Access-Group-ID attribute appears in an Access-Accept packet, it means that the user is a member of all of those groups."

  I haven't taken a detailed look at the rest of the document, but this text in Section 4.1 jumped out at me:

> Step 3: The authentication request is then relayed to the AAA server using a protocol such as RADIUS [RFC2865]. It is assumed that the AAA server has been appropriately configured to store user credentials, e.g., user name, password, group information and other user attributes.

  It may be good to give an example packet, but that may also be too restrictive.  What should be discussed is what format is used by the credentials.  i.e. User-Password or CHAP-Password.  Given other discussions and research in RADEXT, it would be good to suggest here that User-Password is strongly preferred to the alternatives.

  For anyone interested in the underlying reasons, there is a long discussion of this topic in

  Alan DeKok.