RFC 7268

RADIUS Attributes for IEEE 802 Networks

📅 published July 2014, from ietf

RFC 7268: RADIUS Attributes for IEEE 802 Networks 🎀

Okay bestie, this one is RFC 7268 and it's all about RADIUS attributes for IEEE 802 networks 🦋 It was published by the Internet Engineering Task Force (IETF) in July 2014 and it's a Standards Track document, so it's officially part of the Internet's rulebook 💅

Request for Comments: 7268
Category: Standards Track
ISSN: 2070-1721
Date: July 2014
Updates: RFC 3580 and RFC 4072 ✨
Authors: B. Aboba (Microsoft Corporation), J. Malinen (Independent), P. Congdon (Tallac Networks), J. Salowey (Cisco Systems), M. Jones (Azuca Systems) 👑

Abstract ✨

Okay so, RFC 3580 gives guidelines for using the Remote Authentication Dial-In User Service (RADIUS) inside IEEE 802 local area networks (LANs) 🌸 This document adds new attributes for IEEE 802 networks, and it also clarifies how the EAP-Key-Name Attribute and the Called-Station-Id Attribute get used. It updates RFCs 3580 and 4072, so those two are getting a glow-up too 💖

Status of This Memo 🧚

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741.

You can check the current status of this document, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc7268 🔥

Copyright Notice 💜

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the date this document was published. Please read these carefully, because they explain your rights and restrictions for this document. Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 🦋

This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people controlling the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. Unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The one exception is formatting it for publication as an RFC or translating it into languages other than English 🌈

Table of Contents 🍓

   1. Introduction ....................................................3
      1.1. Terminology ................................................4
      1.2. Requirements Language ......................................4
   2. RADIUS Attributes ...............................................5
      2.1. Allowed-Called-Station-Id ..................................5
      2.2. EAP-Key-Name ...............................................6
      2.3. EAP-Peer-Id ................................................7
      2.4. EAP-Server-Id ..............................................8
      2.5. Mobility-Domain-Id .........................................9
      2.6. Preauth-Timeout ...........................................10
      2.7. Network-Id-Name ...........................................11
      2.8. EAPoL-Announcement ........................................12
      2.9. WLAN-HESSID ...............................................14
      2.10. WLAN-Venue-Info ..........................................14
      2.11. WLAN-Venue-Language ......................................16
      2.12. WLAN-Venue-Name ..........................................17
      2.13. WLAN-Reason-Code .........................................18
      2.14. WLAN-Pairwise-Cipher .....................................19
      2.15. WLAN-Group-Cipher ........................................20
      2.16. WLAN-AKM-Suite ...........................................21
      2.17. WLAN-Group-Mgmt-Cipher ...................................22
      2.18. WLAN-RF-Band .............................................23
   3. Table of Attributes ............................................24
   4. IANA Considerations ............................................25
   5. Security Considerations ........................................25
   6. References .....................................................26
      6.1. Normative References ......................................26
      6.2. Informative References ....................................27
   7. Acknowledgments ................................................28

1. Introduction 🌸

Okay so, when you want to manage authentication, authorization, and accounting (AAA) centrally for IEEE 802 [IEEE-802] networks, it's basically expected that you'll deploy a backend authentication and accounting server 🫶 In that setup, IEEE 802 authenticators are expected to act as AAA clients.

"IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines" [RFC3580] is the guide for using RADIUS inside networks that run on IEEE 802 local area networks. This document adds more attributes for IEEE 802 authenticators that are acting as AAA clients ✨

1.1. Terminology 🧚

This document uses the following terms:

Access Point (AP) : A Station that provides access to the distribution services via the wireless medium for associated Stations.

Association : The service used to establish Access Point/Station mapping and enable Station invocation of the distribution system services.

Authenticator : An entity that requires authentication from the Supplicant. The authenticator may be connected to the Supplicant at the other end of a point-to-point LAN segment or wireless link.

Authentication Server : An entity that provides an authentication service to an authenticator. This service verifies the claim of identity made by the Supplicant using the credentials provided by the Supplicant

Station (STA) : Any device that contains an IEEE 802.11 conformant Medium Access Control (MAC) and Physical Layer (PHY) interface to the wireless medium (WM).

Supplicant : An entity that is being authenticated by an authenticator. The Supplicant may be connected to the authenticator at one end of a point-to-point LAN segment or 802.11 wireless link.

1.2. Requirements Language 💅

In this document, several words are used to signify the requirements of the specification. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🎀

2. RADIUS Attributes 🦋

2.1. Allowed-Called-Station-Id 👑

Description

The Allowed-Called-Station-Id Attribute lets the RADIUS server say which authenticator MAC addresses and/or networks the user is allowed to connect to. One or more Allowed-Called-Station-Id Attributes MAY be included in an Access-Accept, CoA-Request, or Accounting-Request packet.

This one is really useful when pre-authentication is supported (for example, IEEE 802.11 pre-authentication). In those scenarios, a Called-Station-Id Attribute usually isn't included in the Access-Request, so the RADIUS server doesn't know which network the user is trying to get into 🙈 The Allowed-Called-Station-Id lets the RADIUS server restrict the networks and attachment points the user can connect to afterwards. It's giving control 💖

A summary of the Allowed-Called-Station-Id Attribute format is shown below. 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       |            String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

174

Length

>=3

String

The String field is one or more octets, specifying a Called-Station-Id that the user MAY connect to. If the Called-Station-Id that the user connects to does not match one of the Allowed-Called-Station-Id Attributes, the Network Access Server (NAS) MUST NOT permit the user to access the network. 🚫

In the case of IEEE 802, the Allowed-Called-Station-Id Attribute is used to store the Medium Access Control (MAC) address. It's represented as an uppercase ASCII character string in Canonical format, with octet values separated by a "-". For example, "00-10-A4-23-19-C0". Where restrictions on both the network and authenticator MAC address usage are intended, the network name MUST be appended to the authenticator MAC address, separated from the MAC address with a ":". For example, "00-10-A4-23-19-C0:AP1". Where no MAC address restriction is intended, the MAC address field MUST be omitted, but ":" and the network name field MUST be included. For example, ":AP1" 🧚

Within IEEE 802.11 [IEEE-802.11], the Service Set Identifier (SSID) is the network name. Within IEEE 802.1X [IEEE-802.1X] wired networks, the Network-Id Name (NID-Name) is the network name. Since a NID-Name can be up to 253 octets long, when it's used with [IEEE-802.1X] wired networks, there may not be enough room in the Allowed-Called-Station-Id Attribute to include both a MAC address and a network name. But the Allowed-Called-Station-Id Attribute is expected to be used mostly in wireless access scenarios, so this restriction isn't considered serious 🌈

2.2. EAP-Key-Name ✨

Description

okay so the EAP-Key-Name Attribute is defined in "Diameter Extensible Authentication Protocol (EAP) Application" [RFC4072], and it carries the EAP Session-Id, which is explained in "Extensible Authentication Protocol (EAP) Key Management Framework" [RFC5247]. how it gets used totally depends on the link layer 💅

ngl not every link layer uses this name 🙈 An EAP-Key-Name Attribute MAY be included within Access-Request, Access-Accept, and CoA-Request packets. here's the format (fields go left to right, obvi) 🦋

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

Type

102 [RFC4072] 🔥

Length

>=3 ✨

String

the String field is one or more octets, containing the EAP Session-Id, as defined in "Extensible Authentication Protocol (EAP) Key Management Framework" [RFC5247]. here's the tea 🫖 the NAS is a pass-through in EAP, so it literally cannot know the EAP Session-Id until the RADIUS server sends it over. so an EAP-Key-Name Attribute sent in an Access-Request MUST only contain a single NUL character. a RADIUS server that gets an Access-Request with an EAP-Key-Name Attribute holding anything other than a single NUL character MUST silently discard the attribute 💀

the RADIUS server SHOULD include this attribute in an Access-Accept or CoA-Request only if an EAP-Key-Name Attribute was present in the Access-Request. a NAS will usually only put an EAP-Key-Name Attribute in an Access-Request when it's needed to provision service, so if one is in the Access-Request but missing from the Access-Accept, the NAS SHOULD treat the Access-Accept as though it were an Access-Reject 😭 and if an EAP-Key-Name Attribute was not in the Access-Request but shows up in the Access-Accept, the NAS SHOULD silently discard the EAP-Key-Name Attribute 🫶

now the MACsec part, which is lowkey my favorite 🌈 as noted in Section 6.2.2 of [IEEE-802.1X], the Connectivity Association Key Name (CKN) is derived from the EAP Session-Id. then, as described in Section 9.3.3 of [IEEE-802.1X], the CKN is used to derive the Key Encrypting Key (KEK) and the Integrity Check Value Key (ICK), which protect the Secure Association Keys (SAKs) used by Media Access Control Security (MACsec). so for the NAS to get what it needs for the MACsec Key Agreement (MKA) exchange, it has to include the EAP-Key-Name Attribute in the Access-Request and receive it back from the RADIUS server in the Access-Accept. iconic 👑

2.3. EAP-Peer-Id ✨

Description

the EAP-Peer-Id Attribute holds a Peer-Id that the EAP method generates 🧚 how this name gets used depends on the link layer, so check [RFC5247] for more tea. the EAP-Peer-Id Attribute MAY be included in Access-Request, Access-Accept, and Accounting-Request packets. but more than one EAP-Peer-Id Attribute MUST NOT be included in an Access-Request, while one or more EAP-Peer-Id Attributes MAY be included in an Access-Accept 🍓

it should be noted that not all link layers use this name, and existing EAP method implementations don't generate it 💅 since the NAS is a pass-through in EAP [RFC3748], it can't know the EAP-Peer-Id before the RADIUS server gives it to it. so an EAP-Peer-Id Attribute sent in an Access-Request MUST only contain a single NUL character. a home RADIUS server that receives an Access-Request with an EAP-Peer-Id Attribute holding anything other than a single NUL character MUST silently discard the attribute 💀 the home RADIUS server SHOULD include one or more EAP-Peer-Id Attributes in an Access-Accept only if an EAP-Peer-Id Attribute was in the Access-Request. and if a NAS gets EAP-Peer-Id Attribute(s) in an Access-Accept without having sent one in the Access-Request, the NAS SHOULD silently discard the attribute(s) 🙈 here's the format, fields 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       |            String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

175 ✨

Length

>=3 🎀

String

the String field is one or more octets, containing an EAP Peer-Id exported by the EAP method. for the details, look at Appendix A of [RFC5247]. a robust implementation SHOULD support the field as undistinguished octets 🔥 only a single EAP Peer-Id may be included per attribute.

2.4. EAP-Server-Id ✨

Description

the EAP-Server-Id Attribute holds a Server-Id that the EAP method generates 🦋 how it's used depends on the link layer, and [RFC5247] has the deets. the EAP-Server-Id Attribute is only allowed in Access-Request, Access-Accept, and Accounting-Request packets. more than one EAP-Server-Id Attribute MUST NOT be included in an Access-Request, but one or more EAP-Server-Id Attributes MAY be included in an Access-Accept 👑

it should be noted that not all link layers use this name, and existing EAP method implementations don't generate it 🌸 since the NAS is a pass-through in EAP [RFC3748], it can't know the EAP-Server-Id before the RADIUS server sends it. so an EAP-Server-Id Attribute sent in an Access-Request MUST contain only a single NUL character. a home RADIUS server that gets an Access-Request with an EAP-Server-Id Attribute holding anything other than a single NUL character MUST silently discard the attribute 💀 the home RADIUS server SHOULD include this attribute in an Access-Accept only if an EAP-Server-Id Attribute was in the Access-Request. here's the format:

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

Type

176 💜

Length

>=3 🧚

String

the String field is one or more octets, containing an EAP Server-Id exported by the EAP method. for details, see Appendix A of [RFC5247]. a robust implementation SHOULD support the field as undistinguished octets ✨

2.5. Mobility-Domain-Id ✨

Description

a single Mobility-Domain-Id Attribute MAY be included in an Access-Request or Accounting-Request so the NAS can give the RADIUS server the Mobility Domain Identifier (MDID), which is defined in Section 8.4.2.49 of [IEEE-802.11] 🌈 here's the format, 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     |             Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Value                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

177 🎀

Length

6 🍓

Value

the Value field is four octets, holding a 32-bit unsigned integer 🫶 the two most significant octets MUST be set to zero by the sender and are ignored by the receiver. the two least significant octets hold the Mobility Domain Identifier (MDID) from Section 8.4.2.49 of [IEEE-802.11] 💅

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Reserved           |   Mobility Domain Identifier  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.6. Preauth-Timeout ✨

Description

this attribute sets the maximum number of seconds that the NAS has to keep pre-authentication state without it being used in a user session ⏳ for example, when [IEEE-802.11] pre-authentication is used, if a user hasn't tried to use the Pairwise Master Key (PMK) that came from pre-authentication within the time set by the Preauth-Timeout Attribute, the Access Point MAY discard the PMK 🌸 but once the session is underway, the Preauth-Timeout Attribute has no say over the user's maximum session time or how long key state can be kept before re-authentication. that's the job of the Session-Timeout Attribute, if it's present 👑

a single Preauth-Timeout Attribute MAY be included within an Access-Accept or CoA-Request packet. that's the only place it lives, so don't go looking elsewhere 💀

here's the format, 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     |             Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Value (cont)         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

178 🦋

Length

6 ✨

Value

the field is 4 octets, holding a 32-bit unsigned integer that encodes the maximum time in seconds that the NAS should keep pre-authentication state 🫶

2.7. Network-Id-Name ✨

Description

okay so the Network-Id-Name Attribute is what [IEEE-802.1X] implementations use to spell out the name of a Network-Id (NID-Name) 🌸

here's the tea: a WiFi SSID maxes out at 32 octets 💅 but a NID-Name can be up to 253 octets 😭 so if the MAC address is already crammed into the Called-Station-Id Attribute, there might not be enough room left to fit the NID-Name too 💀 which is why, when you're using IEEE 802.1X, the Called-Station-Id Attribute SHOULD contain only the MAC address, and the Network-Id-Name Attribute carries the NID-Name instead 🎀 and the Network-Id-Name Attribute MUST NOT be used to encode the IEEE 802.11 SSID. as noted in [RFC3580], the Called-Station-Id Attribute is the one for that job 🧚

you get zero or one Network-Id-Name Attribute in an Access-Request, Access-Challenge, Access-Accept or Accounting-Request packet 🦋 in an Access-Request it's just a hint of which NID-Name the Supplicant should get access to, in an Access-Accept it's the NID-Name the Supplicant is actually going to get access to, and in an Accounting-Request it's the NID-Name the Supplicant has already been granted access to ✨

here's the layout, read 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       |            String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

179 🍓

Length

=3 🌈

String

one or more octets, holding a NID-Name 🥹 for the details, go check [IEEE-802.1X]. a robust implementation SHOULD support this field as undistinguished octets, fr fr 💜

2.8. EAPoL-Announcement 🦋

Description

the EAPoL-Announcement Attribute carries EAPoL-Announcement Type-Length-Value (TLV) tuples, which are defined in Table 11-8 of [IEEE-802.1X] 🌸 (EAPoL just means Extensible Authentication Protocol over Local Area Network, in case you were wondering 🙈)

you can have zero or more EAPoL-Announcement Attributes in an Access-Request, Access-Accept, Access-Challenge, Access-Reject, Accounting-Request, CoA-Request, or Disconnect-Request packet ✨

when it shows up in an Access-Request, the TLVs are ones the user sent in an EAPoL-Announcement 📣 when it's in an Access-Accept, Access-Challenge, Access-Reject, CoA-Request or Disconnect-Request, the TLVs are what the NAS is supposed to send to the user in a unicast EAPoL-Announcement 💖 and in an Accounting-Request, the TLVs are the ones the NAS most recently sent to the user in a unicast EAPoL-Announcement 💅

the layout is the usual, read 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     |             String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

180 🧚

Length

=3 ⭐

String

one or more octets holding EAPoL-Announcement TLVs in the format from Figure 11-8 of Section 11.12 of [IEEE-802.1X] 🫶 any EAPoL-Announcement TLV Type MAY be included in this attribute, Organizationally Specific TLVs included 🔥 and here's the important bit: if there are multiple EAPoL-Announcement Attributes in one packet, their String fields MUST be concatenated before you parse them for TLVs. that's what lets a TLV longer than 253 octets travel over RADIUS 😭 and yep, any EAPoL-Announcement TLV bigger than 253 octets MUST be fragmented across multiple EAPoL-Announcement Attributes 👑

2.9. WLAN-HESSID 🌈

Description

the WLAN-HESSID Attribute holds a MAC address that identifies the Homogenous Extended Service Set 🦋 the HESSID is a globally unique identifier, and together with the SSID (encoded in the Called-Station-Id Attribute as described in [RFC3580]), it can be used to identify a subscription service provider network (SSPN), as described in Section 8.4.2.94 of [IEEE-802.11] 💜 you get zero or one WLAN-HESSID Attribute in an Access-Request or Accounting-Request packet ✨

the layout 🎀

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

Type

181 🍓

Length

19 🌸

String

this one is encoded in uppercase ASCII characters, with the octet values separated by dashes, as described in RFC 3580 [RFC3580] 🥹 for example, "00-10-A4-23-19-C0" 💖

2.10. WLAN-Venue-Info ✨

Description

the WLAN-Venue-Info Attribute tells you what category of venue is hosting the WLAN, as defined in Section 8.4.1.34 of [IEEE-802.11] 🏟️ you can include zero or more WLAN-Venue-Info Attributes in an Access-Request or Accounting-Request 💅

the layout, 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     |             Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             Value                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

182 👑

Length

6 🌈

Value

the Value field is four octets, which is a 32-bit unsigned integer 🧚 the two most significant octets MUST be set to zero by the sender, and the receiver ignores them 🙈 the two least significant octets hold the Venue Group and Venue Type fields 💜

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Reserved           |  Venue Group  |  Venue Type   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Venue Group 🏛️

the Venue Group field is one octet and describes the broad category of the venue, e.g., "Assembly" 🎭 check Section 8.4.1.34 of [IEEE-802.11] for the Venue Group codes and what they mean 🌸

Venue Type 📚

the Venue Type field is one octet and gets more specific within the Venue Group, e.g., "Library" 💖 check Section 8.4.1.34 of [IEEE-802.11] for the Venue Type codes and descriptions 🫶

2.11. WLAN-Venue-Language 🎀

Description

the WLAN-Venue-Language Attribute is a string encoded by ISO-14962-1997 [ISO-14962-1997] that says what language the WLAN-Venue-Name Attribute is in 🌍 you can have zero or more WLAN-Venue-Language Attributes in an Access-Request or Accounting-Request, and each one tells you the language of the WLAN-Venue-Name Attribute right after it 🦋

the layout 💅

 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     |         String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  String (cont) |
+-+-+-+-+-+-+-+-+

Type

183 🍓

Length

4-5 ✨

String

the String field is a two- or three-character language code picked from ISO-639 [ISO-639] 🧚 a two-character code gets a zero ("null" in ISO-14962-1997) appended so it ends up 3 octets long 🙈

2.12. WLAN-Venue-Name 💜

Description

the WLAN-Venue-Name Attribute gives extra metadata about the Basic Service Set (BSS) 🌸 for example, this info can help a user pick the right BSS to associate with 💖 you can include zero or more WLAN-Venue-Name Attributes in an Access-Request or Accounting-Request, in the same language or different ones 🌈

the layout 🎀

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

Type

184 👑

Length

=3 🦋

String

the String field is encoded in UTF-8 and holds the venue's name 🥹 the max length of this field is 252 octets 💅

2.13. WLAN-Reason-Code 🚫

Description

okay so the WLAN-Reason-Code Attribute tells you why a Station got turned away from the network and kicked off (disassociated or de-authenticated) 🙈 it can happen because of policy, or because of something going on with the user's subscription 💀

A WLAN-Reason-Code Attribute MAY be included in an Access-Reject or Disconnect-Request packet, and it can also show up in an Accounting-Request packet 💅 when an Access-Reject or Disconnect-Request has one, the Access Point copies that WLAN-Reason-Code value into the Reason Code field of a Disassociation or Deauthentication frame (see Clauses 8.3.3.4 and 8.3.3.12, respectively, in [IEEE-802.11]), and then that frame gets sent to the Station 🦋

here's the layout of the Attribute. fields go left to right, obviously 🎀

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

Type

185 🧚

Length

6 🌸

Value

the Value field is four octets holding a 32-bit unsigned integer 🔥 the two most significant octets MUST be set to zero by the sender, and the receiver ignores them. the two least significant octets are where the Reason Code values live, which are defined in Table 8-36 of Section 8.4.1.7 of [IEEE-802.11] 🫶

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Reserved           |          Reason Code          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.14. WLAN-Pairwise-Cipher 🔐

Description

the WLAN-Pairwise-Cipher Attribute tells everyone which pairwise ciphersuite got used to set up the robust security network association (RSNA) between the AP and the mobile device 🌈 a WLAN-Pairwise-Cipher Attribute MAY be included in Access-Request and Accounting-Request packets ✨

layout time, fields go 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       |             Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Value                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

186 🦋

Length

6 🍓

Value

the Value field is four octets, a 32-bit unsigned integer 💅 it's in Suite selector format from Figure 8-187 within Section 8.4.2.27.2 of [IEEE-802.11], and the OUI and Suite Type values come from Table 8-99 👑

 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                            |  Suite Type   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.15. WLAN-Group-Cipher 🌸

Description

the WLAN-Group-Cipher Attribute says which group ciphersuite got used to set up the robust security network association (RSNA) between the AP and the mobile device ⭐ a WLAN-Group-Cipher Attribute MAY be included in Access-Request and Accounting-Request packets 🫶

the fields go left to right, same as always 🎀

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

Type

187 💜

Length

6 ✨

Value

the Value field is four octets, a 32-bit unsigned integer 🌈 same deal as the pairwise one: it's in Suite selector format from Figure 8-187 within Section 8.4.2.27.2 of [IEEE-802.11], with the OUI and Suite Type values drawn from Table 8-99 🔥

 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                            |  Suite Type   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.16. WLAN-AKM-Suite 🔑

Description

the WLAN-AKM-Suite Attribute tells you which authentication and key management suite got used to set up the robust security network association (RSNA) between the AP and the mobile device 🧚 a WLAN-AKM-Suite Attribute MAY be included in Access-Request and Accounting-Request packets 💖

fields go left to right, no surprises 🦋

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

Type

188 🍓

Length

6 🌈

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                            |  Suite Type   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.17. WLAN-Group-Mgmt-Cipher 🛡️

Description

the WLAN-Group-Mgmt-Cipher Attribute tells you which group management cipher got used to set up the robust security network association (RSNA) between the AP and the mobile device 👑

zero or one WLAN-Group-Mgmt-Cipher Attribute MAY be included in Access-Request and Accounting-Request packets 🫶 if it's there, that means the Station negotiated to use management frame protection during association 🔥

fields go 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       |     Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Value                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

189 ✨

Length

6 🌸

Value

the Value field is four octets, a 32-bit unsigned integer 🧚 it's in Suite selector format from Figure 8-187 within Section 8.4.2.27.2 of [IEEE-802.11], with the OUI and Suite Type values drawn from Table 8-99:

 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                            |  Suite Type   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.18. WLAN-RF-Band 📡

Description

the WLAN-RF-Band Attribute tells you which radio frequency (RF) band the Access Point used to send and receive stuff to and from the mobile device 💜 zero or one WLAN-RF-Band Attribute MAY be included in an Access-Request or Accounting-Request packet 🌈

fields go left to right, as usual 🦋

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

Type

190 🍓

Length

6 💅

Value

the Value field is four octets, a 32-bit unsigned integer ⭐ the three most significant octets MUST be set to zero by the sender, and the receiver ignores them. the least significant octet holds the RF Band field, and its values are defined by the IEEE 802.11 Band ID field (Table 8-53a of [IEEE-802.11ad]) 🔥

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Reserved                           |    RF Band    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3. Table of Attributes 🎀

okay bestie, this is the cheat sheet 🧚 It tells you which attributes can show up in which packet types, and how many of each you're allowed to send. Two tables, then a little legend.

Access-  Access-  Access-  Access-
Request  Accept   Reject   Challenge  #   Attribute
0        0+       0        0        174  Allowed-Called-Station-Id
0-1      0-1      0        0        102   EAP-Key-Name
0-1      0+       0        0        175  EAP-Peer-Id
0-1      0+       0        0        176  EAP-Server-Id
0-1      0        0        0        177  Mobility-Domain-Id
0-1      0-1      0        0        178  Preauth-Timeout
0-1      0        0        0        179  Network-Id-Name
0+       0+       0+       0+       180  EAPoL-Announcement
0-1      0        0        0        181  WLAN-HESSID
0-1      0        0        0        182  WLAN-Venue-Info
0+       0        0        0        183  WLAN-Venue-Language
0+       0        0        0        184  WLAN-Venue-Name
0        0        0-1      0        185  WLAN-Reason-Code
0-1      0        0        0        186  WLAN-Pairwise-Cipher
0-1      0        0        0        187  WLAN-Group-Cipher
0-1      0        0        0        188  WLAN-AKM-Suite
0-1      0        0        0        189  WLAN-Group-Mgmt-Cipher
0-1      0        0        0        190  WLAN-RF-Band

CoA- Dis-  Acct-
Req  Req   Req  #      Attribute
0+    0    0+   174   Allowed-Called-Station-Id
0-1   0    0    102   EAP-Key-Name
0     0    0+   175   EAP-Peer-Id
0     0    0+   176   EAP-Server-Id
0     0    0-1  177   Mobility-Domain-Id
0-1   0    0    178   Preauth-Timeout
0     0    0-1  179   Network-Id-Name
0+    0+   0+   180   EAPoL-Announcement
0     0    0-1  181   WLAN-HESSID
0     0    0-1  182   WLAN-Venue-Info
0     0    0+   183   WLAN-Venue-Language
0     0    0+   184   WLAN-Venue-Name
0     0-1  0-1  185   WLAN-Reason-Code
0     0    0-1  186   WLAN-Pairwise-Cipher
0     0    0-1  187   WLAN-Group-Cipher
0     0    0-1  188   WLAN-AKM-Suite
0     0    0-1  189   WLAN-Group-Mgmt-Cipher
0     0    0-1  190   WLAN-RF-Band

The table below decodes the symbols up top. Read them like a little secret code 🔐

0 means this attribute MUST NOT be present in packet. 🚫
0+ means zero or more instances of this attribute MAY be present in the packet. 💜
0-1 means zero or one instance of this attribute MAY be present in the packet. 🌸

4. IANA Considerations 🦋

okay so IANA stuff. This document uses the RADIUS [RFC2865] namespace, and you can peek at the registry at <http://www.iana.org/assignments/radius-types>. Per this specification, RADIUS attribute types have been assigned for the following attributes, and yes the numbers are all right there in the table ✨

Attribute                        Type
=========                        ====
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
WLAN-RF-Band                     190

Since this specification relies entirely on values assigned by IEEE 802, no registries are established for maintenance by the IANA. So there's no new IANA registry to babysit, which is honestly a vibe 💅

5. Security Considerations 💀

okay this section is the serious one, so read it with your whole chest 😭

Since this document describes the use of RADIUS for purposes of authentication, authorization, and accounting in IEEE 802 networks, it is vulnerable to all of the threats that are present in other RADIUS applications. For a discussion of these threats, see [RFC2607], [RFC2865], [RFC3162], [RFC3579], [RFC3580], and [RFC5176]. In particular, when RADIUS traffic is sent in the clear, the attributes defined in this document can be obtained by an attacker snooping the exchange between the RADIUS client and server. As a result, RADIUS confidentiality is desirable; for a review of RADIUS security and crypto-agility requirements, see [RFC6421]. Lowkey terrifying, but we know what to do 🔥

While it is possible for a RADIUS server to make decisions on whether to accept or reject an Access-Request based on the values of the WLAN-Pairwise-Cipher, WLAN-Group-Cipher, WLAN-AKM-Suite, WLAN-Group-Mgmt-Cipher, and WLAN-RF-Band Attributes, the value of doing this is limited. In general, an Access-Reject should not be necessary, except where Access Points and Stations are misconfigured so as to enable connections to be made with unacceptable values. Rather than rejecting access on an ongoing basis, users would be better served by fixing the misconfiguration. Ngl, fix the config and everybody eats 🍓

Where access does need to be rejected, the user should be provided with an indication of why the problem has occurred, or else they are likely to become frustrated. For example, if the values of the WLAN-Pairwise-Cipher, WLAN-Group-Cipher, WLAN-AKM-Suite, or WLAN-Group-Mgmt-Cipher Attributes included in the Access-Request are not acceptable to the RADIUS server, then a WLAN-Reason-Code Attribute with a value of 29 (Requested service rejected because of service provider ciphersuite or AKM requirement) SHOULD be returned in the Access-Reject. Similarly, if the value of the WLAN-RF-Band Attribute included in the Access-Request is not acceptable to the RADIUS server, then a WLAN-Reason-Code Attribute with a value of 11 (Disassociated because the information in the Supported Channels element is unacceptable) SHOULD be returned in the Access-Reject. Basically, explain the no so nobody gets ghosted by the network 🙈

6. References 📚

6.1. Normative References

[IEEE-802] IEEE, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture. Amendment 2: Registration of Object Identifiers", ANSI/IEEE Std 802, 2001.
[IEEE-802.11] 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", IEEE Std 802.11-2012, 2012.
[IEEE-802.11ad] 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, Amendment 3: Enhancements for Very High Throughput in the 60 GHz Band", IEEE Std 802.11ad-2012, 2012.
[IEEE-802.1X] IEEE, "IEEE Standard for Local and metropolitan area networks - Port-Based Network Access Control", IEEE Std 802.1X-2010, February 2010.
[ISO-639] ISO, "Codes for the Representation of Names of Languages", ISO 639.
[ISO-14962-1997] ISO, "Space data and information transfer systems - ASCII encoded English", 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008.

6.2. Informative References

[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008.
[RFC6421] Nelson, D., Ed., "Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS)", RFC 6421, November 2011.

7. Acknowledgments 🫶

The authors would like to acknowledge Maximilian Riegel, Dorothy Stanley, Yoshihiro Ohba, and the contributors to the IEEE 802.1 and IEEE 802.11 reviews of this document, for useful discussions. Big thank yous to the whole squad 💖

Authors' Addresses ✨

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
US

EMail: bernard_aboba@hotmail.com


Jouni Malinen

EMail: j@w1.fi


Paul Congdon
Tallac Networks
6528 Lonetree Blvd.
Rocklin, CA 95765
US

Phone: +19167576350
EMail: paul.congdon@tallac.com


Joseph Salowey
Cisco Systems

EMail: jsalowey@cisco.com


Mark Jones
Azuca Systems

EMail:  mark@azu.ca

📦 where this page comes from

ietf: rfc7268 2014-07
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms