RADIUS EXTensions K. Rich Internet-Draft D. Harkins Intended status: Standards Track HPE Expires: 7 February 2027 6 August 2026 RADIUS Attribute for IEEE 802.11 WLAN Security Profiles draft-rich-radext-wlan-security-profile-00 Abstract RADIUS has attributes that let an IEEE 802.11 authenticator report the AKM suite and pairwise cipher selected for an association. That is useful, but it is not enough anymore. IEEE 802.11, as amended, also defines security profiles. A security profile is the complete set of AKM, pairwise cipher, and related security capabilities accepted for an association. The problem is that the AKM and the pairwise cipher no longer maps to a single security profile. Using these two values, the RADIUS server cannot tell which of the security profiles was accepted. This document defines the WLAN-Security-Profile RADIUS attribute. The attribute reports the IEEE 802.11 security profile accepted by the responder for the association. It complements the existing IEEE 802 network attributes. 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 7 February 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Rich & Harkins Expires 7 February 2027 [Page 1] Internet-Draft RADIUS WLAN Security Profile August 2026 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 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 3. NAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. When to Include the Attribute . . . . . . . . . . . . . . 4 3.2. What to Report . . . . . . . . . . . . . . . . . . . . . 4 3.3. Consistency Within an Authentication Exchange . . . . . . 5 3.4. Identifier Scope . . . . . . . . . . . . . . . . . . . . 5 4. WLAN-Security-Profile Attribute . . . . . . . . . . . . . . . 5 5. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 6 6. RADIUS Server Processing . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Operational Considerations . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Security Profile Selector Examples . . . . . . . . . 11 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction This document defines the WLAN-Security-Profile RADIUS attribute. It reports the IEEE 802.11 [IEEE80211] security profile that the responder selected for an association. It complements the IEEE 802 attributes defined by RFC 7268 [RFC7268] and changes the meaning or processing of none of them. RFC 7268 gives a RADIUS server WLAN-AKM-Suite and WLAN-Pairwise- Cipher, which report the AKM suite and pairwise cipher selected for an association. IEEE 802.11, as amended, also defines security profiles. A security profile is an atomic set of AKM, pairwise cipher, and related security capabilities, and the responder selects exactly one. Rich & Harkins Expires 7 February 2027 [Page 2] Internet-Draft RADIUS WLAN Security Profile August 2026 Several security profiles can share the same AKM suite and pairwise cipher, so those two values can no longer uniquely identify the security suite the responder selected. The security profiles specify additional security capabilities, such as whether IEEE 802.1X authentication used Authentication frames, whether (Re)Association frames were encrypted, or whether PMKSA caching privacy applied. Because of this, a server cannot tell which security profile is in effect and cannot apply any policy that depends on it. This document depends on the IEEE 802.11 amendment that defines security profiles, so publication is expected to follow ratification of that amendment. Early allocation under [RFC7120] is requested so that implementation and interoperability work are not blocked on it. 2. Conventions and Terminology 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. AKM suite An IEEE 802.11 Authentication and Key Management suite selector. authentication exchange The sequence of Access-Request and Access-Challenge packets that carries one IEEE 802.1X authentication for an association. RADIUS State binds the packets as described by [RFC5080]. NAS A RADIUS Network Access Server. In this document, the NAS is normally the IEEE 802.11 responder and IEEE 802.1X authenticator. supplicant The IEEE 802.11 non-AP station requesting access, acting as the IEEE 802.1X supplicant. security profile An atomic set of AKM, pairwise cipher, and security capabilities, defined by IEEE 802.11 and identified by a Security Profile Number, or defined by another organization and identified by that organization's Organizationally Unique Identifier (OUI) or Company Identifier (CID) together with a value it assigns. Rich & Harkins Expires 7 February 2027 [Page 3] Internet-Draft RADIUS WLAN Security Profile August 2026 Security Profile Selector The four-octet value defined in Section 4 that identifies a security profile. It consists of a 3-octet OUI or CID followed by a 1-octet Profile field. accepted profile The security profile that the IEEE 802.11 responder has validated and accepted. 3. NAS Behavior 3.1. When to Include the Attribute IEEE 802.11 defines how a security profile is advertised, discovered, and negotiated with the responder. Acceptance occurs before the NAS generates its first Access-Request for the association. A NAS generating an Access-Request for an IEEE 802.1X exchange SHOULD include WLAN-Security-Profile once it has accepted a security profile for the association. A NAS MUST omit the attribute if no security profile was accepted. This specification does not require a NAS to generate an Access- Request solely to report a security profile. If no RADIUS exchange occurs, there is nothing to report. Examples include use of a cached PMKSA or an association that does not use IEEE 802.1X. A NAS MUST include no more than one WLAN-Security-Profile attribute in an Access-Request. 3.2. What to Report The value carried in WLAN-Security-Profile identifies the security profile the responder accepted. The NAS MUST NOT report a security profile that it rejected. The NAS MUST NOT report a security profile that was offered but not accepted. If multiple security profiles were advertised, the NAS MUST report only the accepted one. A NAS MUST NOT report a selector value that identifies any security profile other than the accepted one. A NAS MUST NOT report the Security Profile Number that indicates only that a vendor security profile is in use; it MUST report the selector of the accepted vendor security profile instead. Receipt of WLAN-Security-Profile by the RADIUS server means the NAS is asserting that it accepted the reported profile. It does not, by itself, mean the supplicant has completed or successfully validated any later IEEE 802.11 exchange. Rich & Harkins Expires 7 February 2027 [Page 4] Internet-Draft RADIUS WLAN Security Profile August 2026 3.3. Consistency Within an Authentication Exchange Once a NAS has included WLAN-Security-Profile in an Access-Request, any later Access-Request bound to the same authentication exchange that contains WLAN-Security-Profile MUST contain the same value. The NAS MUST NOT change the reported security profile within an authentication exchange. If the IEEE 802.11 exchange restarts with another security profile, the NAS MUST treat it as a new authentication exchange. State from the previous exchange MUST NOT be reused for the new one. 3.4. Identifier Scope This document reports an IEEE 802.11 value only. Other IEEE 802 link types, including MACsec [IEEE8021AE], do not define a security profile and are outside the scope of this document. Reporting a comparable value for another link type would require a separate attribute. If IEEE 802.11 later needs an identifier that does not fit the selector defined in Section 4, a new RADIUS attribute would be required. This document does not reserve part of the selector space for that purpose. 4. WLAN-Security-Profile Attribute The attribute design follows the RADIUS design guidance in [RFC6158] and the data-type requirements in [RFC8044]. Its format matches the IEEE 802 selector attributes already defined by [RFC7268]. 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 | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: WLAN-Security-Profile Attribute Description: Reports the IEEE 802.11 security profile accepted by the responder for the association. Type: TBD1. Rich & Harkins Expires 7 February 2027 [Page 5] Internet-Draft RADIUS WLAN Security Profile August 2026 Length: 6. An attribute with any other Length is invalid as defined by [RFC6929]. Data Type: integer. Value: The Attr-Data field contains a four-octet Security Profile Selector in network byte order. The selector consists of a 3-octet OUI or CID followed by a 1-octet Profile field. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OUI or CID | Profile | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Security Profile Selector IEEE 802.11 defines security profiles under the OUI 00-0F-AC. When the selector carries that OUI, the Profile field is a Security Profile Number. When the selector carries any other OUI or CID, the Profile field is the value assigned by the organization that holds that identifier. IEEE 802.11 vendor security profiles already take this form, so a NAS copies the value unchanged. The IEEE Registration Authority assigns OUIs and CIDs from disjoint spaces [RFC9542], so the two forms cannot collide. The attribute is registered with data type integer because the value is four octets wide; however, the selector is an identifier and integer-oriented arithmetic operations are not valid on this attribute value. The only meaningful comparison is asking whether two selectors are equal. 5. Table of Attributes The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity. Access- Access- Access- Access- Request Accept Reject Challenge # Attribute 0-1 0 0 0 TBD1 WLAN-Security-Profile The following table defines the meaning of the above table entries. Rich & Harkins Expires 7 February 2027 [Page 6] Internet-Draft RADIUS WLAN Security Profile August 2026 0 This attribute MUST NOT be present in the packet. 0-1 Zero or one instance of this attribute MAY be present in the packet. WLAN-Security-Profile MUST NOT occur in any other RADIUS packet type. This version does not define accounting use of the attribute. 6. RADIUS Server Processing A RADIUS server MAY use WLAN-Security-Profile as input to local policy. The server MUST treat it as lower-layer context asserted by the NAS and MUST NOT treat it as evidence that the supplicant was authenticated. When local policy requires a specific WLAN security profile, the server MUST NOT treat an absent, duplicate, invalid, or unknown WLAN- Security-Profile value as satisfying that policy. An unknown Security Profile Selector MUST NOT be treated as equivalent to any known security profile, although a server MAY apply a distinct policy explicitly configured for unknown or future security profiles. A Security Profile Number identifies exactly one AKM, so a server does not need WLAN-AKM-Suite to determine which AKM the reported security profile uses. When both attributes are present and the selector carries the OUI 00-0F-AC, a server MAY check that the two agree. The NAS derives the two values separately, so a disagreement indicates a NAS defect, a stale mapping table, or modification of the request along the path. A server MUST NOT resolve a disagreement by translating or remapping either value. A selector carrying any other OUI or CID is not subject to this check, because the organization that holds the identifier defines what the value means. A server MAY use WLAN-Security-Profile to select EAP-TLS or TLS policy. EAP-TLS [RFC9190] and TLS [RFC9846] remain responsible for their own negotiation and authentication. Receipt of the attribute does not prove that any particular TLS group, signature algorithm, cipher suite, or other TLS parameter was used. 7. Security Considerations WLAN-Security-Profile is an assertion by the NAS about the IEEE 802.11 link. A server learns what the NAS reports, not something the supplicant confirmed, and even a trusted NAS can inadvertently report a wrong value. The generic RADIUS threats described in [RFC2865] and [RFC3579] apply as they do to any attribute. Rich & Harkins Expires 7 February 2027 [Page 7] Internet-Draft RADIUS WLAN Security Profile August 2026 Removing the attribute, such as by a proxy along the path, is a silent downgrade. A server cannot tell a stripped attribute from a NAS that never sent one. The attribute can reveal the WLAN security posture of a deployment. Confidential transport reduces that exposure. 8. Operational Considerations A RADIUS server should be able to update the IEEE 802.11 security profile mapping used for policy evaluation independently of its RADIUS protocol implementation. IEEE 802.11 assigns security profiles on its own schedule, so a server that builds the mapping into its code needs a software change every time. A security profile that is simply absent from the mapping usually means the mapping predates a later IEEE 802.11 assignment, not that the NAS is misbehaving. Logs should identify the received Security Profile Selector, any received WLAN-AKM-Suite, and the local mapping revision or configuration used to interpret them. Implementations should show named security profiles to policy administrators while retaining the selector values in protocol logs. WLAN-Security-Profile is incrementally deployable with RADIUS implementations and proxy paths that preserve unknown attributes under existing RADIUS behavior. A legacy server cannot apply profile-specific policy. A proxy that removes the attribute can cause a request to fail policy that requires a security profile. Operators should test proxy paths before enabling such policy. 9. IANA Considerations IANA is requested to allocate one value from the standard space of the "RADIUS Attribute Types" registry. This request is consistent with the allocation preference in [RFC6929] for specifications defining fewer than ten attributes. IANA is requested to assign the value 191 if it is available. That value directly follows WLAN-RF-Band, the last of the IEEE 802 attributes defined by [RFC7268], and assigning it keeps the IEEE 802.11 attributes in one contiguous block. Rich & Harkins Expires 7 February 2027 [Page 8] Internet-Draft RADIUS WLAN Security Profile August 2026 +=======+=======================+===========+===========+ | Value | Description | Data Type | Reference | +=======+=======================+===========+===========+ | TBD1 | WLAN-Security-Profile | integer | RFC-to-be | +-------+-----------------------+-----------+-----------+ Table 1: Requested RADIUS Attribute Type The requested data type matches the data type registered for the IEEE 802 selector attributes defined by [RFC7268]. This document does not create or modify an IANA registry for WLAN security profiles. IEEE 802.11 owns the Security Profile Number namespace. Each organization owns the value space under its own OUI or CID. 10. References 10.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, . [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, DOI 10.17487/RFC3579, September 2003, . [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, DOI 10.17487/RFC5080, December 2007, . [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", RFC 6929, DOI 10.17487/RFC6929, April 2013, . Rich & Harkins Expires 7 February 2027 [Page 9] Internet-Draft RADIUS WLAN Security Profile August 2026 [RFC7268] Aboba, B., Malinen, J., Congdon, P., Salowey, J., and M. Jones, "RADIUS Attributes for IEEE 802 Networks", RFC 7268, DOI 10.17487/RFC7268, July 2014, . [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, . [IEEE80211] IEEE, "IEEE Standard for Information Technology - Telecommunications and Information Exchange between Systems Local and Metropolitan Area Networks - Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", as amended by the IEEE 802.11 amendment defining security profiles, IEEE Std 802.11-2020, February 2021. 10.2. Informative References [RFC6158] DeKok, A., Ed. and G. Weber, "RADIUS Design Guidelines", BCP 158, RFC 6158, DOI 10.17487/RFC6158, March 2011, . [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, . [RFC9190] Preuß Mattsson, J. and M. Sethi, "EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3", RFC 9190, DOI 10.17487/RFC9190, February 2022, . [RFC9542] Eastlake 3rd, D., Abley, J., and Y. Li, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 9542, DOI 10.17487/RFC9542, April 2024, . [RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026, . Rich & Harkins Expires 7 February 2027 [Page 10] Internet-Draft RADIUS WLAN Security Profile August 2026 [IEEE8021AE] IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Media Access Control (MAC) Security", IEEE Std 802.1AE-2018, December 2018. Appendix A. Security Profile Selector Examples This appendix is nonnormative. It shows both forms of the Security Profile Selector defined in Section 4. In the first example the responder accepts a security profile defined by IEEE 802.11 and identified by the Security Profile Number NN. The NAS prefixes that number with 00-0F-AC. Type TBD1 Length 6 Value 00-0F-AC-NN Figure 3: Encoded IEEE Security Profile NN stands for whichever Security Profile Number the responder accepted. This document does not use a specific number, because IEEE 802.11 has not reserved one for use in examples. In the second example the responder accepts a vendor-defined security profile identified by the OUI 04-22-34 and the Profile value 42. IEEE 802.11 already identifies the profile by those four octets, so the NAS copies them into the Attr-Data field without change. Type TBD1 Length 6 Value 04-22-34-42 Figure 4: Encoded Vendor Security Profile 04-22-34 is an Organizationally Unique Identifier assigned by the IEEE Registration Authority. The Profile value 42 under it carries no assigned meaning and appears here only to show the encoding. The server applies whatever policy is configured for the selector it receives. In the vendor case the AKM comparison described in Section 6 does not apply, because the OUI is not 00-0F-AC and the organization that holds the identifier defines what the value means. Appendix B. Open Issues Rich & Harkins Expires 7 February 2027 [Page 11] Internet-Draft RADIUS WLAN Security Profile August 2026 * Confirm through RADEXT review that the joint-processing requirements preserve RFC 7268 semantics and still give clear behavior when both attributes are present. * Confirm the exact designation of the normative IEEE 802.11 reference once the amendment defining security profiles is ratified, and update the citation accordingly. * Confirm with IEEE 802.11 that a Security Profile Selector of 00- 0F-AC followed by a Security Profile Number is an acceptable way to render an IEEE-defined security profile outside IEEE 802.11. The vendor form already matches the OUI and OUI Type format used by IEEE 802.11. * Confirm that a vendor security profile can be identified unambiguously on every path that reaches an Access-Request, and that the Security Profile Number used to indicate a vendor security profile is stable. * Settle the exact IEEE clause and table citations once the amendments stabilize. * Determine whether operators need the accepted security profile in Accounting-Request records for audit or compliance evidence. Authors' Addresses Ken Rich HPE Email: ken.rich@hpe.com Dan Harkins HPE Email: daniel.harkins@hpe.com Rich & Harkins Expires 7 February 2027 [Page 12]