ietf-corpus

rfc-7268

RADIUS Attributes for IEEE 802 Networks

B. Aboba, J. Malinen, P. Congdon, J. Salowey, M. Jones
date2014-07 streamIETF areasec wgradext statusPROPOSED STANDARD pages29 canonicalhttps://www.rfc-editor.org/rfc/rfc7268 doi10.17487/RFC7268
RFC 3580 provides guidelines for the use of the Remote Authentication Dial-In User Service (RADIUS) within IEEE 802 local area networks (LANs). This document defines additional attributes for use within IEEE 802 networks and clarifies the usage of the EAP-Key-Name Attribute and the Called-Station-Id Attribute. This document updates RFCs 3580 and 4072.

updated by

updates

Extracted elements (27)

design-rationale §2.7

A separate Network-Id-Name Attribute is defined because the IEEE 802.1X NID-Name can be up to 253 octets, whereas the IEEE 802.11 SSID is at most 32 octets. When the Called-Station-Id Attribute already carries a MAC address there may not be sufficient remaining space for a full NID-Name, necessitating the separate attribute for wired 802.1X deployments.

radius

design-rationale §4

No IANA registries are established by this document for the values within the new attributes because all value assignments (cipher suite identifiers, AKM suite identifiers, Venue Group/Type codes, RF Band IDs, Reason Codes) are governed entirely by IEEE 802 standards, not by IANA.

radius, registry

design-rationale §2.2

The EAP-Key-Name Attribute in an Access-Request is constrained to a single NUL character because the NAS operates as a pass-through in EAP and cannot know the EAP Session-Id before receiving it from the RADIUS server. The placeholder NUL signals to the server that the NAS requires the EAP Session-Id in the Access-Accept.

radius, security

interoperability-note §2.1

The Allowed-Called-Station-Id Attribute is designed primarily for wireless pre-authentication scenarios (e.g., IEEE 802.11 pre-authentication) where no Called-Station-Id is present in the Access-Request. The attribute is expected to be used largely in wireless access scenarios; the potential lack of space for a full NID-Name in wired 802.1X scenarios is acknowledged but not considered serious.

radius

interoperability-note §2.17

The WLAN-Group-Mgmt-Cipher Attribute's presence in an Access-Request or Accounting-Request indicates that the Station negotiated management frame protection during association; its absence signifies no such negotiation took place. This implicit signaling means implementations must treat absence and presence as semantically distinct.

radius, security

normative-requirement §2.2 MUST

An EAP-Key-Name Attribute sent in an Access-Request MUST contain only a single NUL character, because the NAS operates as a pass-through in EAP and cannot know the EAP Session-Id before receiving it from the RADIUS server. A RADIUS server receiving an Access-Request with an EAP-Key-Name Attribute containing anything other than a single NUL character MUST silently discard the attribute.

radius, security

normative-requirement §2.3 MUST

An EAP-Peer-Id Attribute sent in an Access-Request MUST contain only a single NUL character. A home RADIUS server receiving an Access-Request with an EAP-Peer-Id Attribute containing anything other than a single NUL character MUST silently discard the attribute.

radius, security

normative-requirement §2.1 MUST NOT

If a user connects to a Called-Station-Id that does not match any Allowed-Called-Station-Id Attribute provided by the RADIUS server, the NAS MUST NOT permit the user to access the network.

radius, security

normative-requirement §2.2 SHOULD

If an EAP-Key-Name Attribute is included in an Access-Request but is absent from the corresponding Access-Accept, the NAS SHOULD treat the Access-Accept as though it were an Access-Reject, since the NAS only sends EAP-Key-Name when it is required to provision service. Conversely, if EAP-Key-Name was not in the Access-Request but appears in the Access-Accept, the NAS SHOULD silently discard it.

radius, security

normative-requirement §2.8 MUST

If multiple EAPoL-Announcement Attributes are present in a packet, their String fields MUST be concatenated before being parsed for EAPoL-Announcement TLVs, enabling TLVs longer than 253 octets to be transported. Similarly, EAPoL-Announcement TLVs larger than 253 octets MUST be fragmented across multiple EAPoL-Announcement Attributes.

radius

normative-requirement §2.7 MUST NOT

The Network-Id-Name Attribute MUST NOT be used to encode the IEEE 802.11 SSID; the Called-Station-Id Attribute is used for that purpose per RFC 3580. When used with IEEE 802.1X wired networks, the Called-Station-Id Attribute SHOULD contain only the MAC address, with the NID-Name carried in the Network-Id-Name Attribute.

radius

normative-requirement §5 SHOULD

When Access-Request cipher or AKM suite attributes (WLAN-Pairwise-Cipher, WLAN-Group-Cipher, WLAN-AKM-Suite, or WLAN-Group-Mgmt-Cipher) are unacceptable to the RADIUS server, a WLAN-Reason-Code Attribute with value 29 ('Requested service rejected because of service provider ciphersuite or AKM requirement') SHOULD be returned in the Access-Reject.

radius, security

protocol-element §2.1

Allowed-Called-Station-Id (Type 174) allows the RADIUS server to specify the authenticator MAC addresses and/or network names to which a user is permitted to connect. One or more instances MAY appear in Access-Accept, CoA-Request, or Accounting-Request packets. Format is Type/Length/String with Length >= 3.

radius, security

protocol-element §2.2

EAP-Key-Name (Type 102, originally from RFC 4072) contains the EAP Session-Id as defined in RFC 5247. It MAY appear in Access-Request, Access-Accept, and CoA-Request packets. For IEEE 802.1X MACsec, the Connectivity Association Key Name (CKN) is derived from the EAP Session-Id and is required for the MACsec Key Agreement (MKA) exchange.

radius, security, crypto

protocol-element §2.3

EAP-Peer-Id (Type 175) carries a Peer-Id generated by the EAP method as defined in RFC 5247 Appendix A. At most one instance MUST NOT appear in an Access-Request (placeholder NUL only); one or more instances MAY appear in Access-Accept and Accounting-Request packets.

radius, security

protocol-element §2.4

EAP-Server-Id (Type 176) carries a Server-Id generated by the EAP method as defined in RFC 5247 Appendix A. At most one instance MUST NOT appear in an Access-Request (NUL placeholder); one or more instances MAY appear in Access-Accept and Accounting-Request. The home RADIUS server SHOULD include it in the Access-Accept only if it was present in the Access-Request.

radius, security

protocol-element §2.8

EAPoL-Announcement (Type 180) carries EAPoL-Announcement TLV tuples from IEEE 802.1X Table 11-8, including Organizationally Specific TLVs. Zero or more instances are permitted in Access-Request, Access-Accept, Access-Challenge, Access-Reject, Accounting-Request, CoA-Request, and Disconnect-Request packets.

radius

protocol-element §2.7

Network-Id-Name (Type 179) carries the IEEE 802.1X NID-Name (up to 253 octets). Zero or one instance is permitted in Access-Request (hint), Access-Challenge, Access-Accept (authorized NID), and Accounting-Request packets. In an Access-Request it represents a hint of the desired NID-Name; in an Access-Accept it is the authorized NID-Name.

radius

protocol-element §2.6

Preauth-Timeout (Type 178) sets the maximum number of seconds the NAS must retain pre-authentication state (e.g., a Pairwise Master Key derived via IEEE 802.11 pre-authentication) before the session is established. After a session is underway, this attribute has no effect; Session-Timeout governs maximum session time.

radius, security

protocol-element §2.13

WLAN-Reason-Code (Type 185) carries the IEEE 802.11 Reason Code (Table 8-36) to be copied by the AP into a Disassociation or Deauthentication frame upon receipt of an Access-Reject or Disconnect-Request. It MAY appear in Access-Reject, Disconnect-Request, and Accounting-Request packets.

radius, security

registry §4

IANA assigned RADIUS attribute type codes 174–190 for the new attributes defined in this document: Allowed-Called-Station-Id (174), EAP-Peer-Id (175), EAP-Server-Id (176), Mobility-Domain-Id (177), Preauth-Timeout (178), Network-Id-Name (179), EAPoL-Announcement (180), WLAN-HESSID (181), WLAN-Venue-Info (182), WLAN-Venue-Language (183), WLAN-Venue-Name (184), WLAN-Reason-Code (185), WLAN-Pairwise-Cipher (186), WLAN-Group-Cipher (187), WLAN-AKM-Suite (188), WLAN-Group-Mgmt-Cipher (189), and WLAN-RF-Band (190). No new IANA registries are established because all values are assigned by IEEE 802.

radius, registry, security

security-consideration §5

When RADIUS traffic is transmitted in the clear, all attributes defined in this document—including cipher suites, AKM suites, EAP identifiers, and venue metadata—are exposed to an attacker snooping the exchange between RADIUS client and server. RADIUS confidentiality is therefore desirable; RFC 6421 covers RADIUS security and crypto-agility requirements.

radius, security, crypto

wire-format §2.1

Allowed-Called-Station-Id encodes the MAC address as uppercase ASCII in canonical format with octets separated by '-' (e.g., '00-10-A4-23-19-C0'). When network-name restrictions are also intended, the network name is appended after ':', e.g., '00-10-A4-23-19-C0:AP1'. When only a network-name restriction is intended, the MAC address field is omitted but ':' and the network name are included, e.g., ':AP1'.

radius

wire-format §2.5

Mobility-Domain-Id (Type 177) has a fixed Length of 6 (Type + Length + 4-octet Value). The Value is a 32-bit unsigned integer where the two most significant octets MUST be set to zero; the two least significant octets carry the IEEE 802.11 Mobility Domain Identifier (MDID).

radius

wire-format §2.9

WLAN-HESSID (Type 181) has a fixed Length of 19 (Type + Length + 17-octet String). The String encodes a MAC address in uppercase ASCII with octets separated by '-', identifying the Homogeneous Extended Service Set for use with subscription service provider network identification.

radius

wire-format §2.18

WLAN-RF-Band (Type 190) has a fixed Length of 6 (Type + Length + 4-octet Value). The three most significant octets MUST be set to zero by the sender; the least significant octet carries the RF Band field using values from IEEE 802.11ad Table 8-53a Band ID field.

radius

wire-format §2.14

WLAN-Venue-Info (Type 182), WLAN-Pairwise-Cipher (Type 186), WLAN-Group-Cipher (Type 187), WLAN-AKM-Suite (Type 188), and WLAN-Group-Mgmt-Cipher (Type 189) all use a 6-octet format (Type + Length + 4-octet Value). For cipher/AKM suites the 4-byte Value uses IEEE 802.11 Suite Selector format: 3-octet OUI followed by 1-octet Suite Type.

radius, crypto