| Internet-Draft | RADIUS WLAN Security Profile | August 2026 |
| Rich & Harkins | Expires 7 February 2027 | [Page] |
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.¶
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 (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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
| Value | Description | Data Type | Reference |
|---|---|---|---|
| TBD1 | WLAN-Security-Profile | integer | RFC-to-be |
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.¶
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
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
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.¶