[radext] Re: New I-D: draft-seralathan-radext-persistent-devid-00

[Alexander Clouter <[e-mail]>]

Hello,

On Tue, 2 Jun 2026, at 07:02, Premanand Seralathan (pseralat) wrote:
>  1. As you noted, some NAS products don't support multiple Class 
> attributes. Class is already widely used for policy names, VLAN tags, 
> billing codes, etc. In those deployments there's no room for a device 
> ID without displacing existing usage.

Does any off the shelf vendor equipment support Persistent-Device-Id today?

Alan's point was where support would need to be added for Persistent-Device-Id by a vendor, that vendor would be better to fix their support for Class rather than put their efforts in introducing something new.

>  2. A "devid:" prefix is an ad-hoc convention -- every consuming system 
> (profiling engine, SIEM, compliance) would need to know to parse Class 
> values looking for the prefix. A defined attribute with IANA 
> registration gives interoperability without per-deployment conventions.

I am not sure leaning on the lack of middleware support is a reason to define something new that nothing supports is the correct course of action here. :)

Class can be whatever the site wishes it to be. Any 'contract' around its use can be determined there.

>  3. Class is opaque by specification - RFC 2865 says implementations 
> "SHOULD NOT attempt to interpret" it. Requiring systems to parse and 
> interpret Class content works against this.

It is unsporting to trim down the quote without including the rest of it :)

In the same sub-section, "information is site or application specific" and the "codification of the range of allowed usage of this field is outside the scope of this specification."

Instead, Persistent-Device-Id could be replaced with a proposal offering a format to use for Class instead.

Mechanisms that could be leant on:

 * to determine if a given Class value is for your application, use an encoding strategy that avoids confusion, such as appending a signature/checksum or use symmetric encryption where the plaintext starts with your prefix; you are not looking for confidentiality so maybe the key used could be public.

 * a persistent device ID must vary on every authentication but be linked back to a static ID server/application side; whether with a lookup table or include a nonce with the key or a RFC2289 inspired approach where you encode and send a counter N and the N times hashed value of the original UUID to make it reversible server side.

On that last point, I think over the wire static user/device IDs is something that can and should be avoided in new specifications, especially when RADIUS proxies over a federation of many administrative domains would have access to this ID. CUI accomplishes this by allowing mixing of a time component (ISO week number makes for a good choice) and visited site (ie. Operator-Name).

I am not convinced of the technical necessity of Persistent-Device-Id for the functioning of middleware systems providing policy enforcement and regulatory compliance. Those systems are typically deployed to coordinate with a central service and so only a per-session ID would be necessary.

My preference is to see less over-the-wire readable user/device tracking, as well as improved support for Class from vendors.

This draft may be pushing us in the opposite direction so my initial reflex would be to oppose it.

Cheers

Alex