]> Cisco Systems

170 West Tasman Drive San Jose 95134 US pseralat@cisco.com

Cisco Systems

Cessna Business Park, Kadubeesanahalli ORR Bangalore 560103 IN lmukund@cisco.com

Hewlett Packard Enterprise (HPE)

6280 America Center Dr San Jose 95002 US antoni.milton@hpe.com

general RADEXT Working Group Internet-Draft RADIUS Device-Id This document defines a Chargeable-Device-Identity (CDI) -- a privacy- preserving, rotating device correlator carried in existing RADIUS Class attributes -- that enables Network Access Control (NAC) systems to maintain device session correlation across Media Access Control (MAC) address changes. Modern operating systems randomize MAC addresses by default, disrupting RADIUS-based authentication, authorization, and accounting workflows that rely on the Calling-Station-Id attribute as a persistent device identifier. CDI is modeled after the Chargeable-User-Identity (CUI) defined in RFC 4372, providing an analogous device-level correlator with explicit privacy controls: epoch-based rotation limits long-term tracking, HMAC construction prevents identifier reversal by intermediate systems, and transport within the Class attribute ensures immediate deployability on existing infrastructure. This document additionally defines a new RADIUS attribute, Persistent-Device-Id, for deployments that require explicit device identity semantics beyond what the opaque Class attribute can provide. The Class-based CDI mechanism is the RECOMMENDED approach for immediate deployment; the dedicated attribute provides a migration path for future interoperability.

Introduction The RADIUS protocol uses the Calling-Station-Id attribute (Type 31) to carry the Media Access Control (MAC) address of the connecting device. This attribute serves as the de facto device identifier in Network Access Control (NAC) deployments, used for device identification, profiling, policy assignment, license counting, and regulatory audit trails. MAC address randomization as a privacy feature was first introduced during active scanning in iOS 8 (2014). Since 2020, major operating system vendors have adopted randomized MAC addresses by default for network association. provides a comprehensive taxonomy of MAC address selection policies and documents current OS practices: per-network randomization (PNGM), per-connection randomization (PSGM), periodic rotation (PPGM), and scan-time randomization are now widely deployed across Android , iOS , Windows , and Linux. Current versions of all major mobile operating systems transmit randomized MAC addresses by default when connecting to wireless networks, disrupting network services that depend on the MAC address as a stable device identifier. The impact on RADIUS-based NAC systems is significant:

• A single physical device may present different Calling-Station-Id values across connections, creating multiple unrelated endpoint records.
• Device profiling data becomes fragmented across records keyed by different MAC addresses.
• RADIUS Accounting records cannot be correlated across sessions for the same device.
• License management systems produce inflated device counts.
• Regulatory audit trails required by frameworks such as and lose device-level continuity.

IEEE 802.11bh-2024 addresses session continuity at Layer 2 but does not extend to the AAA layer. This document addresses the gap by defining a RADIUS attribute that carries a persistent device identifier above the MAC address layer.

Mechanism Overview The mechanism works as follows:

1. During device enrollment (via MDM or self-service portal), a UUID (version 4, per ) is generated and embedded in the device's X.509 certificate, in the Subject Alternative Name (SAN) URI field using the urn:uuid: namespace.
2. When the device connects to the network, it authenticates using a certificate-based EAP method (EAP-TLS, EAP-TTLS, or TEAP). The device presents its certificate inside the encrypted EAP tunnel.
3. The RADIUS server extracts the UUID from the certificate's SAN URI field and includes it as the Persistent-Device-Id attribute in the Access-Accept message returned to the Network Access Device (NAD).
4. The NAD caches the Persistent-Device-Id for the duration of the session and includes it in all subsequent Accounting-Request messages. The NAD also shares the identifier with integrated platforms (profiling engines, location services, SIEM, compliance systems) for endpoint correlation.
5. When the device reconnects with a different randomized MAC address, it presents the same certificate. The RADIUS server extracts the same UUID and returns the same Persistent-Device-Id. All sessions are correlated by the server regardless of MAC address changes.

The NAD does not need to correlate the device across connections -- the correlation happens entirely at the RADIUS server based on the certificate. The NAD's role is limited to per-session caching and forwarding of the identifier, analogous to the handling of the Class attribute but with persistence across sessions.

Privacy Model This mechanism applies exclusively to devices that have voluntarily enrolled and present a certificate during authentication. The device owner (or their organization) has explicitly consented to identification by completing the enrollment process and provisioning a certificate containing a persistent identifier. The following device categories are completely unaffected by this specification:

• Guest devices using open or captive portal access
• Unenrolled BYOD devices without certificates
• Devices authenticating via MAC Authentication Bypass (MAB)
• Any device that does not present a certificate during EAP authentication

These devices continue to benefit fully from MAC address randomization privacy protections. No passive tracking, fingerprinting, or correlation is introduced for unenrolled devices. This is enterprise device management, not surveillance. The mechanism is analogous to an employee voluntarily enrolling a device with their organization's MDM system -- identification follows from a deliberate enrollment action, not from passive network observation. The Persistent-Device-Id is visible only within the administrative domain that provisioned the certificate and MUST NOT leak to external networks (see ).

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology Persistent-Device-Id (PDID):

• A unique identifier carried within the device's certificate, typically provisioned during device enrollment by a Mobile Device Management (MDM) system or the NAC server's own registration process. The RADIUS server extracts this identifier during certificate-based authentication and includes i t in the RADIUS Access-Accept to provide a persistent device identity that survives MAC address changes.

RADIUS Client:

• A network device (switch, wireless controller, VPN concentrator) that acts as a RADIUS authenticator per .

RADIUS Server:

• A server that processes RADIUS Access-Request messages, performs authentication and authorization, and returns Access-Accept or Access-Reject messages. In this context, the RADIUS server is also the entity that assigns and manages Persistent-Device-Id values.

MAC Address Randomization:

• The practice of replacing a device's hardware-assigned MAC address with a locally-administered, randomly-generated alternative, as described in .

Locally-Administered MAC Address:

• A MAC address with the locally-administered bit (bit 1 of the first octet) set to 1. Unlike globally-assigned (burned-in) MAC addresses, a locally-administered address has local significance only, can be assigned by any entity, and is not guaranteed to be globally unique. Randomized MAC addresses use locally-administered addresses.

Identity Correlation Source:

• A piece of information available during the RADIUS exchange that can be used to associate a new MAC address with a previously assigned Persistent-Device-Id. Examples include certificate Common Name (from certificate-based EAP methods such as EAP-TLS, EAP-TTLS, or TEAP), MDM device identifier, and IEEE 802.1X authenticated username.

Problem Statement

Calling-Station-Id as Device Identifier Section 5.31 of defines the Calling-Station-Id attribute as carrying "the phone number" of the user. In practice, for IEEE 802 networks, this attribute carries the MAC address of the connecting device, formatted as a string of hex digits (e.g., "AA-BB-CC-DD-EE-FF"). NAC systems use Calling-Station-Id as the primary key for:

1. Endpoint record lookup and creation
2. Device profiling and classification
3. Authorization policy evaluation
4. RADIUS Accounting session correlation
5. License and compliance tracking

Impact of MAC Address Randomization When a device randomizes its MAC address, the Calling-Station-Id value changes. From the RADIUS server's perspective, each randomized MAC appears to be a new, unrelated device. This causes:

1. Endpoint Record Proliferation: A single device generates N endpoint records for N different MAC addresses, fragmenting device state.
2. Profiling Data Loss: Attributes collected from network probes (DHCP, HTTP, SNMP, DNS) are stored against a MAC-keyed record. When the MAC changes, the accumulated profiling data is inaccessible for the new session.
3. Accounting Discontinuity: Accounting Start and Stop records for the same device carry different Calling-Station-Id values, preventing session correlation.
4. License Count Inflation: License management based on unique Calling-Station-Id values produces artificially high counts.
5. Compliance Gaps: Regulatory frameworks requiring device-level audit trails (HIPAA , FISMA , PCI-DSS ) cannot be satisfied when device identity is ephemeral.

Limitations of Existing Mechanisms No existing standard RADIUS attribute provides a persistent device identifier independent of the MAC address. The following existing attributes are insufficient: Calling-Station-Id (Type 31):

• Carries the MAC address, which is now unstable.

User-Name (Type 1):

• Identifies the user, not the device. A user may have multiple devices, and conversely, a single device may be shared by several individuals.

NAS-Port-Id (Type 87):

• Identifies the network port, not the device.

Class (Type 25):

• An opaque value sent by the RADIUS server in Access-Accept and echoed by the NAS in subsequent Accounting-Request messages . The Class attribute is server-generated per session for accounting grouping and policy context. It is opaque to the NAS, has no defined structure for device identification, and is not guaranteed to persist across sessions or MAC address changes. It cannot serve as a stable device identifier.

Chargeable-User-Identity (CUI) :

• Provides a stable user-level identity for inter-domain roaming and billing. While CUI carries an opaque identifier, it is semantically a user identity, not a device identity. A single user may have multiple devices, and a shared device may serve multiple users. CUI cannot distinguish between devices belonging to the same user. Furthermore, RFC 4372 specifies that the CUI binding lifetime should be temporary (e.g., one billing period), whereas persistent device identification requires a stable identity across the device's entire enrollment lifecycle. Overloading CUI to carry device identity would violate its defined semantics and conflict with existing CUI deployments used for roaming billing.

Certificate-based EAP fields (EAP-TLS, EAP-TTLS, TEAP):

• Available only for certificate-based authentication methods, not for MAC Authentication Bypass (MAB) or credential-based EAP methods.

The absence of a standard attribute has led to vendor-specific workarounds that are mutually incompatible, as described in the following section.

Current Vendor-Specific Approaches In the absence of a standard RADIUS attribute for persistent device identity, network access control vendors have independently implemented proprietary solutions to address the MAC address randomization problem. These approaches differ in their choice of RADIUS attribute, encoding format, and client-side parsing requirements. Some implementations repurpose existing standard RADIUS attributes such as User-Name (Type 1) to carry device identifiers in the Access-Accept message. This approach violates the semantic definition of User-Name in RFC 2865, which specifies it as "the name of the user to be authenticated." Overloading User-Name with device identity creates ambiguity for downstream consumers of RADIUS data, including accounting systems, billing platforms, and compliance audit tools that expect User-Name to contain an actual user identity. It also requires RADIUS clients (NAS devices) to implement vendor-specific logic to distinguish between a true user name and an encoded device identifier. Other implementations use Vendor-Specific Attributes (Type 26) to carry the persistent device identifier within a vendor-allocated attribute space. While VSAs are a legitimate RADIUS extension mechanism, they are inherently non-interoperable: a RADIUS client from one vendor cannot interpret the VSA encoding of another vendor's RADIUS server. In multi-vendor enterprise deployments -- where network access devices, RADIUS servers, and policy engines may come from different manufacturers -- VSA-based approaches result in fragmented device identity that cannot be correlated across the infrastructure. Both approaches share a common deficiency: they require modifications to RADIUS client firmware for each vendor's proprietary encoding, creating a fragmented ecosystem where persistent device identity is available only within single-vendor deployments. Enterprise networks that use equipment from multiple vendors -- a common scenario in large organizations -- cannot achieve onsistent device identity across their infrastructure. A standard RADIUS attribute for persistent device identity, as defined in this document, would eliminate this fragmentation by providing a single, interoperable mechanism that all vendors can implement without proprietary extensions or semantic overloading of existing attributes.

Persistent-Device-Id Attribute

Attribute Format The Persistent-Device-Id attribute is a standard RADIUS attribute with the following format:

Encoding Persistent-Device-Id Attribute

Type

• • TBD1 (to be assigned by IANA)

Length

• • Variable (2 octets for Type and Length, plus the length of the string value)

Data Type

• • String

Value

• A string containing the persistent device identifier extracted from the device's certificate. Implementations SHOULD use UUID version 4 in the standard 36-character string representation (e.g., "f47ac10b-58cc-4372-a567-0e02b2c3d479"). The identifier is provisioned into the certificate during device enrollment and is not generated by the RADIUS server.

String Representation When UUID version 4 is used as the Persistent-Device-Id, it MUST use the standard string format defined in Section 4 of :

• xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx

where "x" is a lowercase hexadecimal digit and "y" is one of 8, 9, a, or b. The "4" indicates UUID version 4. This string representation is carried directly in the RADIUS attribute value field. Example:

• Persistent-Device-Id = "f47ac10b-58cc-4372-a567-0e02b2c3d479"

Attribute Properties The following table summarizes the properties of the Persistent-Device-Id attribute:

Attribute Name	Persistent-Device-Id
Attribute Type	TBD1
Value Type	String
Length	Variable
Allowed in	Access-Accept, Accounting-Request, Accounting-Response, CoA-Request
Forbidden in	Access-Request, Access-Reject, Access-Challenge
Presence	OPTIONAL
Maximum Occurrences	1
Encrypted	Yes (as per RADIUS shared secret)

Security and Deployment Model This section defines the security and deployment model for the Persistent-Device-Id specification. A clear understanding of the actors, threats addressed, explicit non-goals, and security invariants is essential to evaluate the privacy and security properties of this mechanism.

Actors The following actors are relevant to this specification:

1. Device Owner/User: The individual who owns or operates the device. In enterprise environments, this may be an employee using a corporate-issued or BYOD device. The device owner has a legitimate expectation of privacy from passive observers and external networks, while accepting that their employer's network may identify their device for security and compliance purposes.
2. Enterprise Administrator: The network operator responsible for device enrollment, certificate provisioning, NAC policy enforcement, and compliance auditing. The administrator has a legitimate need to persistently identify enrolled devices for security operations.
3. Passive Observer: An entity that can observe Layer 2 frames on the wireless medium or local network segment. This includes any device within radio range of a wireless network. The passive observer is the primary adversary that MAC address randomization is designed to defeat.
4. Rogue Access Point / Man-in-the-Middle: An attacker operating an unauthorized access point to intercept or manipulate network traffic. This actor can observe Layer 2 frames and may attempt to intercept authentication exchanges.
5. External Network: A network operator outside the device's home administrative domain. External networks should not be able to learn the Persistent-Device-Id or correlate device activity across domains.

Threats Addressed MAC address randomization was introduced to mitigate the following threats. This specification is designed to preserve these protections:

1. Passive Device Tracking: A passive observer monitors Layer 2 frame headers to track a device's location and movement patterns using its MAC address. MAC randomization defeats this by changing the MAC address. The Persistent-Device-Id does NOT reintroduce this threat because it is never present in any Layer 2 frame. The identifier value originates from the device certificate exchanged within the encrypted EAP tunnel, and the Persistent-Device-Id RADIUS attribute is carried only in RADIUS messages between the server and authenticator, protected by RADIUS/TLS .
2. Cross-Network Correlation: An adversary correlates a device's activity across multiple networks using a stable identifier. MAC randomization limits this by using different MAC addresses on different networks. The Persistent-Device-Id does NOT enable cross-network correlation because: (i) the identifier is scoped to the administrative domain that provisioned the certificate, (ii) external networks never see the identifier, and (iii) the RADIUS server MUST NOT share it with external entities.
3. Device Fingerprinting: An attacker combines observable characteristics (probe requests, timing patterns, supported capabilities) to fingerprint a device. The Persistent-Device-Id does not contribute to fingerprinting because it is not observable by any entity other than the RADIUS server and the authenticated NAS.

Explicit Non-Goals This specification explicitly does NOT:

1. Enable tracking of unenrolled devices. Devices without certificates (guest, unauthenticated, MAB-only) are completely unaffected by this specification and continue to benefit fully from MAC randomization privacy.
2. Provide a mechanism for cross-network tracking. The Persistent-Device-Id is administratively scoped and MUST NOT be shared across administrative domains.
3. Enable surveillance or monitoring of user behavior. The identifier correlates a device for NAC, compliance, and licensing purposes only. It does not reveal user activity, browsing history, or application usage.
4. Undermine the user's choice to use MAC randomization. The MAC address continues to randomize at Layer 2 as the device vendor intended. The Persistent-Device-Id operates at a different layer (AAA/RADIUS) and is visible only to the enterprise network the device has voluntarily enrolled with.
5. Introduce a covert or hidden identifier. The identifier is explicitly provisioned into the device's certificate during a transparent enrollment process that requires device owner or administrator action.

Security Invariants The following security properties MUST hold for any conforming implementation:

1. The Persistent-Device-Id MUST NOT appear in the clear in any Layer 2 frame (Ethernet, Wi-Fi management, or data frames).
2. The Persistent-Device-Id value is derived from the device certificate exchanged within the encrypted EAP tunnel (device to RADIUS server). The Persistent-Device-Id RADIUS attribute MUST only be transmitted within RADIUS messages protected by RADIUS/TLS (RADIUS server to NAS).
3. The Persistent-Device-Id MUST NOT be derivable from the device's MAC address (randomized or real).
4. The Persistent-Device-Id MUST NOT be observable by passive observers on the wireless medium or local network segment.
5. The Persistent-Device-Id MUST NOT be shared with entities outside the administrative domain without explicit device owner consent.

Device Consent and Control A central concern raised by device vendors and privacy advocates is whether a persistent device identifier undermines the user's control over their device identity. This section specifies the consent and control requirements that ensure the Persistent-Device-Id respects device owner autonomy.

Consent Model The Persistent-Device-Id is NEVER assigned to a device without explicit action by the device owner or an authorized administrator. The identifier exists only because a certificate containing it was provisioned onto the device through one of the following consent-based mechanisms:

1. Corporate Device Enrollment (Administrator Consent): An enterprise administrator enrolls the device in a Mobile Device Management (MDM) system. The MDM system generates a certificate containing the Persistent-Device-Id and pushes it to the device. The administrator acts on behalf of the organization, and the device is corporate-owned. The employee is informed of the enrollment through the organization's acceptable use policy.
2. BYOD Self-Enrollment (User Consent): The device owner voluntarily connects to a provisioning portal (captive portal or onboarding SSID) and follows an enrollment workflow. During this process, the portal generates a certificate containing the Persistent-Device-Id and installs it on the device. The user explicitly initiates and approves this enrollment. On most operating systems (iOS, Android, Windows, macOS), installing a certificate profile requires the user to accept a system-level prompt.
3. MDM-Initiated BYOD Enrollment (User Consent with MDM): The device owner installs an MDM agent application and enrolls their personal device in the organization's MDM. The MDM provisions the certificate. The user must explicitly install the MDM profile and grant the required permissions, providing informed consent.

User Control and Opt-Out The device owner retains full control over the Persistent-Device-Id at all times:

1. Certificate Removal: The device owner can remove the certificate (and with it, the Persistent-Device-Id) at any time by deleting the certificate profile from the device settings. On iOS, this is under Settings > General > VPN & Device Management. On Android, Settings > Security > Credentials. On Windows, certmgr.msc. On macOS, Keychain Access. Once the certificate is removed, the device will no longer present a Persistent-Device-Id during authentication, and the RADIUS server will treat it as a new, unidentified device.
2. MDM Unenrollment: For MDM-managed devices, the device owner can unenroll from the MDM system, which removes the MDM profile and all associated certificates, including the one containing the Persistent-Device-Id.
3. Network Disconnection: The device owner can choose not to connect to the enterprise network. No identifier is transmitted unless the device actively authenticates to the network using the provisioned certificate.
4. No Silent Re-provisioning: The RADIUS server or NAS MUST NOT provision or re-provision a certificate containing a Persistent-Device-Id without the device owner's or administrator's explicit action. If a certificate expires or is revoked, a new enrollment process requiring consent is needed.

Transparency Requirements Organizations deploying the Persistent-Device-Id SHOULD:

1. Inform device owners, through an acceptable use policy or enrollment notification, that a persistent device identifier will be embedded in the c ertificate and used for network access control, compliance, and licensing purposes.
2. Clearly describe what data is associated with the Persistent-Device-Id (MAC address history, session records, compliance state) and how long it is retained.
3. Provide a documented procedure for device owners to request deletion of their Persistent-Device-Id records, in compliance with applicable privacy regulations (e.g., the General Data Protection Regulation Article 17, the California Consumer Privacy Act).

The above recommendations are expressed as SHOULD to accommodate deployments where equivalent transparency is already provided through existing enterprise acceptable use policies, device management agreements, or where jurisdictional requirements impose alternative notification obligations that satisfy the same intent.

Certificate Provisioning Lifecycle The provisioning of the Persistent-Device-Id into the device's certificate is outside the scope of the RADIUS protocol. This section provides an informational overview of the lifecycle:

1. Enrollment: The device is enrolled through an MDM system or a NAC registration portal. During enrollment, the system generates a UUID version 4 using a CSPRNG and embeds it in the certificate's Subject Alternative Name (SAN) URI field using the URN format defined in , e.g., "urn:uuid:f47ac10b-58cc-4372-a567-0e02b2c3d479". The certificate is signed by the organization's CA and pushed to the device.
   • The SAN URI field is chosen over the X.509v3 subjectUniqueId field for the following reasons. First, Section 4.1.2.8 states that conforming CAs "MUST NOT generate certificates with unique identifiers", effectively deprecating subjectUniqueId for new deployments. Second, the SAN extension is the standard mechanism for carrying additional identity forms in X.509 certificates and is universally supported by certificate tooling, MDM systems, and SCEP/EST enrollment protocols. Third, the urn:uuid: namespace is already registered , requiring no new URI scheme registration. The RADIUS server extracts the UUID from the SAN URI by parsing the urn:uuid: prefix and using the remaining string representation directly as the RADIUS attribute value.
2. Consent: Certificate installation requires explicit action -- either by an administrator (corporate MDM push) or by the device owner (accepting a certificate profile prompt during BYOD onboarding). The identifier is never provisioned silently.
3. Authentication: When the device connects to the network, it presents the certificate inside the encrypted EAP tunnel (e.g., EAP-TLS, EAP-TTLS, TEAP). The RADIUS server extracts the Persistent-Device-Id from the SAN URI field and includes it in the Access-Accept message.
4. Renewal: When the certificate approaches expiration, the MDM or NAC system renews it. The renewed certificate must contain the same Persistent-Device-Id as the original, preserving identity continuity.
5. Revocation: When a device is decommissioned, lost, or stolen, the administrator revokes the certificate. The RADIUS server rejects subsequent authentication attempts. The Persistent-Device-Id record may be retained for audit or deleted per the organization's data retention policy.
6. Re-enrollment: If a device is re-enrolled after revocation, a new certificate with a new Persistent-Device-Id should be provisioned. Reuse of a previously revoked identifier is not recommended.

Protocol Sequence Diagrams The following diagram illustrates the complete lifecycle: certificate provisioning, initial authentication with identifier extraction, and re-authentication after MAC address rotation.

Persistent-ID Lifecycle Management | | | | | (user consent) | | | | |--CSR---->| | | | | (UUID in | | | | | SAN URI)| | | | |<-Cert----| | | |<--Push Cert---| | | | | (user accepts | | | | | cert prompt) | | | | | | | | | | PHASE 2: FIRST AUTHENTICATION (certificate-based EAP)| | | | | | |-- 802.1X Start -------------------->| | | (MAC_1 in L2 header) | | | | | | |--Acc-Request->| | | | | Calling-Stn-Id| | | | | = MAC_1 | |<============ EAP Tunnel (e.g., EAP-TLS) ============>| | (cert with UUID_A exchanged inside tunnel) | | | | | | | | | | Server: | | | | | 1.Extract | | | | | UUID_A | | | | | from cert | | | | | 2.Store: | | | | | UUID_A -> | | | | | MAC_1 | | | | | | | | | |<-Acc-Accept---| | | | | PDID=UUID_A | |<-- EAP-Success ---------------------| | | | | |--Acct-Req---->| | | | | MAC_1,UUID_A | | | | | | | PHASE 3: RE-AUTH AFTER MAC ROTATION | | | | | | | [MAC rotates: MAC_1 -> MAC_2] | | | | | | | |-- 802.1X Start -------------------->| | | (MAC_2 in L2 header) | | | | | | |--Acc-Request->| | | | | Calling-Stn-Id| | | | | = MAC_2 | |<============ EAP Tunnel (e.g., EAP-TLS) ============>| | (same cert, same UUID_A) | | | | | | | | | | | Server: | | | | | 1.Extract | | | | | UUID_A | | | | | 2.Find | | | | | existing | | | | | record | | | | | 3.Add MAC_2 | | | | | to UUID_A | | | | | | | | | |<-Acc-Accept---| | | | | PDID=UUID_A | | | | | (same as | | | | | before) | |<-- EAP-Success ---------------------| | | | | |--Acct-Req---->| | | | | MAC_2,UUID_A | ]]>

Key observations: (1) The UUID is provisioned with user/admin consent during enrollment. (2) The UUID originates from the device certificate exchanged within the encrypted EAP tunnel -- it never appears in any Layer 2 frame. The Persistent-Device-Id RADIUS attribute is carried only in RADIUS messages protected by RADIUS/TLS. (3) After MAC rotation, the same UUID is extracted from the same certificate, allowing the RADIUS server to unify device records across MAC changes. (4) Unenrolled devices (no certificate) are unaffected and receive no Persistent-Device-Id.

Attribute Assignment Procedures

Identifier Extraction from Certificate When a RADIUS server receives an Access-Request containing a certificate-based authentication (e.g., EAP-TLS, EAP-TTLS, TEAP), and the device's certificate contains a persistent device identifier, the server MUST:

1. Extract the persistent device identifier from the device's certificate.
2. Store or update the identifier in association with the device's current Calling-Station-Id (MAC address) for correlation purposes.
3. Include the Persistent-Device-Id attribute in the Access-Accept message.

Correlation and Retrieval When a RADIUS server receives an Access-Request and the Calling-Station-Id does not match any stored device record, but the device authenticates via a certificate-based method, the server SHOULD attempt to correlate the request with an existing Persistent-Device-Id by extracting the identifier from the certificate and looking up the stored records. The primary identity correlation source is the device certificate. If the authentication method is certificate-based (e.g., EAP-TLS, EAP-TTLS, TEAP), the server extracts the persistent device identifier from the certificate and uses it to look up an existing device record. If a matching record is found, the server associates the new MAC address with the existing record. Note: External device management systems (e.g., MDM) provision the persistent identifier into the device's certificate during enrollment. The identifier reaches the RADIUS server through the certificate-based authentication exchange, not through a separate channel. Therefore, MDM-managed devices are covered by the certificate-based extraction above. For authentication methods that do not involve certificates (e.g., MAB, credential-based EAP methods, guest access), no persistent device identifier is available in the authentication exchange. In these cases, the RADIUS server does not assign a Persistent-Device-Id, and MAC address randomization continues to result in separate device records per MAC address. This document does not define alternative mechanisms for persistent device identification in non-certificate-based authentication scenarios. Such mechanisms are outside the scope of this specification. If the extracted identifier matches an existing record, the server MUST:

1. Associate the new Calling-Station-Id (MAC address) with the existing Persistent-Device-Id record.
2. Include the existing Persistent-Device-Id in the Access-Accept message.

If the device authenticates via a non-certificate-based method, or if the certificate does not contain a persistent device identifier, the server MUST NOT include a Persistent-Device-Id attribute in the Access-Accept.

Immutability The Persistent-Device-Id value is determined by the identifier provisioned in the device's certificate. It MUST NOT be modified by the RADIUS server. If administrative action requires re-identification of a device (e.g., device decommissioning and re-enrollment), a new certificate with a new identifier must be provisioned to the device. The old identifier MUST be retired and MUST NOT be reassigned to a different device.

Uniqueness The persistent device identifier provisioned in each device's certificate MUST be globally unique. The enrollment system (MDM or NAC registration portal) is responsible for ensuring uniqueness during certificate provisioning. The use of UUID version 4 with a CSPRNG during provisioning provides sufficient uniqueness guarantees.

Concurrency In deployments where multiple RADIUS server instances process authentication requests concurrently, implementations MUST ensure that the extracted Persistent-Device-Id and its associated MAC address mappings are consistently replicated across all server instances. Since the identifier originates from the certificate (not generated by the server), concurrency risks are limited to MAC address association updates. Recommended approaches include: 1. Advisory locking on the Calling-Station-Id or identity correlation key before checking for existing assignments. 1. A check-then-act pattern with lock acquisition: acquire lock, re-query for existing assignment, create if absent, release lock. 1. Distributed coordination across server instances in clustered deployments. The lock hold time SHOULD NOT exceed 5 seconds to prevent processing delays.

NAD and Platform Integration After receiving the Persistent-Device-Id in the Access-Accept message, the Network Access Device (NAD) caches the identifier for the duration of the authenticated session. The NAD does not perform cross-connection correlation -- correlation across MAC address changes is handled entirely by the RADIUS server based on the device's certificate. The NAD's role is analogous to its handling of the Class attribute: receive, cache, and echo. Beyond caching and echoing in RADIUS Accounting-Request messages, the NAD distributes the Persistent-Device-Id to integrated platforms, enabling several downstream use cases:

1. Device Profiling and Fingerprinting: The NAD or RADIUS server can share the Persistent-Device-Id with endpoint analytics and profiling systems. These systems build device fingerprint profiles -- aggregating attributes such as DHCP options, HTTP user-agent, and CDP/LLDP data -- indexed by the persistent identifier rather than the transient MAC address. This ensures profiling data survives MAC rotation.
2. Location and Presence Analytics: The NAD can include the Persistent-Device-Id in location telemetry messages (e.g., via streaming telemetry or location service protocols) sent to location analytics platforms. This allows location services to track device presence and movement patterns using a stable identifier, even as the MAC address changes between sessions.
3. Cross-Platform Distribution: The RADIUS server or NAD can distribute the Persistent-Device-Id to network management, assurance, and third-party platforms through integration mechanisms such as publish-subscribe frameworks, REST APIs, or event streaming. This enables a consistent device identity across the ecosystem of network services -- including compliance engines, network assurance dashboards, and third-party security tools -- without requiring each platform to independently resolve MAC address changes.

In all cases, the Persistent-Device-Id MUST be treated with the same access control and privacy protections described in this specification. Platforms receiving the identifier MUST NOT expose it to entities outside the administrative domain without explicit device owner consent.

Deployment Considerations The Persistent-Device-Id mechanism is designed to be deployable without changes to existing NAD firmware or software. The NAD behavior required by this specification -- receiving a new attribute in Access-Accept, caching it for the session, and echoing it in Accounting-Request messages -- is identical to how RADIUS clients already handle the Class attribute per . Any NAD that correctly implements Class attribute handling can support Persistent-Device-Id without modification. The primary changes required for deployment are:

1. Enrollment System: The certificate enrollment system (MDM, SCEP/EST server, or NAC self-service portal) must generate and embed a UUID in the device certificate's SAN URI field during provisioning.
2. RADIUS Server: The RADIUS server must be updated to extract the UUID from the SAN URI field of the client certificate during EAP-TLS, EAP-TTLS, or TEAP authentication, and to include it as the Persistent-Device-Id attribute in the Access-Accept.
3. Backend Systems: Profiling engines, compliance systems, and analytics platforms must be updated to consume the Persistent-Device-Id as the primary device correlation key instead of (or in addition to) the MAC address.

No changes are required at the NAD layer, which reduces the barrier to deployment in existing network infrastructure.

Usage in RADIUS Messages

Access-Accept When a RADIUS server extracts a Persistent-Device-Id from a device's certificate during authentication, it SHOULD include the Persistent-Device-Id attribute in the Access-Accept message sent to the RADIUS client (authenticator).

Persistent Device ID in Access Accept | | (Persistent-Device-Id = UUID) | | (other authorization attributes) | | | ]]>

Accounting-Request When a RADIUS client has received a Persistent-Device-Id in an Access-Accept, it SHOULD include the Persistent-Device-Id attribute in all subsequent Accounting-Request messages (Accounting-Start, Interim-Update, and Accounting-Stop) for that session. This enables the RADIUS server to correlate accounting records across sessions where the Calling-Station-Id may differ due to MAC address randomization.

Persistent Device ID in Accounting Request | | (Calling-Station-Id = MAC_1) | | (Persistent-Device-Id = UUID_A) | | | | [Device reconnects with new MAC] | | | |---- Accounting-Request (Start) ------>| | (Calling-Station-Id = MAC_2) | | (Persistent-Device-Id = UUID_A) | | | ]]>

The RADIUS server can now correlate both sessions as belonging to the same device (UUID_A) despite different MAC addresses.

CoA-Request A RADIUS server MAY include the Persistent-Device-Id attribute in a Change-of-Authorization (CoA) Request RFC5176 to identify the target device session. The RADIUS client MUST use the Persistent-Device-Id, if present, to identify the session to which the CoA applies, in preference to Calling-Station-Id when both are present.

Access-Request The Persistent-Device-Id attribute MUST NOT appear in Access-Request messages. The identifier is extracted from the device's certificate by the RADIUS server during authentication processing, not supplied by the RADIUS client. Exception: If a RADIUS client has cached a Persistent-Device-Id from a previous Access-Accept for the same device, and the server's deployment policy explicitly permits it, the client MAY include the cached Persistent-Device-Id in the Access-Request as a hint to assist correlation. When present in an Access-Request, the server MUST validate the hint against its own records and MUST NOT trust it as authoritative.

Access-Reject and Access-Challenge The Persistent-Device-Id attribute MUST NOT appear in Access-Reject or Access-Challenge messages. A Persistent-Device-Id is only included upon successful certificate-based authentication where the certificate contains a valid persistent device identifier.

Interaction with Existing Attributes

Calling-Station-Id (Type 31) The Persistent-Device-Id attribute supplements but does not replace Calling-Station-Id. The Calling-Station-Id continues to carry the MAC address (randomized or not) as observed by the RADIUS client. Systems that need the current MAC address for network-level operations (e.g., VLAN assignment, ACL application) continue to use Calling-Station-Id for that purpose. The Persistent-Device-Id provides the stable device-level correlation that Calling-Station-Id can no longer guarantee.

User-Name (Type 1) The Persistent-Device-Id identifies a device, not a user. A single User-Name may be associated with multiple Persistent-Device-Id values (one per device), and a single Persistent-Device-Id MAY be associated with multiple User-Name values (if different users authenticate on the same device).

Acct-Session-Id (Type 44) The Acct-Session-Id attribute identifies a single session. The Persistent-Device-Id identifies the device across sessions. Together, they enable both session-level and device-level accounting correlation.

Class (Type 25) The Class attribute and the Persistent-Device-Id share a similar operational pattern: both are assigned by the RADIUS server in Access-Accept and echoed by the NAS in subsequent messages (Accounting-Request for both; Access-Request for Class per ). However, they differ in key respects:

1. Persistence: Class is session-scoped. The NAS echoes it during a single session, and the value is not guaranteed to persist across sessions or MAC address changes. Persistent-Device-Id is designed to remain stable across sessions, MAC changes, and certificate renewals.
2. Semantics: Class is opaque to the NAS and has no defined meaning -- the server may use it for any purpose. Persistent-Device-Id has a defined semantic: it identifies a device. This allows downstream systems (profiling, compliance, SIEM) to consume the value with a shared understanding of its meaning.
3. Origin: Class is generated by the RADIUS server at its discretion. Persistent-Device-Id is extracted from the device's certificate, provisioned during enrollment. The server does not create the identifier -- it reads it from the certificate.

Implementations familiar with Class attribute handling will find the NAS-side behavior of Persistent-Device-Id analogous: receive in Access-Accept, cache for the session, include in Accounting-Requests.

Chargeable-User-Identity The Chargeable-User-Identity (CUI) attribute defined in provides a stable user-level identity for inter-domain roaming and billing. While both CUI and Persistent-Device-Id carry opaque identifiers in RADIUS messages, they serve fundamentally different purposes and cannot be used interchangeably. The key differences are:

1. Semantic Scope: CUI identifies a user (or chargeable entity) for billing purposes. Persistent-Device-Id identifies a physical device. These are orthogonal concepts: a single user may own multiple devices (each requiring a distinct Persistent-Device-Id), and a shared device may authenticate multiple users (each receiving a distinct CUI). Overloading one attribute to serve both purposes would create ambiguity and prevent independent user and device correlation.
2. Identifier Origin: CUI is generated by the home RADIUS server as an opaque token. Persistent-Device-Id is extracted from the device's certificate (SAN URI field), provisioned by the enrollment system. The RADIUS server does not generate the Persistent-Device-Id; it reads it from the certificate presented during certificate-based EAP authentication. These are different data flows requiring different handling semantics.
3. Binding Lifetime: RFC 4372 explicitly states that the CUI binding "should be temporary -- long enough to be useful for the external applications and not too long such that it can be used to identify the user." A typical CUI lifetime is one billing period. In contrast, the Persistent-Device-Id MUST remain stable for the entire duration the device's certificate is valid, potentially spanning years, to enable persistent device identification across MAC address changes.
4. Deployment Scope: CUI is designed for cross-network roaming scenarios involving visited and home networks with intermediary proxies. Persistent-Device-Id is scoped to a single administrative domain for NAC, compliance, and audit purposes. A deployment may legitimately need both attributes simultaneously -- CUI for roaming billing and Persistent-Device-Id for device identification -- in the same RADIUS message.
5. Opaqueness Constraint: mandates that "RADIUS entities other than the Home RADIUS server MUST treat the CUI content as an opaque token, and SHOULD NOT perform operations on its content other than a binary equality comparison test." Any scheme to differentiate user vs. device identity within a CUI value (e.g., using a class prefix or structured encoding) would require intermediaries to inspect and interpret CUI content, directly violating this requirement.

In roaming scenarios, both CUI and Persistent-Device-Id MAY be present in the same RADIUS message, providing independent user-level and device-level correlation without ambiguity or attribute overloading.

EAP-Message (Type 79) When certificate-based EAP authentication is used (e.g., EAP-TLS, EAP-TTLS, TEAP), the device's certificate is the source of the Persistent-Device-Id. The RADIUS server extracts the identifier from the certificate during the EAP exchange and includes it in the Access-Accept. This is the primary and intended use case for this specification.

Operational Considerations

Replication In deployments with multiple RADIUS servers, the Persistent-Device-Id assignments and the associated MAC address mappings MUST be replicated across all servers. This ensures that a device authenticating to any server in the deployment receives the same Persistent-Device-Id. The replication mechanism is implementation-specific and outside the scope of this document. Implementations SHOULD provide eventual consistency with a convergence time appropriate for the deployment's authentication rate.

Proxy Environments When a RADIUS proxy forwards an Access-Request to an upstream RADIUS server, and the upstream server includes a Persistent-Device-Id in the Access-Accept, the proxy MUST forward the Persistent-Device-Id attribute to the RADIUS client without modification. Within an administrative domain, RADIUS proxies that forward Access-Accept messages MUST pass the Persistent-Device-Id attribute through unchanged. Enterprises SHOULD strip the Persistent-Device-Id attribute before sending RADIUS packets outside of the administrative domain. This prevents the persistent identifier from leaking to external organizations or roaming partners. The stripping requirement applies at the administrative domain boundary, not to all RADIUS proxies in the forwarding path.

Incremental Deployment RADIUS clients that do not support the Persistent-Device-Id attribute will ignore it in Access-Accept messages per standard RADIUS behavior (unknown attributes are silently discarded). This allows incremental deployment where RADIUS servers begin including the attribute before all clients are upgraded.

Pre-Existing Device Records When a RADIUS server implementing this specification receives an Access-Request for a device that has an existing record (created before Persistent-Device-Id support was deployed), and the device authenticates via a certificate containing a persistent identifier, the server SHOULD:

1. Extract the Persistent-Device-Id from the certificate and associate it with the existing device record.
2. Associate it with the existing device record, preserving all historical data.
3. Include the Persistent-Device-Id in the Access-Accept.

This provides a seamless deployment path for existing deployments.

Mixed-Mode Operation During deployment, some device records will have Persistent-Device-Id values and some will not. Implementations MUST support lookups by both Calling-Station-Id (for legacy records) and Persistent-Device-Id (for migrated records) until deployment is complete.

Transition via Class Attribute In deployments where RADIUS clients do not yet recognize the Persistent-Device-Id attribute, the RADIUS server MAY additionally convey the persistent device identifier in the Class attribute (Type 25) as defined in . Since all compliant RADIUS clients already cache the Class attribute from Access-Accept and echo it in subsequent Accounting-Request messages, this provides an immediate deployment path without requiring any client-side changes. This approach has limitations compared to a dedicated attribute:

1. Semantic Ambiguity: The Class attribute is opaque and may already be in use for other purposes (e.g., VLAN assignment, policy tagging). Embedding the persistent device identifier requires a convention (e.g., a structured prefix) that all consuming systems must understand.
2. Session Scope: The Class attribute is session-scoped. It is not guaranteed to persist across re-authentications or MAC address changes unless the server re-populates it in every Access-Accept.
3. No Interoperability Guarantee: Because Class has no defined semantic, third-party systems cannot consume it as a device identifier without deployment-specific configuration.

Despite these limitations, the Class attribute provides a practical deployment mechanism. Deployments MAY use Class to carry the persistent device identifier as an interim measure while migrating to the dedicated Persistent-Device-Id attribute. Servers implementing this approach SHOULD include both the Class attribute (for backward compatibility) and the Persistent-Device-Id attribute (for clients that support it) in the same Access-Accept message.

Chargeable-Device-Identity (CDI)

Concept and Motivation The Chargeable-User-Identity (CUI) defined in established the pattern of using an opaque, server-generated identifier to correlate RADIUS sessions for a user without exposing the user's real identity to visited networks. This specification defines an analogous concept for devices: the Chargeable-Device-Identity (CDI). CDI is a privacy-preserving, rotating identifier that correlates RADIUS sessions belonging to the same physical device across MAC address changes, without exposing a static device identifier on the wire. The CDI mechanism is designed to:

1. Work with equipment deployed in production today (no NAS changes required).
2. Preserve MAC randomization privacy by avoiding static identifiers.
3. Provide time-bounded correlation suitable for operational and compliance needs.
4. Be deployable immediately using the existing Class attribute as transport.

CDI Format and Construction The CDI value is constructed by the RADIUS server using the following formula: Where:

• server-secret: A secret key known only to the RADIUS server (or cluster of servers sharing the key). This secret MUST NOT be the RADIUS shared secret; it is a separate key dedicated to CDI generation.
• device-id: The stable device identifier known to the server (e.g., the UUID extracted from the device certificate's SAN URI field during certificate-based EAP authentication).
• epoch: A time-based rotation value. The epoch boundary is configurable by the operator (e.g., daily, weekly, monthly). All sessions within the same epoch for the same device produce the same CDI value.
• "cdi:": A fixed prefix that allows consuming systems to identify the Class value as a CDI (as opposed to other uses of the Class attribute).

The resulting CDI value is opaque to the NAS and to any intermediate RADIUS proxy. Only the originating RADIUS server (possessing the server-secret) can reverse the mapping from CDI to device-id.

CDI Rotation and Privacy Properties The CDI rotates at epoch boundaries. This provides the following privacy properties:

1. Time-Bounded Correlation: Sessions can be correlated within an epoch (e.g., one week) for operational purposes such as compliance auditing and session accounting. Cross-epoch correlation is not possible without access to the RADIUS server's mapping table.
2. No Static Identifier on Wire: Unlike a raw UUID, the CDI changes periodically. An observer who captures CDI values from different epochs cannot correlate them to the same device.
3. Server-Only Reversibility: The HMAC construction ensures that only the server possessing the server-secret can determine which device-id produced a given CDI. Intermediate systems (proxies, accounting servers, SIEM) can perform equality comparisons within an epoch but cannot reverse the mapping.
4. Epoch Configuration Flexibility: Operators can tune the rotation period based on their privacy/utility tradeoff. Shorter epochs (daily) provide stronger privacy but limit the correlation window. Longer epochs (monthly) provide broader correlation but with reduced privacy. The RECOMMENDED default is weekly rotation.

CDI Transport via Class Attribute The CDI is transported using the existing RADIUS Class attribute (Type 25) as defined in . This is the RECOMMENDED transport mechanism because:

1. All compliant RADIUS clients (NAS devices) already implement Class attribute handling: receive in Access-Accept, cache for the session, echo in Accounting-Request messages.
2. No NAS firmware changes are required.
3. The mechanism works with equipment deployed in production today.

The RADIUS server includes the CDI value as one of potentially multiple Class attribute instances in the Access-Accept. The NAS echoes all Class values in subsequent Accounting-Request messages per . Example Access-Accept containing CDI: Consuming systems (accounting servers, compliance platforms, SIEM) identify CDI values by the "cdi:" prefix and use them for device session correlation.

CDI Server-Side Correlation Service For systems that require correlation beyond the current epoch, or that need to resolve a CDI back to a device identity, the RADIUS server SHOULD provide an authorized query interface. This interface allows authorized consumers to:

1. Query by CDI value to retrieve the associated device identity (subject to access control and audit logging).
2. Query by device identity to retrieve all associated CDI values across epochs (for compliance audits spanning multiple rotation periods).
3. Query by MAC address and time to retrieve the CDI and/or device identity that was active at that point in time.

This server-side correlation service provides an "opt-in" model for device tracking: only systems authorized to access the mapping can perform cross-epoch or cross-MAC correlation. Systems that only receive CDI values via accounting records can correlate within an epoch but cannot identify the underlying device without querying the authoritative service. The correlation service:

• MUST require authentication and authorization for all queries.
• MUST log all access to the mapping data (who, when, what was queried).
• SHOULD support time-bounded queries to limit data exposure.
• MAY provide event-stream interfaces (e.g., publish-subscribe) for real-time notification of device state changes to authorized consumers.

CDI and the Persistent-Device-Id Attribute CDI (transported via Class) and the Persistent-Device-Id attribute (defined in this document) serve complementary purposes:

Property	CDI (Class)	Persistent-Device-Id
Transport	Class attribute	Dedicated attribute (TBD1)
NAS changes required	None	Attribute recognition
Identifier stability	Rotates per epoch	Stable across certificate lifetime
Privacy	Time-bounded correlation	Persistent correlation
Reversibility	Server-only	Any system with the value
Semantic clarity	Opaque (prefix convention)	Explicit device identity semantic
Deployability	Immediate (today)	Requires NAS support

The RECOMMENDED deployment approach is:

1. Deploy CDI via Class immediately for all environments.
2. When NAS implementations add support for the Persistent-Device-Id attribute, deploy it alongside CDI for systems that require explicit device identity semantics.
3. Servers SHOULD include both CDI (in Class) and Persistent-Device-Id (when supported by the NAS) in the same Access-Accept during the transition period.

Security Considerations

Identifier Provisioning The Persistent-Device-Id is provisioned into the device's certificate by the enrollment system (MDM or NAC registration portal) during device onboarding. The enrollment system MUST use a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG) when generating the identifier to ensure unpredictability. Use of predictable or sequential identifiers would allow an attacker to enumerate devices or anticipate future identifiers. The RADIUS server does not generate identifiers; it extracts them from certificates presented during authentication.

Transport Security The Persistent-Device-Id benefits from two layers of transport protection. First, the identifier value originates from the device's certificate, which is exchanged inside the encrypted EAP tunnel (e.g., EAP-TLS, EAP-TTLS, TEAP) between the supplicant and the RADIUS server. This ensures the identifier is never transmitted in cleartext over the air (wireless) or on the wire (wired), and is not visible to passive observers, neighboring devices, or any entity not party to the authenticated EAP session. This is in stark contrast to the MAC address, which appears in plaintext in every Layer 2 frame header. Second, the Persistent-Device-Id RADIUS attribute is carried within RADIUS messages between the server and the authenticator, protected by the RADIUS shared secret mechanism or, for stronger security, by RADIUS/TLS (RadSec) . For deployments requiring stronger transport security, RADIUS/TLS (RadSec) SHOULD be used. further deprecates RADIUS over UDP and MD5-based security mechanisms, mandating TLS-based transport for all RADIUS deployments. When RadSec is in use, the Persistent-Device-Id receives the same TLS protection as all other RADIUS attributes.

Access Control The Persistent-Device-Id mapping table (associating UUIDs with MAC addresses and device attributes) contains sensitive information. Access to this table MUST be restricted to authorized administrators and audit systems. All access to the mapping table SHOULD be logged.

Identifier Spoofing If the Access-Request hint mechanism is implemented, the RADIUS server MUST validate any client-provided Persistent-Device-Id against its authoritative records. A RADIUS client MUST NOT be trusted as the source of truth for Persistent-Device-Id values.

Replay Protection The Persistent-Device-Id does not introduce new replay attack vectors beyond those inherent in the RADIUS protocol. Standard RADIUS replay protections (Request Authenticator, Message-Authenticator attribute ) apply.

Privacy Considerations

Persistent Identification The Persistent-Device-Id is explicitly designed to enable persistent device identification within an administrative domain. This is its intended purpose for NAC, compliance, and auditing. However, this capability must be balanced against user privacy expectations.

Scope Limitation The Persistent-Device-Id SHOULD be scoped to a single administrative domain. Enterprises SHOULD strip the Persistent-Device-Id attribute before sending RADIUS packets outside of the administrative domain. A Persistent-Device-Id assigned by one organization's RADIUS server MUST NOT be shared with other organizations without explicit user consent, except as required by applicable law.

Data Retention Organizations deploying Persistent-Device-Id SHOULD establish data retention policies that define: 1. Maximum retention period for Persistent-Device-Id records. 1. Procedures for deleting Persistent-Device-Id records when a device is decommissioned. 1. Procedures for honoring data deletion requests from device owners, where required by applicable privacy regulations (e.g., GDPR Article 17, ).

Relationship to MAC Randomization Goals MAC address randomization was introduced to prevent cross-network tracking of devices at Layer 2. A key privacy concern is whether introducing a Persistent-Device-Id undermines the privacy benefits of MAC randomization. This specification preserves MAC randomization privacy because the Persistent-Device-Id value originates from the device certificate exchanged within the encrypted EAP tunnel during certificate-based authentication, and the RADIUS attribute is carried only in RADIUS messages protected by RADIUS/TLS. Unlike the MAC address, which is transmitted in plaintext in Layer 2 frames and is visible to any passive observer on the wireless medium or local network segment, the Persistent-Device-Id is never exposed in cleartext over the air or on the wire. Specifically:

1. Transport Protection: The Persistent-Device-Id value originates from the device's certificate, which is exchanged within the encrypted EAP tunnel (e.g., EAP-TLS, EAP-TTLS, TEAP). The TLS handshake encrypts the certificate exchange, ensuring the identifier is never visible to passive observers, neighboring devices, or any entity not participating in the authenticated session. The Persistent-Device-Id RADIUS attribute is then carried in RADIUS messages protected by the shared secret or by RADIUS/TLS. In contrast, the MAC address is present in every Layer 2 frame header in plaintext and can be captured by any device within radio range (wireless) or on the same network segment (wired). MAC randomization exists precisely because the MAC address lacks this transport protection. The Persistent-Device-Id does not share this vulnerability.
2. Explicit Enrollment and Consent: The Persistent-Device-Id is only present on devices that have been explicitly enrolled through an MDM system or NAC registration portal. The device owner or administrator has voluntarily provisioned the certificate containing the identifier. This is fundamentally different from MAC address tracking, which occurs without the device owner's knowledge or consent. Unenrolled devices (guest, BYOD without certificates) are not affected by this specification and continue to benefit fully from MAC randomization privacy.
3. Domain-Scoped Visibility: The Persistent-Device-Id is scoped to the administrative domain that provisioned the certificate. It is visible only to the RADIUS server and the authenticator within that domain. It cannot be used for cross-network tracking because external networks never see the identifier -- it is not broadcast, not included in probe requests, and not present in any Layer 2 frame. The MAC address, even when randomized, is visible to every network the device encounters. The Persistent-Device-Id has strictly narrower visibility than even a randomized MAC address.
4. RADIUS Transport Encryption: When the Persistent-Device-Id is included in the RADIUS Access-Accept message from the server to the authenticator, it is protected by the RADIUS shared secret mechanism. For deployments requiring stronger protection, RADIUS/TLS (RadSec) provides full encryption of the RADIUS transport. Together, the encrypted EAP tunnel protects the certificate exchange (device to server), and RADIUS/TLS protects the attribute transport (server to authenticator), ensuring the identifier is never exposed in cleartext at any point.

Organizations MUST NOT use the Persistent-Device-Id to correlate device activity across independent administrative domains unless the device owner has provided explicit consent.

IANA Considerations

RADIUS Attribute Type This document requests IANA to allocate a new RADIUS Attribute Type from the "RADIUS Attribute Types" registry (https://www.iana.org/assignments/radius-types/):

Type	Name	Data Type	Reference
TBD1	Persistent-Device-Id	string	[this document]

Note: The Chargeable-Device-Identity (CDI) mechanism defined in does not require a new IANA allocation. CDI is transported using the existing Class attribute (Type 25) and is identified by the "cdi:" prefix convention defined in this document.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK] This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. This memo provides information for the Internet community. This document defines Remote Authentication Dial In User Service (RADIUS) support for the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication mechanisms. In the proposed scheme, the Network Access Server (NAS) forwards EAP packets to and from the RADIUS server, encapsulated within EAP-Message attributes. This has the advantage of allowing the NAS to support any EAP authentication method, without the need for method- specific code, which resides on the RADIUS server. While EAP was originally developed for use with PPP, it is now also in use with IEEE 802. This memo provides information for the Internet community. This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. This memo provides information for the Internet community. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This specification defines UUIDs (Universally Unique IDentifiers) -- also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform Resource Name namespace for UUIDs. A UUID is 128 bits long and is intended to guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System (NCS), later in the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the OSF DCE specification with the kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have been incorporated into this document. This document obsoletes RFC 4122. Deutsches Forschungsnetz | German National Research and Education Network Painless Security Fondation Restena | Restena Foundation This document defines transport profiles for running RADIUS over Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS), allowing the secure and reliable transport of RADIUS messages. RADIUS/TLS and RADIUS/DTLS are collectively referred to as RadSec. This document obsoletes RFC6614 and RFC7360, which specified experimental versions of RADIUS over TLS and DTLS. Informative References This document describes a new Remote Authentication Dial-In User Service (RADIUS) attribute, Chargeable-User-Identity. This attribute can be used by a home network to identify a user for the purpose of roaming transactions that occur outside of the home network. [STANDARDS-TRACK] Internet users are becoming more aware that their activity over the Internet leaves a vast digital footprint, that communications might not always be properly secured, and that their location and actions can be tracked. One of the main factors that eases tracking of Internet users is the wide use of long-lasting, and sometimes persistent, identifiers at various protocol layers. This document focuses on Media Access Control (MAC) addresses. There have been several initiatives within the IETF and the IEEE 802 standards committees to address some of the privacy issues involved. This document provides an overview of these activities to help coordinate standardization activities in these bodies. InkBridge Networks RADIUS crypto-agility was first mandated as future work by RFC 6421. The outcome of that work was the publication of RADIUS over TLS (RFC 6614) and RADIUS over DTLS (RFC 7360) as experimental documents. Those transport protocols have been in wide-spread use for many years in a wide range of networks, and have recently been standardized in [I-D.ietf-radext-radiusdtls-bis]. TLS has proven to be a useful replacment for UDP (RFC 2865) and TCP (RFC 6613) transports. With that knowledge, the continued use of insecure transports for RADIUS has serious and negative implications for privacy and security. The publication of the "BlastRADIUS" exploit has also shown that RADIUS security needs to be updated. It is no longer acceptable for RADIUS to rely on MD5 for security. It is no longer acceptable to send device or location information in clear text across the wider Internet. This document therefore deprecates many insecure practices in RADIUS, and mandates support for secure TLS-based transport layers. Related security issues with RADIUS are discussed, and recommendations are made for practices which increase both security and privacy. n.d.

Use Case Examples

CDI-Based Session Correlation (Class Attribute) This example demonstrates the RECOMMENDED CDI approach using the existing Class attribute. No NAS changes are required.

BYOD with Certificate-Based Authentication A personal device is onboarded via a provisioning portal and issued a device certificate. The certificate contains a persistent device identifier provisioned during enrollment. The following example uses EAP-TLS, but the same flow applies to any certificate-based EAP method (EAP-TTLS, TEAP). Step 1: Device connects with MAC_1, authenticates via certificate-based EAP Step 2: RADIUS server extracts Persistent-Device-Id from certificate Step 3: No existing record found for this identifier Step 4: Server stores: PDID -> {MAC_1, cert identity} Step 5: Access-Accept includes Persistent-Device-Id = PDID [Later, device reconnects with randomized MAC_2] Step 6: Device connects with MAC_2, authenticates via certificate-based EAP Step 7: RADIUS server extracts same Persistent-Device-Id from certificate Step 8: Server finds existing record for this identifier Step 9: Server adds MAC_2 to the PDID record Step 10: Access-Accept includes same Persistent-Device-Id = PDID

MDM-Managed Device A corporate device is enrolled in a Mobile Device Management system. The MDM provisions a device certificate containing a persistent device identifier. {MAC_1, cert identity} Step 5: Access-Accept includes Persistent-Device-Id = PDID [Later, device reconnects with randomized MAC_2] Step 6: Device connects with MAC_2, authenticates via certificate-based EAP Step 7: RADIUS server extracts same Persistent-Device-Id from certificate Step 8: Server finds existing record Step 9: Access-Accept includes same Persistent-Device-Id = PDID ]]>

Accounting Correlation Across MAC Changes

Guest Access Limitations For unauthenticated guest access (e.g., open hotspot), no identity correlation source is available. In this scenario: Step 1: Device connects with MAC_1, no certificate-based authentication Step 2: RADIUS server has no certificate to extract identifier from Step 3: No Persistent-Device-Id included in Access-Accept Step 4: Device is treated as a new endpoint keyed by MAC_1 This limitation is inherent: without an identity assertion from the device, persistent identification across MAC changes is not possible without resorting to fingerprinting techniques that undermine the privacy goals of MAC randomization.

Future Work

Alternative Identity Derivation This specification relies on extracting the Persistent-Device-Id from the device's X.509 certificate. An alternative approach would be to derive a persistent device identifier from keying material produced during EAP authentication -- specifically from the Master Session Key (MSK) or Extended Master Session Key (EMSK) as defined by the applicable EAP method. Such a derivation could provide persistent device identity without requiring changes to the certificate enrollment process. However, this approach introduces additional complexity in key management and requires careful analysis of the cryptographic binding properties. Investigation of MSK/EMSK-based device identity derivation is left for future work.

Changelog

• 01 - Addressed feedback from RADEXT mailing list review (Alan DeKok, Alexander Clouter):
  • Added Mechanism Overview subsection to Introduction for early end-to-end clarity.
  • Added Privacy Model subsection to Introduction, explicitly distinguishing enrolled devices (subject to identification) from guest, unenrolled BYOD, and MAB-only devices (unaffected).
  • Clarified NAD role: per-session caching only, no cross-connection correlation; added Class attribute analogy.
  • Added Deployment Considerations subsection explaining that no NAD changes are required.
  • Added Chargeable-Device-Identity (CDI) section defining a privacy- preserving, rotating device correlator modeled after CUI (RFC 4372), transported via the existing Class attribute for immediate deployability without NAS changes.
  • Defined CDI format: HMAC-SHA-256 construction with epoch-based rotation providing time-bounded correlation and server-only reversibility.
  • Defined CDI server-side correlation service for authorized cross-epoch queries, providing opt-in device tracking with access control and audit logging.
  • Repositioned the Persistent-Device-Id attribute as complementary to CDI: CDI for immediate deployment via Class; dedicated attribute for explicit semantics when NAS support is available.
  • Updated proxy language: enterprises SHOULD strip the attribute before sending packets outside the administrative domain (rather than placing the requirement on all RADIUS proxies).
  • Added Class (Type 25) comparison in Interaction with Existing Attributes section.
  • Added Future Work section discussing alternative identity derivation from MSK/EMSK keying material.
  • Updated title and abstract to reflect the dual CDI + Persistent- Device-Id approach.
• 00 - initial draft.

Acknowledgements The authors thank Suresh Krishnan, Juan Carlos Zuniga, Jerome Henry, Mark Grayson, Eric Vyncke, Alan DeKok, and Alexander Clouter for their valuable technical review, feedback, and contributions to the development of this specification. The authors acknowledge the work of the IETF MADINAS working group in documenting the impacts of MAC address randomization, which motivated this specification. Disclosure of AI Use: The authors used AI-assisted tools for drafting and language editing of this document. All technical concepts and protocol specifications presented are the original intellectual contributions of the authors, developed through years of hands-on engineering work on network access control systems. The authors reviewed, edited, and verified all content and take full responsibility for the accuracy and integrity of this publication.