idnits 2.17.1 draft-ietf-radext-ieee802ext-08.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 (Using the creation date from RFC4072, updated by this document, for RFC5378 checks: 2002-06-24) -- 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 (14 July 2013) is 3939 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) -- Looks like a reference, but probably isn't: '1' on line 225 -- Looks like a reference, but probably isn't: '2' on line 237 -- Looks like a reference, but probably isn't: '3' on line 245 -- 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' -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RADEXT Working Group Bernard Aboba 3 INTERNET-DRAFT Skype 4 Category: Proposed Standard Jouni Malinen 5 Expires: January 14, 2014 Devicescape Software 6 Updates: 4072 Paul Congdon 7 Hewlett Packard Company 8 Joseph Salowey 9 Cisco Systems 10 Mark Jones 11 Azuca Systems 12 14 July 2013 14 RADIUS Attributes for IEEE 802 Networks 15 draft-ietf-radext-ieee802ext-08.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 proposes additional attributes for use within 22 IEEE 802 networks, as well as clarifications on the usage of the EAP- 23 Key-Name attribute, updating RFC 4072. The attributes defined in 24 this document are usable both within RADIUS and Diameter. 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 January 14, 2014. 49 Copyright Notice 51 Copyright (c) 2013 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 .................................... 7 84 2.3 EAP-Peer-Id ..................................... 8 85 2.4 EAP-Server-Id ................................... 9 86 2.5 Mobility-Domain-Id .............................. 10 87 2.6 Preauth-Timeout ................................. 11 88 2.7 Network-Id-Name ................................. 12 89 2.8 Access-Info ..................................... 13 90 2.9 WLAN-HESSID ..................................... 14 91 2.10 WLAN-Venue-Info ................................. 14 92 2.11 WLAN-Venue-Language ............................. 16 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 ................................... 24 101 4. Diameter Considerations ............................... 25 102 5. IANA Considerations ................................... 26 103 6. Security Considerations ............................... 26 104 7. References ............................................ 27 105 7.1 Normative References .................................. 27 106 7.2 Informative References ................................ 28 107 ACKNOWLEDGMENTS .............................................. 29 108 AUTHORS' ADDRESSES ........................................... 29 109 1. Introduction 111 In situations where it is desirable to centrally manage 112 authentication, authorization and accounting (AAA) for IEEE 802 113 [IEEE-802] networks, deployment of a backend authentication and 114 accounting server is desirable. In such situations, it is expected 115 that IEEE 802 authenticators will function as AAA clients. 117 "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) 118 Usage Guidelines" [RFC3580] defined guidelines for the use of the 119 Remote Authentication Dialin User Service (RADIUS) within networks 120 utilizing IEEE 802 local area networks. This document defines 121 additional attributes suitable for usage by IEEE 802 authenticators 122 acting as AAA clients. The attributes defined in this document are 123 usable both within RADIUS and Diameter. 125 1.1. Terminology 127 This document uses the following terms: 129 Access Point (AP) 130 A Station that provides access to the distribution 131 services via the wireless medium for associated Stations. 133 Association The service used to establish Access Point/Station 134 mapping and enable Station invocation of the distribution 135 system services. 137 authenticator An authenticator is an entity that require authentication 138 from the supplicant. The authenticator may be connected 139 to the supplicant at the other end of a point-to-point 140 LAN segment or wireless link. 142 authentication server 143 An authentication server is an entity that provides an 144 authentication service to an authenticator. This service 145 verifies from the credentials provided by the supplicant, 146 the claim of identity made by the supplicant. 148 Station (STA) Any device that contains an IEEE 802.11 conformant medium 149 access control (MAC) and physical layer (PHY) interface 150 to the wireless medium (WM). 152 Supplicant A supplicant is an entity that is being authenticated by 153 an authenticator. The supplicant may be connected to the 154 authenticator at one end of a point-to-point LAN segment 155 or 802.11 wireless link. 157 1.2. Requirements Language 159 In this document, several words are used to signify the requirements 160 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 161 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 162 and "OPTIONAL" in this document are to be interpreted as described in 163 [RFC2119]. 165 2. RADIUS attributes 167 2.1. Allowed-Called-Station-Id 169 Description 171 The Allowed-Called-Station-Id Attribute allows the RADIUS server 172 to specify the authenticator MAC addresses and/or networks to 173 which the user is allowed to connect. One or more Allowed-Called- 174 Station-Id attributes MAY be included in an Access-Accept or CoA- 175 Request packet. 177 A summary of the Allowed-Called-Station-Id Attribute format is 178 shown below. The fields are transmitted from left to right. 180 0 1 2 3 181 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 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Type | Length | String... 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 Code 188 TBD1 190 Length 192 >=3 194 String 196 The String field is one or more octets, containing the layer 2 197 endpoint that the user's call is allowed to be terminated on, as 198 specified in the definition of Called-Station-Id in [RFC2865] 199 Section 5.30 and [RFC3580] Section 3.20. In the case of IEEE 802, 200 the Allowed-Called-Station-Id Attribute is used to store the 201 Medium Access Control (MAC) address in ASCII format (upper case 202 only), with octet values separated by a "-". Example: 203 "00-10-A4-23-19-C0". Where restrictions on both the network and 204 authenticator MAC address usage are intended, the network name 205 MUST be appended to the authenticator MAC address, separated from 206 the MAC address with a ":". Example: "00-10-A4-23-19-C0:AP1". 207 Where no MAC address restriction is intended, the MAC address 208 field MUST be omitted, but ":" and the network name field MUST be 209 included. Example: ":AP1". Within IEEE 802.11 [IEEE-802.11], the 210 SSID constitutes the network name; within IEEE 802.1X 211 [IEEE-802.1X], the Network-Id Name (NID-Name) constitutes the 212 network name. Since a NID-Name can be up to 253 octets in length, 213 when used with [IEEE-802.1X], there may not be sufficient room 214 within the Allowed-Called-Station-Id Attribute to include a MAC 215 address. 217 If the user attempts to connect to the NAS from a Called-Station- 218 Id that does not match one of the Allowed-Called-Station-Id 219 attributes, then the user MUST NOT be permitted to access the 220 network. 222 The Allowed-Called-Station-Id Attribute can be useful in the 223 following situations: 225 [1] Where users can connect to a NAS without an Access-Request being 226 sent by the NAS to the RADIUS server (e.g. where key caching is 227 supported within IEEE 802.11 or IEEE 802.1X [IEEE-802.1X]). To 228 ensure that an attacker cannot gain entry to a network they have 229 not authenticated to, key cache entries are typically only 230 usable within the network to which the user originally 231 authenticated (e.g. the originally selected network name is 232 implicitly attached to the key cache entry). Also, if it is 233 desired that access to a network name not be available from a 234 particular authenticator MAC address, then the authenticator can 235 be set up not to advertise that particular network name. 237 [2] Where pre-authentication may be supported (e.g. IEEE 802.1X 238 pre-authentication). In this situation, the network name 239 typically will not be included in a Called-Station-Id Attribute 240 within the Access-Request, so that the RADIUS server will not 241 know the network that the user is attempting to access. As a 242 result, the RADIUS server may desire to restrict the networks to 243 which the user can subsequently connect. 245 [3] Where the network portion of the Called-Station-Id is present 246 within an Access-Request, the RADIUS server can desire to 247 authorize access to a network different from the one that the 248 user selected. 250 2.2. EAP-Key-Name 252 Description 254 The EAP-Key-Name Attribute, defined in "Diameter Extensible 255 Authentication Protocol (EAP) Application" [RFC4072], contains the 256 EAP Session-Id, as described in "Extensible Authentication 257 Protocol (EAP) Key Management Framework" [RFC5247]. Exactly how 258 this Attribute is used depends on the link layer in question. 260 It should be noted that not all link layers use this name. An 261 EAP-Key-Name Attribute MAY be included within Access-Request, 262 Access-Accept and CoA-Request packets. A summary of the EAP-Key- 263 Name Attribute format is shown below. The fields are transmitted 264 from left to right. 266 0 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Type | Length | String... 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Code 274 102 [RFC4072] 276 Length 278 >=3 280 String 282 The String field is one or more octets, containing the EAP 283 Session-Id, as defined in "Extensible Authentication Protocol 284 (EAP) Key Management Framework" [RFC5247]. Since the NAS operates 285 as a pass-through in EAP, it cannot know the EAP Session-Id before 286 receiving it from the RADIUS server. As a result, an EAP-Key-Name 287 Attribute sent in an Access-Request MUST only contain a single NUL 288 character. A RADIUS server receiving an Access-Request with an 289 EAP-Key-Name Attribute containing anything other than a single NUL 290 character MUST silently discard the Attribute. In addition, the 291 RADIUS server SHOULD include this Attribute in an Access-Accept or 292 CoA-Request only if an EAP-Key-Name Attribute was present in the 293 Access-Request. Since a NAS will typically only include a EAP- 294 Key-Name Attribute in an Access-Request in situations where the 295 Attribute is required to provision service, if an EAP-Key-Name 296 Attribute is included in an Access-Request but is not present in 297 the Access-Accept, the NAS SHOULD treat the Access-Accept as 298 though it were an Access-Reject. If an EAP-Key-Name Attribute was 299 not present in the Access-Request but is included in the Access- 300 Accept, then the NAS SHOULD silently discard the EAP-Key-Name 301 Attribute. 303 2.3. EAP-Peer-Id 305 Description 307 The EAP-Peer-Id Attribute contains a Peer-Id generated by the EAP 308 method. Exactly how this name is used depends on the link layer 309 in question. See [RFC5247] for more discussion. The EAP-Peer-Id 310 Attribute MAY be included in Access-Request, Access-Accept and 311 Accounting-Request packets. More than one EAP-Peer-Id Attribute 312 MUST NOT be included in an Access-Request; one or more EAP-Peer-Id 313 attributes MAY be included in an Access-Accept. 315 It should be noted that not all link layers use this name, and 316 existing EAP method implementations do not generate it. Since the 317 NAS operates as a pass-through in EAP [RFC3748], it cannot know 318 the EAP-Peer-Id before receiving it from the RADIUS server. As a 319 result, an EAP-Peer-Id Attribute sent in an Access-Request MUST 320 only contain a single NUL character. A home RADIUS server 321 receiving an Access-Request an EAP-Peer-Id Attribute containing 322 anything other than a single NUL character MUST silently discard 323 the Attribute. In addition, the home RADIUS server SHOULD include 324 one or more EAP-Peer-Id attributes in an Access-Accept only if an 325 EAP-Peer-Id Attribute was present in the Access-Request. If a NAS 326 receives EAP-Peer-Id Attribute(s) in an Access-Accept without 327 having included one in an Access-Request, the NAS SHOULD silently 328 discard the Attribute(s). A summary of the EAP-Peer-Id Attribute 329 format is shown below. The fields are transmitted from left to 330 right. 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Type | Length | String... 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 Code 340 TBD2 342 Length 344 >=3 346 String 348 The String field is one or more octets containing a EAP Peer-Id 349 exported by the EAP method. For details, see [RFC5247] Appendix 350 A. A robust implementation SHOULD support the field as 351 undistinguished octets. Only a single EAP Peer-Id may be included 352 per Attribute. 354 2.4. EAP-Server-Id 356 Description 358 The EAP-Server-Id Attribute contains a Server-Id generated by the 359 EAP method. Exactly how this name is used depends on the link 360 layer in question. See [RFC5247] for more discussion. The EAP- 361 Server-Id Attribute is only allowed in Access-Request, Access- 362 Accept, and Accounting-Request packets. More than one EAP-Server- 363 Id Attribute MUST NOT be included in an Access-Request; one or 364 more EAP-Server-Id attributes MAY be included in an Access-Accept. 366 It should be noted that not all link layers use this name, and 367 existing EAP method implementations do not generate it. Since the 368 NAS operates as a pass-through in EAP [RFC3748], it cannot know 369 the EAP-Server-Id before receiving it from the RADIUS server. As 370 a result, an EAP-Server-Id Attribute sent in an Access-Request 371 MUST contain only a single NUL character. A home RADIUS server 372 receiving in an Access-Request an EAP-Server-Id Attribute 373 containing anything other than a single NUL character MUST 374 silently discard the Attribute. In addition, the home RADIUS 375 server SHOULD include this Attribute an Access-Accept only if an 376 EAP-Server-Id Attribute was present in the Access-Request. A 377 summary of the EAP-Server-Id Attribute format is shown below. The 378 fields are transmitted from left to right. 380 0 1 2 3 381 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 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Type | Length | String... 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 Code 388 TBD3 390 Length 392 >=3 394 String 396 The String field is one or more octets, containing a EAP Server-Id 397 exported by the EAP method. For details, see [RFC5247] Appendix 398 A. A robust implementation SHOULD support the field as 399 undistinguished octets. 401 2.5. Mobility-Domain-Id 403 Description 405 A single Mobility-Domain-Id Attribute MAY be included in an 406 Access-Request or Accounting-Request, in order to enable the NAS 407 to provide the RADIUS server with the Mobility Domain Identifier 408 (MDID), defined in Section 8.4.2.49 of [IEEE-802.11]. A summary 409 of the Mobility-Domain-Id Attribute format is shown below. The 410 fields are transmitted from left to right. 412 0 1 2 3 413 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 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Type | Length | Value 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Value | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 Code 422 TBD4 424 Length 426 6 428 Value 430 The Value field is four octets, containing a 32-bit unsigned 431 integer. The two most significant octets MUST be set to zero by 432 the sender, and are ignored by the receiver; the two least 433 significant octets contain the Mobility Domain Identifier (MDID) 434 defined in Section 8.4.2.49 of [IEEE-802.11]. 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Reserved | Mobility Domain Identifier | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 2.6. Preauth-Timeout 444 Description 446 This Attribute sets the maximum number of seconds which pre- 447 authentication state is required to be kept by the NAS, without 448 being utilized within a user session. For example, when 449 [IEEE-802.11] pre-authentication is used, if a user has not 450 attempted to utilize the Pairwise Master Key (PMK) derived as a 451 result of pre-authentication within the time specified by the 452 Preauth-Timeout Attribute, the PMK MAY be discarded by the Access 453 Point. However, once the session is underway, the Preauth-Timeout 454 Attribute has no bearing on the maximum session time for the user, 455 or the maximum time during which key state may be kept prior to 456 re-authentication. This is determined by the Session-Timeout 457 Attribute, if present. 459 A single Preauth-Timeout Attribute MAY be included within an 460 Access-Accept or CoA-Request packet. A summary of the Preauth- 461 Timeout Attribute format is shown below. The fields are 462 transmitted from left to right. 464 0 1 2 3 465 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 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Type | Length | Value 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 Value (cont) | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 Code 474 TBD5 476 Length 478 6 480 Value 482 The field is 4 octets, containing a 32-bit unsigned integer 483 encoding the maximum time in seconds that pre-authentication state 484 should be retained by the NAS. 486 2.7. Network-Id-Name 488 Description 490 The Network-Id-Name Attribute is utilized by implementations of 491 IEEE-802.1X [IEEE-802.1X] to specify the name of a Network-Id 492 (NID-Name). 494 Unlike the IEEE 802.11 SSID (which is a maximum of 32 octets in 495 length), the NID-Name may be up to 253 octets in length. 496 Consequently, if the MAC address is included within the Called- 497 Station-Id Attribute, it is possible that there will not be enough 498 remaining space to encode the NID-Name as well. Therefore when 499 used with IEEE 802.1X [IEEE-802.1X], the Called-Station-Id 500 Attribute SHOULD contain only the MAC address, with the Network- 501 Id-Name Attribute used to transmit the NID-Name. The Network-Id- 502 Name Attribute MUST NOT be used to encode the IEEE 802.11 SSID; as 503 noted in [RFC3580], the Called-Station-Id Attribute is used for 504 this purpose. 506 Zero or one Network-Id-Name Attribute is permitted within an 507 Access-Request, Access-Challenge, Access-Accept or Accounting- 508 Request packet. When included within an Access-Request packet, 509 the Network-Id-Name Attribute represents a hint of the NID-Name to 510 which the Supplicant should be granted access. When included 511 within an Access-Accept packet, the Network-Id-Name Attribute 512 represents the NID-Name to which the Supplicant is to be granted 513 access. When included within an Accounting-Request packet, the 514 Network-Id-Name Attribute represents the NID-Name to which the 515 Supplicant has been granted access. 517 A summary of the Network-Id-Name Attribute format is shown below. 518 The fields are transmitted from left to right. 520 0 1 2 3 521 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 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Type | Length | String... 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 Code 528 TBD6 530 Length 532 >=3 534 String 536 The String field is one or more octets, containing a NID-Name. 537 For details, see [IEEE-802.1X]. A robust implementation SHOULD 538 support the field as undistinguished octets. 540 2.8. Access-Info 542 Description 544 The Access-Info Attribute is utilized by implementations of 545 IEEE-802.1X [IEEE-802.1X] to specify the Access status information 546 field within an Access Information Type Length Value Tuple (TLV) 547 to be sent to the user within MACsec Key Agreement (MKA) or EAPoL- 548 Announcement (Specific) frames. 550 Zero or one Access-Info Attribute is permitted within an Access- 551 Accept, Access-Challenge, Access-Reject, Accounting-Request, CoA- 552 Request or Disconnect-Request packet. When sent along with the 553 Network-Id-Name Attribute, the Access-Info Attribute provides 554 Access status information relating to that particular NID-Name. 556 A summary of the Access-Info Attribute format is shown below. The 557 fields are transmitted from left to right. 559 0 1 2 3 560 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 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Type | Length | Value 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 Value | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 Code 569 TBD7 571 Length 573 6 575 Value 577 The Value field is four octets, containing a 32-bit unsigned 578 integer. The two most significant octets MUST be set to zero by 579 the sender, and are ignored by the receiver; the two least 580 significant octets contain the Access status information defined 581 in Table 11-9 of Section 11.12.2 of [IEEE-802.1X]. 583 0 1 2 3 584 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 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Reserved | Access status information | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 2.9. WLAN-HESSID 591 Description 593 The WLAN-HESSID attribute contains a MAC address that identifies 594 the Homogenous Extended Service Set. The HESSID is a globally 595 unique identifier that in conjunction with the SSID, encoded 596 within the Called-Station-Id Attribute as described in [RFC3580], 597 may be used to provide network identification for a subscription 598 service provider network (SSPN), as described in Section 8.4.2.94 599 of [IEEE-802.11]. Zero or one WLAN-HESSID Attribute is permitted 600 within an Access-Request or Accounting-Request packet. 602 A summary of the WLAN-HESSID Attribute format is shown below. The 603 fields are transmitted from left to right. 605 0 1 2 3 606 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 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Type | Length | String... 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 Code 613 TBD8 615 Length 617 19 619 String 621 The String field is encoded in upper-case ASCII characters with 622 the octet values separated by dash characters, as described in RFC 623 3580 [RFC3580]. Example: "00-10-A4-23-19-C0". 625 2.10. WLAN-Venue-Info 627 Description 629 The WLAN-Venue-Info attribute identifies the category of venue 630 hosting the WLAN, as defined in Section 8.4.1.34 of [IEEE-802.11]. 632 Zero or more WLAN-Venue-Info attributes may be included in an 633 Access-Request or Accounting-Request. 635 A summary of the WLAN-Venue-Info Attribute format is shown below. 636 The fields are transmitted from left to right. 638 0 1 2 3 639 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 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Type | Length | Value 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 Value | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 Code 648 TBD9 650 Length 652 6 654 Value 656 The Value field is four octets, containing a 32-bit unsigned 657 integer. The two most significant octets MUST be set to zero by 658 the sender, and are ignored by the receiver; the two least 659 significant octets contain the Venue Group and Venue Type fields. 661 0 1 2 3 662 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 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Reserved | Venue Group | Venue Type | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 Venue Group 669 The Venue Group field is a single octet and describes the broad 670 category of the venue, e.g. "Assembly". See Section 8.4.1.34 671 [IEEE-802.11] for Venue Group codes and descriptions. 673 Venue Type 675 The Venue Type field is a single octet and describes the venue in 676 a finer granularity within the Venue Group, e.g. "Library". See 677 Section 8.4.1.34 of [IEEE-802.11] for Venue Type codes and 678 descriptions. 680 2.11. WLAN-Venue-Language 682 Description 684 The WLAN-Venue-Language attribute is an ISO-14962-1997 685 [ISO-14962-1997] encoded string that defines the language used in 686 the WLAN-Venue-Name attribute. Zero or more WLAN-Venue-Language 687 attributes may be included in an Access-Request or Accounting- 688 Request and each one indicates the language of the WLAN-Venue-Name 689 attribute that follows it. 691 A summary of the WLAN-Venue-Language Attribute format is shown 692 below. The fields are transmitted from left to right. 694 0 1 2 3 695 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 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Type | Length | String... 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 String (cont) | 700 +-+-+-+-+-+-+-+-+ 702 Code 704 TBD10 706 Length 708 4-5 710 String 712 The String field is a two or three character language code 713 selected from ISO-639 [ISO-639]. A two character language code 714 has a zero ("null" in ISO-14962-1997) appended to make it 3 octets 715 in length. 717 2.12. WLAN-Venue-Name 719 Description 721 The WLAN-Venue-Name attribute provides additional metadata on the 722 BSS. For example, this information may be used to assist a user 723 in selecting the appropriate BSS with which to associate. Zero or 724 more WLAN-Venue-Name attributes may be included in an Access- 725 Request or Accounting-Request in the same or different languages. 727 A summary of the WLAN-Venue-Name Attribute format is shown below. 729 The fields are transmitted from left to right. 731 0 1 2 3 732 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 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | Type | Length | String... 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 Code 739 TBD11 741 Length 743 >=3 745 String 747 The String field is a UTF-8 formatted field containing the venue's 748 name. The maximum length of this field is 252 octets. 750 2.13. WLAN-Reason-Code 752 Description 754 The WLAN-Reason-Code Attribute contains information on the reason 755 why a station has been refused network access and has been 756 disassociated or de-authenticated. This can occur due to policy 757 or for reasons related to the user's subscription. 759 A WLAN-Reason-Code Attribute MAY be included within an Access- 760 Reject or Disconnect-Request packet, as well as within an 761 Accounting-Request packet. Upon receipt of an Access-Reject or 762 Disconnect-Request packet containing a WLAN-Reason-Code Attribute, 763 the WLAN-Reason-Code value is copied by the Access Point into the 764 Reason Code field of a Disassociation or Deauthentication frame 765 (see clause 8.3.3.4 and 8.3.3.12 respectively in [IEEE- 802.11]), 766 which is subsequently transmitted to the station. 768 A summary of the WLAN-Reason-Code Attribute format is shown below. 769 The fields are transmitted from left to right. 771 0 1 2 3 772 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 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | Type | Length | Value 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 Value | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 Code 781 TBD12 783 Length 785 6 787 Value 789 The Value field is four octets, containing a 32-bit unsigned 790 integer. The two most significant octets MUST be set to zero by 791 the sender, and are ignored by the receiver; the two least 792 significant octets contain the Reason Code values defined in Table 793 8-36 of Section 8.4.1.7 of [IEEE-802.11]. 795 0 1 2 3 796 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 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Reserved | Reason Code | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 2.14. WLAN-Pairwise-Cipher 803 Description 805 The WLAN-Pairwise-Cipher Attribute contains information on the 806 pairwise cipher suite used to establish the robust security 807 network association (RSNA) between the AP and mobile device. A 808 WLAN-Pairwise-Cipher Attribute MAY be included within Access- 809 Request and Accounting-Request packets. 811 A summary of the WLAN-Pairwise-Cipher Attribute format is shown 812 below. The fields are transmitted from left to right. 814 0 1 2 3 815 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 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Type | Length | Value 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 Value | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 Code 824 TBD13 826 Length 828 6 830 Value 832 The Value field is four octets, containing a 32-bit unsigned 833 integer, in Suite selector format as specified in Figure 8-187 834 within Section 8.4.2.27.2 of [IEEE-802.11], with values of OUI and 835 Suite type drawn from Table 8-99. 837 0 1 2 3 838 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 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | OUI | Suite Type | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 2.15. WLAN-Group-Cipher 845 Description 847 The WLAN-Group-Cipher Attribute contains information on the group 848 cipher suite used to establish the robust security network 849 association (RSNA) between the AP and mobile device. A WLAN- 850 Group-Cipher Attribute MAY be included within Access-Request and 851 Accounting-Request packets. 853 A summary of the WLAN-Group-Cipher Attribute format is shown 854 below. The fields are transmitted from left to right. 856 0 1 2 3 857 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 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Type | Length | Value 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 Value | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 Code 866 TBD14 868 Length 870 6 872 Value 874 The Value field is four octets, containing a 32-bit unsigned 875 integer, in Suite selector format as specified in Figure 8-187 876 within Section 8.4.2.27.2 of [IEEE-802.11], with values of OUI and 877 Suite type drawn from Table 8-99. 879 0 1 2 3 880 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 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | OUI | Suite Type | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 2.16. WLAN-AKM-Suite 887 Description 889 The WLAN-AKM-Suite Attribute contains information on the 890 authentication and key management suite used to establish the 891 robust security network association (RSNA) between the AP and 892 mobile device. A WLAN-AKM-Suite Attribute MAY be included within 893 Access-Request and Accounting-Request packets. 895 A summary of the WLAN-AKM-Suite Attribute format is shown below. 896 The fields are transmitted from left to right. 898 0 1 2 3 899 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 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | Type | Length | Value 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 Value | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 Code 908 TBD15 910 Length 912 6 914 Value 916 The Value field is four octets, containing a 32-bit unsigned 917 integer, in Suite selector format as specified in Figure 8-187 918 within Section 8.4.2.27.2 of [IEEE-802.11], with values of OUI and 919 Suite type drawn from Table 8-101: 921 0 1 2 3 922 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 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | OUI | Suite Type | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 2.17. WLAN-Group-Mgmt-Cipher 929 Description 931 The WLAN-Group-Mgmt-Cipher Attribute contains information on group 932 management cipher used to establish the robust security network 933 association (RSNA) between the AP and mobile device. 935 Zero or one WLAN-Group-Mgmt-Cipher Attribute MAY be included 936 within Access-Request and Accounting-Request packets. Presence of 937 the attribute indicates that the station negotiated to use 938 management frame protection during association. 940 A summary of the WLAN-Group-Mgmt-Cipher Attribute format is shown 941 below. The fields are transmitted from left to right. 943 0 1 2 3 944 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 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | Type | Length | Value 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 Value | 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 Code 953 TBD16 955 Length 957 6 959 Value 961 The Value field is four octets, containing a 32-bit unsigned 962 integer, in Suite selector format as specified in Figure 8-187 963 within Section 8.4.2.27.2 of [IEEE-802.11], with values of OUI and 964 Suite type drawn from Table 8-99: 966 0 1 2 3 967 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 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | OUI | Suite Type | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 2.18. WLAN-RF-Band 974 Description 976 The WLAN-RF-Band Attribute contains information on the RF band 977 used by the Access Point for transmission and reception of 978 information to and from the mobile device. Zero or one WLAN-RF- 979 Band Attribute MAY be included within an Access-Request or 980 Accounting-Request packet. 982 A summary of the WLAN-RF-Band Attribute format is shown below. 983 The fields are transmitted from left to right. 985 0 1 2 3 986 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 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | Type | Length | Value 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 Value | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 Code 995 TBD17 997 Length 999 6 1001 Value 1003 The Value field is four octets, containing a 32-bit unsigned 1004 integer. The three most significant octets MUST be set to zero by 1005 the sender, and are ignored by the receiver; the least significant 1006 octet contains the RF Band field, whose values are defined in 1007 Table 8-53a of [IEEE-802.11ad]. 1009 0 1 2 3 1010 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 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 | Reserved | RF Band | 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 3. Table of attributes 1017 The following table provides a guide to which attributes may be found 1018 in which kinds of packets, and in what quantity. 1020 Access- Access- Access- Access- 1021 Request Accept Reject Challenge # Attribute 1022 0 0+ 0 0 TBD1 Allowed-Called-Station-Id 1023 0-1 0-1 0 0 102 EAP-Key-Name 1024 0-1 0+ 0 0 TBD2 EAP-Peer-Id 1025 0-1 0+ 0 0 TBD3 EAP-Server-Id 1026 0-1 0 0 0 TBD4 Mobility-Domain-Id 1027 0-1 0-1 0 0 TBD5 Preauth-Timeout 1028 0-1 0 0 0 TBD6 Network-Id-Name 1029 0 0-1 0-1 0-1 TBD7 Access-Info 1030 0-1 0 0 0 TBD8 WLAN-HESSID 1031 0-1 0 0 0 TBD9 WLAN-Venue-Info 1032 0+ 0 0 0 TBD10 WLAN-Venue-Language 1033 0+ 0 0 0 TBD11 WLAN-Venue-Name 1034 0 0 0-1 0 TBD12 WLAN-Reason-Code 1035 0-1 0 0 0 TBD13 WLAN-Pairwise-Cipher 1036 0-1 0 0 0 TBD14 WLAN-Group-Cipher 1037 0-1 0 0 0 TBD15 WLAN-AKM-Suite 1038 0-1 0 0 0 TBD16 WLAN-Group-Mgmt-Cipher 1039 0-1 0 0 0 TBD17 WLAN-RF-Band 1041 CoA- Dis- Acct- 1042 Req Req Req # Attribute 1043 0+ 0 0 TBD1 Allowed-Called-Station-Id 1044 0-1 0 0 102 EAP-Key-Name 1045 0 0 0+ TBD2 EAP-Peer-Id 1046 0 0 0+ TBD3 EAP-Server-Id 1047 0 0 0-1 TBD4 Mobility-Domain-Id 1048 0-1 0 0 TBD5 Preauth-Timeout 1049 0 0 0-1 TBD6 Network-Id-Name 1050 0-1 0-1 0-1 TBD7 Access-Info 1051 0 0 0-1 TBD8 WLAN-HESSID 1052 0 0 0-1 TBD9 WLAN-Venue-Info 1053 0 0 0+ TBD10 WLAN-Venue-Language 1054 0 0 0+ TBD11 WLAN-Venue-Name 1055 0 0-1 0-1 TBD12 WLAN-Reason-Code 1056 0 0 0-1 TBD13 WLAN-Pairwise-Cipher 1057 0 0 0-1 TBD14 WLAN-Group-Cipher 1058 0 0 0-1 TBD15 WLAN-AKM-Suite 1059 0 0 0-1 TBD16 WLAN-Group-Mgmt-Cipher 1060 0 0 0-1 TBD17 WLAN-RF-Band 1062 The following table defines the meaning of the above table entries. 1064 0 This Attribute MUST NOT be present in packet. 1065 0+ Zero or more instances of this Attribute MAY be 1066 present in the packet. 1067 0-1 Zero or one instance of this Attribute MAY be 1068 present in the packet. 1070 4. Diameter Considerations 1072 The EAP-Key-Name Attribute is already defined as a RADIUS Attribute 1073 within Diameter EAP [RFC4072]. When used in Diameter, the other 1074 attributes defined in this specification can be used as Diameter AVPs 1075 from the Code space 1-255 (RADIUS Attribute compatibility space). No 1076 additional Diameter Code values are therefore allocated. The data 1077 types and flag rules for the attributes are as follows: 1079 +---------------------+ 1080 | AVP Flag rules | 1081 |----+-----+----+-----|----+ 1082 | | |SHLD| MUST| | 1083 Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr| 1084 -----------------------------------------|----+-----+----+-----|----| 1085 Allowed-Called-Station-Id UTF8String | M | P | | V | Y | 1086 EAP-Peer-Id UTF8String | M | P | | V | Y | 1087 EAP-Server-Id UTF8String | M | P | | V | Y | 1088 Mobility-Domain-Id Unsigned32 | M | P | | V | Y | 1089 Preauth-Timeout Unsigned32 | M | P | | V | Y | 1090 Network-Id-Name UTF8String | M | P | | V | Y | 1091 Access-Info Unsigned32 | M | P | | V | Y | 1092 WLAN-HESSID UTF8String | M | P | | V | Y | 1093 WLAN-Venue-Info Unsigned32 | M | P | | V | Y | 1094 WLAN-Venue-Language UTF8String | M | P | | V | Y | 1095 WLAN-Venue-Name UTF8String | M | P | | V | Y | 1096 WLAN-Reason-Code Unsigned32 | M | P | | V | Y | 1097 WLAN-Pairwise-Cipher Unsigned32 | M | P | | V | Y | 1098 WLAN-Group-Cipher Unsigned32 | M | P | | V | Y | 1099 WLAN-AKM-Suite Unsigned32 | M | P | | V | Y | 1100 WLAN-Group-Mgmt-Cipher Unsigned32 | M | P | | V | Y | 1101 WLAN-RF-Band Unsigned32 | M | P | | V | Y | 1102 -----------------------------------------|----+-----+----+-----|----| 1104 The attributes in this specification have no special translation 1105 requirements for Diameter to RADIUS or RADIUS to Diameter gateways; 1106 they are copied as is, except for changes relating to headers, 1107 alignment, and padding. 1109 What this specification says about the applicability of the 1110 attributes for RADIUS Access-Request packets applies in Diameter to 1111 AA-Request [RFC4005] or Diameter-EAP-Request [RFC4072]. What is said 1112 about Access-Challenge applies in Diameter to AA-Answer [RFC4005] or 1113 Diameter-EAP-Answer [RFC4072] with Result-Code AVP set to 1114 DIAMETER_MULTI_ROUND_AUTH. 1116 What is said about Access-Accept applies in Diameter to AA-Answer or 1117 Diameter-EAP-Answer messages that indicate success. Similarly, what 1118 is said about RADIUS Access-Reject packets applies in Diameter to AA- 1119 Answer or Diameter-EAP-Answer messages that indicate failure. 1121 What is said about COA-Request applies in Diameter to Re-Auth-Request 1122 [RFC4005]. What is said about Accounting-Request applies to Diameter 1123 Accounting- Request [RFC4005] as well. 1125 5. IANA Considerations 1127 This document uses the RADIUS [RFC2865] namespace, see 1128 . This specification 1129 requires assignment of a RADIUS attribute types for the following 1130 attributes: 1132 Attribute Type 1133 ========= ==== 1134 Allowed-Called-Station-Id TBD1 1135 EAP-Peer-Id TBD2 1136 EAP-Server-Id TBD3 1137 Mobility-Domain-Id TBD4 1138 Preauth-Timeout TBD5 1139 Network-Id-Name TBD6 1140 Access-Info TBD7 1141 WLAN-HESSID TBD8 1142 WLAN-Venue-Info TBD9 1143 WLAN-Venue-Language TBD10 1144 WLAN-Venue-Name TBD11 1145 WLAN-Reason-Code TBD12 1146 WLAN-Pairwise-Cipher TBD13 1147 WLAN-Group-Cipher TBD14 1148 WLAN-AKM-Suite TBD15 1149 WLAN-Group-Mgmt-Cipher TBD16 1150 WLAN-RF-Band TBD17 1152 Since this specification relies on values assigned by IEEE 802, no 1153 registries are established for maintenance by the IANA. 1155 6. Security Considerations 1157 Since this document describes the use of RADIUS for purposes of 1158 authentication, authorization, and accounting in IEEE 802 networks, 1159 it is vulnerable to all of the threats that are present in other 1160 RADIUS applications. For a discussion of these threats, see 1161 [RFC2607], [RFC2865], [RFC3162], [RFC3579], [RFC3580] and [RFC5176]. 1163 While it is possible for a RADIUS server to make decisions on whether 1164 to Accept or Reject an Access-Request based on the values of the 1165 WLAN-Pairwise-Cipher, WLAN-Group-Cipher, WLAN-AKM-Suite, WLAN-Group- 1166 Mgmt-Cipher and WLAN-RF-Band Attributes the value of doing this is 1167 limited. In general, an Access-Reject should not be necessary, 1168 except where Access Points and Stations are misconfigured so as to 1169 enable connections to be made with unacceptable values. Rather than 1170 rejecting access on an ongoing basis, users would be better served by 1171 fixing the misconfiguration. 1173 Where access does need to be rejected, the user should be provided 1174 with an indication of why the problem has occurred, or else they are 1175 likely to become frustrated. For example, if the values of the WLAN- 1176 Pairwise-Cipher, WLAN-Group-Cipher, WLAN-AKM-Suite or WLAN-Group- 1177 Mgmt-Cipher Attributes included in the Access-Request are not 1178 acceptable to the RADIUS server, then a WLAN-Reason-Code Attribute 1179 with a value of 29 (Requested service rejected because of service 1180 provider cipher suite or AKM requirement) SHOULD be returned in the 1181 Access-Reject. Similarly, if the value of the WLAN-RF-Band Attribute 1182 included in the Access-Request is not acceptable to the RADIUS 1183 server, then a WLAN-Reason-Code Attribute with a value of 11 1184 (Disassociated because the information in the Supported Channels 1185 element is unacceptable) SHOULD be returned in the Access-Reject. 1187 7. References 1189 7.1. Normative references 1191 [IEEE-802] IEEE Standards for Local and Metropolitan Area Networks: 1192 Overview and Architecture, ANSI/IEEE Std 802, 1990. 1194 [IEEE-802.11] 1195 Information technology - Telecommunications and Information 1196 Exchange Between Systems - Local and Metropolitan Area 1197 Networks - Specific Requirements Part 11: Wireless LAN 1198 Medium Access Control (MAC) and Physical Layer (PHY) 1199 Specifications, IEEE Std. 802.11-2012, 2012. 1201 [IEEE-802.11ad] 1202 Information technology - Telecommunications and Information 1203 Exchange Between Systems - Local and Metropolitan Area 1204 Networks - Specific Requirements Part 11: Wireless LAN 1205 Medium Access Control (MAC) and Physical Layer (PHY) 1206 Specifications, Amendment 3: Enhancements for Very High 1207 Throughput in the 60 GHz Band, IEEE Std. 802.11ad-2012, 2012. 1209 [IEEE-802.1X] 1210 IEEE Standard for Local and Metropolitan Area Networks - 1211 Port-Based Network Access Control, IEEE 802.1X-2010, February 1212 2010. 1214 [ISO-639] ISO, "Codes for the Representation of Names of Languages". 1216 [ISO-14962-1997] 1217 ISO, "Space data and information transfer systems - ASCII 1218 encoded English", 1997. 1220 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1221 Requirement Levels", RFC 2119, March, 1997. 1223 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 1224 Authentication Dial In User Service (RADIUS)", RFC 2865, June 1225 2000. 1227 [RFC4072] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 1228 Authentication Protocol (EAP) Application", RFC 4072, August 1229 2005. 1231 [RFC5247] Aboba, B., Simon, D. and P. Eronen, "EAP Key Management 1232 Framework", RFC 5247, August 2008. 1234 7.2. Informative references 1236 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 1237 Implementation in Roaming", RFC 2607, June 1999. 1239 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 1240 3162, August 2001. 1242 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 1243 Authentication Protocol (EAP)", RFC 3579, September 2003. 1245 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 1246 "IEEE 802.1X Remote Authentication Dial In User Service 1247 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 1249 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 1250 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 1251 3748, June 2004. 1253 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter 1254 Network Access Server Application", RFC 4005, August 2005. 1256 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, 1257 "Dynamic Authorization Extensions to Remote Authentication 1258 Dial In User Service (RADIUS)", RFC 5176, January 2008. 1260 Acknowledgments 1262 The authors would like to acknowledge Maximilian Riegel, Dorothy 1263 Stanley, Yoshihiro Ohba, and the contributors to the IEEE 802.1 and 1264 IEEE 802.11 reviews of this document, for useful discussions. 1266 Authors' Addresses 1268 Bernard Aboba 1269 Skype 1270 EMail: bernard_aboba@hotmail.com 1272 Jouni Malinen 1273 EMail: j@w1.fi 1275 Paul Congdon 1276 Hewlett Packard Company 1277 HP ProCurve Networking 1278 8000 Foothills Blvd, M/S 5662 1279 Roseville, CA 95747 1281 Phone: +1 916 785 5753 1282 Fax: +1 916 785 8478 1283 EMail: paul_congdon@hp.com 1285 Joseph Salowey 1286 Cisco Systems 1287 EMail: jsalowey@cisco.com 1289 Mark Jones 1290 Azuca Systems 1291 EMail: mark@azu.ca