idnits 2.17.1 draft-ietf-radext-ieee802ext-11.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 (17 March 2014) is 3692 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 Corporation 4 Category: Proposed Standard Jouni Malinen 5 Expires: September 24, 2014 Devicescape Software 6 Updates: 3580, 4072 Paul Congdon 7 Tallac Networks 8 Joseph Salowey 9 Cisco Systems 10 Mark Jones 11 Azuca Systems 12 17 March 2014 14 RADIUS Attributes for IEEE 802 Networks 15 draft-ietf-radext-ieee802ext-11.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 September 24, 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] wired networks, the 221 Network-Id Name (NID-Name) constitutes the network name. Since a 222 NID-Name can be up to 253 octets in length, when used with 223 [IEEE-802.1X] wired networks, there may not be sufficient room 224 within the Allowed-Called-Station-Id Attribute to include both a 225 MAC address and a Network Name. However, as the Allowed-Called- 226 Station-Id Attribute is expected to be used largely in wireless 227 access scenarios, this restriction is not considered serious. 229 2.2. EAP-Key-Name 231 Description 233 The EAP-Key-Name Attribute, defined in "Diameter Extensible 234 Authentication Protocol (EAP) Application" [RFC4072], contains the 235 EAP Session-Id, as described in "Extensible Authentication 236 Protocol (EAP) Key Management Framework" [RFC5247]. Exactly how 237 this Attribute is used depends on the link layer in question. 239 It should be noted that not all link layers use this name. An 240 EAP-Key-Name Attribute MAY be included within Access-Request, 241 Access-Accept and CoA-Request packets. A summary of the EAP-Key- 242 Name Attribute format is shown below. The fields are transmitted 243 from left to right. 245 0 1 2 3 246 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Type | Length | String... 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 Code 253 102 [RFC4072] 255 Length 257 >=3 259 String 261 The String field is one or more octets, containing the EAP 262 Session-Id, as defined in "Extensible Authentication Protocol 263 (EAP) Key Management Framework" [RFC5247]. Since the NAS operates 264 as a pass-through in EAP, it cannot know the EAP Session-Id before 265 receiving it from the RADIUS server. As a result, an EAP-Key-Name 266 Attribute sent in an Access-Request MUST only contain a single NUL 267 character. A RADIUS server receiving an Access-Request with an 268 EAP-Key-Name Attribute containing anything other than a single NUL 269 character MUST silently discard the Attribute. In addition, the 270 RADIUS server SHOULD include this Attribute in an Access-Accept or 271 CoA-Request only if an EAP-Key-Name Attribute was present in the 272 Access-Request. Since a NAS will typically only include a EAP- 273 Key-Name Attribute in an Access-Request in situations where the 274 Attribute is required to provision service, if an EAP-Key-Name 275 Attribute is included in an Access-Request but is not present in 276 the Access-Accept, the NAS SHOULD treat the Access-Accept as 277 though it were an Access-Reject. If an EAP-Key-Name Attribute was 278 not present in the Access-Request but is included in the Access- 279 Accept, then the NAS SHOULD silently discard the EAP-Key-Name 280 Attribute. 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 Extensible Authentication Protocol over Local Area Network 524 (EAPoL)-Announcement Attribute contains EAPoL-Announcement Type 525 Length Value Tuples (TLVs) defined within Table 11-8 of 526 IEEE-802.1X [IEEE-802.1X]. 528 Zero or more EAPoL-Announcement attributes are permitted within an 529 Access-Request, Access-Accept, Access-Challenge, Access-Reject, 530 Accounting-Request, CoA-Request or Disconnect-Request packet. 532 When included within an Access-Request packet, EAPoL-Announcement 533 attributes contain EAPoL-Announcement TLVs that the user sent in 534 an EAPoL-Announcement. When included within an Access-Accept, 535 Access-Challenge, Access-Reject, CoA-Request or Disconnect-Request 536 packet, EAPoL-Announcement attributes contain EAPoL-Announcement 537 TLVs that the NAS is to send to the user in a unicast EAPoL- 538 Announcement. When sent within an Accounting-Request packet, 539 EAPoL-Announcment attributes contain EAPoL-Announcement TLVs that 540 the NAS has most recently sent to the user in a unicast EAPoL- 541 Announcement. 543 A summary of the EAPoL-Announcement Attribute format is shown 544 below. The fields are transmitted from left to right. 546 0 1 2 3 547 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 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Type | Length | String... 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 Code 554 TBD7 556 Length 558 >=3 560 String 562 The String field is one or more octets, containing EAPoL- 563 Announcement TLVs in the format defined in Figure 11-8 of Section 564 11.12 of [IEEE-802.1X]. Any EAPoL-Announcement TLV Type MAY be 565 included within an EAPoL-Announcement Attribute, including 566 Organizationally Specific TLVs. If multiple EAPoL-Announcement 567 attributes are present in a packet, their String fields MUST be 568 concatenated before being parsed for EAPoL-Announcement TLVs; this 569 allows EAPoL-Announcement TLVs longer than 253 octets to be 570 transported by RADIUS. Similarly, EAPoL-Announcement TLVs larger 571 than 253 octets MUST be fragmented between multiple EAPoL- 572 Announcement attributes. 574 2.9. WLAN-HESSID 576 Description 578 The WLAN-HESSID attribute contains a MAC address that identifies 579 the Homogenous Extended Service Set. The HESSID is a globally 580 unique identifier that in conjunction with the SSID, encoded 581 within the Called-Station-Id Attribute as described in [RFC3580], 582 may be used to provide network identification for a subscription 583 service provider network (SSPN), as described in Section 8.4.2.94 584 of [IEEE-802.11]. Zero or one WLAN-HESSID Attribute is permitted 585 within an Access-Request or Accounting-Request packet. 587 A summary of the WLAN-HESSID Attribute format is shown below. The 588 fields are transmitted from left to right. 590 0 1 2 3 591 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 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Type | Length | String... 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 Code 598 TBD8 600 Length 602 19 604 String 606 The String field is encoded in upper-case ASCII characters with 607 the octet values separated by dash characters, as described in RFC 608 3580 [RFC3580]. Example: "00-10-A4-23-19-C0". 610 2.10. WLAN-Venue-Info 612 Description 614 The WLAN-Venue-Info attribute identifies the category of venue 615 hosting the WLAN, as defined in Section 8.4.1.34 of [IEEE-802.11]. 616 Zero or more WLAN-Venue-Info attributes may be included in an 617 Access-Request or Accounting-Request. 619 A summary of the WLAN-Venue-Info Attribute format is shown below. 620 The fields are transmitted from left to right. 622 0 1 2 3 623 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 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Type | Length | Value 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 Value | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 Code 631 TBD9 633 Length 635 6 637 Value 639 The Value field is four octets, containing a 32-bit unsigned 640 integer. The two most significant octets MUST be set to zero by 641 the sender, and are ignored by the receiver; the two least 642 significant octets contain the Venue Group and Venue Type fields. 644 0 1 2 3 645 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 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Reserved | Venue Group | Venue Type | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 Venue Group 652 The Venue Group field is a single octet and describes the broad 653 category of the venue, e.g. "Assembly". See Section 8.4.1.34 654 [IEEE-802.11] for Venue Group codes and descriptions. 656 Venue Type 658 The Venue Type field is a single octet and describes the venue in 659 a finer granularity within the Venue Group, e.g. "Library". See 660 Section 8.4.1.34 of [IEEE-802.11] for Venue Type codes and 661 descriptions. 663 2.11. WLAN-Venue-Language 665 Description 667 The WLAN-Venue-Language attribute is an ISO-14962-1997 668 [ISO-14962-1997] encoded string that defines the language used in 669 the WLAN-Venue-Name attribute. Zero or more WLAN-Venue-Language 670 attributes may be included in an Access-Request or Accounting- 671 Request and each one indicates the language of the WLAN-Venue-Name 672 attribute that follows it. 674 A summary of the WLAN-Venue-Language Attribute format is shown 675 below. The fields are transmitted from left to right. 677 0 1 2 3 678 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 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | Type | Length | String... 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 String (cont) | 683 +-+-+-+-+-+-+-+-+ 685 Code 687 TBD10 689 Length 691 4-5 693 String 695 The String field is a two or three character language code 696 selected from ISO-639 [ISO-639]. A two character language code 697 has a zero ("null" in ISO-14962-1997) appended to make it 3 octets 698 in length. 700 2.12. WLAN-Venue-Name 702 Description 704 The WLAN-Venue-Name attribute provides additional metadata on the 705 BSS. For example, this information may be used to assist a user 706 in selecting the appropriate BSS with which to associate. Zero or 707 more WLAN-Venue-Name attributes may be included in an Access- 708 Request or Accounting-Request in the same or different languages. 710 A summary of the WLAN-Venue-Name Attribute format is shown below. 711 The fields are transmitted from left to right. 713 0 1 2 3 714 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 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | Type | Length | String... 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 Code 721 TBD11 723 Length 724 >=3 726 String 728 The String field is a UTF-8 formatted field containing the venue's 729 name. The maximum length of this field is 252 octets. 731 2.13. WLAN-Reason-Code 733 Description 735 The WLAN-Reason-Code Attribute contains information on the reason 736 why a station has been refused network access and has been 737 disassociated or de-authenticated. This can occur due to policy 738 or for reasons related to the user's subscription. 740 A WLAN-Reason-Code Attribute MAY be included within an Access- 741 Reject or Disconnect-Request packet, as well as within an 742 Accounting-Request packet. Upon receipt of an Access-Reject or 743 Disconnect-Request packet containing a WLAN-Reason-Code Attribute, 744 the WLAN-Reason-Code value is copied by the Access Point into the 745 Reason Code field of a Disassociation or Deauthentication frame 746 (see clause 8.3.3.4 and 8.3.3.12 respectively in [IEEE- 802.11]), 747 which is subsequently transmitted to the station. 749 A summary of the WLAN-Reason-Code Attribute format is shown below. 750 The fields are transmitted from left to right. 752 0 1 2 3 753 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 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | Type | Length | Value 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 Value | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 Code 762 TBD12 764 Length 766 6 768 Value 770 The Value field is four octets, containing a 32-bit unsigned 771 integer. The two most significant octets MUST be set to zero by 772 the sender, and are ignored by the receiver; the two least 773 significant octets contain the Reason Code values defined in Table 774 8-36 of Section 8.4.1.7 of [IEEE-802.11]. 776 0 1 2 3 777 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 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Reserved | Reason Code | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 2.14. WLAN-Pairwise-Cipher 784 Description 786 The WLAN-Pairwise-Cipher Attribute contains information on the 787 pairwise cipher suite used to establish the robust security 788 network association (RSNA) between the AP and mobile device. A 789 WLAN-Pairwise-Cipher Attribute MAY be included within Access- 790 Request and Accounting-Request packets. 792 A summary of the WLAN-Pairwise-Cipher Attribute format is shown 793 below. The fields are transmitted from left to right. 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 | Type | Length | Value 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 Value | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 Code 805 TBD13 807 Length 809 6 811 Value 813 The Value field is four octets, containing a 32-bit unsigned 814 integer, in Suite selector format as specified in Figure 8-187 815 within Section 8.4.2.27.2 of [IEEE-802.11], with values of OUI and 816 Suite type drawn from Table 8-99. 818 0 1 2 3 819 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 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | OUI | Suite Type | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 2.15. WLAN-Group-Cipher 826 Description 828 The WLAN-Group-Cipher Attribute contains information on the group 829 cipher suite used to establish the robust security network 830 association (RSNA) between the AP and mobile device. A WLAN- 831 Group-Cipher Attribute MAY be included within Access-Request and 832 Accounting-Request packets. 834 A summary of the WLAN-Group-Cipher Attribute format is shown 835 below. The fields are transmitted from left to right. 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 | Type | Length | Value 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 Value | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 Code 847 TBD14 849 Length 851 6 853 Value 855 The Value field is four octets, containing a 32-bit unsigned 856 integer, in Suite selector format as specified in Figure 8-187 857 within Section 8.4.2.27.2 of [IEEE-802.11], with values of OUI and 858 Suite type drawn from Table 8-99. 860 0 1 2 3 861 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 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | OUI | Suite Type | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 2.16. WLAN-AKM-Suite 868 Description 870 The WLAN-AKM-Suite Attribute contains information on the 871 authentication and key management suite used to establish the 872 robust security network association (RSNA) between the AP and 873 mobile device. A WLAN-AKM-Suite Attribute MAY be included within 874 Access-Request and Accounting-Request packets. 876 A summary of the WLAN-AKM-Suite Attribute format is shown below. 877 The fields are transmitted from left to right. 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 | Type | Length | Value 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 Value | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 Code 889 TBD15 891 Length 893 6 895 Value 897 The Value field is four octets, containing a 32-bit unsigned 898 integer, in Suite selector format as specified in Figure 8-187 899 within Section 8.4.2.27.2 of [IEEE-802.11], with values of OUI and 900 Suite type drawn from Table 8-101: 902 0 1 2 3 903 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 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | OUI | Suite Type | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 2.17. WLAN-Group-Mgmt-Cipher 910 Description 912 The WLAN-Group-Mgmt-Cipher Attribute contains information on group 913 management cipher used to establish the robust security network 914 association (RSNA) between the AP and mobile device. 916 Zero or one WLAN-Group-Mgmt-Cipher Attribute MAY be included 917 within Access-Request and Accounting-Request packets. Presence of 918 the attribute indicates that the station negotiated to use 919 management frame protection during association. 921 A summary of the WLAN-Group-Mgmt-Cipher Attribute format is shown 922 below. The fields are transmitted from left to right. 924 0 1 2 3 925 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 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | Type | Length | Value 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 Value | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 Code 934 TBD16 936 Length 938 6 940 Value 942 The Value field is four octets, containing a 32-bit unsigned 943 integer, in Suite selector format as specified in Figure 8-187 944 within Section 8.4.2.27.2 of [IEEE-802.11], with values of OUI and 945 Suite type drawn from Table 8-99: 947 0 1 2 3 948 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 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | OUI | Suite Type | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 2.18. WLAN-RF-Band 955 Description 957 The WLAN-RF-Band Attribute contains information on the RF band 958 used by the Access Point for transmission and reception of 959 information to and from the mobile device. Zero or one WLAN-RF- 960 Band Attribute MAY be included within an Access-Request or 961 Accounting-Request packet. 963 A summary of the WLAN-RF-Band Attribute format is shown below. 964 The fields are transmitted from left to right. 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 | Type | Length | Value 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 Value | 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 Code 976 TBD17 978 Length 980 6 982 Value 984 The Value field is four octets, containing a 32-bit unsigned 985 integer. The three most significant octets MUST be set to zero by 986 the sender, and are ignored by the receiver; the least significant 987 octet contains the RF Band field, whose values are defined in 988 Table 8-53a of [IEEE-802.11ad]. 990 0 1 2 3 991 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 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 | Reserved | RF Band | 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 3. Table of attributes 998 The following table provides a guide to which attributes may be found 999 in which kinds of packets, and in what quantity. 1001 Access- Access- Access- Access- 1002 Request Accept Reject Challenge # Attribute 1003 0 0+ 0 0 TBD1 Allowed-Called-Station-Id 1004 0-1 0-1 0 0 102 EAP-Key-Name 1005 0-1 0+ 0 0 TBD2 EAP-Peer-Id 1006 0-1 0+ 0 0 TBD3 EAP-Server-Id 1007 0-1 0 0 0 TBD4 Mobility-Domain-Id 1008 0-1 0-1 0 0 TBD5 Preauth-Timeout 1009 0-1 0 0 0 TBD6 Network-Id-Name 1010 0+ 0+ 0+ 0+ TBD7 EAPoL-Announcement 1011 0-1 0 0 0 TBD8 WLAN-HESSID 1012 0-1 0 0 0 TBD9 WLAN-Venue-Info 1013 0+ 0 0 0 TBD10 WLAN-Venue-Language 1014 0+ 0 0 0 TBD11 WLAN-Venue-Name 1015 0 0 0-1 0 TBD12 WLAN-Reason-Code 1016 0-1 0 0 0 TBD13 WLAN-Pairwise-Cipher 1017 0-1 0 0 0 TBD14 WLAN-Group-Cipher 1018 0-1 0 0 0 TBD15 WLAN-AKM-Suite 1019 0-1 0 0 0 TBD16 WLAN-Group-Mgmt-Cipher 1020 0-1 0 0 0 TBD17 WLAN-RF-Band 1022 CoA- Dis- Acct- 1023 Req Req Req # Attribute 1024 0+ 0 0+ TBD1 Allowed-Called-Station-Id 1025 0-1 0 0 102 EAP-Key-Name 1026 0 0 0+ TBD2 EAP-Peer-Id 1027 0 0 0+ TBD3 EAP-Server-Id 1028 0 0 0-1 TBD4 Mobility-Domain-Id 1029 0-1 0 0 TBD5 Preauth-Timeout 1030 0 0 0-1 TBD6 Network-Id-Name 1031 0+ 0+ 0+ TBD7 EAPoL-Announcement 1032 0 0 0-1 TBD8 WLAN-HESSID 1033 0 0 0-1 TBD9 WLAN-Venue-Info 1034 0 0 0+ TBD10 WLAN-Venue-Language 1035 0 0 0+ TBD11 WLAN-Venue-Name 1036 0 0-1 0-1 TBD12 WLAN-Reason-Code 1037 0 0 0-1 TBD13 WLAN-Pairwise-Cipher 1038 0 0 0-1 TBD14 WLAN-Group-Cipher 1039 0 0 0-1 TBD15 WLAN-AKM-Suite 1040 0 0 0-1 TBD16 WLAN-Group-Mgmt-Cipher 1041 0 0 0-1 TBD17 WLAN-RF-Band 1043 The following table defines the meaning of the above table entries. 1045 0 This Attribute MUST NOT be present in packet. 1046 0+ Zero or more instances of this Attribute MAY be 1047 present in the packet. 1048 0-1 Zero or one instance of this Attribute MAY be 1049 present in the packet. 1051 4. IANA Considerations 1053 This document uses the RADIUS [RFC2865] namespace, see 1054 . This specification 1055 requires assignment of a RADIUS attribute types for the following 1056 attributes: 1058 Attribute Type 1059 ========= ==== 1060 Allowed-Called-Station-Id TBD1 1061 EAP-Peer-Id TBD2 1062 EAP-Server-Id TBD3 1063 Mobility-Domain-Id TBD4 1064 Preauth-Timeout TBD5 1065 Network-Id-Name TBD6 1066 EAPoL-Announcement TBD7 1067 WLAN-HESSID TBD8 1068 WLAN-Venue-Info TBD9 1069 WLAN-Venue-Language TBD10 1070 WLAN-Venue-Name TBD11 1071 WLAN-Reason-Code TBD12 1072 WLAN-Pairwise-Cipher TBD13 1073 WLAN-Group-Cipher TBD14 1074 WLAN-AKM-Suite TBD15 1075 WLAN-Group-Mgmt-Cipher TBD16 1076 WLAN-RF-Band TBD17 1078 Since this specification relies entirely on values assigned by IEEE 1079 802, no registries are established for maintenance by the IANA. 1081 5. Security Considerations 1083 Since this document describes the use of RADIUS for purposes of 1084 authentication, authorization, and accounting in IEEE 802 networks, 1085 it is vulnerable to all of the threats that are present in other 1086 RADIUS applications. For a discussion of these threats, see 1087 [RFC2607], [RFC2865], [RFC3162], [RFC3579], [RFC3580] and [RFC5176]. 1089 While it is possible for a RADIUS server to make decisions on whether 1090 to Accept or Reject an Access-Request based on the values of the 1091 WLAN-Pairwise-Cipher, WLAN-Group-Cipher, WLAN-AKM-Suite, WLAN-Group- 1092 Mgmt-Cipher and WLAN-RF-Band Attributes the value of doing this is 1093 limited. In general, an Access-Reject should not be necessary, 1094 except where Access Points and Stations are misconfigured so as to 1095 enable connections to be made with unacceptable values. Rather than 1096 rejecting access on an ongoing basis, users would be better served by 1097 fixing the misconfiguration. 1099 Where access does need to be rejected, the user should be provided 1100 with an indication of why the problem has occurred, or else they are 1101 likely to become frustrated. For example, if the values of the WLAN- 1102 Pairwise-Cipher, WLAN-Group-Cipher, WLAN-AKM-Suite or WLAN-Group- 1103 Mgmt-Cipher Attributes included in the Access-Request are not 1104 acceptable to the RADIUS server, then a WLAN-Reason-Code Attribute 1105 with a value of 29 (Requested service rejected because of service 1106 provider cipher suite or AKM requirement) SHOULD be returned in the 1107 Access-Reject. Similarly, if the value of the WLAN-RF-Band Attribute 1108 included in the Access-Request is not acceptable to the RADIUS 1109 server, then a WLAN-Reason-Code Attribute with a value of 11 1110 (Disassociated because the information in the Supported Channels 1111 element is unacceptable) SHOULD be returned in the Access-Reject. 1113 6. References 1115 6.1. Normative references 1117 [IEEE-802] IEEE Standards for Local and Metropolitan Area Networks: 1118 Overview and Architecture, ANSI/IEEE Std 802, 1990. 1120 [IEEE-802.11] 1121 Information technology - Telecommunications and Information 1122 Exchange Between Systems - Local and Metropolitan Area 1123 Networks - Specific Requirements Part 11: Wireless LAN 1124 Medium Access Control (MAC) and Physical Layer (PHY) 1125 Specifications, IEEE Std. 802.11-2012, 2012. 1127 [IEEE-802.11ad] 1128 Information technology - Telecommunications and Information 1129 Exchange Between Systems - Local and Metropolitan Area 1130 Networks - Specific Requirements Part 11: Wireless LAN 1131 Medium Access Control (MAC) and Physical Layer (PHY) 1132 Specifications, Amendment 3: Enhancements for Very High 1133 Throughput in the 60 GHz Band, IEEE Std. 802.11ad-2012, 2012. 1135 [IEEE-802.1X] 1136 IEEE Standard for Local and Metropolitan Area Networks - 1137 Port-Based Network Access Control, IEEE 802.1X-2010, February 1138 2010. 1140 [ISO-639] ISO, "Codes for the Representation of Names of Languages". 1142 [ISO-14962-1997] 1143 ISO, "Space data and information transfer systems - ASCII 1144 encoded English", 1997. 1146 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1147 Requirement Levels", RFC 2119, March, 1997. 1149 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 1150 Authentication Dial In User Service (RADIUS)", RFC 2865, June 1151 2000. 1153 [RFC4072] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 1154 Authentication Protocol (EAP) Application", RFC 4072, August 1155 2005. 1157 [RFC5247] Aboba, B., Simon, D. and P. Eronen, "EAP Key Management 1158 Framework", RFC 5247, August 2008. 1160 6.2. Informative references 1162 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 1163 Implementation in Roaming", RFC 2607, June 1999. 1165 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 1166 3162, August 2001. 1168 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 1169 Authentication Protocol (EAP)", RFC 3579, September 2003. 1171 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 1172 "IEEE 802.1X Remote Authentication Dial In User Service 1173 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 1175 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 1176 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 1177 3748, June 2004. 1179 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, 1180 "Dynamic Authorization Extensions to Remote Authentication 1181 Dial In User Service (RADIUS)", RFC 5176, January 2008. 1183 Acknowledgments 1185 The authors would like to acknowledge Maximilian Riegel, Dorothy 1186 Stanley, Yoshihiro Ohba, and the contributors to the IEEE 802.1 and 1187 IEEE 802.11 reviews of this document, for useful discussions. 1189 Authors' Addresses 1191 Bernard Aboba 1192 Microsoft Corporation 1193 One Microsoft Way 1194 Redmond, WA 98052 1196 EMail: bernard_aboba@hotmail.com 1198 Jouni Malinen 1199 EMail: j@w1.fi 1201 Paul Congdon 1202 Tallac Networks 1203 6528 Lonetree Blvd. 1204 Rocklin, CA 95765 1206 Phone: +19167576350 1207 EMail: paul.congdon@tallac.com 1209 Joseph Salowey 1210 Cisco Systems 1211 EMail: jsalowey@cisco.com 1213 Mark Jones 1214 Azuca Systems 1215 EMail: mark@azu.ca