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

Alexander Clouter <> Tue, 08 August 2023 22:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 75F12C151546 for <>; Tue, 8 Aug 2023 15:45:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b="WQezaxDe"; dkim=pass (2048-bit key) header.b="apjbW8hs"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xUgkynsv9Raj for <>; Tue, 8 Aug 2023 15:45:20 -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 24DEEC15153D for <>; Tue, 8 Aug 2023 15:45:19 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 2A34432007F9 for <>; Tue, 8 Aug 2023 18:45:19 -0400 (EDT)
Received: from imap46 ([]) by compute5.internal (MEProxy); Tue, 08 Aug 2023 18:45:19 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm2; t=1691534718; x=1691621118; bh=0X P7J3SCINj96Zi+39M6yuLzKxfz4e8Xro8ssZdFrRI=; b=WQezaxDevxmSAy2Mft UjJUEzhGC2qtPrhatgptTFjvM5oO4Zf6RmmNmtGt6l+13lOa8FnIdGAmlrTZYVV8 7/M8Uvk5s6GVt1GYFubrob2a6kypfTbEdk6gFqATJ1vrSsqkn+5t+vwjQ/N688Et 7sCL8e+S1Ml2r/U4OEXlcsf0tg1BjXH+QwvNzFKRBWhlUFYpG85NRD6AbwIPmo7q /EMsA6zlBScdt0ZSKtrST+9jYUkJUTn6K4TBeK3Ku8RePWl/SjPxpPLhrKEtYPSh QYq1sbIDbFriotK+o6uVCMaYw7HZqOUiSyVAhwQSvfkpftCBUsk0JGU+IucIyTyw bwYg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1691534718; x=1691621118; bh=0XP7J3SCINj96 Zi+39M6yuLzKxfz4e8Xro8ssZdFrRI=; b=apjbW8hsUKCW9lsxtLhf424Kc+a2K tdilctmRoDxORfHnYZSCnwlNHCSeQZycyhNf6Turwzmw0KoxkOmew1yeJyD/NNzE fD8QPzV6cw/zG02DtnGnDQIU1BRkIu3VvcF+DpfAAceURkfv10IzEpuOLkfn/dzX COCG3czlX5/IY0r9BOR9KWcSaQ10qRLkxuSVYB6bHRBK1PwaORU0IyP8C5kDo255 URLe4SvLvmfT65iqPz2Y+GV+1pJ4uWjZwoxfS3goN+/pSdFMcY0fb0n+Z2UJkTST fNmItwgLVS67oIw8RMU0ynk1YDeMHXydKuNMUfb16U+getVp6Sbvtt/Mw==
X-ME-Sender: <xms:fsXSZEnLtKe6-TQpnH03Qnjub3mbuyH2Vbw9hXKqqQYh5xOVZsKMDA> <xme:fsXSZD1A4NOK6Za3iCpy0S6Atmsyjvs8zWz99fr4QcsPLYrDMXVBU-b3hOiX5ALXc 9vvhwx0mIr4d6iP7w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrleefgddufecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdetlhgvgigrnhguvghrucevlhhouhhtvghrfdcuoegrlhgv gidoihgvthhfsegtohhrvghmvghmrdgtohhmqeenucggtffrrghtthgvrhhnpeegjeehgf eiueduuedufeethfeuvdeiffeggeduveekgedvhefhkeefiedtveekueenucffohhmrghi nhepihgvthhfrdhorhhgpdgrrhgthhhivhgvrdhorhhgpdhrhhhulhdrrggtrdhukhenuc evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhgvgido ihgvthhfsegtohhrvghmvghmrdgtohhm
X-ME-Proxy: <xmx:fsXSZCqAzsV4MBzBw1LjhPKYk2YD2TAMI7U5JVv7tT1aW4zyvARvqQ> <xmx:fsXSZAm6rZfFeHO5woNHXn0KA6o4xAHAapU4dXjfnfWF3W4-SlMDhg> <xmx:fsXSZC0QrDQJSyTjbSffmu_kjF3_XuMEtGFifBrYv-fvAjEdP7cXww> <xmx:fsXSZDD2bS3SwDRqcWAJeF3aooIqNGzFw3J8bQ3DVI7te_tUQ6BZrg>
Feedback-ID: ie3614602:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 693A72A20085; Tue, 8 Aug 2023 18:45:18 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.9.0-alpha0-624-g7714e4406d-fm-20230801.001-g7714e440
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <>
Date: Tue, 08 Aug 2023 23:44:58 +0100
From: Alexander Clouter <>
Content-Type: text/plain
Archived-At: <>
Subject: Re: [radext] Fwd: 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: Tue, 08 Aug 2023 22:45:24 -0000

On Wed, 26 Jul 2023, at 01:38, Alan DeKok wrote:
>   I've added substantial text on how to make existing uses of RADIUS more secure.  e.g. use EAP when proxying outside of your local network.
>   Thanks to Margaret and the WG for making concrete suggestions at the meeting in SF.
>> Begin forwarded message:
>> *From: *
>> *Subject: **New Version Notification for draft-dekok-radext-deprecating-radius-02.txt*
>> *Date: *July 25, 2023 at 5:27:20 PM PDT
>> *To: *"Alan DeKok" <>
>> A new version of I-D, draft-dekok-radext-deprecating-radius-02.txt
>> has been successfully submitted by Alan DeKok and posted to the
>> IETF repository.
>> Name: draft-dekok-radext-deprecating-radius
>> Revision: 02
>> Title: Deprecating RADIUS/UDP and RADIUS/TCP
>> Document date: 2023-07-25
>> Group: Individual Submission
>> Pages: 24
>> URL:
>> Status:
>> Html:
>> Htmlized:
>> Diff:

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"

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, ..."

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."

'week number' could be a suggestion but nothing prevents the use of some other datetime modulo math.

Supplement the math later with the stateless approach:

CUI = HASH(visited network data + user identifier + week number + key)

If we do this, we should highlight that 'week number' should probably have day offsets applied based on the visited network data and user identifier so that not every suddenly changes at the same time...though maybe this is actually desirable?


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

s/transport thos data/transport this data/
s/cleartext/clear-text/ <-- single inconsistent occurrence
s/Margart/Margaret/g <-- first Matthew[1], and now Margaret...who will be the next 'M'-victim