idnits 2.17.1 draft-ietf-radext-ieee802ext-10.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 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 (21 January 2014) is 3741 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 (~~), 1 warning (==), 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 4 Category: Proposed Standard Jouni Malinen 5 Expires: July 20, 2014 Devicescape Software 6 Updates: 3580, 4072 Paul Congdon 7 Hewlett Packard Company 8 Joseph Salowey 9 Cisco Systems 10 Mark Jones 11 Azuca Systems 12 21 January 2014 14 RADIUS Attributes for IEEE 802 Networks 15 draft-ietf-radext-ieee802ext-10.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 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 July 20, 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 ..................................... 13 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 .......................... 20 99 2.18 WLAN-RF-Band .................................... 21 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], the Network-Id Name (NID- 221 Name) constitutes the network name. Since a NID-Name can be up to 222 253 octets in length, when used with [IEEE-802.1X], there may not 223 be sufficient room within the Allowed-Called-Station-Id Attribute 224 to include both a MAC address and a Network Name. However, since 225 the Allowed-Called-Station-Id Attribute is expected to be used 226 largely in wireless access scenarios, this restriction is not 227 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. 282 2.3. EAP-Peer-Id 284 Description 286 The EAP-Peer-Id Attribute contains a Peer-Id generated by the EAP 287 method. Exactly how this name is used depends on the link layer 288 in question. See [RFC5247] for more discussion. The EAP-Peer-Id 289 Attribute MAY be included in Access-Request, Access-Accept and 290 Accounting-Request packets. More than one EAP-Peer-Id Attribute 291 MUST NOT be included in an Access-Request; one or more EAP-Peer-Id 292 attributes MAY be included in an Access-Accept. 294 It should be noted that not all link layers use this name, and 295 existing EAP method implementations do not generate it. Since the 296 NAS operates as a pass-through in EAP [RFC3748], it cannot know 297 the EAP-Peer-Id before receiving it from the RADIUS server. As a 298 result, an EAP-Peer-Id Attribute sent in an Access-Request MUST 299 only contain a single NUL character. A home RADIUS server 300 receiving an Access-Request an EAP-Peer-Id Attribute containing 301 anything other than a single NUL character MUST silently discard 302 the Attribute. In addition, the home RADIUS server SHOULD include 303 one or more EAP-Peer-Id attributes in an Access-Accept only if an 304 EAP-Peer-Id Attribute was present in the Access-Request. If a NAS 305 receives EAP-Peer-Id Attribute(s) in an Access-Accept without 306 having included one in an Access-Request, the NAS SHOULD silently 307 discard the Attribute(s). A summary of the EAP-Peer-Id Attribute 308 format is shown below. The fields are transmitted from left to 309 right. 311 0 1 2 3 312 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 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Type | Length | String... 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 Code 319 TBD2 321 Length 323 >=3 325 String 327 The String field is one or more octets containing a EAP Peer-Id 328 exported by the EAP method. For details, see [RFC5247] Appendix 329 A. A robust implementation SHOULD support the field as 330 undistinguished octets. Only a single EAP Peer-Id may be included 331 per Attribute. 333 2.4. EAP-Server-Id 335 Description 337 The EAP-Server-Id Attribute contains a Server-Id generated by the 338 EAP method. Exactly how this name is used depends on the link 339 layer in question. See [RFC5247] for more discussion. The EAP- 340 Server-Id Attribute is only allowed in Access-Request, Access- 341 Accept, and Accounting-Request packets. More than one EAP-Server- 342 Id Attribute MUST NOT be included in an Access-Request; one or 343 more EAP-Server-Id attributes MAY be included in an Access-Accept. 345 It should be noted that not all link layers use this name, and 346 existing EAP method implementations do not generate it. Since the 347 NAS operates as a pass-through in EAP [RFC3748], it cannot know 348 the EAP-Server-Id before receiving it from the RADIUS server. As 349 a result, an EAP-Server-Id Attribute sent in an Access-Request 350 MUST contain only a single NUL character. A home RADIUS server 351 receiving in an Access-Request an EAP-Server-Id Attribute 352 containing anything other than a single NUL character MUST 353 silently discard the Attribute. In addition, the home RADIUS 354 server SHOULD include this Attribute an Access-Accept only if an 355 EAP-Server-Id Attribute was present in the Access-Request. A 356 summary of the EAP-Server-Id Attribute format is shown below. The 357 fields are transmitted from left to right. 359 0 1 2 3 360 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 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Type | Length | String... 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 Code 367 TBD3 369 Length 371 >=3 373 String 375 The String field is one or more octets, containing a EAP Server-Id 376 exported by the EAP method. For details, see [RFC5247] Appendix 377 A. A robust implementation SHOULD support the field as 378 undistinguished octets. 380 2.5. Mobility-Domain-Id 382 Description 384 A single Mobility-Domain-Id Attribute MAY be included in an 385 Access-Request or Accounting-Request, in order to enable the NAS 386 to provide the RADIUS server with the Mobility Domain Identifier 387 (MDID), defined in Section 8.4.2.49 of [IEEE-802.11]. A summary 388 of the Mobility-Domain-Id Attribute format is shown below. The 389 fields are transmitted from left to right. 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Type | Length | Value 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 Value | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 Code 401 TBD4 403 Length 405 6 407 Value 409 The Value field is four octets, containing a 32-bit unsigned 410 integer. The two most significant octets MUST be set to zero by 411 the sender, and are ignored by the receiver; the two least 412 significant octets contain the Mobility Domain Identifier (MDID) 413 defined in Section 8.4.2.49 of [IEEE-802.11]. 415 0 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Reserved | Mobility Domain Identifier | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 2.6. Preauth-Timeout 423 Description 425 This Attribute sets the maximum number of seconds which pre- 426 authentication state is required to be kept by the NAS, without 427 being utilized within a user session. For example, when 428 [IEEE-802.11] pre-authentication is used, if a user has not 429 attempted to utilize the Pairwise Master Key (PMK) derived as a 430 result of pre-authentication within the time specified by the 431 Preauth-Timeout Attribute, the PMK MAY be discarded by the Access 432 Point. However, once the session is underway, the Preauth-Timeout 433 Attribute has no bearing on the maximum session time for the user, 434 or the maximum time during which key state may be kept prior to 435 re-authentication. This is determined by the Session-Timeout 436 Attribute, if present. 438 A single Preauth-Timeout Attribute MAY be included within an 439 Access-Accept or CoA-Request packet. A summary of the Preauth- 440 Timeout Attribute format is shown below. The fields are 441 transmitted from left to right. 443 0 1 2 3 444 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 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Type | Length | Value 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 Value (cont) | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 Code 453 TBD5 455 Length 457 6 459 Value 461 The field is 4 octets, containing a 32-bit unsigned integer 462 encoding the maximum time in seconds that pre-authentication state 463 should be retained by the NAS. 465 2.7. Network-Id-Name 467 Description 469 The Network-Id-Name Attribute is utilized by implementations of 470 IEEE-802.1X [IEEE-802.1X] to specify the name of a Network-Id 471 (NID-Name). 473 Unlike the IEEE 802.11 SSID (which is a maximum of 32 octets in 474 length), the NID-Name may be up to 253 octets in length. 475 Consequently, if the MAC address is included within the Called- 476 Station-Id Attribute, it is possible that there will not be enough 477 remaining space to encode the NID-Name as well. Therefore when 478 used with IEEE 802.1X [IEEE-802.1X], the Called-Station-Id 479 Attribute SHOULD contain only the MAC address, with the Network- 480 Id-Name Attribute used to transmit the NID-Name. The Network-Id- 481 Name Attribute MUST NOT be used to encode the IEEE 802.11 SSID; as 482 noted in [RFC3580], the Called-Station-Id Attribute is used for 483 this purpose. 485 Zero or one Network-Id-Name Attribute is permitted within an 486 Access-Request, Access-Challenge, Access-Accept or Accounting- 487 Request packet. When included within an Access-Request packet, 488 the Network-Id-Name Attribute represents a hint of the NID-Name to 489 which the Supplicant should be granted access. When included 490 within an Access-Accept packet, the Network-Id-Name Attribute 491 represents the NID-Name to which the Supplicant is to be granted 492 access. When included within an Accounting-Request packet, the 493 Network-Id-Name Attribute represents the NID-Name to which the 494 Supplicant has been granted access. 496 A summary of the Network-Id-Name Attribute format is shown below. 497 The fields are transmitted from left to right. 499 0 1 2 3 500 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 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Type | Length | String... 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 Code 507 TBD6 509 Length 511 >=3 513 String 515 The String field is one or more octets, containing a NID-Name. 516 For details, see [IEEE-802.1X]. A robust implementation SHOULD 517 support the field as undistinguished octets. 519 2.8. EAPoL-Announcement 521 Description 523 The EAPoL-Announcement Attribute contains EAPoL-Announcement Type 524 Length Value Tuples (TLVs) defined within Table 11-8 of 525 IEEE-802.1X [IEEE-802.1X]. 527 Zero or more EAPoL-Announcement attributes are permitted within an 528 Access-Request, Access-Accept, Access-Challenge, Access-Reject, 529 Accounting-Request, CoA-Request or Disconnect-Request packet. 531 When included within an Access-Request packet, EAPoL-Announcement 532 attributes contain EAPoL-Announcement TLVs that the user sent in 533 an EAPoL-Announcement. When included within an Access-Accept, 534 Access-Challenge, Access-Reject, CoA-Request or Disconnect-Request 535 packet, EAPoL-Announcement attributes contain EAPoL-Announcement 536 TLVs that the NAS is to send to the user in a unicast EAPoL- 537 Announcement. When sent within an Accounting-Request packet, 538 EAPoL-Announcment attributes contain EAPoL-Announcement TLVs that 539 the NAS has most recently sent to the user in a unicast EAPoL- 540 Announcement. 542 A summary of the EAPoL-Announcement Attribute format is shown 543 below. The fields are transmitted from left to right. 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Type | Length | String... 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 Code 553 TBD7 555 Length 557 >=3 559 String 561 The String field is one or more octets, containing EAPoL- 562 Announcement TLVs in the format defined in Figure 11-8 of Section 563 11.12 of [IEEE-802.1X]. Any EAPoL-Announcement TLV Type MAY be 564 included within an EAPoL-Announcement Attribute, including 565 Organizationally Specific TLVs. If multiple EAPoL-Announcement 566 attributes are present in a packet, their String fields MUST be 567 concatenated before being parsed for EAPoL-Announcement TLVs; this 568 allows EAPoL-Announcement TLVs longer than 253 octets to be 569 transported by RADIUS. Similarly, EAPoL-Announcement TLVs larger 570 than 253 octets MUST be fragmented between multiple EAPoL- 571 Announcement attributes. 573 2.9. WLAN-HESSID 575 Description 577 The WLAN-HESSID attribute contains a MAC address that identifies 578 the Homogenous Extended Service Set. The HESSID is a globally 579 unique identifier that in conjunction with the SSID, encoded 580 within the Called-Station-Id Attribute as described in [RFC3580], 581 may be used to provide network identification for a subscription 582 service provider network (SSPN), as described in Section 8.4.2.94 583 of [IEEE-802.11]. Zero or one WLAN-HESSID Attribute is permitted 584 within an Access-Request or Accounting-Request packet. 586 A summary of the WLAN-HESSID Attribute format is shown below. The 587 fields are transmitted from left to right. 589 0 1 2 3 590 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 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Type | Length | String... 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 Code 597 TBD8 599 Length 601 19 603 String 605 The String field is encoded in upper-case ASCII characters with 606 the octet values separated by dash characters, as described in RFC 607 3580 [RFC3580]. Example: "00-10-A4-23-19-C0". 609 2.10. WLAN-Venue-Info 611 Description 613 The WLAN-Venue-Info attribute identifies the category of venue 614 hosting the WLAN, as defined in Section 8.4.1.34 of [IEEE-802.11]. 615 Zero or more WLAN-Venue-Info attributes may be included in an 616 Access-Request or Accounting-Request. 618 A summary of the WLAN-Venue-Info Attribute format is shown below. 619 The fields are transmitted from left to right. 621 0 1 2 3 622 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 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Type | Length | Value 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 Value | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 Code 630 TBD9 632 Length 634 6 636 Value 638 The Value field is four octets, containing a 32-bit unsigned 639 integer. The two most significant octets MUST be set to zero by 640 the sender, and are ignored by the receiver; the two least 641 significant octets contain the Venue Group and Venue Type fields. 643 0 1 2 3 644 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 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | Reserved | Venue Group | Venue Type | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 Venue Group 651 The Venue Group field is a single octet and describes the broad 652 category of the venue, e.g. "Assembly". See Section 8.4.1.34 653 [IEEE-802.11] for Venue Group codes and descriptions. 655 Venue Type 657 The Venue Type field is a single octet and describes the venue in 658 a finer granularity within the Venue Group, e.g. "Library". See 659 Section 8.4.1.34 of [IEEE-802.11] for Venue Type codes and 660 descriptions. 662 2.11. WLAN-Venue-Language 664 Description 666 The WLAN-Venue-Language attribute is an ISO-14962-1997 667 [ISO-14962-1997] encoded string that defines the language used in 668 the WLAN-Venue-Name attribute. Zero or more WLAN-Venue-Language 669 attributes may be included in an Access-Request or Accounting- 670 Request and each one indicates the language of the WLAN-Venue-Name 671 attribute that follows it. 673 A summary of the WLAN-Venue-Language Attribute format is shown 674 below. The fields are transmitted from left to right. 676 0 1 2 3 677 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 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Type | Length | String... 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 String (cont) | 682 +-+-+-+-+-+-+-+-+ 684 Code 686 TBD10 688 Length 690 4-5 692 String 694 The String field is a two or three character language code 695 selected from ISO-639 [ISO-639]. A two character language code 696 has a zero ("null" in ISO-14962-1997) appended to make it 3 octets 697 in length. 699 2.12. WLAN-Venue-Name 701 Description 703 The WLAN-Venue-Name attribute provides additional metadata on the 704 BSS. For example, this information may be used to assist a user 705 in selecting the appropriate BSS with which to associate. Zero or 706 more WLAN-Venue-Name attributes may be included in an Access- 707 Request or Accounting-Request in the same or different languages. 709 A summary of the WLAN-Venue-Name Attribute format is shown below. 710 The fields are transmitted from left to right. 712 0 1 2 3 713 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 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | Type | Length | String... 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 Code 720 TBD11 722 Length 723 >=3 725 String 727 The String field is a UTF-8 formatted field containing the venue's 728 name. The maximum length of this field is 252 octets. 730 2.13. WLAN-Reason-Code 732 Description 734 The WLAN-Reason-Code Attribute contains information on the reason 735 why a station has been refused network access and has been 736 disassociated or de-authenticated. This can occur due to policy 737 or for reasons related to the user's subscription. 739 A WLAN-Reason-Code Attribute MAY be included within an Access- 740 Reject or Disconnect-Request packet, as well as within an 741 Accounting-Request packet. Upon receipt of an Access-Reject or 742 Disconnect-Request packet containing a WLAN-Reason-Code Attribute, 743 the WLAN-Reason-Code value is copied by the Access Point into the 744 Reason Code field of a Disassociation or Deauthentication frame 745 (see clause 8.3.3.4 and 8.3.3.12 respectively in [IEEE- 802.11]), 746 which is subsequently transmitted to the station. 748 A summary of the WLAN-Reason-Code Attribute format is shown below. 749 The fields are transmitted from left to right. 751 0 1 2 3 752 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 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | Type | Length | Value 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 Value | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 Code 761 TBD12 763 Length 765 6 767 Value 769 The Value field is four octets, containing a 32-bit unsigned 770 integer. The two most significant octets MUST be set to zero by 771 the sender, and are ignored by the receiver; the two least 772 significant octets contain the Reason Code values defined in Table 773 8-36 of Section 8.4.1.7 of [IEEE-802.11]. 775 0 1 2 3 776 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 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | Reserved | Reason Code | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 2.14. WLAN-Pairwise-Cipher 783 Description 785 The WLAN-Pairwise-Cipher Attribute contains information on the 786 pairwise cipher suite used to establish the robust security 787 network association (RSNA) between the AP and mobile device. A 788 WLAN-Pairwise-Cipher Attribute MAY be included within Access- 789 Request and Accounting-Request packets. 791 A summary of the WLAN-Pairwise-Cipher Attribute format is shown 792 below. The fields are transmitted from left to right. 794 0 1 2 3 795 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 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Type | Length | Value 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 Value | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 Code 804 TBD13 806 Length 808 6 810 Value 812 The Value field is four octets, containing a 32-bit unsigned 813 integer, in Suite selector format as specified in Figure 8-187 814 within Section 8.4.2.27.2 of [IEEE-802.11], with values of OUI and 815 Suite type drawn from Table 8-99. 817 0 1 2 3 818 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 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | OUI | Suite Type | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 2.15. WLAN-Group-Cipher 825 Description 827 The WLAN-Group-Cipher Attribute contains information on the group 828 cipher suite used to establish the robust security network 829 association (RSNA) between the AP and mobile device. A WLAN- 830 Group-Cipher Attribute MAY be included within Access-Request and 831 Accounting-Request packets. 833 A summary of the WLAN-Group-Cipher Attribute format is shown 834 below. The fields are transmitted from left to right. 836 0 1 2 3 837 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 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Type | Length | Value 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 Value | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 Code 846 TBD14 848 Length 850 6 852 Value 854 The Value field is four octets, containing a 32-bit unsigned 855 integer, in Suite selector format as specified in Figure 8-187 856 within Section 8.4.2.27.2 of [IEEE-802.11], with values of OUI and 857 Suite type drawn from Table 8-99. 859 0 1 2 3 860 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 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | OUI | Suite Type | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 2.16. WLAN-AKM-Suite 867 Description 869 The WLAN-AKM-Suite Attribute contains information on the 870 authentication and key management suite used to establish the 871 robust security network association (RSNA) between the AP and 872 mobile device. A WLAN-AKM-Suite Attribute MAY be included within 873 Access-Request and Accounting-Request packets. 875 A summary of the WLAN-AKM-Suite Attribute format is shown below. 876 The fields are transmitted from left to right. 878 0 1 2 3 879 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 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | Type | Length | Value 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 Value | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 Code 888 TBD15 890 Length 892 6 894 Value 896 The Value field is four octets, containing a 32-bit unsigned 897 integer, in Suite selector format as specified in Figure 8-187 898 within Section 8.4.2.27.2 of [IEEE-802.11], with values of OUI and 899 Suite type drawn from Table 8-101: 901 0 1 2 3 902 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 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | OUI | Suite Type | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 2.17. WLAN-Group-Mgmt-Cipher 909 Description 911 The WLAN-Group-Mgmt-Cipher Attribute contains information on group 912 management cipher used to establish the robust security network 913 association (RSNA) between the AP and mobile device. 915 Zero or one WLAN-Group-Mgmt-Cipher Attribute MAY be included 916 within Access-Request and Accounting-Request packets. Presence of 917 the attribute indicates that the station negotiated to use 918 management frame protection during association. 920 A summary of the WLAN-Group-Mgmt-Cipher Attribute format is shown 921 below. The fields are transmitted from left to right. 923 0 1 2 3 924 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 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | Type | Length | Value 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 Value | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 Code 933 TBD16 935 Length 937 6 939 Value 941 The Value field is four octets, containing a 32-bit unsigned 942 integer, in Suite selector format as specified in Figure 8-187 943 within Section 8.4.2.27.2 of [IEEE-802.11], with values of OUI and 944 Suite type drawn from Table 8-99: 946 0 1 2 3 947 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 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | OUI | Suite Type | 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 2.18. WLAN-RF-Band 954 Description 956 The WLAN-RF-Band Attribute contains information on the RF band 957 used by the Access Point for transmission and reception of 958 information to and from the mobile device. Zero or one WLAN-RF- 959 Band Attribute MAY be included within an Access-Request or 960 Accounting-Request packet. 962 A summary of the WLAN-RF-Band Attribute format is shown below. 963 The fields are transmitted from left to right. 965 0 1 2 3 966 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 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 | Type | Length | Value 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 Value | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 Code 975 TBD17 977 Length 979 6 981 Value 983 The Value field is four octets, containing a 32-bit unsigned 984 integer. The three most significant octets MUST be set to zero by 985 the sender, and are ignored by the receiver; the least significant 986 octet contains the RF Band field, whose values are defined in 987 Table 8-53a of [IEEE-802.11ad]. 989 0 1 2 3 990 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 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | Reserved | RF Band | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 3. Table of attributes 997 The following table provides a guide to which attributes may be found 998 in which kinds of packets, and in what quantity. 1000 Access- Access- Access- Access- 1001 Request Accept Reject Challenge # Attribute 1002 0 0+ 0 0 TBD1 Allowed-Called-Station-Id 1003 0-1 0-1 0 0 102 EAP-Key-Name 1004 0-1 0+ 0 0 TBD2 EAP-Peer-Id 1005 0-1 0+ 0 0 TBD3 EAP-Server-Id 1006 0-1 0 0 0 TBD4 Mobility-Domain-Id 1007 0-1 0-1 0 0 TBD5 Preauth-Timeout 1008 0-1 0 0 0 TBD6 Network-Id-Name 1009 0+ 0+ 0+ 0+ TBD7 EAPoL-Announcement 1010 0-1 0 0 0 TBD8 WLAN-HESSID 1011 0-1 0 0 0 TBD9 WLAN-Venue-Info 1012 0+ 0 0 0 TBD10 WLAN-Venue-Language 1013 0+ 0 0 0 TBD11 WLAN-Venue-Name 1014 0 0 0-1 0 TBD12 WLAN-Reason-Code 1015 0-1 0 0 0 TBD13 WLAN-Pairwise-Cipher 1016 0-1 0 0 0 TBD14 WLAN-Group-Cipher 1017 0-1 0 0 0 TBD15 WLAN-AKM-Suite 1018 0-1 0 0 0 TBD16 WLAN-Group-Mgmt-Cipher 1019 0-1 0 0 0 TBD17 WLAN-RF-Band 1021 CoA- Dis- Acct- 1022 Req Req Req # Attribute 1023 0+ 0 0+ TBD1 Allowed-Called-Station-Id 1024 0-1 0 0 102 EAP-Key-Name 1025 0 0 0+ TBD2 EAP-Peer-Id 1026 0 0 0+ TBD3 EAP-Server-Id 1027 0 0 0-1 TBD4 Mobility-Domain-Id 1028 0-1 0 0 TBD5 Preauth-Timeout 1029 0 0 0-1 TBD6 Network-Id-Name 1030 0+ 0+ 0+ TBD7 EAPoL-Announcement 1031 0 0 0-1 TBD8 WLAN-HESSID 1032 0 0 0-1 TBD9 WLAN-Venue-Info 1033 0 0 0+ TBD10 WLAN-Venue-Language 1034 0 0 0+ TBD11 WLAN-Venue-Name 1035 0 0-1 0-1 TBD12 WLAN-Reason-Code 1036 0 0 0-1 TBD13 WLAN-Pairwise-Cipher 1037 0 0 0-1 TBD14 WLAN-Group-Cipher 1038 0 0 0-1 TBD15 WLAN-AKM-Suite 1039 0 0 0-1 TBD16 WLAN-Group-Mgmt-Cipher 1040 0 0 0-1 TBD17 WLAN-RF-Band 1042 The following table defines the meaning of the above table entries. 1044 0 This Attribute MUST NOT be present in packet. 1045 0+ Zero or more instances of this Attribute MAY be 1046 present in the packet. 1047 0-1 Zero or one instance of this Attribute MAY be 1048 present in the packet. 1050 4. IANA Considerations 1052 This document uses the RADIUS [RFC2865] namespace, see 1053 . This specification 1054 requires assignment of a RADIUS attribute types for the following 1055 attributes: 1057 Attribute Type 1058 ========= ==== 1059 Allowed-Called-Station-Id TBD1 1060 EAP-Peer-Id TBD2 1061 EAP-Server-Id TBD3 1062 Mobility-Domain-Id TBD4 1063 Preauth-Timeout TBD5 1064 Network-Id-Name TBD6 1065 EAPoL-Announcement TBD7 1066 WLAN-HESSID TBD8 1067 WLAN-Venue-Info TBD9 1068 WLAN-Venue-Language TBD10 1069 WLAN-Venue-Name TBD11 1070 WLAN-Reason-Code TBD12 1071 WLAN-Pairwise-Cipher TBD13 1072 WLAN-Group-Cipher TBD14 1073 WLAN-AKM-Suite TBD15 1074 WLAN-Group-Mgmt-Cipher TBD16 1075 WLAN-RF-Band TBD17 1077 Since this specification relies entirely on values assigned by IEEE 1078 802, no registries are established for maintenance by the IANA. 1080 5. Security Considerations 1082 Since this document describes the use of RADIUS for purposes of 1083 authentication, authorization, and accounting in IEEE 802 networks, 1084 it is vulnerable to all of the threats that are present in other 1085 RADIUS applications. For a discussion of these threats, see 1086 [RFC2607], [RFC2865], [RFC3162], [RFC3579], [RFC3580] and [RFC5176]. 1088 While it is possible for a RADIUS server to make decisions on whether 1089 to Accept or Reject an Access-Request based on the values of the 1090 WLAN-Pairwise-Cipher, WLAN-Group-Cipher, WLAN-AKM-Suite, WLAN-Group- 1091 Mgmt-Cipher and WLAN-RF-Band Attributes the value of doing this is 1092 limited. In general, an Access-Reject should not be necessary, 1093 except where Access Points and Stations are misconfigured so as to 1094 enable connections to be made with unacceptable values. Rather than 1095 rejecting access on an ongoing basis, users would be better served by 1096 fixing the misconfiguration. 1098 Where access does need to be rejected, the user should be provided 1099 with an indication of why the problem has occurred, or else they are 1100 likely to become frustrated. For example, if the values of the WLAN- 1101 Pairwise-Cipher, WLAN-Group-Cipher, WLAN-AKM-Suite or WLAN-Group- 1102 Mgmt-Cipher Attributes included in the Access-Request are not 1103 acceptable to the RADIUS server, then a WLAN-Reason-Code Attribute 1104 with a value of 29 (Requested service rejected because of service 1105 provider cipher suite or AKM requirement) SHOULD be returned in the 1106 Access-Reject. Similarly, if the value of the WLAN-RF-Band Attribute 1107 included in the Access-Request is not acceptable to the RADIUS 1108 server, then a WLAN-Reason-Code Attribute with a value of 11 1109 (Disassociated because the information in the Supported Channels 1110 element is unacceptable) SHOULD be returned in the Access-Reject. 1112 6. References 1114 6.1. Normative references 1116 [IEEE-802] IEEE Standards for Local and Metropolitan Area Networks: 1117 Overview and Architecture, ANSI/IEEE Std 802, 1990. 1119 [IEEE-802.11] 1120 Information technology - Telecommunications and Information 1121 Exchange Between Systems - Local and Metropolitan Area 1122 Networks - Specific Requirements Part 11: Wireless LAN 1123 Medium Access Control (MAC) and Physical Layer (PHY) 1124 Specifications, IEEE Std. 802.11-2012, 2012. 1126 [IEEE-802.11ad] 1127 Information technology - Telecommunications and Information 1128 Exchange Between Systems - Local and Metropolitan Area 1129 Networks - Specific Requirements Part 11: Wireless LAN 1130 Medium Access Control (MAC) and Physical Layer (PHY) 1131 Specifications, Amendment 3: Enhancements for Very High 1132 Throughput in the 60 GHz Band, IEEE Std. 802.11ad-2012, 2012. 1134 [IEEE-802.1X] 1135 IEEE Standard for Local and Metropolitan Area Networks - 1136 Port-Based Network Access Control, IEEE 802.1X-2010, February 1137 2010. 1139 [ISO-639] ISO, "Codes for the Representation of Names of Languages". 1141 [ISO-14962-1997] 1142 ISO, "Space data and information transfer systems - ASCII 1143 encoded English", 1997. 1145 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1146 Requirement Levels", RFC 2119, March, 1997. 1148 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 1149 Authentication Dial In User Service (RADIUS)", RFC 2865, June 1150 2000. 1152 [RFC4072] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 1153 Authentication Protocol (EAP) Application", RFC 4072, August 1154 2005. 1156 [RFC5247] Aboba, B., Simon, D. and P. Eronen, "EAP Key Management 1157 Framework", RFC 5247, August 2008. 1159 6.2. Informative references 1161 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 1162 Implementation in Roaming", RFC 2607, June 1999. 1164 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 1165 3162, August 2001. 1167 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 1168 Authentication Protocol (EAP)", RFC 3579, September 2003. 1170 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 1171 "IEEE 802.1X Remote Authentication Dial In User Service 1172 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 1174 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 1175 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 1176 3748, June 2004. 1178 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, 1179 "Dynamic Authorization Extensions to Remote Authentication 1180 Dial In User Service (RADIUS)", RFC 5176, January 2008. 1182 Acknowledgments 1184 The authors would like to acknowledge Maximilian Riegel, Dorothy 1185 Stanley, Yoshihiro Ohba, and the contributors to the IEEE 802.1 and 1186 IEEE 802.11 reviews of this document, for useful discussions. 1188 Authors' Addresses 1190 Bernard Aboba 1191 Microsoft Corporation 1192 One Microsoft Way 1193 Redmond, WA 98052 1195 EMail: bernard_aboba@hotmail.com 1197 Jouni Malinen 1198 EMail: j@w1.fi 1200 Paul Congdon 1201 Hewlett Packard Company 1202 HP ProCurve Networking 1203 8000 Foothills Blvd, M/S 5662 1204 Roseville, CA 95747 1206 Phone: +1 916 785 5753 1207 Fax: +1 916 785 8478 1208 EMail: paul_congdon@hp.com 1210 Joseph Salowey 1211 Cisco Systems 1212 EMail: jsalowey@cisco.com 1214 Mark Jones 1215 Azuca Systems 1216 EMail: mark@azu.ca