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

Alan DeKok <aland@deployingradius.com> Wed, 26 July 2023 17:10 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 D7E02C16B5BC for <radext@ietfa.amsl.com>; Wed, 26 Jul 2023 10:10:09 -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 VHlKs6v0aomi for <radext@ietfa.amsl.com>; Wed, 26 Jul 2023 10:10:04 -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 3FF2BC17CE81 for <radext@ietf.org>; Wed, 26 Jul 2023 10:10:03 -0700 (PDT)
Received: from smtpclient.apple (dhcp-8aa8.meeting.ietf.org [31.133.138.168]) by mail.networkradius.com (Postfix) with ESMTPSA id 6DDE2308; Wed, 26 Jul 2023 17:10:01 +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: <0D326753-2295-4FA9-B14E-06FE55C9AFB4@deployingradius.com>
Date: Wed, 26 Jul 2023 10:09:58 -0700
Cc: Josh Howlett <josh.howlett@gmail.com>, radext@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <61776FFB-7C8B-4234-8B1F-C4F33150106D@deployingradius.com>
References: <06c301d9bfc0$e07154d0$a153fe70$@gmail.com> <5390176A-A8D1-40E5-AA3B-9008328650F9@gmail.com> <0D326753-2295-4FA9-B14E-06FE55C9AFB4@deployingradius.com>
To: Margaret Cullen <mrcullen42@gmail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/B_s-QFQHGOjjQwBarY-k1J0vSK4>
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 17:10:09 -0000

  Some suggested text on CUI:

Where the Chargeable-User-Identifer (CUI) {{?RFC4372}} is used, it Chargeable-User-Identifer SHOULD be unique per session.  This pracrice will help to maximize user privacy, as it will be more difficult to track users across multiple sessions.  Due to additional constraints which we will discuss below, we cannot require that the CUI change for ecery session.

What we can do is require that the home server MUST provide a unique CUI for each combination of user and visited network.  That is, if the same user visits multiple networks, the home server MUST provide different CUIs to each visited network for that user.  The CUI MAY be the same across multiple sessions for that user on one particular network.  The CUI MAY be the same for multiple devices used by that user on one particular network.

We note that the MAC address is likely the same across multiple user sessions on one network.  Therefore changing the CUI offers little additional benefit, as the user can still be tracked by the unchanging MAC address.  Never the less, we believe that having a unique CUI per session can be useful, because there is ongoing work on increasing user privacy by allowing more MAC address randomization.  If we were to recommend that the CUI remain constant across multiple sessions, that would in turn negate much of the effort being put into MAC address randomization.

One reason to have a constant CUI value for a user (or user devices) on one network is that network access providers may need to enforce limits on simultaneous logins.  Network providers may also need to correlate user behavior across mutliple sessions in order to track and prevent abuse.  Both of these requirements are impossible if the CUI changes for every user session.

The result is that there is a trade-off between user privacy and the needs of the local network.  While perfect user privacy is an admirable goal, perfect user privacy may also allow anonymous users to abuse the visited network.  The network would then likely simply refuse to provide network access.  Users may therefore have to accept some limitations on privacy, in order to obtain network access.