IETF Logo Mail Archive

Re: [radext] CUI comments in "deprecating insecure transports"

Alan DeKok <aland@deployingradius.com> Wed, 26 July 2023 16: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 31DEAC151095 for <radext@ietfa.amsl.com>; Wed, 26 Jul 2023 09:00:35 -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 ApFlGtFB-F_o for <radext@ietfa.amsl.com>; Wed, 26 Jul 2023 09:00:30 -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 B702DC15107E for <radext@ietf.org>; Wed, 26 Jul 2023 09:00:30 -0700 (PDT)
Received: from smtpclient.apple (dhcp-8aa8.meeting.ietf.org [31.133.138.168]) by mail.networkradius.com (Postfix) with ESMTPSA id 9562F29F for <radext@ietf.org>; Wed, 26 Jul 2023 16:00:28 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
From: Alan DeKok <aland@deployingradius.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Date: Wed, 26 Jul 2023 09:00:26 -0700
References: <BC530A34-D348-44D0-886E-DB1ECF3A5010@deployingradius.com> <06c301d9bfc0$e07154d0$a153fe70$@gmail.com> <5F5C2E17-2061-4FFC-942A-9C4ED861EE5F@deployingradius.com> <PH0PR11MB5928721437690CD39DC3ECEFD200A@PH0PR11MB5928.namprd11.prod.outlook.com>
To: radext@ietf.org
In-Reply-To: <PH0PR11MB5928721437690CD39DC3ECEFD200A@PH0PR11MB5928.namprd11.prod.outlook.com>
Message-Id: <EFA3EFE1-6656-45F1-92CC-97A40242265A@deployingradius.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/8YiJ7gqjTWki1qpdrFxprnl8DFQ>
Subject: Re: [radext] CUI comments in "deprecating insecure transports"
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, 26 Jul 2023 16:00:35 -0000

On Jul 26, 2023, at 8:52 AM, Mark Grayson (mgrayson) <mgrayson=40cisco.com@dmarc.ietf.org> wrote:
> 
> Whereas there is text on binding-lifetime for CUI, does there need to be equivalent discussion around the use of user-name re-write and class attribute?

  I can't find the reference now, but IIRC there are recommendations against rewriting the User-Name.  At least for EAP, any User-Name rewriting means that the EAP Identity is not the same as the User-Name, and bad things happen.

  The Class attribute is an opaque token which is returned by the home server in an Access-Accept, and echoed back by the NAS in an Accounting-Request packet.  It has no meaning to anyone.

  I'm presuming that Class can be the same across multiple session, or even the same across multiple users.  Any system observing the Class attribute can make no inference about it, or about its contents.

  Alan DeKok.

v2.35.0 | Report a Bug | By Email | System Status