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

[Alexander Clouter <[e-mail]>]

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: *[e-mail]
>> *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" <[e-mail]>
>> 
>> 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:      https://www.ietf.org/archive/id/draft-dekok-radext-deprecating-radius-02.txt
>> Status:   https://datatracker.ietf.org/doc/draft-dekok-radext-deprecating-radius/
>> Html:     https://www.ietf.org/archive/id/draft-dekok-radext-deprecating-radius-02.html
>> Htmlized: https://datatracker.ietf.org/doc/html/draft-dekok-radext-deprecating-radius
>> Diff:     https://author-tools.ietf.org/iddiff?url2=draft-dekok-radext-deprecating-radius-02

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?

Misc:

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

s/possbile/possible/g
s/defintions/definitions/g
s/Messge/Message/g
s/attacket/attacker/g
s/Acccess/Access/g
s/transport thos data/transport this data/
s/obfsucated/obfuscated/g
s/identies/identities/g
s/aobut/about/g
s/organizstion/organization/g
s/mutliple/multiple/g
s/managung/managing/g
s/preceeding/preceding/g
s/ssesion/session/g
s/tunneled/tunnelled/g
s/ddifferent/different/g
s/cleartext/clear-text/ <-- single inconsistent occurrence
s/implementer/implementor/
s/Margart/Margaret/g <-- first Matthew[1], and now Margaret...who will be the next 'M'-victim

Cheers

[1] https://mailarchive.ietf.org/arch/msg/radext/Gv_z9gALm4ML3orJTAGALq_kPpM/
[2] https://web.archive.org/web/20230512090344/https://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf