IETF Logo Mail Archive

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

Alan DeKok <aland@deployingradius.com> Wed, 26 July 2023 20:11 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 BC0C7C151AFE for <radext@ietfa.amsl.com>; Wed, 26 Jul 2023 13:11:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 VoEcGTtorNix for <radext@ietfa.amsl.com>; Wed, 26 Jul 2023 13:11:54 -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 49EA8C151AF9 for <radext@ietf.org>; Wed, 26 Jul 2023 13:11:53 -0700 (PDT)
Received: from smtpclient.apple (dhcp-8aa8.meeting.ietf.org [31.133.138.168]) by mail.networkradius.com (Postfix) with ESMTPSA id 03C12308; Wed, 26 Jul 2023 20:11:50 +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: <076101d9bfe6$7b34c720$719e5560$@gmail.com>
Date: Wed, 26 Jul 2023 13:11:47 -0700
Cc: Alexander Clouter <alex+ietf@coremem.com>, radext@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <6899551A-104C-45C8-B61B-5B917F56C3F5@deployingradius.com>
References: <BC530A34-D348-44D0-886E-DB1ECF3A5010@deployingradius.com> <06c301d9bfc0$e07154d0$a153fe70$@gmail.com> <5F5C2E17-2061-4FFC-942A-9C4ED861EE5F@deployingradius.com> <a0df55dd-01e3-44ee-bc18-183d7057390c@app.fastmail.com> <076101d9bfe6$7b34c720$719e5560$@gmail.com>
To: Josh Howlett <josh.howlett@gmail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/5GPH1YMR7Sej1rMdQdTUYfRTwho>
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 20:11:58 -0000

On Jul 26, 2023, at 10:27 AM, josh.howlett@gmail.com wrote:
> In particular, I don't think we need to prescribe what value the CUI should
> take. That is configuration, and the value of that attribute should be
> controlled by business agreement.

   The choice of value or values has privacy implications.  I think it's worth describing what's reasonable, and what's bad.

  If there are no restrictions on CUI values, then servers could respond with "14" for every user session.  Which makes CUI useless.

> I do think it would be valuable to describe the privacy implications of CUI
> and the algorithms that can be used to generate privacy-preserving CUI
> values.

  I will add some text on generating CUI values.

  The issue for the home server is the cost of tracking the relationship between CUI and user.  There are hopefully ways to decrease that cost.

  Alan DeKok.

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