]> HPE

ken.rich@hpe.com

HPE

daniel.harkins@hpe.com

Security RADIUS EXTensions RADIUS IEEE 802.11 security profile 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.

Introduction This document defines the WLAN-Security-Profile RADIUS attribute. It reports the IEEE 802.11 security profile that the responder selected for an association. It complements the IEEE 802 attributes defined by RFC 7268 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 is requested so that implementation and interoperability work are not blocked on it.

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 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 .

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.

Security Profile Selector

The four-octet value defined in 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.

NAS Behavior

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.

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.

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.

Identifier Scope This document reports an IEEE 802.11 value only. Other IEEE 802 link types, including MACsec , 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 , a new RADIUS attribute would be required. This document does not reserve part of the selector space for that purpose.

WLAN-Security-Profile Attribute The attribute design follows the RADIUS design guidance in and the data-type requirements in . Its format matches the IEEE 802 selector attributes already defined by .

WLAN-Security-Profile Attribute

Description:

Reports the IEEE 802.11 security profile accepted by the responder for the association.

Type:

TBD1.

Length:

6. An attribute with any other Length is invalid as defined by .

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.

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 , 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.

Table of Attributes The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity. The following table defines the meaning of the above table entries. WLAN-Security-Profile MUST NOT occur in any other RADIUS packet type. This version does not define accounting use of the attribute.

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 and TLS 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.

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 and 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.

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.

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 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 , and assigning it keeps the IEEE 802.11 attributes in one contiguous block. Requested RADIUS Attribute Type

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 . 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.

References Normative References &RFC2119; &RFC2865; &RFC3579; &RFC5080; &RFC6929; &RFC7268; &RFC8044; &RFC8174; IEEE as amended by the IEEE 802.11 amendment defining security profiles Informative References &RFC6158; &RFC7120; &RFC9190; &RFC9542; &RFC9846; IEEE

Security Profile Selector Examples This appendix is nonnormative. It shows both forms of the Security Profile Selector defined in . 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.

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.

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 does not apply, because the OUI is not 00-0F-AC and the organization that holds the identifier defines what the value means.

Open Issues

• 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.