idnits 2.17.1 draft-aboba-radext-wlan-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4072, but the abstract doesn't seem to directly say this. It does mention RFC4072 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4072, updated by this document, for RFC5378 checks: 2002-06-24) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (22 October 2011) is 4569 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 213 -- Looks like a reference, but probably isn't: '2' on line 225 -- Looks like a reference, but probably isn't: '3' on line 233 -- 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.11r' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE-802.1X' ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Bernard Aboba 3 INTERNET-DRAFT Microsoft Corporation 4 Category: Proposed Standard Jouni Malinen 5 Expires: April 23, 2012 Devicescape Software 6 Updates: 4072 Paul Congdon 7 Hewlett Packard Company 8 Joseph Salowey 9 Cisco Systems 10 22 October 2011 12 RADIUS Attributes for IEEE 802 Networks 13 draft-aboba-radext-wlan-15.txt 15 Abstract 17 RFC 3580 provides guidelines for the use of the Remote Authentication 18 Dialin User Service (RADIUS) within IEEE 802 local area networks 19 (LANs). This document proposes additional attributes for use within 20 IEEE 802 networks, as well as providing clarifications on the usage 21 of the EAP-Key-Name attribute, updating RFC 4072. The attributes 22 defined in this document are usable both within RADIUS and Diameter. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on April 23, 2012. 47 Copyright Notice 49 Copyright (c) 2011 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction .......................................... 4 77 1.1 Terminology ..................................... 4 78 1.2 Requirements Language ........................... 5 79 2. RADIUS attributes ..................................... 5 80 2.1 Allowed-Called-Station-Id ....................... 5 81 2.2 EAP-Key-Name .................................... 7 82 2.3 EAP-Peer-Id ..................................... 8 83 2.4 EAP-Server-Id ................................... 9 84 2.5 Mobility-Domain-Id .............................. 10 85 2.6 Preauth-Timeout ................................. 10 86 2.7 Network-Id-Name ................................. 11 87 2.8 Access-Info ..................................... 12 88 3. Table of attributes ................................... 13 89 4. Diameter Considerations ............................... 14 90 5. IANA Considerations ................................... 15 91 6. Security Considerations ............................... 15 92 7. References ............................................ 15 93 7.1 Normative References .................................. 15 94 7.2 Informative References ................................ 16 95 ACKNOWLEDGMENTS .............................................. 17 96 AUTHORS' ADDRESSES ........................................... 18 97 1. Introduction 99 In situations where it is desirable to centrally manage 100 authentication, authorization and accounting (AAA) for IEEE 802 101 [IEEE-802] networks, deployment of a backend authentication and 102 accounting server is desirable. In such situations, it is expected 103 that IEEE 802 authenticators will function as AAA clients. 105 "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) 106 Usage Guidelines" [RFC3580] defined guidelines for the use of the 107 Remote Authentication Dialin User Service (RADIUS) within networks 108 utilizing IEEE 802 local area networks. This document defines 109 additional attributes suitable for usage by IEEE 802 authenticators 110 acting as AAA clients. The attributes defined in this document are 111 usable both within RADIUS and Diameter. 113 1.1. Terminology 115 This document uses the following terms: 117 Access Point (AP) 118 A Station that provides access to the distribution 119 services via the wireless medium for associated Stations. 121 Association The service used to establish Access Point/Station 122 mapping and enable Station invocation of the distribution 123 system services. 125 authenticator An authenticator is an entity that require authentication 126 from the supplicant. The authenticator may be connected 127 to the supplicant at the other end of a point-to-point 128 LAN segment or wireless link. 130 authentication server 131 An authentication server is an entity that provides an 132 authentication service to an authenticator. This service 133 verifies from the credentials provided by the supplicant, 134 the claim of identity made by the supplicant. 136 Station (STA) Any device that contains an IEEE 802.11 conformant medium 137 access control (MAC) and physical layer (PHY) interface 138 to the wireless medium (WM). 140 Supplicant A supplicant is an entity that is being authenticated by 141 an authenticator. The supplicant may be connected to the 142 authenticator at one end of a point-to-point LAN segment 143 or 802.11 wireless link. 145 1.2. Requirements Language 147 In this document, several words are used to signify the requirements 148 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 149 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 150 and "OPTIONAL" in this document are to be interpreted as described in 151 [RFC2119]. 153 2. RADIUS attributes 155 2.1. Allowed-Called-Station-Id 157 Description 159 The Allowed-Called-Station-Id Attribute allows the RADIUS server 160 to specify the authenticator MAC addresses and/or networks to 161 which the user is allowed to connect. One or more Allowed-Called- 162 Station-Id attributes MAY be included in an Access-Accept or CoA- 163 Request packet. 165 A summary of the Allowed-Called-Station-Id Attribute format is 166 shown below. The fields are transmitted from left to right. 168 0 1 2 3 169 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 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Type | Length | String... 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 Code 176 TBD1 178 Length 180 >=3 182 String 184 The String field is one or more octets, containing the layer 2 185 endpoint that the user's call is allowed to be terminated on, as 186 specified in the definition of Called-Station-Id in [RFC2865] 187 Section 5.30 and [RFC3580] Section 3.20. In the case of IEEE 802, 188 the Allowed-Called-Station-Id Attribute is used to store the 189 Medium Access Control (MAC) address in ASCII format (upper case 190 only), with octet values separated by a "-". Example: 191 "00-10-A4-23-19-C0". Where restrictions on both the network and 192 authenticator MAC address usage are intended, the network name 193 MUST be appended to the authenticator MAC address, separated from 194 the MAC address with a ":". Example: "00-10-A4-23-19-C0:AP1". 195 Where no MAC address restriction is intended, the MAC address 196 field MUST be omitted, but the network name field MUST be 197 included. Example: "AP1". Within IEEE 802.11 [IEEE-802.11], the 198 SSID constitutes the network name; within IEEE 802.1X 199 [IEEE-802.1X], the Network-Id Name (NID-Name) constitutes the 200 network name. Since a NID-Name can be up to 253 octets in length, 201 when used with [IEEE-802.1X], there may not be sufficient room 202 within the Allowed-Called-Station-Id Attribute to include a MAC 203 address. 205 If the user attempts to connect to the NAS from a Called-Station- 206 Id that does not match one of the Allowed-Called-Station-Id 207 attributes, then the user MUST NOT be permitted to access the 208 network. 210 The Allowed-Called-Station-Id Attribute can be useful in the 211 following situations: 213 [1] Where users can connect to a NAS without an Access-Request being 214 sent by the NAS to the RADIUS server (e.g. where key caching is 215 supported within IEEE 802.11 or IEEE 802.1X [IEEE-802.1X]). To 216 avoid elevation of privilege attacks, key cache entries are 217 typically only usable within the network to which the user 218 originally authenticated (e.g. the originally selected network 219 name is implicitly attached to the key cache entry). Also, if 220 it is desired that access to a network name not be available 221 from a particular authenticator MAC address, then the 222 authenticator can be set up not to advertise that particular 223 network name. 225 [2] Where pre-authentication may be supported (e.g. IEEE 802.1X 226 pre-authentication). In this situation, the network name 227 typically will not be included in a Called-Station-Id Attribute 228 within the Access-Request, so that the RADIUS server will not 229 know the network that the user is attempting to access. As a 230 result, the RADIUS server may desire to restrict the networks to 231 which the user can subsequently connect. 233 [3] Where the network portion of the Called-Station-Id is present 234 within an Access-Request, the RADIUS server can desire to 235 authorize access to a network different from the one that the 236 user selected. 238 2.2. EAP-Key-Name 240 Description 242 The EAP-Key-Name Attribute, defined in "Diameter Extensible 243 Authentication Protocol (EAP) Application" [RFC4072], contains the 244 EAP Session-Id, as described in "Extensible Authentication 245 Protocol (EAP) Key Management Framework" [RFC5247]. Exactly how 246 this Attribute is used depends on the link layer in question. 248 It should be noted that not all link layers use this name and 249 existing EAP method implementations do not generate it. An EAP- 250 Key-Name Attribute MAY be included within Access-Request, Access- 251 Accept and CoA-Request packets. A summary of the EAP-Key-Name 252 Attribute format is shown below. The fields are transmitted from 253 left to right. 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Type | Length | String... 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 Code 263 102 [RFC4072] 265 Length 267 >=3 269 String 271 The String field is one or more octets, containing the EAP 272 Session-Id, as defined in "Extensible Authentication Protocol 273 (EAP) Key Management Framework" [RFC5247]. Since the NAS operates 274 as a pass-through in EAP, it cannot know the EAP Session-Id before 275 receiving it from the RADIUS server. As a result, an EAP-Key-Name 276 Attribute sent in an Access-Request MUST only contain a single NUL 277 character. A RADIUS server receiving an Access-Request with an 278 EAP-Key-Name Attribute containing anything other than a single NUL 279 character MUST silently discard the Attribute. In addition, the 280 RADIUS server SHOULD include this Attribute in an Access-Accept or 281 CoA-Request only if an EAP-Key-Name Attribute was present in the 282 Access-Request. 284 2.3. EAP-Peer-Id 286 Description 288 The EAP-Peer-Id Attribute contains a Peer-Id generated by the EAP 289 method. Exactly how this name is used depends on the link layer 290 in question. See [RFC5247] for more discussion. The EAP-Peer-Id 291 Attribute MAY be included in Access-Request, Access-Accept and 292 Accounting-Request packets. More than one EAP-Peer-Id Attribute 293 MUST NOT be included in an Access-Request; one or more EAP-Peer-Id 294 attributes MAY be included in an Access-Accept. 296 It should be noted that not all link layers use this name, and 297 existing EAP method implementations do not generate it. Since the 298 NAS operates as a pass-through in EAP [RFC3748], it cannot know 299 the EAP-Peer-Id before receiving it from the RADIUS server. As a 300 result, an EAP-Peer-Id Attribute sent in an Access-Request MUST 301 only contain a single NUL character. A home RADIUS server 302 receiving an Access-Request an EAP-Peer-Id Attribute containing 303 anything other than a single NUL character MUST silently discard 304 the Attribute. In addition, the home RADIUS server SHOULD include 305 one or more EAP-Peer-Id attributes in an Access-Accept only if an 306 EAP-Peer-Id Attribute was present in the Access-Request. A 307 summary of the EAP-Peer-Id Attribute format is shown below. The 308 fields are transmitted from left to right. 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Type | Length | String... 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 Code 318 TBD2 320 Length 322 >=3 324 String 326 The String field is one or more octets containing a EAP Peer-Id 327 exported by the EAP method. For details, see [RFC5247] Appendix 328 A. A robust implementation SHOULD support the field as 329 undistinguished octets. 331 2.4. EAP-Server-Id 333 Description 335 The EAP-Server-Id Attribute contains a Server-Id generated by the 336 EAP method. Exactly how this name is used depends on the link 337 layer in question. See [RFC5247] for more discussion. The EAP- 338 Server-Id Attribute is only allowed in Access-Request, Access- 339 Accept, and Accounting-Request packets. More than one EAP-Server- 340 Id Attribute MUST NOT be included in an Access-Request; one or 341 more EAP-Server-Id attributes MAY be included in an Access-Accept. 343 It should be noted that not all link layers use this name, and 344 existing EAP method implementations do not generate it. Since the 345 NAS operates as a pass-through in EAP [RFC3748], it cannot know 346 the EAP-Server-Id before receiving it from the RADIUS server. As 347 a result, an EAP-Server-Id Attribute sent in an Access-Request 348 MUST contain only a single NUL character. A home RADIUS server 349 receiving in an Access-Request an EAP-Server-Id Attribute 350 containing anything other than a single NUL character MUST 351 silently discard the Attribute. In addition, the home RADIUS 352 server SHOULD include this Attribute an Access-Accept only if an 353 EAP-Server-Id Attribute was present in the Access-Request. A 354 summary of the EAP-Server-Id Attribute format is shown below. The 355 fields are transmitted from left to right. 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Type | Length | String... 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 Code 365 TBD3 367 Length 369 >=3 371 String 373 The String field is one or more octets, containing a EAP Server-Id 374 exported by the EAP method. For details, see [RFC5247] Appendix 375 A. A robust implementation SHOULD support the field as 376 undistinguished octets. 378 2.5. Mobility-Domain-Id 380 Description 382 A single Mobility-Domain-Id Attribute MAY be included in an 383 Access-Request or Accounting-Request, in order to enable the NAS 384 to provide the RADIUS server with the Mobility Domain Identifier 385 (MDID), defined in IEEE 802.11r [IEEE-802.11r]. A summary of the 386 Mobility-Domain-Id Attribute format is shown below. The fields 387 are transmitted from left to right. 389 0 1 2 3 390 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 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Type | Length | Value 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 Value | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Code 399 TBD4 401 Length 403 6 405 Value 407 The Value field is four octets, containing a 32-bit unsigned 408 integer. Since the Mobility Domain Identifier defined in IEEE 409 802.11r [IEEE-802.11r] is only two octets in length, the two most 410 significant octets MUST be set to zero by the sender, and are 411 ignored by the receiver; the two least significant octets contain 412 the MDID value. 414 2.6. Preauth-Timeout 416 Description 418 This Attribute sets the maximum number of seconds which pre- 419 authentication state is required to be kept by the NAS, without 420 being utilized within a user session. For example, when 421 [IEEE-802.11] pre-authentication is used, if a user has not 422 attempted to utilize the PMK derived as a result of pre- 423 authentication within the time specified by the Preauth-Timeout 424 Attribute, the PMK MAY be discarded by the Access Point. However, 425 once the session is underway, the Preauth-Timeout Attribute has no 426 bearing on the maximum session time for the user, or the maximum 427 time during which key state may be kept prior to re- 428 authentication. This is determined by the Session-Timeout 429 Attribute, if present. 431 This Attribute MAY be sent by the server to the NAS in an Access- 432 Accept. A summary of the Preauth-Timeout Attribute format is 433 shown below. The fields are transmitted from left to right. 435 0 1 2 3 436 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 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Type | Length | Value 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 Value (cont) | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 Code 445 TBD5 447 Length 449 6 451 Value 453 The field is 4 octets, containing a 32-bit unsigned integer 454 encoding the maximum time in seconds that pre-authentication state 455 should be retained by the NAS. 457 2.7. Network-Id-Name 459 Description 461 The Network-Id-Name Attribute is utilized by implementations of 462 IEEE-802.1X [IEEE-802.1X] to specify the name of a Network-Id 463 (NID-Name). 465 Unlike the IEEE 802.11 SSID (which is a maximum of 32 octets in 466 length), the NID-Name may be up to 253 octets in length. 467 Consequently, if the MAC address is included within the Called- 468 Station-Id Attribute, it is possible that there will not be enough 469 remaining space to encode the NID-Name as well. Therefore when 470 used with IEEE 802.1X [IEEE-802.1X], the Called-Station-Id 471 Attribute SHOULD contain only the MAC address, with the Network- 472 Id-Name Attribute used to transmit the NID-Name. The Network-Id- 473 Name Attribute SHOULD NOT be used to encode the IEEE 802.11 SSID; 474 as noted in [RFC3580], the Called-Station-Id Attribute is used for 475 this purpose. 477 Zero or one Network-Id-Name Attribute is permitted within a RADIUS 478 Access-Request or Accounting-Request packet. When included within 479 an Access-Request packet, the Network-Id-Name Attribute represents 480 a hint of the NID-Name to which the Supplicant should be granted 481 access. In order to indicate which network names the Supplicant 482 is permitted to access, the Allowed-Called-Station-Id Attribute is 483 provided within an Access-Accept. When included within an 484 Accounting-Request packet, the Network-Id-Name Attribute 485 represents the NID-Name to which the Supplicant has been granted 486 access. 488 A summary of the Network-Id-Name Attribute format is shown below. 489 The fields are transmitted from left to right. 491 0 1 2 3 492 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 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Type | Length | String... 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 Code 499 TBD7 501 Length 503 >=3 505 String 507 The String field is one or more octets, containing a NID-Name. 508 For details, see [IEEE-802.1X]. A robust implementation SHOULD 509 support the field as undistinguished octets. 511 2.8. Access-Info 513 Description 515 The Access-Info Attribute is utilized by implementations of 516 IEEE-802.1X [IEEE-802.1X] to specify the Access status information 517 field within an Access Information Type Length Value Tuple (TLV) 518 to be sent to the user within MACsec Key Agreement (MKA) or EAPoL- 519 Announcement frames. 521 A single Access-Info Attribute is permitted within a RADIUS 522 Access-Accept, Access-Challenge, Access-Reject or Accounting- 523 Request packet. 525 A summary of the Access-Info Attribute format is shown below. The 526 fields are transmitted from left to right. 528 0 1 2 3 529 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 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Type | Length | Value 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 Value | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 Code 538 TBD8 540 Length 542 6 544 Value 546 The Value field is four octets containing a 32-bit unsigned 547 integer. Since the Acess status information field of the Access 548 Information TLV defined in [IEEE-802.1X] Section 11.12.2 is only 549 two octets in length, the two most significant octets of the Value 550 field MUST be set to zero by the sender and are ignored by the 551 receiver. 553 3. Table of attributes 555 The following table provides a guide to which attributes may be found 556 in which kinds of packets, and in what quantity. 558 Access- Access- Access- Access- 559 Request Accept Reject Challenge # Attribute 560 0 0+ 0 0 TBD1 Allowed-Called-Station-Id 561 0-1 0-1 0 0 102 EAP-Key-Name 562 0-1 0+ 0 0 TBD2 EAP-Peer-Id 563 0-1 0+ 0 0 TBD3 EAP-Server-Id 564 0-1 0 0 0 TBD4 Mobility-Domain-Id 565 0-1 0-1 0 0 TBD5 Preauth-Timeout 566 0-1 0 0 0 TBD6 Network-Id-Name 567 0 0-1 0-1 0-1 TBD7 Access-Info 569 CoA- Acct- 570 Req Req # Attribute 571 0+ 0 TBD1 Allowed-Called-Station-Id 572 0-1 0 102 EAP-Key-Name 573 0 0+ TBD2 EAP-Peer-Id 574 0 0+ TBD3 EAP-Server-Id 575 0 0-1 TBD4 Mobility-Domain-Id 576 0 0 TBD5 Preauth-Timeout 577 0 0-1 TBD6 Network-Id-Name 578 0-1 0-1 TBD7 Access-Info 580 The following table defines the meaning of the above table entries. 582 0 This Attribute MUST NOT be present in packet. 583 0+ Zero or more instances of this Attribute MAY be 584 present in the packet. 585 0-1 Zero or one instance of this Attribute MAY be 586 present in the packet. 588 4. Diameter Considerations 590 The EAP-Key-Name Attribute is already defined as a RADIUS Attribute 591 within Diameter EAP [RFC4072]. When used in Diameter, the other 592 attributes defined in this specification can be used as Diameter AVPs 593 from the Code space 1-255 (RADIUS Attribute compatibility space). No 594 additional Diameter Code values are therefore allocated. The data 595 types and flag rules for the attributes are as follows: 597 +---------------------+ 598 | AVP Flag rules | 599 |----+-----+----+-----|----+ 600 | | |SHLD| MUST| | 601 Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr| 602 -----------------------------------------|----+-----+----+-----|----| 603 Allowed-Called- | | | | | | 604 Station-Id UTF8String | M | P | | V | Y | 605 EAP-Peer-Id UTF8String | M | P | | V | Y | 606 EAP-Server-Id UTF8String | M | P | | V | Y | 607 Mobility-Domain-Id Unsigned32 | | P | | V | Y | 608 Preauth-Timeout Unsigned32 | M | P | | V | Y | 609 Network-Id-Name UTF8String | M | P | | V | Y | 610 Access-Info Unsigned32 | M | P | | V | Y | 611 -----------------------------------------|----+-----+----+-----|----| 613 The attributes in this specification have no special translation 614 requirements for Diameter to RADIUS or RADIUS to Diameter gateways; 615 they are copied as is, except for changes relating to headers, 616 alignment, and padding. See also [RFC3588] Section 4.1 and [RFC4005] 617 Section 9. 619 What this specification says about the applicability of the 620 attributes for RADIUS Access-Request packets applies in Diameter to 621 AA-Request [RFC4005] or Diameter-EAP-Request [RFC4072]. What is said 622 about Access-Challenge applies in Diameter to AA-Answer [RFC4005] or 623 Diameter-EAP-Answer [RFC4072] with Result-Code AVP set to 624 DIAMETER_MULTI_ROUND_AUTH. 626 What is said about Access-Accept applies in Diameter to AA-Answer or 627 Diameter-EAP-Answer messages that indicate success. Similarly, what 628 is said about RADIUS Access-Reject packets applies in Diameter to AA- 629 Answer or Diameter-EAP-Answer messages that indicate failure. 631 What is said about COA-Request applies in Diameter to Re-Auth-Request 632 [RFC4005]. What is said about Accounting-Request applies to Diameter 633 Accounting- Request [RFC4005] as well. 635 5. IANA Considerations 637 This document uses the RADIUS [RFC2865] namespace, see 638 . This specification 639 requires assignment of a RADIUS attribute types for the following 640 attributes: 642 Attribute Type 643 ========= ==== 644 Allowed-Called-Station-Id TBD1 645 EAP-Peer-Id TBD2 646 EAP-Server-Id TBD3 647 Mobility-Domain-Id TBD4 648 Preauth-Timeout TBD5 649 Network-Id-Name TBD6 650 Access-Info TBD7 652 6. Security Considerations 654 Since this document describes the use of RADIUS for purposes of 655 authentication, authorization, and accounting in IEEE 802 networks, 656 it is vulnerable to all of the threats that are present in other 657 RADIUS applications. For a discussion of these threats, see 658 [RFC2607], [RFC2865], [RFC3162], [RFC3579], [RFC3580] and [RFC5176]. 660 7. References 662 7.1. Normative references 664 [IEEE-802] IEEE Standards for Local and Metropolitan Area Networks: 665 Overview and Architecture, ANSI/IEEE Std 802, 1990. 667 [IEEE-802.11] 668 Information technology - Telecommunications and information 669 exchange between systems - Local and metropolitan area 670 networks - Specific Requirements Part 11: Wireless LAN 671 Medium Access Control (MAC) and Physical Layer (PHY) 672 Specifications, IEEE Std. 802.11-2007, 2007. 674 [IEEE-802.11r] 675 Amendment to Standard for Information technology - 676 Telecommunications and information exchange between systems - 677 Local and metropolitan area networks - Specific Requirements 678 Part 11: Wireless LAN Medium Access Control (MAC) and 679 Physical Layer (PHY) Specifications: Amendment 2: Fast BSS 680 Transition, IEEE 802.11r-2008, July 2008. 682 [IEEE-802.1X] 683 IEEE Standard for Local and Metropolitan Area Networks - 684 Port-Based Network Access Control, IEEE 802.1X-2010, February 685 2010. 687 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 688 Requirement Levels", RFC 2119, March, 1997. 690 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 691 Authentication Dial In User Service (RADIUS)", RFC 2865, June 692 2000. 694 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 695 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 697 [RFC4072] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 698 Authentication Protocol (EAP) Application", RFC 4072, August 699 2005. 701 [RFC5247] Aboba, B., Simon, D. and P. Eronen, "EAP Key Management 702 Framework", RFC 5247, August 2008. 704 7.2. Informative references 706 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 707 Implementation in Roaming", RFC 2607, June 1999. 709 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 710 3162, August 2001. 712 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 713 Authentication Protocol (EAP)", RFC 3579, September 2003. 715 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 716 "IEEE 802.1X Remote Authentication Dial In User Service 717 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 719 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 720 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 721 3748, June 2004. 723 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter 724 Network Access Server Application", RFC 4005, August 2005. 726 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, 727 "Dynamic Authorization Extensions to Remote Authentication 728 Dial In User Service (RADIUS)", RFC 5176, January 2008. 730 Acknowledgments 732 The authors would like to acknowledge Mick Seaman, Dorothy Stanley, 733 Yoshihiro Ohba, and the contributors to the IEEE 802.1 and IEEE 734 802.11 reviews of this document, for useful discussions. 736 Authors' Addresses 738 Bernard Aboba 739 Microsoft Corporation 740 One Microsoft Way 741 Redmond, WA 98052 743 EMail: bernard_aboba@hotmail.com 745 Jouni Malinen 746 Devicescape Software, Inc. 747 900 Cherry Avenue 748 San Bruno, CA 94066 750 EMail: jkm@devicescape.com 751 Phone: +1 650 829 2600 752 Fax: +1 650 829 2601 754 Paul Congdon 755 Hewlett Packard Company 756 HP ProCurve Networking 757 8000 Foothills Blvd, M/S 5662 758 Roseville, CA 95747 760 Phone: +1 916 785 5753 761 Fax: +1 916 785 8478 762 EMail: paul_congdon@hp.com 764 Joseph Salowey 765 Cisco Systems 767 EMail: jsalowey@cisco.com