RADEXT Working Group S. Gundavelli Internet-Draft Ameriband Intended status: Standards Track S. Das Expires: 12 April 2027 National Spectrum Consortium M. Grayson Cisco Systems M. Dolly AT&T A. Nguyen US DHS/CISA 9 October 2026 RADIUS attributes for National Security and Emergency Preparedness Service draft-ietf-radext-epcs-01 Abstract This document defines RADIUS attributes for authorizing the use of Emergency Preparedness Communication Service (EPCS) priority access defined in IEEE 802.11be. These attributes allow an Identity Provider to indicate that an authenticated user is authorized for EPCS, enabling the Wi-Fi network provider to apply EPCS priority access to the user's Wi-Fi session. The attributes also support RADIUS accounting for Wi-Fi sessions in which EPCS priority access is used. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 12 April 2027. Gundavelli, et al. Expires 12 April 2027 [Page 1] Internet-Draft RADIUS Attributes for EPCS October 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview of EPCS Provisioning . . . . . . . . . . . . . . . . 5 3. EPCS RADIUS Exchanges . . . . . . . . . . . . . . . . . . . . 6 3.1. EPCS Authorization RADIUS Exchange . . . . . . . . . . . 6 3.2. EPCS Invocation and RADIUS Accounting . . . . . . . . . . 10 4. RADIUS EPCS Attributes . . . . . . . . . . . . . . . . . . . 13 4.1. EPCS-Capable-Indication . . . . . . . . . . . . . . . . . 13 4.2. EPCS-Regulatory-Info . . . . . . . . . . . . . . . . . . 14 4.3. EPCS-Subscription-Info . . . . . . . . . . . . . . . . . 15 5. Mapping Priority Levels to EDCA and MU-EDCA Parameters . . . 16 6. Relationship Between EPCS Authorization and Invocation . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 19 Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction Priority Services (PS) communications in support of National Security/Emergency Preparedness (NS/EP) services are operational in various countries around the world. While these have traditionally only been supported over cellular networks [TS.22153], the recent addition of Emergency Preparedness Communications Service (EPCS) functionality into Wi-Fi 7 [IEEE80211BE] means that Wi-Fi now supports preferred or prioritized channel access (PCA) to authorized users that can be used for Multimedia Priority Services (MPS) Gundavelli, et al. Expires 12 April 2027 [Page 2] Internet-Draft RADIUS Attributes for EPCS October 2026 communications over public/private Wi-Fi networks in emergency service (ES) scenarios. Whereas Wi-Fi 7 defines the interactions between the Wi-Fi Access Point (AP) and the Wi-Fi Station (STA) device for prioritized channel access, it does not provide an end-to-end architecture for enabling EPCS authorization capability on a per device basis. CSRIC VIII WG4 recommendations for FCC highlight the opportunities for regulatory bodies, like the FCC, to assess and promote Wi-Fi's role in emergency services [CSRC8-WG4]. Earlier deliverables from CSRIC V WG8 have provided recommendations for the role of the network within the priority services platform and to enforce priority levels on traffic associated with priority users [CSRC5-WG8]. There are number of factors critical to this enforcement function: * The priority user must be authenticated and authorized to receive priority treatment. * The network must be able to uniquely identify priority-user traffic and, when applicable, apply the medium-access parameters corresponding to the authorized priority level. * The network must then have the means to apply prioritization to the identified traffic. * For cases where networks interconnect, traffic prioritization indicators must be securely passed to interconnected networks for downstream prioritization. This document specifies extensions to the Remote Authentication Dial- In User Service (RADIUS) protocol [RFC2865] that enable a Wi-Fi Network Access Server (NAS) to indicate to a RADIUS server that it is EPCS capable, enable a RADIUS server to indicate to a NAS that an authenticated user is authorized to receive EPCS, and identify RADIUS accounting sessions [RFC2866] associated with EPCS priority access. This document does not change the handling of emergency calls or other emergency communications, such as calls to 911, 112, or equivalent services. EPCS priority access is intended for authenticated and authorized Wi-Fi priority-service sessions and does not replace or reduce any treatment required for emergency communications. Gundavelli, et al. Expires 12 April 2027 [Page 3] Internet-Draft RADIUS Attributes for EPCS October 2026 1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Terminology Priority Services: A feature designed to enable National Security or Emergency Preparedness subscribers to receive priority treatment for calls or data sessions on a service provider's network, particularly during periods of congestion. Priority Services Authority: A government, regulator, or other competent authority responsible for establishing eligibility for priority services and for designating entities permitted to provision priority-service entitlements or issue EPCS grants. EPCS Authorization Provider: An Identity Provider or service provider designated by a Priority Services Authority to administer priority-service entitlements and issue EPCS grants. In the RADIUS exchange, the EPCS Authorization Provider uses the provisioned entitlement and its authorization policy to determine whether to issue an EPCS grant. It conveys the grant by including the EPCS-Subscription-Info Attribute in an Access- Accept. EPCS-Capable Wi-Fi Access Network: A Wi-Fi access network that supports EPCS priority access to the wireless medium as defined in IEEE 802.11be and can provide such access to authorized users. The network can be operated by a commercial or private Wi-Fi service provider. Wi-Fi Priority Service User: An individual eligible to receive priority services over a Wi-Fi access network. In this document, EPCS priority access is authorized and enabled for an authenticated network session associated with that individual. Gundavelli, et al. Expires 12 April 2027 [Page 4] Internet-Draft RADIUS Attributes for EPCS October 2026 2. Overview of EPCS Provisioning This section first provides background on how MPS service is currently provisioned and authorized. The section then describes how this can be adapted for EPCS to support Wi-Fi use cases. The service user engages with a Priority Services Authority to request the provision of Multimedia Priority Service for a device that has a subscription with a service provider. If the request is successful, the service provider, such as a cellular operator, will receive an indication from the Priority Services Authority, by an out of band mechanism, that a subscriber has been authorized for priority services. The service provider will store such an indication as part of the subscription profile of the subscriber (e.g., in the cellular network defined Home Subscriber Server (HSS)). The Priority Services Authority described in this section approves and provisions priority-service entitlements. During the EPCS RADIUS exchange, the EPCS Authorization Provider uses the provisioned entitlement when deciding whether to issue an EPCS grant. These roles can be performed by the same entity or by different entities, depending on the deployment. Figure 1 illustrates the scenario where the service provider is a cellular operator that is also operating as a Wi-Fi Identity Provider, e.g., using SIM card credentials to authenticate users onto third-party Wi-Fi networks. In such cases, the cellular operator can mirror the priority service subscription profile information in their Wi-Fi Authentication, Authorization and Accounting (AAA) system. Gundavelli, et al. Expires 12 April 2027 [Page 5] Internet-Draft RADIUS Attributes for EPCS October 2026 .---------. .------------. .--------------. .-----------. | Wi-Fi | |EPCS Capable| | Cellular | | Priority | |Priority | |Wi-Fi Access| |Operator/Wi-Fi| | Services | | Service | | Network | | Identity | | Authority | | User | | | | Provider | | | .----+----. .-----+------. .-------+------. .-----+-----. | | | | |1. Standard service user authorization for priority | | Service (unchanged) | | |<--------------------------------------------------->| | | | | | | |2. Receive Priority | | | Authorization | | | 3. Mirror HSS | (unchanged) | | | Authorization |<--------------->| | | in Wi-Fi AAA | | | | .--------| | | | | | | | | .------->| | | | | | | | | | Figure 1: Provisioning Priority Services over Wi-Fi Networks 3. EPCS RADIUS Exchanges 3.1. EPCS Authorization RADIUS Exchange The top level RADIUS Authorization flow for an EPCS Service User is illustrated in Figure 2. Network selection and EPCS authorization are separate functions. A device may use a Passpoint profile [PASSPOINT] to select an access network based on matching network information advertised or provided by the access network. Such information can include an RCOI, an NAI realm, 3GPP cellular network information, or another Passpoint- supported network identifier. The network selection and attachment mechanism used by the device is outside the scope of this document. EPCS authorization can depend on the location of the access network. When location information is supplied, the IdP can use it, according to its authorization policy, to determine whether the access network operates within a regulatory regime for which the IdP is authorized to issue EPCS grants, or whether the access network is within an area affected by an emergency. The IdP can use this determination when deciding whether to grant EPCS authorization and, in deployments that distinguish among multiple priority levels, the permitted priority level. Gundavelli, et al. Expires 12 April 2027 [Page 6] Internet-Draft RADIUS Attributes for EPCS October 2026 Successful authentication using credentials issued by an Identity Provider does not, by itself, authorize EPCS priority access. The ANP accepts an EPCS authorization only when the Access-Accept contains an EPCS-Subscription-Info Attribute and the realm portion of the NAI conveyed in the EAP-Response/Identity is recognized by the ANP as a realm authorized to issue EPCS grants. The presence of the attribute indicates that the EPCS Authorization Provider responsible for that realm has determined, as part of the normal RADIUS authorization process, that the authenticated user is eligible for EPCS priority access. 1. In step 1, the Wi-Fi Access Network Provider configures the access network with the network information used by devices for network discovery and selection. 2. In step 2, the device is provisioned with the network-access profile and credentials required to access the network. 3. In step 3, the device uses network information advertised or provided by the access network to select the network. In a Passpoint deployment, the device matches the Passpoint identifiers advertised in the Wi-Fi beacon, probe response, or Access Network Query Protocol (ANQP) response with identifiers included in its Passpoint profile, as specified in [PASSPOINT]. The Wi-Fi AP includes the EHT MAC Capabilities EPCS Priority Access Support indication in its beacon and probe responses. 4. In steps 4 and 5, the Wi-Fi device associates with the Wi-Fi Access Point/Wireless LAN Controller (AP/WLC). The device indicates its EPCS capability in the EHT Capabilities element included in the Association Request and receives an Association Response from the AP/WLC. 5. In steps 6 and 7, the AP/WLC performs the Extensible Authentication Protocol (EAP) exchange over the LAN using EAPOL frames exchanged with the device. The AP/WLC requests the device's EAP identity and receives the identity associated with the device's network-access credentials in the EAP response. 6. In step 8, the AP/WLC extracts the EAP identity and includes it in a RADIUS Access-Request that is sent to the Identity Provider. In this example, the identity realm corresponds to a cellular operator and is constructed as defined in [TS.23003]. Subject to local policy, the AP/WLC MAY include the Location- Information and Location-Data Attributes defined in [RFC5580]. In the illustrated flow, the AP/WLC also includes the EPCS- Capable-Indication Attribute specified in Section 4.1. Gundavelli, et al. Expires 12 April 2027 [Page 7] Internet-Draft RADIUS Attributes for EPCS October 2026 7. In step 9, the EAP dialogue completes between the supplicant in the Wi-Fi device and the Identity Provider's EAP server. 8. In step 10, the IdP determines, as part of the normal RADIUS authorization process, whether the authenticated user is eligible for EPCS priority access and, when multiple priority levels are supported, the permitted priority level. 9. In step 11, the IdP returns a RADIUS Access-Accept containing the EAP-Success message and the EPCS-Subscription-Info Attribute defined in Section 4.3. The Access-Accept MAY also include the EPCS-Regulatory-Info Attribute defined in Section 4.2. 10. In step 12, the AP/WLC stores the EPCS authorization and, when applicable, the associated priority level received in the Access-Accept. In step 13, the AP/WLC recovers the keying material and forwards the EAP-SUCCESS message to the device. .---------. .------------. .--------------. | Wi-Fi | |EPCS Capable| | Wireless | |Priority | |Wi-Fi Access| | Operator / | | Service | | Network | | Identity | | Device | | | | Provider | '----+----' '-----+------' '-------+------' | | | | | 1. Configure network | | | information | | |--------. | | | | | | |<-------' | | | | | 2. Provision network-access profile | | and credentials | |--------. | | | | | | |<-------' | | | | | | 3. Network information matches the | | network-access profile; EHT MAC | | Capabilities indicate EPCS Priority | | Access Support | |<-----------------| | | | | | 4. Association Request indicating | | EPCS capability in the EHT | | Capabilities element | |----------------->| | | | | Gundavelli, et al. Expires 12 April 2027 [Page 8] Internet-Draft RADIUS Attributes for EPCS October 2026 | 5. Association Response | |<-----------------| | | | | | 6. EAP-Identity Request | |<-----------------| | | | | | 7. EAP-Identity Response | |----------------->| | | | | | | 8. RADIUS Access-Request | | EAP Response Identity | | (opt) Location-Information | | and Location-Data | | EPCS-Capable-Indication | |--------------------->| | | | | 9. EAP Dialogue | |<--------------------------------------->| | | | | | | 10. Determine | | | EPCS | | | authorization | | | and when | | | applicable, | | | priority level | | |--------. | | | | | | |<-------' | | | | | 11. RADIUS Access-Accept | | EAP-Success | | | EPCS-Regulatory-Info | | EPCS-Subscription-Info | |<---------------------| | | | | | 12. Store EPCS authorization | | and when applicable, priority level | |--------. | | | | | | |<-------' | | | | | 13. EAP-SUCCESS | | |<-----------------| | | | | Figure 2: Authorizing Priority Services over Wi-Fi Gundavelli, et al. Expires 12 April 2027 [Page 9] Internet-Draft RADIUS Attributes for EPCS October 2026 The flow in Figure 2 authorizes the device for EPCS and allows the AP/WLC to retain the authorization and priority level. It does not invoke EPCS priority access. Invocation is described in Section 6. 3.2. EPCS Invocation and RADIUS Accounting The RADIUS accounting flow associated with EPCS invocation is illustrated in Figure 3. EPCS authorization can be received when the device initially connects, while EPCS priority access can be invoked later. When EPCS priority access is invoked and RADIUS accounting is enabled for EPCS, the NAS starts an EPCS accounting session using a new Acct-Session-Id. The EPCS accounting session covers only the interval during which EPCS priority access is active. When EPCS priority access ends, the NAS stops the EPCS accounting session. Whether the NAS continues, suspends, or terminates an existing standard Wi-Fi accounting session is an implementation and deployment matter outside the scope of this document. 1. In step 1, the device receives standard Wi-Fi service. The AP/ WLC can have retained an EPCS authorization received during the authorization exchange. 2. In step 2, a higher-layer function at either the STA or the AP/ WLC determines that EPCS priority access is needed. 3. In step 3, the AP/WLC verifies that the device has a valid cached EPCS authorization. In step 4, the STA and AP complete the applicable IEEE 802.11 exchange to invoke EPCS priority access. The exchange can be initiated by either the STA or the AP. 4. If RADIUS accounting is enabled for EPCS, in step 5 the AP/WLC sends an Accounting-Request with Acct-Status-Type set to Start for a new EPCS accounting session. The request contains a new Acct-Session-Id and includes the EPCS-Subscription-Info Attribute indicating the priority level applied to the session. 5. In step 6, the device receives EPCS priority access. 6. In step 7, a higher-layer function at either the STA or the AP/ WLC determines that EPCS priority access is no longer needed. In step 8, the STA and AP complete the applicable IEEE 802.11 procedure to terminate EPCS priority access. Gundavelli, et al. Expires 12 April 2027 [Page 10] Internet-Draft RADIUS Attributes for EPCS October 2026 7. If RADIUS accounting is enabled for EPCS, in step 9 the AP/WLC sends an Accounting-Request with Acct-Status-Type set to Stop for the EPCS accounting session. The request contains the Acct- Session-Id assigned when the session was started and includes the EPCS-Subscription-Info Attribute indicating the priority level applied to the session. 8. In step 10, the device continues to receive standard Wi-Fi service. Gundavelli, et al. Expires 12 April 2027 [Page 11] Internet-Draft RADIUS Attributes for EPCS October 2026 .---------. .------------. .------------. | Wi-Fi | |EPCS Capable| | Wireless | |Priority | |Wi-Fi Access| | Operator | | Service | | Network | | Wi-Fi AAA | | Device | | | | | .----+----. .-----+------. .------+-----. | | | .----+---------------+-----. | |1. Standard Wi-Fi Service | | .----+---------------+-----. | | | | |2. STA or AP/WLC determines that | | EPCS priority access is needed | | | | | |3. Verify cached | | | authorization | | |------. | | | | | | |<-----. | |4. IEEE 802.11 EPCS invocation | | exchange initiated by either | | the STA or AP | |<------------->| | | |5. Accounting-Request | | Acct-Status-Type Start | | Acct-Session-Id | | EPCS-Subscription-Info | |------------------>| .----+---------------+-----. | |6. EPCS Priority Access | | .----+---------------+-----. | | | | |7. STA or AP/WLC determines that | | EPCS priority access should end | | | | |8. IEEE 802.11 EPCS termination | | procedure | |<------------->| | | |9. Accounting-Request | | Acct-Status-Type Stop | | Acct-Session-Id | | EPCS-Subscription-Info | |------------------>| .----+---------------+-----. | |10. Standard Wi-Fi Service| | .----+---------------+-----. | | | | Gundavelli, et al. Expires 12 April 2027 [Page 12] Internet-Draft RADIUS Attributes for EPCS October 2026 Figure 3: EPCS Invocation and RADIUS Accounting 4. RADIUS EPCS Attributes The current RADIUS protocol does not have the support for the flow described in the previous section and therefore, the following attributes are defined in this document. 4.1. EPCS-Capable-Indication Description The EPCS-Capable-Indication (TBA1) Attribute allows a RADIUS NAS to indicate to a RADIUS server how the NAS supports EPCS priority access. One EPCS-Capable-Indication Attribute MAY be included in an Access- Request packet. A summary of the EPCS-Capable-Indication Attribute format is shown in Figure 4. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Capability | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Capability (cont'd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Encoding EPCS-Capable-Indication Attribute Type TBA1, assigned by IANA. Length 6 octets. The length includes the Type, Length, and Capability fields. Capability The Capability field is of data type enum, as defined in Section 3.2 of [RFC8044]. The following values are defined: Gundavelli, et al. Expires 12 April 2027 [Page 13] Internet-Draft RADIUS Attributes for EPCS October 2026 0: EPCS priority access is supported by the NAS regardless of whether the device supports EPCS [FCC]. When the device does not support EPCS, the NAS can prioritize downlink traffic. When the device supports EPCS, the NAS can prioritize both uplink and downlink traffic. 1: EPCS priority access is supported by the NAS only for devices that support EPCS. The NAS can prioritize uplink and downlink traffic for authorized EPCS users. How the NAS prioritizes traffic is vendor-specific and is outside the scope of this document. 4.2. EPCS-Regulatory-Info Description The EPCS-Regulatory-Info (TBA2) Attribute allows a RADIUS server to indicate the regulatory regime applicable to an EPCS grant. One EPCS-Regulatory-Info Attribute MAY be included in an Access- Accept packet. A summary of the EPCS-Regulatory-Info Attribute format is shown in Figure 5. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | Code ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Figure 5: Encoding EPCS-Regulatory-Info Attribute Type TBA2, assigned by IANA. Length 4 octets when the Code field contains a country code, and 6 through 8 octets when the Code field contains a subdivision code. The length includes the Type, Length, and Code fields. Code Gundavelli, et al. Expires 12 April 2027 [Page 14] Internet-Draft RADIUS Attributes for EPCS October 2026 The Code field is of data type text, as defined in Section 3.4 of [RFC8044]. It contains either an ISO 3166-1 alpha-2 country code or an ISO 3166-2 subdivision code [ISO3166]. The country code is represented by two uppercase ASCII letters. A subdivision code consists of a two-letter country code, a hyphen, and one to three uppercase ASCII letters or digits. Examples are US, FR, and US- NY. 4.3. EPCS-Subscription-Info Description The EPCS-Subscription-Info (TBA3) Attribute allows a RADIUS server to indicate that an authenticated user is authorized for EPCS priority access and to specify the priority level authorized for the user. In an Accounting-Request, the attribute allows a NAS to identify an EPCS accounting session and report the priority level applied to that session. An Access-Accept packet MAY contain at most one EPCS-Subscription- Info Attribute. Its presence indicates that the authenticated user is authorized to receive EPCS priority access at the indicated priority level. Exactly one EPCS-Subscription-Info Attribute MUST be included in each Accounting-Request associated with an EPCS accounting session. Its presence identifies the session as an EPCS accounting session, and its Priority-Level field identifies the priority level applied by the NAS to that session. The attribute MUST NOT be included in an Accounting-Request associated with a standard Wi-Fi accounting session. The EPCS-Subscription-Info Attribute is of data type string, as defined in Section 3.5 of [RFC8044]. A summary of the attribute format is shown in Figure 6. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Rsvd | PL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Encoding EPCS-Subscription-Info Attribute Type TBA3, assigned by IANA. Gundavelli, et al. Expires 12 April 2027 [Page 15] Internet-Draft RADIUS Attributes for EPCS October 2026 Length 3 octets. This length includes the Type, Length, Reserved, and Priority-Level fields. Reserved A four-bit field that MUST be set to zero by the sender and ignored by the receiver. Priority-Level (PL) A four-bit unsigned integer identifying the priority level authorized for the user or applied to the EPCS accounting session. The valid range is 1 through 15. A value of zero is invalid. Current deployments can practically operate with a single EPCS priority level. The four-bit Priority-Level field allows additional priority levels to be supported if needed by future deployments. The Priority-Level field identifies the priority level assigned by the EPCS Authorization Provider. The NAS interprets and maps this value to the EPCS priority-access treatment described in Section 5. In a deployment that defines a single EPCS priority level, the Priority-Level field carries the value assigned to that level. 5. Mapping Priority Levels to EDCA and MU-EDCA Parameters The Priority-Level value carried in the EPCS-Subscription-Info Attribute represents the priority level for which the user has been authorized. It does not directly encode an IEEE 802.11 EDCA or MU- EDCA parameter set. The NAS interprets the authorized priority level within the regulatory regime identified by the EPCS-Regulatory-Info Attribute and maps it to the EDCA and, when applicable, MU-EDCA parameter values used for EPCS priority access. The definition of this mapping and the selection of specific EDCA and MU-EDCA parameter values are outside the scope of this document. If the EPCS-Regulatory-Info Attribute is not present, the NAS determines the applicable regulatory regime from local policy or configuration, such as the configured regulatory domain of the access network. Gundavelli, et al. Expires 12 April 2027 [Page 16] Internet-Draft RADIUS Attributes for EPCS October 2026 The mapping is expected to be controlled by local policy or configuration on the AP or WLAN controller. The policy can take into account the applicable regulatory regime, operator policy, radio conditions, link characteristics, and other deployment-specific considerations. The NAS applies the selected parameters using the EPCS priority access procedures defined by IEEE 802.11 [IEEE80211BE]. EDCA-based differentiation is probabilistic and depends on factors such as channel load, the number of contending stations, traffic distribution, and the selected parameter values. Consequently, defining a large number of priority levels does not necessarily result in an equivalent number of operationally distinguishable channel-access behaviors. Deployments are therefore encouraged to map authorized priority levels to a small number of meaningfully differentiated EDCA and MU-EDCA parameter sets. In many deployments, no more than three such parameter sets are expected to provide useful differentiation. 6. Relationship Between EPCS Authorization and Invocation The EPCS-Subscription-Info Attribute authorizes a device to use EPCS priority access but does not invoke the service. The AP/WLC can retain the authorization received in the Access-Accept and use it when EPCS priority access is subsequently invoked by either the STA or the AP. Invocation of EPCS priority access does not, by itself, require a new RADIUS authorization exchange. Before enabling priority access, the AP/WLC verifies that a valid EPCS authorization exists. Reauthorization can be performed when required by local policy. 7. Security Considerations The attributes defined by this document affect the allocation of preferential access to Wi-Fi resources. An attacker that can insert or modify these attributes could obtain unauthorized priority access, alter the assigned priority level, or cause the NAS to apply an incorrect regulatory policy. Gundavelli, et al. Expires 12 April 2027 [Page 17] Internet-Draft RADIUS Attributes for EPCS October 2026 The existence of an emergency, or an indication that the access network is located within an area affected by an emergency, does not by itself authorize EPCS priority access. The NAS MUST accept EPCS authorization attributes only when the realm portion of the user's NAI is recognized by the ANP as a realm authorized to issue EPCS grants. The NAS MUST enable EPCS priority access only for the authenticated network session to which a valid EPCS authorization applies. The NAS MUST validate the received regulatory information and priority level before enabling EPCS priority access. Receipt of an EPCS authorization does not override regulatory requirements or local policy at the NAS. This document does not change the handling of emergency calls or other emergency communications, such as calls to 911, 112, or equivalent services. EPCS priority access MUST NOT override or reduce any priority or access treatment required for such communications by applicable law, regulation, or local policy. The EPCS attributes can reveal that a user is authorized for priority service and the priority level assigned to that user. Location attributes included in an Access-Request can additionally reveal the location of the access network. Implementations MUST protect this information from unauthorized disclosure. The privacy and security considerations in [RFC5580] apply when its location attributes are included. RADIUS packets carrying the attributes defined in this document MUST be protected against unauthorized disclosure and modification. When such packets are sent outside a secure network, implementations MUST use a secure transport, such as IPsec, RADIUS/TLS, or RADIUS/DTLS, as described in [I-D.ietf-radext-deprecating-radius]. 8. IANA Considerations IANA is requested to allocate three Attribute Type Code values from the "RADIUS Attribute Types" registry in the "RADIUS Types" registry group: Gundavelli, et al. Expires 12 April 2027 [Page 18] Internet-Draft RADIUS Attributes for EPCS October 2026 +=======+=========================+===========+=============+ | Value | Description | Data Type | Reference | +=======+=========================+===========+=============+ | TBA1 | EPCS-Capable-Indication | enum | Section 4.1 | +-------+-------------------------+-----------+-------------+ | TBA2 | EPCS-Regulatory-Info | text | Section 4.2 | +-------+-------------------------+-----------+-------------+ | TBA3 | EPCS-Subscription-Info | string | Section 4.3 | +-------+-------------------------+-----------+-------------+ Table 1: RADIUS Attribute Type Allocations RFC Editor: Please replace TBA1, TBA2, and TBA3 throughout this document with the values assigned by IANA and remove this note before publication. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, . [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, DOI 10.17487/RFC2866, June 2000, . [RFC8044] DeKok, A., "Data Types in RADIUS", RFC 8044, DOI 10.17487/RFC8044, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [CSRC5-WG8] WG8, C. S. R. A. I. C. V., "PRIORITY SERVICES", March 2017, . Gundavelli, et al. Expires 12 April 2027 [Page 19] Internet-Draft RADIUS Attributes for EPCS October 2026 [CSRC8-WG4] COMMUNICATIONS SECURITY, RELIABILITY, AND INTEROPERABILITY COUNCIL VIII WG4, "REPORT ON 911 SERVICE OVER WI-FI", March 2023, . [FCC] Federal Communications Commission, "Review of Rules and Requirements For Priority Services", May 2022, . [I-D.ietf-radext-deprecating-radius] DeKok, A., "Deprecating Insecure Practices in RADIUS", Work in Progress, Internet-Draft, draft-ietf-radext- deprecating-radius-10, 3 July 2026, . [IEEE80211BE] IEEE, "Enhancements for Extremely High Throughput (EHT)", IEEE 802.11be-2024 Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment , October 2024. [ISO3166] ISO, "The International Standard for country codes and codes for their subdivisions", n.d., . [PASSPOINT] Wi-Fi Alliance, "Passpoint Specification, v3.3.7", February 2024, . [RFC5580] Tschofenig, H., Ed., Adrangi, F., Jones, M., Lior, A., and B. Aboba, "Carrying Location Objects in RADIUS and Diameter", RFC 5580, DOI 10.17487/RFC5580, August 2009, . [TS.22153] 3GPP, "Multimedia priority service", 3GPP TS 22.153 20.0.0 , January 2025. [TS.23003] 3GPP, "Numbering, addressing and identification", 3GPP TS 23.003 19.0.0 , September 2024. Changelog * draft-ietf-radext-epcs-00: Working Group adoption. The technical content is unchanged from draft-gundavelli-radepcs-03. Gundavelli, et al. Expires 12 April 2027 [Page 20] Internet-Draft RADIUS Attributes for EPCS October 2026 * draft-ietf-radext-epcs-01: Separated the authorization and accounting flows; generalized network selection and attachment; clarified EPCS capability signaling, location-aware authorization, trusted authorization realms, authorization versus invocation, regulatory-domain handling, priority-level mapping, and accounting behavior; expanded the security considerations; and updated author information. Acknowledgements The authors thank the participants of the IETF RADEXT Working Group for their reviews and contributions, with special thanks to Alan DeKok for his valuable feedback and guidance. Authors' Addresses Sri Gundavelli Ameriband San Jose, CA 95135 United States of America Email: sri.ietf@gmail.com Subir Das National Spectrum Consortium Belle Mead, NJ 08502 United States of America Email: subirdas21@gmail.com Mark Grayson Cisco Systems 10 New Square Park Feltham TW14 8HA United Kingdom Email: mgrayson@cisco.com Martin C Dolly AT&T 200 Laurel Avenue Middletown, 07748 United States of America Email: Md3135@att.com Gundavelli, et al. Expires 12 April 2027 [Page 21] Internet-Draft RADIUS Attributes for EPCS October 2026 An Nguyen US DHS/CISA 245 Murray Lane SW, MS0123 Washington, DC, 20528-0123 United States of America Email: an.p.nguyen@cisa.dhs.gov Gundavelli, et al. Expires 12 April 2027 [Page 22]