Re: [radext] New Version Notification for draft-dekok-radext-deprecating-radius-02.txt

Alan DeKok <> Wed, 09 August 2023 13:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 87D2BC1516E0 for <>; Wed, 9 Aug 2023 06:41:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.909
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kWdL3ReWNzwM for <>; Wed, 9 Aug 2023 06:41: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 9A208C151532 for <>; Wed, 9 Aug 2023 06:41:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id 9C5A6380; Wed, 9 Aug 2023 13:41:22 +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: Wed, 09 Aug 2023 09:41:20 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Alexander Clouter <>
X-Mailer: Apple Mail (2.3696.
Archived-At: <>
Subject: Re: [radext] New Version Notification for draft-dekok-radext-deprecating-radius-02.txt
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: Wed, 09 Aug 2023 13:41:29 -0000

On Aug 8, 2023, at 6:44 PM, Alexander Clouter <> wrote:
> Some nitpicking, but otherwise everything looks great, especially the CUI section:


> Section 1:
> * 'corporate executives' I think should be replaced with 'an individual' which is more pointed and resonates more to me the privacy worries here.
> * "The negative implications for security and individual safety are obvious" may read better dropping 'obvious' to become  "These implications do not bode well for security and individual safety"
> * "AAA servers can also minimize the impact of such attacks using TLS connections with short lifetimes, though that practice can cause spurious errors in a proxy environment.", if you want to reference a source on the why there is [2] but I think we can do better here to suggest ways of avoiding interrupting by rekey'ing an existing connection (SSL_key_update) or failing that to open a second connection and drain the original connection. So maybe instead "AAA servers should minimize the impact of such attacks by using a byte (recommended) or time based limit before replacing the session keys though a process of either rekeying the existing connection, opening a new connection and draining the original or, at risk of causing spurious errors in a proxy environment, just to immediately close the connection"

  I'll update that.

> Section 7:
> A lot of this applies to even TLS connections, PII stripping whilst proxying and even hiding from the visited site is important.
> Maybe amend "Implementors and administrators need to be aware of all of these issues, ..." to "Implementors and administrators need to be aware of all of these issues, which also impact proxy and roaming environments, ..."

  I'll update the section to be more generic about "Increasing the Security of RADIUS Transports", and add some text about TLS.

> Section 7.1.1:
> Do we want to describe a stateless method too?
> "In general, the simplest way to track CUIs long term is to associate the CUI to user identity in some kind of stateful database or alternatively stateless by using the week number."

  It has to be invertible, though.  i.e. given a particular CUI, the local network has to be able to associate that with a user.  It's not productive to require brute-force inversion.

  I'll add some text clarifying this, and suggesting a stateless approach based on invertible encryption.

> Lastly, ran this through aspell and found these, there may be others:

  Fixed, thanks.

  Alan DeKok.