idnits 2.17.1 draft-ietf-radext-ieee802ext-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4072, but the abstract doesn't seem to directly say this. It does mention RFC4072 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 282 has weird spacing: '...Id, and as de...' (Using the creation date from RFC3580, updated by this document, for RFC5378 checks: 2000-06-22) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (28 March 2014) is 3644 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.11' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.11ad' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.1X' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-639' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-14962-1997' Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RADEXT Working Group Bernard Aboba 3 INTERNET-DRAFT Microsoft Corporation 4 Category: Proposed Standard Jouni Malinen 5 Expires: October 1, 2014 Devicescape Software 6 Updates: 3580, 4072 Paul Congdon 7 Tallac Networks 8 Joseph Salowey 9 Cisco Systems 10 Mark Jones 11 Azuca Systems 12 28 March 2014 14 RADIUS Attributes for IEEE 802 Networks 15 draft-ietf-radext-ieee802ext-12.txt 17 Abstract 19 RFC 3580 provides guidelines for the use of the Remote Authentication 20 Dialin User Service (RADIUS) within IEEE 802 local area networks 21 (LANs). This document defines additional attributes for use within 22 IEEE 802 networks, as well as clarifying the usage of the EAP-Key- 23 Name attribute and the Called-Station-Id attribute. This document 24 updates RFC 3580 as well as RFC 4072. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on October 1, 2014. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 This document may contain material from IETF Documents or IETF 65 Contributions published or made publicly available before November 66 10, 2008. The person(s) controlling the copyright in some of this 67 material may not have granted the IETF Trust the right to allow 68 modifications of such material outside the IETF Standards Process. 69 Without obtaining an adequate license from the person(s) controlling 70 the copyright in such materials, this document may not be modified 71 outside the IETF Standards Process, and derivative works of it may 72 not be created outside the IETF Standards Process, except to format 73 it for publication as an RFC or to translate it into languages other 74 than English. 76 Table of Contents 78 1. Introduction .......................................... 4 79 1.1 Terminology ..................................... 4 80 1.2 Requirements Language ........................... 5 81 2. RADIUS attributes ..................................... 5 82 2.1 Allowed-Called-Station-Id ....................... 5 83 2.2 EAP-Key-Name .................................... 6 84 2.3 EAP-Peer-Id ..................................... 7 85 2.4 EAP-Server-Id ................................... 8 86 2.5 Mobility-Domain-Id .............................. 9 87 2.6 Preauth-Timeout ................................. 10 88 2.7 Network-Id-Name ................................. 11 89 2.8 EAPoL-Announcement .............................. 12 90 2.9 WLAN-HESSID ..................................... 14 91 2.10 WLAN-Venue-Info ................................. 14 92 2.11 WLAN-Venue-Language ............................. 15 93 2.12 WLAN-Venue-Name ................................. 16 94 2.13 WLAN-Reason-Code ................................ 17 95 2.14 WLAN-Pairwise-Cipher ............................ 18 96 2.15 WLAN-Group-Cipher ............................... 19 97 2.16 WLAN-AKM-Suite .................................. 20 98 2.17 WLAN-Group-Mgmt-Cipher .......................... 21 99 2.18 WLAN-RF-Band .................................... 22 100 3. Table of attributes ................................... 23 101 4. IANA Considerations ................................... 24 102 5. Security Considerations ............................... 24 103 6. References ............................................ 25 104 6.1 Normative References .................................. 25 105 6.2 Informative References ................................ 26 106 ACKNOWLEDGMENTS .............................................. 26 107 AUTHORS' ADDRESSES ........................................... 27 108 1. Introduction 110 In situations where it is desirable to centrally manage 111 authentication, authorization and accounting (AAA) for IEEE 802 112 [IEEE-802] networks, deployment of a backend authentication and 113 accounting server is desirable. In such situations, it is expected 114 that IEEE 802 authenticators will function as AAA clients. 116 "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) 117 Usage Guidelines" [RFC3580] provides guidelines for the use of the 118 Remote Authentication Dialin User Service (RADIUS) within networks 119 utilizing IEEE 802 local area networks. This document defines 120 additional attributes suitable for usage by IEEE 802 authenticators 121 acting as AAA clients. 123 1.1. Terminology 125 This document uses the following terms: 127 Access Point (AP) 128 A Station that provides access to the distribution 129 services via the wireless medium for associated Stations. 131 Association The service used to establish Access Point/Station 132 mapping and enable Station invocation of the distribution 133 system services. 135 authenticator An authenticator is an entity that require authentication 136 from the supplicant. The authenticator may be connected 137 to the supplicant at the other end of a point-to-point 138 LAN segment or wireless link. 140 authentication server 141 An authentication server is an entity that provides an 142 authentication service to an authenticator. This service 143 verifies from the credentials provided by the supplicant, 144 the claim of identity made by the supplicant. 146 Station (STA) Any device that contains an IEEE 802.11 conformant medium 147 access control (MAC) and physical layer (PHY) interface 148 to the wireless medium (WM). 150 Supplicant A supplicant is an entity that is being authenticated by 151 an authenticator. The supplicant may be connected to the 152 authenticator at one end of a point-to-point LAN segment 153 or 802.11 wireless link. 155 1.2. Requirements Language 157 In this document, several words are used to signify the requirements 158 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 159 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 160 and "OPTIONAL" in this document are to be interpreted as described in 161 [RFC2119]. 163 2. RADIUS attributes 165 2.1. Allowed-Called-Station-Id 167 Description 169 The Allowed-Called-Station-Id Attribute allows the RADIUS server 170 to specify the authenticator MAC addresses and/or networks to 171 which the user is allowed to connect. One or more Allowed-Called- 172 Station-Id attributes MAY be included in an Access-Accept, CoA- 173 Request or Accounting-Request packet. 175 The Allowed-Called-Station-Id Attribute can be useful in 176 situations where pre-authentication is supported (e.g. IEEE 177 802.11 pre-authentication). In these scenarios, a Called-Station- 178 Id Attribute typically will not be included within the Access- 179 Request so that the RADIUS server will not know the network that 180 the user is attempting to access. The Allowed-Called-Station-Id 181 enables the RADIUS server to restrict the networks and attachment 182 points to which the user can subsequently connect. 184 A summary of the Allowed-Called-Station-Id Attribute format is 185 shown below. The fields are transmitted from left to right. 187 0 1 2 3 188 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 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Type | Length | String... 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 Code 195 TBD1 197 Length 199 >=3 201 String 202 The String field is one or more octets, specifying a Called- 203 Station-Id that the user MAY connect to; if the Called-Station-Id 204 that the user connects to does not match one of the Allowed- 205 Called-Station-Id Attributes, the Network Authentication Server 206 (NAS) MUST NOT permit the user to access the network. 208 In the case of IEEE 802, the Allowed-Called-Station-Id Attribute 209 is used to store the Medium Access Control (MAC) address in ASCII 210 format (upper case only), with octet values separated by a "-". 211 Example: "00-10-A4-23-19-C0". Where restrictions on both the 212 network and authenticator MAC address usage are intended, the 213 network name MUST be appended to the authenticator MAC address, 214 separated from the MAC address with a ":". Example: 215 "00-10-A4-23-19-C0:AP1". Where no MAC address restriction is 216 intended, the MAC address field MUST be omitted, but ":" and the 217 network name field MUST be included. Example: ":AP1". 219 Within IEEE 802.11 [IEEE-802.11], the SSID constitutes the network 220 name; within IEEE 802.1X [IEEE-802.1X] wired networks, the 221 Network-Id Name (NID-Name) constitutes the network name. Since a 222 NID-Name can be up to 253 octets in length, when used with 223 [IEEE-802.1X] wired networks, there may not be sufficient room 224 within the Allowed-Called-Station-Id Attribute to include both a 225 MAC address and a Network Name. However, as the Allowed-Called- 226 Station-Id Attribute is expected to be used largely in wireless 227 access scenarios, this restriction is not considered serious. 229 2.2. EAP-Key-Name 231 Description 233 The EAP-Key-Name Attribute, defined in "Diameter Extensible 234 Authentication Protocol (EAP) Application" [RFC4072], contains the 235 EAP Session-Id, as described in "Extensible Authentication 236 Protocol (EAP) Key Management Framework" [RFC5247]. Exactly how 237 this Attribute is used depends on the link layer in question. 239 It should be noted that not all link layers use this name. An 240 EAP-Key-Name Attribute MAY be included within Access-Request, 241 Access-Accept and CoA-Request packets. A summary of the EAP-Key- 242 Name Attribute format is shown below. The fields are transmitted 243 from left to right. 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Type | Length | String... 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 Code 253 102 [RFC4072] 255 Length 257 >=3 259 String 261 The String field is one or more octets, containing the EAP 262 Session-Id, as defined in "Extensible Authentication Protocol 263 (EAP) Key Management Framework" [RFC5247]. Since the NAS operates 264 as a pass-through in EAP, it cannot know the EAP Session-Id before 265 receiving it from the RADIUS server. As a result, an EAP-Key-Name 266 Attribute sent in an Access-Request MUST only contain a single NUL 267 character. A RADIUS server receiving an Access-Request with an 268 EAP-Key-Name Attribute containing anything other than a single NUL 269 character MUST silently discard the Attribute. In addition, the 270 RADIUS server SHOULD include this Attribute in an Access-Accept or 271 CoA-Request only if an EAP-Key-Name Attribute was present in the 272 Access-Request. Since a NAS will typically only include a EAP- 273 Key-Name Attribute in an Access-Request in situations where the 274 Attribute is required to provision service, if an EAP-Key-Name 275 Attribute is included in an Access-Request but is not present in 276 the Access-Accept, the NAS SHOULD treat the Access-Accept as 277 though it were an Access-Reject. If an EAP-Key-Name Attribute was 278 not present in the Access-Request but is included in the Access- 279 Accept, then the NAS SHOULD silently discard the EAP-Key-Name 280 Attribute. As noted in [IEEE-802.1X] Section 6.2.2, the 281 Connectivity Association Key Name (CKN) is derived from the EAP 282 Session-Id, and as described in Section 9.3.3, the CKN is 283 subsequently used in the derivation of the Key Encrypting Key 284 (KEK) and the Integrity Check Value Key (ICK), utilized to protect 285 the secret keys (SAKs) utilized by Media Access Control Security 286 (MACsec). As a result, for the NAS to acquire information needed 287 in the MACsec Key Agreement (MKA) exchange, it needs to include 288 the EAP-Key-Name attribute in the Access-Request and receive it 289 from the RADIUS server in the Access-Accept. 291 2.3. EAP-Peer-Id 293 Description 295 The EAP-Peer-Id Attribute contains a Peer-Id generated by the EAP 296 method. Exactly how this name is used depends on the link layer 297 in question. See [RFC5247] for more discussion. The EAP-Peer-Id 298 Attribute MAY be included in Access-Request, Access-Accept and 299 Accounting-Request packets. More than one EAP-Peer-Id Attribute 300 MUST NOT be included in an Access-Request; one or more EAP-Peer-Id 301 attributes MAY be included in an Access-Accept. 303 It should be noted that not all link layers use this name, and 304 existing EAP method implementations do not generate it. Since the 305 NAS operates as a pass-through in EAP [RFC3748], it cannot know 306 the EAP-Peer-Id before receiving it from the RADIUS server. As a 307 result, an EAP-Peer-Id Attribute sent in an Access-Request MUST 308 only contain a single NUL character. A home RADIUS server 309 receiving an Access-Request an EAP-Peer-Id Attribute containing 310 anything other than a single NUL character MUST silently discard 311 the Attribute. In addition, the home RADIUS server SHOULD include 312 one or more EAP-Peer-Id attributes in an Access-Accept only if an 313 EAP-Peer-Id Attribute was present in the Access-Request. If a NAS 314 receives EAP-Peer-Id Attribute(s) in an Access-Accept without 315 having included one in an Access-Request, the NAS SHOULD silently 316 discard the Attribute(s). A summary of the EAP-Peer-Id Attribute 317 format is shown below. The fields are transmitted from left to 318 right. 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Type | Length | String... 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 Code 328 TBD2 330 Length 332 >=3 334 String 336 The String field is one or more octets containing a EAP Peer-Id 337 exported by the EAP method. For details, see [RFC5247] Appendix 338 A. A robust implementation SHOULD support the field as 339 undistinguished octets. Only a single EAP Peer-Id may be included 340 per Attribute. 342 2.4. EAP-Server-Id 344 Description 346 The EAP-Server-Id Attribute contains a Server-Id generated by the 347 EAP method. Exactly how this name is used depends on the link 348 layer in question. See [RFC5247] for more discussion. The EAP- 349 Server-Id Attribute is only allowed in Access-Request, Access- 350 Accept, and Accounting-Request packets. More than one EAP-Server- 351 Id Attribute MUST NOT be included in an Access-Request; one or 352 more EAP-Server-Id attributes MAY be included in an Access-Accept. 354 It should be noted that not all link layers use this name, and 355 existing EAP method implementations do not generate it. Since the 356 NAS operates as a pass-through in EAP [RFC3748], it cannot know 357 the EAP-Server-Id before receiving it from the RADIUS server. As 358 a result, an EAP-Server-Id Attribute sent in an Access-Request 359 MUST contain only a single NUL character. A home RADIUS server 360 receiving in an Access-Request an EAP-Server-Id Attribute 361 containing anything other than a single NUL character MUST 362 silently discard the Attribute. In addition, the home RADIUS 363 server SHOULD include this Attribute an Access-Accept only if an 364 EAP-Server-Id Attribute was present in the Access-Request. A 365 summary of the EAP-Server-Id Attribute format is shown below. The 366 fields are transmitted from left to right. 368 0 1 2 3 369 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 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Type | Length | String... 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 Code 376 TBD3 378 Length 380 >=3 382 String 384 The String field is one or more octets, containing a EAP Server-Id 385 exported by the EAP method. For details, see [RFC5247] Appendix 386 A. A robust implementation SHOULD support the field as 387 undistinguished octets. 389 2.5. Mobility-Domain-Id 391 Description 393 A single Mobility-Domain-Id Attribute MAY be included in an 394 Access-Request or Accounting-Request, in order to enable the NAS 395 to provide the RADIUS server with the Mobility Domain Identifier 396 (MDID), defined in Section 8.4.2.49 of [IEEE-802.11]. A summary 397 of the Mobility-Domain-Id Attribute format is shown below. The 398 fields are transmitted from left to right. 400 0 1 2 3 401 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 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Type | Length | Value 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 Value | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 Code 410 TBD4 412 Length 414 6 416 Value 418 The Value field is four octets, containing a 32-bit unsigned 419 integer. The two most significant octets MUST be set to zero by 420 the sender, and are ignored by the receiver; the two least 421 significant octets contain the Mobility Domain Identifier (MDID) 422 defined in Section 8.4.2.49 of [IEEE-802.11]. 424 0 1 2 3 425 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 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Reserved | Mobility Domain Identifier | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 2.6. Preauth-Timeout 432 Description 434 This Attribute sets the maximum number of seconds which pre- 435 authentication state is required to be kept by the NAS, without 436 being utilized within a user session. For example, when 437 [IEEE-802.11] pre-authentication is used, if a user has not 438 attempted to utilize the Pairwise Master Key (PMK) derived as a 439 result of pre-authentication within the time specified by the 440 Preauth-Timeout Attribute, the PMK MAY be discarded by the Access 441 Point. However, once the session is underway, the Preauth-Timeout 442 Attribute has no bearing on the maximum session time for the user, 443 or the maximum time during which key state may be kept prior to 444 re-authentication. This is determined by the Session-Timeout 445 Attribute, if present. 447 A single Preauth-Timeout Attribute MAY be included within an 448 Access-Accept or CoA-Request packet. A summary of the Preauth- 449 Timeout Attribute format is shown below. The fields are 450 transmitted from left to right. 452 0 1 2 3 453 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 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Type | Length | Value 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 Value (cont) | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 Code 462 TBD5 464 Length 466 6 468 Value 470 The field is 4 octets, containing a 32-bit unsigned integer 471 encoding the maximum time in seconds that pre-authentication state 472 should be retained by the NAS. 474 2.7. Network-Id-Name 476 Description 478 The Network-Id-Name Attribute is utilized by implementations of 479 IEEE-802.1X [IEEE-802.1X] to specify the name of a Network-Id 480 (NID-Name). 482 Unlike the IEEE 802.11 SSID (which is a maximum of 32 octets in 483 length), the NID-Name may be up to 253 octets in length. 484 Consequently, if the MAC address is included within the Called- 485 Station-Id Attribute, it is possible that there will not be enough 486 remaining space to encode the NID-Name as well. Therefore when 487 used with IEEE 802.1X [IEEE-802.1X], the Called-Station-Id 488 Attribute SHOULD contain only the MAC address, with the Network- 489 Id-Name Attribute used to transmit the NID-Name. The Network-Id- 490 Name Attribute MUST NOT be used to encode the IEEE 802.11 SSID; as 491 noted in [RFC3580], the Called-Station-Id Attribute is used for 492 this purpose. 494 Zero or one Network-Id-Name Attribute is permitted within an 495 Access-Request, Access-Challenge, Access-Accept or Accounting- 496 Request packet. When included within an Access-Request packet, 497 the Network-Id-Name Attribute represents a hint of the NID-Name to 498 which the Supplicant should be granted access. When included 499 within an Access-Accept packet, the Network-Id-Name Attribute 500 represents the NID-Name to which the Supplicant is to be granted 501 access. When included within an Accounting-Request packet, the 502 Network-Id-Name Attribute represents the NID-Name to which the 503 Supplicant has been granted access. 505 A summary of the Network-Id-Name Attribute format is shown below. 506 The fields are transmitted from left to right. 508 0 1 2 3 509 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 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Type | Length | String... 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 Code 516 TBD6 518 Length 520 >=3 522 String 524 The String field is one or more octets, containing a NID-Name. 525 For details, see [IEEE-802.1X]. A robust implementation SHOULD 526 support the field as undistinguished octets. 528 2.8. EAPoL-Announcement 530 Description 532 The Extensible Authentication Protocol over Local Area Network 533 (EAPoL)-Announcement Attribute contains EAPoL-Announcement Type 534 Length Value Tuples (TLVs) defined within Table 11-8 of 535 IEEE-802.1X [IEEE-802.1X]. 537 Zero or more EAPoL-Announcement attributes are permitted within an 538 Access-Request, Access-Accept, Access-Challenge, Access-Reject, 539 Accounting-Request, CoA-Request or Disconnect-Request packet. 541 When included within an Access-Request packet, EAPoL-Announcement 542 attributes contain EAPoL-Announcement TLVs that the user sent in 543 an EAPoL-Announcement. When included within an Access-Accept, 544 Access-Challenge, Access-Reject, CoA-Request or Disconnect-Request 545 packet, EAPoL-Announcement attributes contain EAPoL-Announcement 546 TLVs that the NAS is to send to the user in a unicast EAPoL- 547 Announcement. When sent within an Accounting-Request packet, 548 EAPoL-Announcment attributes contain EAPoL-Announcement TLVs that 549 the NAS has most recently sent to the user in a unicast EAPoL- 550 Announcement. 552 A summary of the EAPoL-Announcement Attribute format is shown 553 below. The fields are transmitted from left to right. 555 0 1 2 3 556 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 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Type | Length | String... 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 Code 563 TBD7 565 Length 567 >=3 569 String 571 The String field is one or more octets, containing EAPoL- 572 Announcement TLVs in the format defined in Figure 11-8 of Section 573 11.12 of [IEEE-802.1X]. Any EAPoL-Announcement TLV Type MAY be 574 included within an EAPoL-Announcement Attribute, including 575 Organizationally Specific TLVs. If multiple EAPoL-Announcement 576 attributes are present in a packet, their String fields MUST be 577 concatenated before being parsed for EAPoL-Announcement TLVs; this 578 allows EAPoL-Announcement TLVs longer than 253 octets to be 579 transported by RADIUS. Similarly, EAPoL-Announcement TLVs larger 580 than 253 octets MUST be fragmented between multiple EAPoL- 581 Announcement attributes. 583 2.9. WLAN-HESSID 585 Description 587 The WLAN-HESSID attribute contains a MAC address that identifies 588 the Homogenous Extended Service Set. The HESSID is a globally 589 unique identifier that in conjunction with the SSID, encoded 590 within the Called-Station-Id Attribute as described in [RFC3580], 591 may be used to provide network identification for a subscription 592 service provider network (SSPN), as described in Section 8.4.2.94 593 of [IEEE-802.11]. Zero or one WLAN-HESSID Attribute is permitted 594 within an Access-Request or Accounting-Request packet. 596 A summary of the WLAN-HESSID Attribute format is shown below. The 597 fields are transmitted from left to right. 599 0 1 2 3 600 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 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Type | Length | String... 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 Code 607 TBD8 609 Length 611 19 613 String 615 The String field is encoded in upper-case ASCII characters with 616 the octet values separated by dash characters, as described in RFC 617 3580 [RFC3580]. Example: "00-10-A4-23-19-C0". 619 2.10. WLAN-Venue-Info 621 Description 623 The WLAN-Venue-Info attribute identifies the category of venue 624 hosting the WLAN, as defined in Section 8.4.1.34 of [IEEE-802.11]. 625 Zero or more WLAN-Venue-Info attributes may be included in an 626 Access-Request or Accounting-Request. 628 A summary of the WLAN-Venue-Info Attribute format is shown below. 629 The fields are transmitted from left to right. 631 0 1 2 3 632 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 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Type | Length | Value 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 Value | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 Code 641 TBD9 643 Length 645 6 647 Value 649 The Value field is four octets, containing a 32-bit unsigned 650 integer. The two most significant octets MUST be set to zero by 651 the sender, and are ignored by the receiver; the two least 652 significant octets contain the Venue Group and Venue Type fields. 654 0 1 2 3 655 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 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Reserved | Venue Group | Venue Type | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 Venue Group 662 The Venue Group field is a single octet and describes the broad 663 category of the venue, e.g. "Assembly". See Section 8.4.1.34 664 [IEEE-802.11] for Venue Group codes and descriptions. 666 Venue Type 668 The Venue Type field is a single octet and describes the venue in 669 a finer granularity within the Venue Group, e.g. "Library". See 670 Section 8.4.1.34 of [IEEE-802.11] for Venue Type codes and 671 descriptions. 673 2.11. WLAN-Venue-Language 675 Description 677 The WLAN-Venue-Language attribute is an ISO-14962-1997 678 [ISO-14962-1997] encoded string that defines the language used in 679 the WLAN-Venue-Name attribute. Zero or more WLAN-Venue-Language 680 attributes may be included in an Access-Request or Accounting- 681 Request and each one indicates the language of the WLAN-Venue-Name 682 attribute that follows it. 684 A summary of the WLAN-Venue-Language Attribute format is shown 685 below. The fields are transmitted from left to right. 687 0 1 2 3 688 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 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | Type | Length | String... 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 String (cont) | 693 +-+-+-+-+-+-+-+-+ 695 Code 697 TBD10 699 Length 701 4-5 703 String 705 The String field is a two or three character language code 706 selected from ISO-639 [ISO-639]. A two character language code 707 has a zero ("null" in ISO-14962-1997) appended to make it 3 octets 708 in length. 710 2.12. WLAN-Venue-Name 712 Description 714 The WLAN-Venue-Name attribute provides additional metadata on the 715 BSS. For example, this information may be used to assist a user 716 in selecting the appropriate BSS with which to associate. Zero or 717 more WLAN-Venue-Name attributes may be included in an Access- 718 Request or Accounting-Request in the same or different languages. 720 A summary of the WLAN-Venue-Name Attribute format is shown below. 721 The fields are transmitted from left to right. 723 0 1 2 3 724 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 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | Type | Length | String... 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 Code 731 TBD11 733 Length 735 >=3 737 String 739 The String field is a UTF-8 formatted field containing the venue's 740 name. The maximum length of this field is 252 octets. 742 2.13. WLAN-Reason-Code 744 Description 746 The WLAN-Reason-Code Attribute contains information on the reason 747 why a station has been refused network access and has been 748 disassociated or de-authenticated. This can occur due to policy 749 or for reasons related to the user's subscription. 751 A WLAN-Reason-Code Attribute MAY be included within an Access- 752 Reject or Disconnect-Request packet, as well as within an 753 Accounting-Request packet. Upon receipt of an Access-Reject or 754 Disconnect-Request packet containing a WLAN-Reason-Code Attribute, 755 the WLAN-Reason-Code value is copied by the Access Point into the 756 Reason Code field of a Disassociation or Deauthentication frame 757 (see clause 8.3.3.4 and 8.3.3.12 respectively in [IEEE- 802.11]), 758 which is subsequently transmitted to the station. 760 A summary of the WLAN-Reason-Code Attribute format is shown below. 761 The fields are transmitted from left to right. 763 0 1 2 3 764 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 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Type | Length | Value 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 Value | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 Code 773 TBD12 775 Length 777 6 779 Value 781 The Value field is four octets, containing a 32-bit unsigned 782 integer. The two most significant octets MUST be set to zero by 783 the sender, and are ignored by the receiver; the two least 784 significant octets contain the Reason Code values defined in Table 785 8-36 of Section 8.4.1.7 of [IEEE-802.11]. 787 0 1 2 3 788 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 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | Reserved | Reason Code | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 2.14. WLAN-Pairwise-Cipher 795 Description 797 The WLAN-Pairwise-Cipher Attribute contains information on the 798 pairwise cipher suite used to establish the robust security 799 network association (RSNA) between the AP and mobile device. A 800 WLAN-Pairwise-Cipher Attribute MAY be included within Access- 801 Request and Accounting-Request packets. 803 A summary of the WLAN-Pairwise-Cipher Attribute format is shown 804 below. The fields are transmitted from left to right. 806 0 1 2 3 807 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 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Type | Length | Value 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 Value | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 Code 816 TBD13 818 Length 819 6 821 Value 823 The Value field is four octets, containing a 32-bit unsigned 824 integer, in Suite selector format as specified in Figure 8-187 825 within Section 8.4.2.27.2 of [IEEE-802.11], with values of OUI and 826 Suite type drawn from Table 8-99. 828 0 1 2 3 829 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 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | OUI | Suite Type | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 2.15. WLAN-Group-Cipher 836 Description 838 The WLAN-Group-Cipher Attribute contains information on the group 839 cipher suite used to establish the robust security network 840 association (RSNA) between the AP and mobile device. A WLAN- 841 Group-Cipher Attribute MAY be included within Access-Request and 842 Accounting-Request packets. 844 A summary of the WLAN-Group-Cipher Attribute format is shown 845 below. The fields are transmitted from left to right. 847 0 1 2 3 848 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 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | Type | Length | Value 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 Value | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 Code 857 TBD14 859 Length 861 6 863 Value 865 The Value field is four octets, containing a 32-bit unsigned 866 integer, in Suite selector format as specified in Figure 8-187 867 within Section 8.4.2.27.2 of [IEEE-802.11], with values of OUI and 868 Suite type drawn from Table 8-99. 870 0 1 2 3 871 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 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | OUI | Suite Type | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 2.16. WLAN-AKM-Suite 878 Description 880 The WLAN-AKM-Suite Attribute contains information on the 881 authentication and key management suite used to establish the 882 robust security network association (RSNA) between the AP and 883 mobile device. A WLAN-AKM-Suite Attribute MAY be included within 884 Access-Request and Accounting-Request packets. 886 A summary of the WLAN-AKM-Suite Attribute format is shown below. 887 The fields are transmitted from left to right. 889 0 1 2 3 890 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 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | Type | Length | Value 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 Value | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 Code 899 TBD15 901 Length 903 6 905 Value 907 The Value field is four octets, containing a 32-bit unsigned 908 integer, in Suite selector format as specified in Figure 8-187 909 within Section 8.4.2.27.2 of [IEEE-802.11], with values of OUI and 910 Suite type drawn from Table 8-101: 912 0 1 2 3 913 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 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | OUI | Suite Type | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 2.17. WLAN-Group-Mgmt-Cipher 920 Description 922 The WLAN-Group-Mgmt-Cipher Attribute contains information on group 923 management cipher used to establish the robust security network 924 association (RSNA) between the AP and mobile device. 926 Zero or one WLAN-Group-Mgmt-Cipher Attribute MAY be included 927 within Access-Request and Accounting-Request packets. Presence of 928 the attribute indicates that the station negotiated to use 929 management frame protection during association. 931 A summary of the WLAN-Group-Mgmt-Cipher Attribute format is shown 932 below. The fields are transmitted from left to right. 934 0 1 2 3 935 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 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | Type | Length | Value 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 Value | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 Code 944 TBD16 946 Length 948 6 950 Value 952 The Value field is four octets, containing a 32-bit unsigned 953 integer, in Suite selector format as specified in Figure 8-187 954 within Section 8.4.2.27.2 of [IEEE-802.11], with values of OUI and 955 Suite type drawn from Table 8-99: 957 0 1 2 3 958 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 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 | OUI | Suite Type | 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 2.18. WLAN-RF-Band 965 Description 967 The WLAN-RF-Band Attribute contains information on the RF band 968 used by the Access Point for transmission and reception of 969 information to and from the mobile device. Zero or one WLAN-RF- 970 Band Attribute MAY be included within an Access-Request or 971 Accounting-Request packet. 973 A summary of the WLAN-RF-Band Attribute format is shown below. 974 The fields are transmitted from left to right. 976 0 1 2 3 977 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 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | Type | Length | Value 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 Value | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 Code 986 TBD17 988 Length 990 6 992 Value 994 The Value field is four octets, containing a 32-bit unsigned 995 integer. The three most significant octets MUST be set to zero by 996 the sender, and are ignored by the receiver; the least significant 997 octet contains the RF Band field, whose values are defined in 998 Table 8-53a of [IEEE-802.11ad]. 1000 0 1 2 3 1001 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 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 | Reserved | RF Band | 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 3. Table of attributes 1008 The following table provides a guide to which attributes may be found 1009 in which kinds of packets, and in what quantity. 1011 Access- Access- Access- Access- 1012 Request Accept Reject Challenge # Attribute 1013 0 0+ 0 0 TBD1 Allowed-Called-Station-Id 1014 0-1 0-1 0 0 102 EAP-Key-Name 1015 0-1 0+ 0 0 TBD2 EAP-Peer-Id 1016 0-1 0+ 0 0 TBD3 EAP-Server-Id 1017 0-1 0 0 0 TBD4 Mobility-Domain-Id 1018 0-1 0-1 0 0 TBD5 Preauth-Timeout 1019 0-1 0 0 0 TBD6 Network-Id-Name 1020 0+ 0+ 0+ 0+ TBD7 EAPoL-Announcement 1021 0-1 0 0 0 TBD8 WLAN-HESSID 1022 0-1 0 0 0 TBD9 WLAN-Venue-Info 1023 0+ 0 0 0 TBD10 WLAN-Venue-Language 1024 0+ 0 0 0 TBD11 WLAN-Venue-Name 1025 0 0 0-1 0 TBD12 WLAN-Reason-Code 1026 0-1 0 0 0 TBD13 WLAN-Pairwise-Cipher 1027 0-1 0 0 0 TBD14 WLAN-Group-Cipher 1028 0-1 0 0 0 TBD15 WLAN-AKM-Suite 1029 0-1 0 0 0 TBD16 WLAN-Group-Mgmt-Cipher 1030 0-1 0 0 0 TBD17 WLAN-RF-Band 1032 CoA- Dis- Acct- 1033 Req Req Req # Attribute 1034 0+ 0 0+ TBD1 Allowed-Called-Station-Id 1035 0-1 0 0 102 EAP-Key-Name 1036 0 0 0+ TBD2 EAP-Peer-Id 1037 0 0 0+ TBD3 EAP-Server-Id 1038 0 0 0-1 TBD4 Mobility-Domain-Id 1039 0-1 0 0 TBD5 Preauth-Timeout 1040 0 0 0-1 TBD6 Network-Id-Name 1041 0+ 0+ 0+ TBD7 EAPoL-Announcement 1042 0 0 0-1 TBD8 WLAN-HESSID 1043 0 0 0-1 TBD9 WLAN-Venue-Info 1044 0 0 0+ TBD10 WLAN-Venue-Language 1045 0 0 0+ TBD11 WLAN-Venue-Name 1046 0 0-1 0-1 TBD12 WLAN-Reason-Code 1047 0 0 0-1 TBD13 WLAN-Pairwise-Cipher 1048 0 0 0-1 TBD14 WLAN-Group-Cipher 1049 0 0 0-1 TBD15 WLAN-AKM-Suite 1050 0 0 0-1 TBD16 WLAN-Group-Mgmt-Cipher 1051 0 0 0-1 TBD17 WLAN-RF-Band 1053 The following table defines the meaning of the above table entries. 1055 0 This Attribute MUST NOT be present in packet. 1056 0+ Zero or more instances of this Attribute MAY be 1057 present in the packet. 1058 0-1 Zero or one instance of this Attribute MAY be 1059 present in the packet. 1061 4. IANA Considerations 1063 This document uses the RADIUS [RFC2865] namespace, see 1064 . This specification 1065 requires assignment of a RADIUS attribute types for the following 1066 attributes: 1068 Attribute Type 1069 ========= ==== 1070 Allowed-Called-Station-Id TBD1 1071 EAP-Peer-Id TBD2 1072 EAP-Server-Id TBD3 1073 Mobility-Domain-Id TBD4 1074 Preauth-Timeout TBD5 1075 Network-Id-Name TBD6 1076 EAPoL-Announcement TBD7 1077 WLAN-HESSID TBD8 1078 WLAN-Venue-Info TBD9 1079 WLAN-Venue-Language TBD10 1080 WLAN-Venue-Name TBD11 1081 WLAN-Reason-Code TBD12 1082 WLAN-Pairwise-Cipher TBD13 1083 WLAN-Group-Cipher TBD14 1084 WLAN-AKM-Suite TBD15 1085 WLAN-Group-Mgmt-Cipher TBD16 1086 WLAN-RF-Band TBD17 1088 Since this specification relies entirely on values assigned by IEEE 1089 802, no registries are established for maintenance by the IANA. 1091 5. Security Considerations 1093 Since this document describes the use of RADIUS for purposes of 1094 authentication, authorization, and accounting in IEEE 802 networks, 1095 it is vulnerable to all of the threats that are present in other 1096 RADIUS applications. For a discussion of these threats, see 1097 [RFC2607], [RFC2865], [RFC3162], [RFC3579], [RFC3580] and [RFC5176]. 1098 In particular, when RADIUS traffic is sent in the clear, the 1099 attributes defined in this document can be obtained by an attacker 1100 snooping the exchange between the RADIUS client and server. As a 1101 result, RADIUS confidentiality is desirable; for a review of RADIUS 1102 security and crypto-agility requirements, see [RFC6421]. 1104 While it is possible for a RADIUS server to make decisions on whether 1105 to Accept or Reject an Access-Request based on the values of the 1106 WLAN-Pairwise-Cipher, WLAN-Group-Cipher, WLAN-AKM-Suite, WLAN-Group- 1107 Mgmt-Cipher and WLAN-RF-Band Attributes the value of doing this is 1108 limited. In general, an Access-Reject should not be necessary, 1109 except where Access Points and Stations are misconfigured so as to 1110 enable connections to be made with unacceptable values. Rather than 1111 rejecting access on an ongoing basis, users would be better served by 1112 fixing the misconfiguration. 1114 Where access does need to be rejected, the user should be provided 1115 with an indication of why the problem has occurred, or else they are 1116 likely to become frustrated. For example, if the values of the WLAN- 1117 Pairwise-Cipher, WLAN-Group-Cipher, WLAN-AKM-Suite or WLAN-Group- 1118 Mgmt-Cipher Attributes included in the Access-Request are not 1119 acceptable to the RADIUS server, then a WLAN-Reason-Code Attribute 1120 with a value of 29 (Requested service rejected because of service 1121 provider cipher suite or AKM requirement) SHOULD be returned in the 1122 Access-Reject. Similarly, if the value of the WLAN-RF-Band Attribute 1123 included in the Access-Request is not acceptable to the RADIUS 1124 server, then a WLAN-Reason-Code Attribute with a value of 11 1125 (Disassociated because the information in the Supported Channels 1126 element is unacceptable) SHOULD be returned in the Access-Reject. 1128 6. References 1130 6.1. Normative references 1132 [IEEE-802] IEEE Standards for Local and Metropolitan Area Networks: 1133 Overview and Architecture, ANSI/IEEE Std 802, 1990. 1135 [IEEE-802.11] 1136 Information technology - Telecommunications and Information 1137 Exchange Between Systems - Local and Metropolitan Area 1138 Networks - Specific Requirements Part 11: Wireless LAN 1139 Medium Access Control (MAC) and Physical Layer (PHY) 1140 Specifications, IEEE Std. 802.11-2012, 2012. 1142 [IEEE-802.11ad] 1143 Information technology - Telecommunications and Information 1144 Exchange Between Systems - Local and Metropolitan Area 1145 Networks - Specific Requirements Part 11: Wireless LAN 1146 Medium Access Control (MAC) and Physical Layer (PHY) 1147 Specifications, Amendment 3: Enhancements for Very High 1148 Throughput in the 60 GHz Band, IEEE Std. 802.11ad-2012, 2012. 1150 [IEEE-802.1X] 1151 IEEE Standard for Local and Metropolitan Area Networks - 1152 Port-Based Network Access Control, IEEE 802.1X-2010, February 1153 2010. 1155 [ISO-639] ISO, "Codes for the Representation of Names of Languages". 1157 [ISO-14962-1997] 1158 ISO, "Space data and information transfer systems - ASCII 1159 encoded English", 1997. 1161 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1162 Requirement Levels", RFC 2119, March, 1997. 1164 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 1165 Authentication Dial In User Service (RADIUS)", RFC 2865, June 1166 2000. 1168 [RFC4072] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 1169 Authentication Protocol (EAP) Application", RFC 4072, August 1170 2005. 1172 [RFC5247] Aboba, B., Simon, D. and P. Eronen, "EAP Key Management 1173 Framework", RFC 5247, August 2008. 1175 6.2. Informative references 1177 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 1178 Implementation in Roaming", RFC 2607, June 1999. 1180 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 1181 3162, August 2001. 1183 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 1184 Authentication Protocol (EAP)", RFC 3579, September 2003. 1186 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 1187 "IEEE 802.1X Remote Authentication Dial In User Service 1188 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 1190 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 1191 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 1192 3748, June 2004. 1194 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, 1195 "Dynamic Authorization Extensions to Remote Authentication 1196 Dial In User Service (RADIUS)", RFC 5176, January 2008. 1198 [RFC6421] Nelson, D., "Crypto-Agility Requirements for Remote 1199 Authentication Dial-In User Service (RADIUS)", RFC 6421, 1200 November 2011. 1202 Acknowledgments 1204 The authors would like to acknowledge Maximilian Riegel, Dorothy 1205 Stanley, Yoshihiro Ohba, and the contributors to the IEEE 802.1 and 1206 IEEE 802.11 reviews of this document, for useful discussions. 1208 Authors' Addresses 1210 Bernard Aboba 1211 Microsoft Corporation 1212 One Microsoft Way 1213 Redmond, WA 98052 1215 EMail: bernard_aboba@hotmail.com 1217 Jouni Malinen 1218 EMail: j@w1.fi 1220 Paul Congdon 1221 Tallac Networks 1222 6528 Lonetree Blvd. 1223 Rocklin, CA 95765 1225 Phone: +19167576350 1226 EMail: paul.congdon@tallac.com 1228 Joseph Salowey 1229 Cisco Systems 1230 EMail: jsalowey@cisco.com 1232 Mark Jones 1233 Azuca Systems 1234 EMail: mark@azu.ca