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

["Premanand Seralathan (pseralat)" <[e-mail]>]

Hi Alan,

Thanks for the review. Inline below.

It took a while of reading the document before it was clear exactly what the mechanism was, and how it worked. It would be useful to have a short overview at the start of the document.

Agreed. Will add a mechanism overview in the Introduction for -01.

this proposal has similar behavior to the Class attribute, but is persistent across multiple connections. It would be good to mention this.

Good point — same echo-back pattern, but semantically defined and persistent across sessions/MAC changes. Will add an explicit comparison in Section 10.

it's not clear from the document how the NAS persistently identifies the device across multiple connections.

e.g. Section 9.4 talks about the RADIUS client caching Persistent-Device-Id. How is this done?

The NAS doesn't need to correlate across connections — the server does. On reconnect with a new MAC, the same certificate yields the same UUID server-side. The NAS caches Persistent-Device-Id for the current session, echoes it in accounting, and shares it with integrated platforms (profiling engines, location services) so they can identify the endpoint across MAC changes. Will clarify this in -01.

Do the NASes have to change? If so, what changes need to be made? If not, why not?

No NAS changes required for the core mechanism. The NAS receives it in Access-Accept and echoes in accounting — standard attribute handling. Unrecognized attributes are silently ignored per RFC 2865 Section 5. NAS-side use of the identifier (local correlation, UI display) is optional. Will add a deployment considerations subsection.

it would be good if it was useful for EAP methods which didn't use TLS. Perhaps one option would be to derive the Persistent-Device-Id from the MSK / EMSK on an initial connection.

Interesting idea. It would give per-NAS consistency but not cross-NAS and would change with credential changes. Worth exploring as a future extension — will add a discussion in Future Work for -01 and keep the current scope to certificate-based methods.

Will address all of these in -01.


Thanks again.

Prem

On 5/17/26, 9:05 AM, "Alan DeKok" <alan.dekok=[e-mail]> wrote:

On Apr 30, 2026, at 3:13 PM, Premanand Seralathan (pseralat) <pseralat=[e-mail]<mailto:[e-mail]>> wrote:
> We have submitted a new individual Internet-Draft to the RADEXT working group:
> RADIUS Attribute for Persistent Device Identity in MAC-Randomized Environments https://datatracker.ietf.org/doc/draft-seralathan-radext-persistent-devid/
>
> Modern operating systems now randomize MAC addresses by default, breaking RADIUS workflows that use Calling-Station-Id as a stable device identifier. This draft defines a new RADIUS attribute, Persistent-Device-Id, that carries a stable identifier derived from the device's X.509 certificate used during certificate-based EAP authentication (EAP-TLS, TEAP, EAP-TTLS). The attribute is returned in Access-Accept and propagated through Accounting messages, enabling session correlation, device profiling, and policy enforcement despite MAC changes.
>
> We welcome review and feedback from the working group.

  Thanks for the draft.  I have some comments, mostly nits:

* It took a while of reading the document before it was clear exactly what the mechanism was, and how it worked.  It would be useful to have a short overview at the start of the document.  That overview could give a high level summary of how it works, without getting into detail.  That then provides motivation and framework for longer explanations later in the document.


* this proposal has similar behavior to the Class attribute, but is persistent across multiple connections.  It would be good to mention this.  That will help readers understand how it relates to existing practices.


* it's not clear from the document how the NAS persistently identifies the device across multiple connections.  Is there an external reference which can be used to describe how this is done?

  e.g. Section 9.4 talks about the RADIUS client caching Persistent-Device-Id.  How is this done?


* if this proposal doesn't require changes to RADIUS clients, then it's much easier to implement.  The RADIUS servers have to be updated, and that's about it.


* if this proposal requires (or suggests) changes to RADIUS clients, then it will take a long time for it to be deployed.  This isn't an argument against the proposal, it's just an unfortunate reality.

  Suggestion: make this clearer in the document.  Do the NASes have to change?  If so, what changes need to be made?  If not, why not?


* it would be good if it was useful for EAP methods which didn't use TLS.  It's not clear how to do that, though.

  Perhaps one option would be to derive the Persistent-Device-Id from the MSK / EMSK on an initial connection.  So long as the user reconnect to the same NAS, the NAS can cache it (presuming that's possible), and send it on subsequent authentication attempts.

  That process doesn't create a value for Persistent-Device-Id which is constant across multiple NASes or visited locations.  But it at least provides a consistent value for a particular location.

  Alan DeKok.