doc: Add RFC documents

1 files changed, 1627 insertions, 0 deletions

diff --git a/doc/rfc/rfc7268.txt b/doc/rfc/rfc7268.txt
new file mode 100644
index 0000000..e33913d
--- /dev/null
+++ b/doc/rfc/rfc7268.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          B. Aboba
+Request for Comments: 7268                         Microsoft Corporation
+Updates: 3580, 4072                                           J. Malinen
+Category: Standards Track                                    Independent
+ISSN: 2070-1721                                               P. Congdon
+                                                         Tallac Networks
+                                                              J. Salowey
+                                                           Cisco Systems
+                                                                M. Jones
+                                                           Azuca Systems
+                                                               July 2014
+
+
+                RADIUS Attributes for IEEE 802 Networks
+
+Abstract
+
+   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.
+
+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 has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7268.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al.                Standards Track                    [Page 1]
+
+RFC 7268             RADIUS Attributes for IEEE 802            July 2014
+
+
+Copyright Notice
+
+   Copyright (c) 2014 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
+   (http://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 Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, 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, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al.                Standards Track                    [Page 2]
+
+RFC 7268             RADIUS Attributes for IEEE 802            July 2014
+
+
+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
+
+   In situations where it is desirable to centrally manage
+   authentication, authorization, and accounting (AAA) for IEEE 802
+   [IEEE-802] networks, deployment of a backend authentication and
+   accounting server is desirable.  In such situations, it is expected
+   that IEEE 802 authenticators will function as AAA clients.
+
+   "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS)
+   Usage Guidelines" [RFC3580] provides guidelines for the use of the
+   Remote Authentication Dial-In User Service (RADIUS) within networks
+   utilizing IEEE 802 local area networks.  This document defines
+   additional attributes suitable for usage by IEEE 802 authenticators
+   acting as AAA clients.
+
+
+
+
+
+Aboba, et al.                Standards Track                    [Page 3]
+
+RFC 7268             RADIUS Attributes for IEEE 802            July 2014
+
+
+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].
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al.                Standards Track                    [Page 4]
+
+RFC 7268             RADIUS Attributes for IEEE 802            July 2014
+
+
+2.  RADIUS Attributes
+
+2.1.  Allowed-Called-Station-Id
+
+   Description
+
+      The Allowed-Called-Station-Id Attribute allows the RADIUS server
+      to specify the authenticator MAC addresses and/or networks to
+      which the user is allowed to connect.  One or more Allowed-Called-
+      Station-Id Attributes MAY be included in an Access-Accept, CoA-
+      Request, or Accounting-Request packet.
+
+      The Allowed-Called-Station-Id Attribute can be useful in
+      situations where pre-authentication is supported (e.g., IEEE
+      802.11 pre-authentication).  In these scenarios, a Called-Station-
+      Id Attribute typically will not be included within the Access-
+      Request so that the RADIUS server will not know the network that
+      the user is attempting to access.  The Allowed-Called-Station-Id
+      enables the RADIUS server to restrict the networks and attachment
+      points to which the user can subsequently connect.
+
+      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.
+
+
+
+
+
+
+Aboba, et al.                Standards Track                    [Page 5]
+
+RFC 7268             RADIUS Attributes for IEEE 802            July 2014
+
+
+      In the case of IEEE 802, the Allowed-Called-Station-Id Attribute
+      is used to store the Medium Access Control (MAC) address,
+      represented as an uppercase ASCII character string in Canonical
+      format and 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) constitutes the network name; within IEEE 802.1X
+      [IEEE-802.1X] wired networks, the Network-Id Name (NID-Name)
+      constitutes the network name.  Since a NID-Name can be up to 253
+      octets in length, when used with [IEEE-802.1X] wired networks,
+      there may not be sufficient room within the Allowed-Called-
+      Station-Id Attribute to include both a MAC address and a network
+      name.  However, as the Allowed-Called-Station-Id Attribute is
+      expected to be used largely in wireless access scenarios, this
+      restriction is not considered serious.
+
+2.2.  EAP-Key-Name
+
+   Description
+
+      The EAP-Key-Name Attribute, defined in "Diameter Extensible
+      Authentication Protocol (EAP) Application" [RFC4072], contains the
+      EAP Session-Id, as described in "Extensible Authentication
+      Protocol (EAP) Key Management Framework" [RFC5247].  Exactly how
+      this attribute is used depends on the link layer in question.
+
+      It should be noted that not all link layers use this name.  An
+      EAP-Key-Name Attribute MAY be included within Access-Request,
+      Access-Accept, and CoA-Request packets.  A summary of the EAP-Key-
+      Name 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
+
+      102 [RFC4072]
+
+
+
+Aboba, et al.                Standards Track                    [Page 6]
+
+RFC 7268             RADIUS Attributes for IEEE 802            July 2014
+
+
+   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].  Since the NAS operates
+      as a pass-through in EAP, it cannot know the EAP Session-Id before
+      receiving it from the RADIUS server.  As a result, an EAP-Key-Name
+      Attribute sent in an Access-Request MUST only contain a single NUL
+      character.  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.  In addition, 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.  Since a NAS will typically only include an EAP-
+      Key-Name Attribute in an Access-Request in situations where the
+      attribute is required to provision service, if an EAP-Key-Name
+      Attribute is included in an Access-Request but is not present in
+      the Access-Accept, the NAS SHOULD treat the Access-Accept as
+      though it were an Access-Reject.  If an EAP-Key-Name Attribute was
+      not present in the Access-Request but is included in the Access-
+      Accept, then the NAS SHOULD silently discard the EAP-Key-Name
+      Attribute.  As noted in Section 6.2.2 of [IEEE-802.1X], the
+      Connectivity Association Key Name (CKN) is derived from the EAP
+      Session-Id, and, as described in Section 9.3.3 of [IEEE-802.1X],
+      the CKN is subsequently used in the derivation of the Key
+      Encrypting Key (KEK) and the Integrity Check Value Key (ICK),
+      which protect the Secure Association Keys (SAKs) utilized by Media
+      Access Control Security (MACsec).  As a result, for the NAS to
+      acquire information needed in the MACsec Key Agreement (MKA)
+      exchange, it needs to include the EAP-Key-Name Attribute in the
+      Access-Request and receive it from the RADIUS server in the
+      Access-Accept.
+
+2.3.  EAP-Peer-Id
+
+   Description
+
+      The EAP-Peer-Id Attribute contains a Peer-Id generated by the EAP
+      method.  Exactly how this name is used depends on the link layer
+      in question.  See [RFC5247] for more discussion.  The EAP-Peer-Id
+      Attribute MAY be included in Access-Request, Access-Accept, and
+      Accounting-Request packets.  More than one EAP-Peer-Id Attribute
+      MUST NOT be included in an Access-Request; one or more EAP-Peer-Id
+      Attributes MAY be included in an Access-Accept.
+
+
+
+Aboba, et al.                Standards Track                    [Page 7]
+
+RFC 7268             RADIUS Attributes for IEEE 802            July 2014
+
+
+      It should be noted that not all link layers use this name, and
+      existing EAP method implementations do not generate it.  Since the
+      NAS operates as a pass-through in EAP [RFC3748], it cannot know
+      the EAP-Peer-Id before receiving it from the RADIUS server.  As a
+      result, an EAP-Peer-Id Attribute sent in an Access-Request MUST
+      only contain 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.  In addition, 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 present in the
+      Access-Request.  If a NAS receives EAP-Peer-Id Attribute(s) in an
+      Access-Accept without having included one in an Access-Request,
+      the NAS SHOULD silently discard the attribute(s).  A summary of
+      the EAP-Peer-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
+
+      175
+
+   Length
+
+      >=3
+
+   String
+
+      The String field is one or more octets, containing an EAP Peer-Id
+      exported by the EAP method.  For details, see 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 contains a Server-Id generated by the
+      EAP method.  Exactly how this name is used depends on the link
+      layer in question.  See [RFC5247] for more discussion.  The EAP-
+      Server-Id Attribute is only allowed in Access-Request, Access-
+      Accept, and Accounting-Request packets.  More than one EAP-Server-
+
+
+
+Aboba, et al.                Standards Track                    [Page 8]
+
+RFC 7268             RADIUS Attributes for IEEE 802            July 2014
+
+
+      Id Attribute MUST NOT be included in an Access-Request; 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 do not generate it.  Since the
+      NAS operates as a pass-through in EAP [RFC3748], it cannot know
+      the EAP-Server-Id before receiving it from the RADIUS server.  As
+      a result, an EAP-Server-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-Server-Id Attribute
+      containing anything other than a single NUL character MUST
+      silently discard the attribute.  In addition, the home RADIUS
+      server SHOULD include this attribute in an Access-Accept only if
+      an EAP-Server-Id Attribute was present in the Access-Request.  A
+      summary of the EAP-Server-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
+
+      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 in order to enable the NAS to
+      provide the RADIUS server with the Mobility Domain Identifier
+      (MDID), defined in Section 8.4.2.49 of [IEEE-802.11].  A summary
+      of the Mobility-Domain-Id Attribute format is shown below.  The
+      fields are transmitted from left to right.
+
+
+
+Aboba, et al.                Standards Track                    [Page 9]
+
+RFC 7268             RADIUS Attributes for IEEE 802            July 2014
+
+
+       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, containing 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 contain the Mobility Domain Identifier (MDID)
+      defined in 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 pre-
+      authentication state is required to be kept by the NAS without
+      being utilized within a user session.  For example, when
+      [IEEE-802.11] pre-authentication is used, if a user has not
+      attempted to utilize the Pairwise Master Key (PMK) derived as a
+      result of pre-authentication within the time specified by the
+      Preauth-Timeout Attribute, the PMK MAY be discarded by the Access
+      Point.  However, once the session is underway, the Preauth-Timeout
+      Attribute has no bearing on the maximum session time for the user
+      or the maximum time during which key state may be kept prior to
+      re-authentication.  This is determined by the Session-Timeout
+      Attribute, if present.
+
+
+
+
+
+Aboba, et al.                Standards Track                   [Page 10]
+
+RFC 7268             RADIUS Attributes for IEEE 802            July 2014
+
+
+      A single Preauth-Timeout Attribute MAY be included within an
+      Access-Accept or CoA-Request packet.  A summary of the Preauth-
+      Timeout 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     |             Value
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                 Value (cont)         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      178
+
+   Length
+
+      6
+
+   Value
+
+      The field is 4 octets, containing a 32-bit unsigned integer
+      encoding the maximum time in seconds that pre-authentication state
+      should be retained by the NAS.
+
+2.7.  Network-Id-Name
+
+   Description
+
+      The Network-Id-Name Attribute is utilized by implementations of
+      IEEE-802.1X [IEEE-802.1X] to specify the name of a Network-Id
+      (NID-Name).
+
+      Unlike the IEEE 802.11 SSID (which is a maximum of 32 octets in
+      length), the NID-Name may be up to 253 octets in length.
+      Consequently, if the MAC address is included within the Called-
+      Station-Id Attribute, it is possible that there will not be enough
+      remaining space to encode the NID-Name as well.  Therefore, when
+      used with IEEE 802.1X [IEEE-802.1X], the Called-Station-Id
+      Attribute SHOULD contain only the MAC address, with the Network-
+      Id-Name Attribute used to transmit the NID-Name.  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 used for
+      this purpose.
+
+
+
+
+
+Aboba, et al.                Standards Track                   [Page 11]
+
+RFC 7268             RADIUS Attributes for IEEE 802            July 2014
+
+
+      Zero or one Network-Id-Name Attribute is permitted within an
+      Access-Request, Access-Challenge, Access-Accept or Accounting-
+      Request packet.  When included within an Access-Request packet,
+      the Network-Id-Name Attribute represents a hint of the NID-Name to
+      which the Supplicant should be granted access.  When included
+      within an Access-Accept packet, the Network-Id-Name Attribute
+      represents the NID-Name to which the Supplicant is to be granted
+      access.  When included within an Accounting-Request packet, the
+      Network-Id-Name Attribute represents the NID-Name to which the
+      Supplicant has been granted access.
+
+      A summary of the Network-Id-Name 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
+
+      179
+
+   Length
+
+      >=3
+
+   String
+
+      The String field is one or more octets, containing a NID-Name.
+      For details, see [IEEE-802.1X].  A robust implementation SHOULD
+      support the field as undistinguished octets.
+
+2.8.  EAPoL-Announcement
+
+   Description
+
+      The EAPoL-Announcement Attribute contains EAPoL-Announcement Type-
+      Length-Value (TLV) tuples defined within Table 11-8 of IEEE-802.1X
+      [IEEE-802.1X].  The acronym "EAPoL" stands for Extensible
+      Authentication Protocol over Local Area Network.
+
+      Zero or more EAPoL-Announcement Attributes are permitted within an
+      Access-Request, Access-Accept, Access-Challenge, Access-Reject,
+      Accounting-Request, CoA-Request, or Disconnect-Request packet.
+
+
+
+
+
+Aboba, et al.                Standards Track                   [Page 12]
+
+RFC 7268             RADIUS Attributes for IEEE 802            July 2014
+
+
+      When included within an Access-Request packet, EAPoL-Announcement
+      Attributes contain EAPoL-Announcement TLVs that the user sent in
+      an EAPoL-Announcement.  When included within an Access-Accept,
+      Access-Challenge, Access-Reject, CoA-Request or Disconnect-Request
+      packet, EAPoL-Announcement Attributes contain EAPoL-Announcement
+      TLVs that the NAS is to send to the user in a unicast EAPoL-
+      Announcement.  When sent within an Accounting-Request packet,
+      EAPoL-Announcement Attributes contain EAPoL-Announcement TLVs that
+      the NAS has most recently sent to the user in a unicast EAPoL-
+      Announcement.
+
+      A summary of the EAPoL-Announcement 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
+
+      180
+
+   Length
+
+      >=3
+
+   String
+
+      The String field is one or more octets, containing EAPoL-
+      Announcement TLVs in the format defined in Figure 11-8 of Section
+      11.12 of [IEEE-802.1X].  Any EAPoL-Announcement TLV Type MAY be
+      included within an EAPoL-Announcement Attribute, including
+      Organizationally Specific TLVs.  If multiple EAPoL-Announcement
+      Attributes are present in a packet, their String fields MUST be
+      concatenated before being parsed for EAPoL-Announcement TLVs; this
+      allows EAPoL-Announcement TLVs longer than 253 octets to be
+      transported by RADIUS.  Similarly, EAPoL-Announcement TLVs larger
+      than 253 octets MUST be fragmented between multiple EAPoL-
+      Announcement Attributes.
+
+
+
+
+
+
+
+
+
+
+Aboba, et al.                Standards Track                   [Page 13]
+
+RFC 7268             RADIUS Attributes for IEEE 802            July 2014
+
+
+2.9.  WLAN-HESSID
+
+   Description
+
+      The WLAN-HESSID Attribute contains a MAC address that identifies
+      the Homogenous Extended Service Set.  The HESSID is a globally
+      unique identifier that, in conjunction with the SSID, encoded
+      within the Called-Station-Id Attribute as described in [RFC3580],
+      may be used to provide network identification for a subscription
+      service provider network (SSPN), as described in Section 8.4.2.94
+      of [IEEE-802.11].  Zero or one WLAN-HESSID Attribute is permitted
+      within an Access-Request or Accounting-Request packet.
+
+      A summary of the WLAN-HESSID 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
+
+      181
+
+   Length
+
+      19
+
+   String
+
+      The String field is encoded in uppercase ASCII characters with the
+      octet values separated by dash characters, 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 identifies the category of venue
+      hosting the WLAN, as defined in Section 8.4.1.34 of [IEEE-802.11].
+      Zero or more WLAN-Venue-Info Attributes may be included in an
+      Access-Request or Accounting-Request.
+
+
+
+
+
+
+
+Aboba, et al.                Standards Track                   [Page 14]
+
+RFC 7268             RADIUS Attributes for IEEE 802            July 2014
+
+
+      A summary of the WLAN-Venue-Info 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     |             Value
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                 Value                |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      182
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets, containing 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 contain 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 a single octet and describes the broad
+         category of the venue, e.g., "Assembly".  See Section 8.4.1.34
+         of [IEEE-802.11] for Venue Group codes and descriptions.
+
+      Venue Type
+
+         The Venue Type field is a single octet and describes the venue
+         in a finer granularity within the Venue Group, e.g., "Library".
+         See Section 8.4.1.34 of [IEEE-802.11] for Venue Type codes and
+         descriptions.
+
+
+
+
+
+
+
+Aboba, et al.                Standards Track                   [Page 15]
+
+RFC 7268             RADIUS Attributes for IEEE 802            July 2014
+
+
+2.11.  WLAN-Venue-Language
+
+   Description
+
+      The WLAN-Venue-Language Attribute is a string encoded by
+      ISO-14962-1997 [ISO-14962-1997] that defines the language used in
+      the WLAN-Venue-Name Attribute.  Zero or more WLAN-Venue-Language
+      Attributes may be included in an Access-Request or Accounting-
+      Request, and each one indicates the language of the WLAN-Venue-
+      Name Attribute that follows it.
+
+      A summary of the WLAN-Venue-Language 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...
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+        String (cont) |
+      +-+-+-+-+-+-+-+-+
+
+   Type
+
+      183
+
+   Length
+
+      4-5
+
+   String
+
+      The String field is a two- or three-character language code
+      selected from ISO-639 [ISO-639].  A two-character language code
+      has a zero ("null" in ISO-14962-1997) appended to make it 3 octets
+      in length.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al.                Standards Track                   [Page 16]
+
+RFC 7268             RADIUS Attributes for IEEE 802            July 2014
+
+
+2.12.  WLAN-Venue-Name
+
+   Description
+
+      The WLAN-Venue-Name Attribute provides additional metadata on the
+      Basic Service Set (BSS).  For example, this information may be
+      used to assist a user in selecting the appropriate BSS with which
+      to associate.  Zero or more WLAN-Venue-Name Attributes may be
+      included in an Access- Request or Accounting-Request in the same
+      or different languages.
+
+      A summary of the WLAN-Venue-Name 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
+
+      184
+
+   Length
+
+      >=3
+
+   String
+
+      The String field is encoded in UTF-8 and contains the venue's
+      name.  The maximum length of this field is 252 octets.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al.                Standards Track                   [Page 17]
+
+RFC 7268             RADIUS Attributes for IEEE 802            July 2014
+
+
+2.13.  WLAN-Reason-Code
+
+   Description
+
+      The WLAN-Reason-Code Attribute contains information on the reason
+      why a Station has been refused network access and has been
+      disassociated or de-authenticated.  This can occur due to policy
+      or for reasons related to the user's subscription.
+
+      A WLAN-Reason-Code Attribute MAY be included within an Access-
+      Reject or Disconnect-Request packet, as well as within an
+      Accounting-Request packet.  Upon receipt of an Access-Reject or
+      Disconnect-Request packet containing a WLAN-Reason-Code Attribute,
+      the WLAN-Reason-Code value is copied by the Access Point 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]), which is subsequently transmitted to the Station.
+
+      A summary of the WLAN-Reason-Code 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       |             Value
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                 Value                |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      185
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets, containing 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 contain the Reason Code values defined in Table
+      8-36 of Section 8.4.1.7 of [IEEE-802.11].
+
+
+
+
+
+
+
+Aboba, et al.                Standards Track                   [Page 18]
+
+RFC 7268             RADIUS Attributes for IEEE 802            July 2014
+
+
+      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 contains information on the
+      pairwise ciphersuite used to establish the robust security network
+      association (RSNA) between the AP and mobile device.  A WLAN-
+      Pairwise-Cipher Attribute MAY be included within Access-Request
+      and Accounting-Request packets.
+
+      A summary of the WLAN-Pairwise-Cipher 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       |             Value
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                 Value                |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      186
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets, containing a 32-bit unsigned
+      integer, in Suite selector format as specified in Figure 8-187
+      within Section 8.4.2.27.2 of [IEEE-802.11], with values of OUI and
+      Suite Type 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   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Aboba, et al.                Standards Track                   [Page 19]
+
+RFC 7268             RADIUS Attributes for IEEE 802            July 2014
+
+
+2.15.  WLAN-Group-Cipher
+
+   Description
+
+      The WLAN-Group-Cipher Attribute contains information on the group
+      ciphersuite used to establish the robust security network
+      association (RSNA) between the AP and mobile device.  A WLAN-
+      Group-Cipher Attribute MAY be included within Access-Request and
+      Accounting-Request packets.
+
+      A summary of the WLAN-Group-Cipher 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       |             Value
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                 Value                |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      187
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets, containing a 32-bit unsigned
+      integer, in Suite selector format as specified in Figure 8-187
+      within Section 8.4.2.27.2 of [IEEE-802.11], with values of OUI and
+      Suite Type 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   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al.                Standards Track                   [Page 20]
+
+RFC 7268             RADIUS Attributes for IEEE 802            July 2014
+
+
+2.16.  WLAN-AKM-Suite
+
+   Description
+
+      The WLAN-AKM-Suite Attribute contains information on the
+      authentication and key management suite used to establish the
+      robust security network association (RSNA) between the AP and
+      mobile device.  A WLAN-AKM-Suite Attribute MAY be included within
+      Access-Request and Accounting-Request packets.
+
+      A summary of the WLAN-AKM-Suite 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       |             Value
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                 Value                |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      188
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets, containing a 32-bit unsigned
+      integer, in Suite selector format as specified in Figure 8-187
+      within Section 8.4.2.27.2 of [IEEE-802.11], with values of OUI and
+      Suite Type drawn from Table 8-101:
+
+      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   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al.                Standards Track                   [Page 21]
+
+RFC 7268             RADIUS Attributes for IEEE 802            July 2014
+
+
+2.17.  WLAN-Group-Mgmt-Cipher
+
+   Description
+
+      The WLAN-Group-Mgmt-Cipher Attribute contains information on the
+      group management cipher used to establish the robust security
+      network association (RSNA) between the AP and mobile device.
+
+      Zero or one WLAN-Group-Mgmt-Cipher Attribute MAY be included
+      within Access-Request and Accounting-Request packets.  The
+      presence of the Attribute indicates that the Station negotiated to
+      use management frame protection during association.
+
+      A summary of the WLAN-Group-Mgmt-Cipher 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       |     Value
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                 Value                |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      189
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets, containing a 32-bit unsigned
+      integer, in Suite selector format as specified in Figure 8-187
+      within Section 8.4.2.27.2 of [IEEE-802.11], with values of OUI and
+      Suite Type 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   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+Aboba, et al.                Standards Track                   [Page 22]
+
+RFC 7268             RADIUS Attributes for IEEE 802            July 2014
+
+
+2.18.  WLAN-RF-Band
+
+   Description
+
+      The WLAN-RF-Band Attribute contains information on the radio
+      frequency (RF) band used by the Access Point for transmission and
+      reception of information to and from the mobile device.  Zero or
+      one WLAN-RF-Band Attribute MAY be included within an Access-
+      Request or Accounting-Request packet.
+
+      A summary of the WLAN-RF-Band 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       |     Value
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                 Value                |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      190
+
+   Length
+
+      6
+
+   Value
+
+      The Value field is four octets, containing a 32-bit unsigned
+      integer.  The three most significant octets MUST be set to zero by
+      the sender and are ignored by the receiver; the least significant
+      octet contains the RF Band field, whose 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    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+Aboba, et al.                Standards Track                   [Page 23]
+
+RFC 7268             RADIUS Attributes for IEEE 802            July 2014
+
+
+3.  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        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
+
+
+
+
+
+Aboba, et al.                Standards Track                   [Page 24]
+
+RFC 7268             RADIUS Attributes for IEEE 802            July 2014
+
+
+   The following table defines the above table entries.
+
+   0     This attribute MUST NOT be present in packet.
+   0+    Zero or more instances of this attribute MAY be present in the
+         packet.
+   0-1   Zero or one instance of this attribute MAY be present in the
+         packet.
+
+4.  IANA Considerations
+
+   This document uses the RADIUS [RFC2865] namespace; see
+   <http://www.iana.org/assignments/radius-types>.  Per this
+   specification, RADIUS attribute types have been assigned for the
+   following attributes:
+
+   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.
+
+5.  Security Considerations
+
+   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
+
+
+
+
+Aboba, et al.                Standards Track                   [Page 25]
+
+RFC 7268             RADIUS Attributes for IEEE 802            July 2014
+
+
+   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].
+
+   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.
+
+   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.
+
+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.
+
+
+
+
+
+
+
+Aboba, et al.                Standards Track                   [Page 26]
+
+RFC 7268             RADIUS Attributes for IEEE 802            July 2014
+
+
+   [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.
+
+
+
+
+Aboba, et al.                Standards Track                   [Page 27]
+
+RFC 7268             RADIUS Attributes for IEEE 802            July 2014
+
+
+   [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al.                Standards Track                   [Page 28]
+
+RFC 7268             RADIUS Attributes for IEEE 802            July 2014
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al.                Standards Track                   [Page 29]
+