idnits 2.17.1 draft-aboba-radext-fixes-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 834. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 811. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 818. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 824. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 5 characters in excess of 72. -- The draft header indicates that this document updates RFC2865, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2866, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3576, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2869, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3579, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 551 has weird spacing: '...44 only permi...' (Using the creation date from RFC2865, updated by this document, for RFC5378 checks: 1999-03-04) (Using the creation date from RFC2869, updated by this document, for RFC5378 checks: 1998-04-10) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 463 -- Looks like a reference, but probably isn't: '2' on line 466 -- Looks like a reference, but probably isn't: '3' on line 470 == Missing Reference: 'Note 2' is mentioned on line 487, but not defined == Missing Reference: 'RFC2104' is mentioned on line 603, but not defined == Unused Reference: 'RFC2607' is defined on line 721, but no explicit reference was found in the text == Unused Reference: 'RFC2867' is defined on line 730, but no explicit reference was found in the text == Unused Reference: 'RFC2868' is defined on line 734, but no explicit reference was found in the text == Unused Reference: 'RFC2882' is defined on line 741, but no explicit reference was found in the text == Unused Reference: 'RFC3575' is defined on line 747, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2462 (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 3576 (Obsoleted by RFC 5176) -- Obsolete informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group David Nelson 3 INTERNET-DRAFT Enterasys Networks 4 Updates: 2865, 2866, 2869, 3576, 3579 Alan DeKok 5 Category: Proposed Standard Infoblox, Inc. 6 Bernard Aboba 7 3 June 2006 Microsoft 9 Common RADIUS Implementation Issues and Suggested Fixes 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 10, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document describes common issues seen in RADIUS implementations 41 and suggests some fixes. Where applicable, ambiguities and errors in 42 previous RADIUS specifications are clarified. 44 Table of Contents 46 1. Introduction .......................................... 3 47 1.1 Terminology ..................................... 3 48 1.2 Requirements Language ........................... 3 49 2. Issues ................................................ 4 50 2.1 Session Definition .............................. 4 51 2.2 Overload Conditions ............................. 6 52 2.3 Accounting Issues ............................... 7 53 2.4 Multiple Filter-ID Attributes ................... 8 54 2.5 Mandatory and Optional Attributes ............... 9 55 2.6 Interpretation of Access-Reject ................. 10 56 2.7 Addressing ...................................... 12 57 2.8 Idle Timeout .................................... 13 58 2.9 Calculation of Message-Authenticator ............ 14 59 2.10 Unknown Identity ................................ 15 60 3. IANA Considerations ................................... 16 61 4. Security Considerations ............................... 16 62 5. References ............................................ 16 63 5.1 Informative References ................................ 16 64 ACKNOWLEDGMENTS .............................................. 17 65 AUTHORS' ADDRESSES ........................................... 17 66 Intellectual Property Statement .............................. 18 67 Disclaimer of Validity ....................................... 19 68 Copyright Statement .......................................... 19 69 1. Introduction 71 The last few years have seen an increase in the deployment of RADIUS 72 clients and servers. This document describes common issues seen in 73 RADIUS implementations and suggests some fixes. Where applicable, 74 ambiguities and errors in previous RADIUS specifications are 75 clarified. 77 1.1. Terminology 79 This document uses the following terms: 81 Network Access Server (NAS) 82 The device providing access to the network. Also known as the 83 Authenticator (IEEE 802.1X or EAP terminology) or RADIUS client. 85 service 86 The NAS provides a service to the user, such as network access via 87 802.11 or PPP. 89 session 90 Each service provided by the NAS to a peer constitutes a session, 91 with the beginning of the session defined as the point where 92 service is first provided and the end of the session defined as the 93 point where service is ended. A peer may have multiple sessions in 94 parallel or series if the NAS supports that, with each session 95 generating a separate start and stop accounting record. 97 silently discard 98 This means the implementation discards the packet without further 99 processing. The implementation SHOULD provide the capability of 100 logging the error, including the contents of the silently discarded 101 packet, and SHOULD record the event in a statistics counter. 103 1.2. Requirements Language 105 In this document, several words are used to signify the requirements 106 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 107 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 108 and "OPTIONAL" in this document are to be interpreted as described in 109 [RFC2119]. 111 2. Issues 113 2.1. Session Definition 115 2.1.1. State Attribute 117 Regarding the State attribute, [RFC2865] Section 5.24 states: 119 This Attribute is available to be sent by the server to the client 120 in an Access-Challenge and MUST be sent unmodified from the client 121 to the server in the new Access-Request reply to that challenge, 122 if any. 124 This Attribute is available to be sent by the server to the client 125 in an Access-Accept that also includes a Termination-Action 126 Attribute with the value of RADIUS-Request. If the NAS performs 127 the Termination-Action by sending a new Access-Request upon 128 termination of the current session, it MUST include the State 129 attribute unchanged in that Access-Request. 131 Some RADIUS client implementations do not properly use the State 132 attribute in order to distinguish a restarted EAP authentication 133 process from the continuation of an ongoing process (by the same user 134 on the same NAS and port). 136 Where an EAP-Message attribute is included in an Access-Challenge or 137 Access-Accept attribute, RADIUS servers SHOULD also include a State 138 attribute. 140 An Access-Request sent as a result of a new or restarted 141 authentication run MUST NOT include the State attribute, even if the 142 State attribute has previously been received in an Access-Challenge 143 for the same user and port. 145 Since a State attribute is always initially provided by the server in 146 an Access-Accept, Access-Challenge, CoA-Request or Disconnect- 147 Request, a RADIUS client MUST NOT insert a State attribute that it 148 has not previously received from the server. 150 A State attribute is REQUIRED in Access-Request packets neither 151 including an authentication attribute nor a Service-Type attribute 152 with the value Call Check (10). [RFC2865] Section 5.44 states: 154 An Access-Request MUST contain either a User-Password or a CHAP- 155 Password or State. An Access-Request MUST NOT contain both a 156 User-Password and a CHAP-Password. If future extensions allow 157 other kinds of authentication information to be conveyed, the 158 attribute for that can be used in an Access-Request instead of 159 User-Password or CHAP-Password. 161 [RFC3576] defines the Service-Type value of "Authorize-Only". This 162 Service-Type can be included within Disconnect or CoA-Request 163 packets. A NAS receiving such a Disconnect or CoA-Request will send 164 an Access-Request packet containing a Service-Type attribute with the 165 value "Authorize-Only" and no authentication attributes. In order to 166 satisfy the requirements of [RFC2865] Section 5.44, an Access-Request 167 with Service-Type="Authorize-Only" MUST contain a State attribute. 169 In order to provide a State attribute to the NAS, Disconnect and CoA- 170 Request packets containing a Service-Type of value "Authorize-Only" 171 MUST also contain a State attribute, and the NAS MUST include the 172 State attribute unchanged in the Access-Request. A NAS receiving a 173 Disconnect or CoA-Request containing a Service-Type value of 174 "Authorize-Only" but lacking a State attribute MUST send a Disconnect 175 or CoA-NAK and SHOULD include an Error-Cause attribute with value 402 176 (Missing Attribute). 178 2.1.2. Request-ID Supplementation 180 [RFC3579] Section 2.6.1 states: 182 In EAP, each session has its own unique Identifier space. RADIUS 183 server implementations MUST be able to distinguish between EAP 184 packets with the same Identifier existing within distinct 185 sessions, originating on the same NAS. For this purpose, sessions 186 can be distinguished based on NAS and session identification 187 attributes. NAS identification attributes include NAS-Identifier, 188 NAS-IPv6-Address and NAS-IPv4-Address. Session identification 189 attributes include User-Name, NAS-Port, NAS-Port-Type, NAS-Port- 190 Id, Called-Station-Id, Calling-Station-Id and Originating-Line- 191 Info. 193 There are issues with the suggested algorithm. Since proxies may 194 translate Access-Request attributes such as NAS-IP-Address, depending 195 on any attribute under control of the NAS to distinguish request 196 identifiers can result in deployment problems. 198 The FreeRADIUS implementation does not track EAP identifiers by NAS- 199 IP-Address or other attributes sent by the NAS. Instead, it uses the 200 EAP identifier, source IP address, and the State attribute. Since the 201 State attribute is under the control of the RADIUS server, this means 202 that the uniqueness of each session is controlled by the server, not 203 the NAS. The algorithm used in FreeRADIUS is as follows: 205 if (EAP start, or EAP identity) { 206 allocate unique State Attribute 207 insert into "active" queue, with key (EAP identifier, State, source IP) 208 } else { 209 look up active session in queue, with above key 210 } 212 This algorithm appears to work well in variety of situations, 213 including situations where home servers receive messages via 214 intermediate RADIUS proxies. 216 2.2. Overload Conditions 218 2.2.1. Retransmission Behavior 220 [RFC2865] Section 2.4 describes the retransmission requirements for 221 RADIUS clients: 223 At one extreme, RADIUS does not require a "responsive" detection 224 of lost data. The user is willing to wait several seconds for the 225 authentication to complete. The generally aggressive TCP 226 retransmission (based on average round trip time) is not required, 227 nor is the acknowledgment overhead of TCP. 229 At the other extreme, the user is not willing to wait several 230 minutes for authentication. Therefore the reliable delivery of 231 TCP data two minutes later is not useful. The faster use of an 232 alternate server allows the user to gain access before giving up. 234 Some existing RADIUS clients implement excessively aggressive 235 retransmission behavior, utilizing default retransmission timeouts of 236 one second or less without support for congestive backoff. When 237 deployed at large scale, these implementations are susceptible to 238 congestive collapse. For example, as the result of a power failure, 239 a network with 3000 NAS devices with a fixed retransmission timer of 240 one second will continuously generate 3000 RADIUS Access-Requests per 241 second. This is sufficient to overwhelm most RADIUS servers. 243 Suggested solutions include: 245 [b] Jitter. To avoid synchronization, a RADIUS client SHOULD 246 incorporate jitter within its retransmission algorithm. 248 [a] Congestive backoff. While it is not necessary for RADIUS client 249 implementations to implement complex retransmission algorithms, 250 implementations SHOULD support congestive backoff within the limits 251 suggested by [RFC2865] Section 2.4. For example, an implementation 252 SHOULD double the initial retransmission timer until a maximum 253 retransmission time is reached, after which the client will 254 failover to another RADIUS server. For example, if the initial 255 retransmission timer is one second, a maximum retransmission timer 256 of 16 seconds might be used. 258 2.2.2. Server Response to Overload 260 Some RADIUS server implementations are not robust in response to 261 overload, dropping packets with even probability across multiple 262 sessions. In an overload situation, this results in a high failure 263 rate for multi-round authentication protocols such as EAP [RFC3579]. 264 Typically, users will continually retry in an attempt to gain access, 265 increasing the load even further. 267 A more sensible approach is for a RADIUS server to preferentially 268 accept RADIUS Access-Request packets containing a valid State 269 attribute, so that multi-round authentication conversations, once 270 begun, will be more likely to succeed. This will allow some users to 271 gain access to the network, reducing the load created by ongoing 272 access attempts. 274 2.3. Accounting Issues 276 2.3.1. Interim Update 278 [RFC2866] indicates that Acct-Input-Octets, Acct-Output-Octets, Acct- 279 Session-Time, Acct-Input-Packets, Acct-Output-Packets and Acct- 280 Terminate-Cause attributes "can only be present in Accounting-Request 281 records where the Acct-Status-Type is set to Stop." 283 However [RFC2869] Section 2.1 states: 285 It is envisioned that an Interim Accounting record (with Acct- 286 Status-Type = Interim-Update (3)) would contain all of the 287 attributes normally found in an Accounting Stop message with the 288 exception of the Acct-Term-Cause attribute. 290 Although [RFC2869] does not indicate that it updates [RFC2866], this 291 is an oversight, and the above attributes are allowable in an Interim 292 Accounting record. 294 2.3.2. Acct-Session-Id and Acct-Multi-Session-Id 296 [RFC2866] Section 5.5 describes Acct-Session-Id as Text within the 297 description, but also states that "The String field SHOULD be a 298 string of UTF-8 encoded 10646 characters." 300 Since Acct-Multi-Session-Id is consistently described as a String, it 301 appears that this is a typographical error, and that Acct-Session-Id 302 is of type String. 304 The implication is that a robust implementation SHOULD support the 305 String fields within Acct-Session-Id and Acct-Multi-Session-Id as 306 undistinguished octets. 308 2.3.3. Request Authenticator 310 [RFC2866] Section 4.1 states: 312 The Request Authenticator of an Accounting-Request contains a 313 16-octet MD5 hash value calculated according to the method 314 described in "Request Authenticator" above. 316 However, the text does not indicate any action to take when an 317 Accounting-Request packet contains an invalid Request Authenticator. 318 The following text should be considered to be part of the above 319 description: 321 The Request Authenticator field MUST contain the correct data, as 322 given by the above calculation. Invalid packets are silently 323 discarded. Note that some early implementations always set the 324 Request Authenticator to all zeros. New implementations of RADIUS 325 clients MUST use the above algorithm to calculate the Request 326 Authenticator field. New RADIUS server implementations MUST 327 silently discard invalid packets. 329 2.4. Multiple Filter-ID Attributes 331 [RFC2865] Section 5.11 states: 333 Zero or more Filter-Id attributes MAY be sent in an Access-Accept 334 packet. 336 In practice the behavior of a RADIUS client receiving multiple 337 Filter-ID attributes is implementation dependent. For example, some 338 implementations treat multiple instances of the Filter-ID attribute 339 as alternative filters; the first Filter-ID attribute having a name 340 matching a locally defined filter is used, and the remaining ones are 341 discarded. Other implementations may combine matching filters. 343 As a result, the interpretation of multiple Filter-ID attributes is 344 undefined within RADIUS. The sending of multiple Filter-ID 345 attributes within an Access-Accept SHOULD be avoided within 346 heterogeneous deployments and roaming scenarios, where it is likely 347 to produce unpredictable results. 349 2.5. Mandatory and Optional Attributes 351 RADIUS attributes do not explicitly state whether they are optional 352 or mandatory. Nevertheless there are instances where RADIUS 353 attributes need to be treated as mandatory. 355 [RFC2865] Section 1.1 states: 357 A NAS that does not implement a given service MUST NOT implement 358 the RADIUS attributes for that service. For example, a NAS that 359 is unable to offer ARAP service MUST NOT implement the RADIUS 360 attributes for ARAP. A NAS MUST treat a RADIUS access-accept 361 authorizing an unavailable service as an access-reject instead. 363 With respect to the Service-Type attribute, [RFC2865] Section 5.6 364 says: 366 This Attribute indicates the type of service the user has 367 requested, or the type of service to be provided. It MAY be used 368 in both Access-Request and Access-Accept packets. A NAS is not 369 required to implement all of these service types, and MUST treat 370 unknown or unsupported Service-Types as though an Access-Reject 371 had been received instead. 373 [RFC2865] Section 5 states: 375 A RADIUS server MAY ignore Attributes with an unknown Type. 376 A RADIUS client MAY ignore Attributes with an unknown Type. 378 With respect to Vendor-Specific Attributes (VSAs), [RFC2865] Section 379 5.26 states: 381 Servers not equipped to interpret the vendor-specific information 382 sent by a client MUST ignore it (although it may be reported). 383 Clients which do not receive desired vendor-specific information 384 SHOULD make an attempt to operate without it, although they may do 385 so (and report they are doing so) in a degraded mode. 387 It is possible for either a standard attribute or VSA to represent a 388 request for an unavailable service. However, where the Type or 389 Vendor-ID is unknown, a RADIUS client will not know whether the 390 attribute defines a service or not. 392 In general, it is best for RADIUS clients to err on the side of 393 caution. On receiving an Access-Accept including an attribute of 394 unknown Type, a RADIUS client SHOULD assume that it is a potential 395 service definition, and treat it as an Access-Reject. Unknown VSAs 396 SHOULD be ignored by RADIUS clients. 398 RADIUS authentication server implementations SHOULD ignore attributes 399 of unknown Type. Since RADIUS accounting server implementations 400 typically do not need to understand attributes in order to write them 401 to stable storage or pass them to the billing engine, accounting 402 server implementations SHOULD be equipped to handle unknown 403 attributes. 405 To avoid misinterpretation of service requests encoded within VSAs, 406 RADIUS servers SHOULD NOT send VSAs containing service requests to 407 RADIUS clients that are not known to understand them. For example, a 408 RADIUS server should not send a VSA encoding a filter without 409 knowledge that the RADIUS client supports the VSA. 411 2.6. Interpretation of Access-Reject 413 2.6.1. Improper Use of Access-Reject 415 The intent of an Access-Reject is to deny access to the requested 416 service. [RFC2865] Section 2 states: 418 If any condition is not met, the RADIUS server sends an "Access- 419 Reject" response indicating that this user request is invalid. If 420 desired, the server MAY include a text message in the Access- 421 Reject which MAY be displayed by the client to the user. No other 422 Attributes (except Proxy-State) are permitted in an Access-Reject. 424 This text makes it clear that RADIUS does not allow the provisioning 425 of services within an Access-Reject. If the desire is to allow 426 limited access, then an Access-Accept can be sent with attributes 427 provisioning limited access. Attributes within an Access-Reject are 428 restricted to those necessary to route the message (e.g. Proxy- 429 State), attributes providing the user with an indication that access 430 has been denied (e.g. an EAP-Message attribute containing an EAP- 431 Failure) or attributes conveying an error message (e.g. a Reply- 432 Message or Error-Cause attribute). 434 Unfortunately, there are examples where this requirement has been 435 misunderstood. [RFC2869] Section 2.2 states: 437 If that authentication fails, the RADIUS server should return an 438 Access-Reject packet to the NAS, with optional Password-Retry and 439 Reply-Messages attributes. The presence of Password-Retry 440 indicates the ARAP NAS MAY choose to initiate another challenge- 441 response cycle, 443 This paragraph is problematic from two perspectives. Firstly, a 444 Password-Retry attribute is being returned in an Access-Reject; this 445 attribute does not fit into the categories established in [RFC2865]. 447 Secondly, an Access-Reject packet is being sent in the context of a 448 continuing authentication conversation; [RFC2865] requires use of an 449 Access-Challenge for this. [RFC2869] uses the phrase "challenge- 450 response" to describe this use of Access-Reject, indicating that the 451 semantics of Access-Challenge are being used. 453 [RFC2865] Section 4.4, addresses the semantics of Access-Challenge 454 being equivalent to Access-Reject in some cases: 456 If the NAS does not support challenge/response, it MUST treat an 457 Access-Challenge as though it had received an Access-Reject 458 instead. 460 While it is difficult to correct existing deployments of [RFC2869], 461 we make the following recommendations: 463 [1] New RADIUS specifications and implementations MUST NOT use Access- 464 Reject where the semantics of Access-Challenge are intended. 466 [2] Access-Reject MUST mean denial of access to the requested service. 467 In response to an Access-Reject, the NAS MUST NOT send any 468 additional Access-Request packets for that user session. 470 [3] New deployments of ARAP [RFC2869] SHOULD use Access-Challenge 471 instead of Access-Reject packets in the conversations described in 472 [RFC2869] Section 2.2. 474 We also note that the table of attributes [RFC2869] Section 5.19 has 475 an error for the Password-Retry attribute. It says: 477 Request Accept Reject Challenge # Attribute 478 0 0 0-1 0 75 Password-Retry 480 However, the text in [RFC2869] Section 2.3.2 says that Password-Retry 481 can be included within an Access-Challenge packet, for EAP 482 authentication sessions. We recommend a correction to the table: 484 Request Accept Reject Challenge # Attribute 485 0 0 0 0-1 75 Password-Retry [Note 2] 487 [Note 2] As per RFC 3579, the use of the Password-Retry in EAP 488 authentications is deprecated. The Password-Retry attribute can be 489 used only for ARAP authentication. 491 2.6.2. Service Request Denial 493 RADIUS has been deployed for purposes outside network access 494 authentication, authorization and accounting. For example, RADIUS 495 has been deployed as a "back-end" for authenticating VOIP connections 496 [digest], HTTP sessions [apache], FTP sessions [proftpd], and machine 497 logins for multiple operating systems [bsdi, pam, gina]. In those 498 contexts, an Access-Reject sent to the RADIUS client MUST be 499 interpreted as a rejection of the request for service, and the RADIUS 500 client MUST NOT offer that service to the user. 502 For example, when an authentication failure occurs in the context of 503 an FTP session, the normal semantics for rejecting FTP services 504 apply. The rejection does not necessarily cause the FTP server to 505 terminate the underlying TCP connection, but the FTP server MUST NOT 506 offer any services protected by user authentication. 508 Users may request multiple services from the NAS. Where those 509 services are independent, the deployment MUST treat the RADIUS 510 sessions as being independent. 512 For example, a NAS may offer multi-link services, where a user may 513 have multiple simultaneous network connections. In that case, an 514 Access-Reject for a later multi-link connection request does not 515 necessarily mean that earlier multi-link connections are torn down. 516 Similarly, if a NAS offers both dialup and VOIP services, the 517 rejection of a VOIP attempt does not mean that the dialup session is 518 torn down. 520 Where a NAS offers multiple services, confusion may result with 521 respect to interpretation of a Disconnect-Request [RFC3576]. In 522 order to prevent confusion a RADIUS Server SHOULD identify the 523 session that it desires to terminate as specifically as possible. 524 For example, an Acct-Session-Id attribute SHOULD be included in 525 Disconnect-Request and CoA-Request packets, rather than just the 526 User-Name attribute. 528 2.7. Addressing 530 2.7.1. Link-Local Addresses 532 Since Link-Local addresses are unique only on the local link, if the 533 NAS and RADIUS server are not on the same link, then an IPv6 Link- 534 Local address [RFC2462] or an IPv4 Link-Local Address [RFC3927] 535 cannot be used to uniquely identify the NAS. A RADIUS server 536 receiving a NAS-IPv6-Address or NAS-IP-Address attribute containing a 537 Link-Local address SHOULD NOT count such an attribute toward 538 satisfying the requirements of [RFC3162] Section 2.1: 540 NAS-IPv6-Address and/or NAS-IP-Address MAY be present in an 541 Access-Request packet; however, if neither attribute is present 542 then NAS-Identifier MUST be present. 544 2.7.2. Multiple Addresses 546 There are situations in which a RADIUS client or server may have 547 multiple addresses. For example, a dual stack host can have both 548 IPv4 and IPv6 addresses; a host that is a member of multiple VLANs 549 could have IPv4 and/or IPv6 addresses on each VLAN; a host can have 550 multiple IPv4 or IPv6 addresses on a single interface. However, 551 [RFC2865] Section 5.44 only permits zero or one NAS-IP-Address 552 attribute within an Access-Request and [RFC3162] Section 3 only 553 permits zero or one NAS-IPv6-Address attribute within an Access- 554 Request. When a NAS has more than one global address and no ability 555 to determine which is used for identification in a particular 556 request, it is RECOMMENDED that the NAS include the NAS-Identifier 557 attribute in an Access-Request in order to identify itself to the 558 RADIUS server. 560 [RFC2865] Section 3 states: 562 A RADIUS server MUST use the source IP address of the RADIUS 563 UDP packet to decide which shared secret to use, so that 564 RADIUS requests can be proxied. 566 Therefore if a RADIUS client sends packets from more than one source 567 address, a shared secret will need to be configured on both the 568 client and server for each source address. 570 2.8. Idle-Timeout 572 With respect to the Idle-Timeout attribute, [RFC2865] Section 5.28 573 states: 575 This Attribute sets the maximum number of consecutive seconds of 576 idle connection allowed to the user before termination of the 577 session or prompt. This Attribute is available to be sent by the 578 server to the client in an Access-Accept or Access-Challenge. 580 [RFC3580] Section 3.12 states: 582 The Idle-Timeout attribute is described in [RFC2865]. For IEEE 583 802 media other than 802.11 the media are always on. As a result 584 the Idle-Timeout attribute is typically only used with wireless 585 media such as IEEE 802.11. It is possible for a wireless device 586 to wander out of range of all Access Points. In this case, the 587 Idle-Timeout attribute indicates the maximum time that a wireless 588 device may remain idle. 590 In the above paragraphs "idle" may not necessarily mean "no traffic"; 591 the NAS may support filters defining what traffic is included in the 592 idle time determination. As a result, an "idle connection" is 593 defined by local policy in the absence of other attributes. 595 2.9. Calculation of Message-Authenticator 597 [RFC3579] Section 3.3 indicates that the Message-Authenticator 598 attribute may be included in Access-Request, Accept, Reject and 599 Challenge packets, and [RFC3579] Section 3.2 describes how the 600 Message-Authenticator attribute is calculated for these packets: 602 When present in an Access-Request packet, Message-Authenticator is 603 an HMAC-MD5 [RFC2104] checksum of the entire Access-Request 604 packet, including Type, ID, Length and authenticator, using the 605 shared secret as the key, as follows. 607 Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, 608 Request Authenticator, Attributes) 610 When the message integrity check is calculated the signature 611 string should be considered to be sixteen octets of zero. 613 For Access-Challenge, Access-Accept, and Access-Reject packets, 614 the Message-Authenticator is calculated as follows, using the 615 Request-Authenticator from the Access-Request this packet is in 616 reply to: 618 Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, 619 Request Authenticator, Attributes) 621 When the message integrity check is calculated the signature 622 string should be considered to be sixteen octets of zero. The 623 shared secret is used as the key for the HMAC-MD5 message 624 integrity check. The is calculated and inserted in the packet 625 before the Response Authenticator is calculated. 627 [RFC3576] Section 3.2 indicates that a Message-Authenticator 628 attribute may be included within a Disconnect or CoA-Request, ACK or 629 NAK. However [RFC3579] does not describe how a Message-Authenticator 630 attribute is calculated for these RADIUS packets, or for Accounting- 631 Request or Response packets. 633 The algorithm described in [RFC3579] Section 3.2 cannot be applied 634 because in a Disconnect, CoA or Accounting-Request packet the Request 635 Authenticator is not a nonce, but rather represents a keyed MD5 hash 636 over the packet. This creates a circular dependency -- the Request 637 Authenticator depends on Message-Authenticator and Message- 638 Authenticator depends on the Response Authenticator. 640 As a result, in Accounting, CoA or Disconnect-Request or Response 641 packets the Message-Authenticator attribute is calculated as follows: 643 Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, 644 Authenticator, Attributes) 646 When the HMAC-MD5 hash is calculated the Authenticator field and 647 Message-Authenticator attribute should be considered to be sixteen 648 octets of zero. The Message-Authenticator is calculated and 649 inserted in the packet before the Authenticator is calculated. 651 2.10. Unknown Identity 653 [RFC3748] Section 5.1 states: 655 If the Identity is unknown, the Identity Response field 656 should be zero bytes in length. 658 However, [RFC2865] Section 5.1 describes the User-Name attribute as 659 follows: 661 The String field is one or more octets. 663 How should the RADIUS client behave if it receives an EAP- 664 Response/Identity that is zero octets in length? 666 [RFC2865] Section 5.1 states: 668 This Attribute indicates the name of the user to be authenticated. 669 It MUST be sent in Access-Request packets if available. 671 This suggests that the User-Name attribute may be ommitted if it is 672 unavailable. 674 However, [RFC3579] Section 2.1 states: 676 In order to permit non-EAP aware RADIUS proxies to forward the 677 Access-Request packet, if the NAS initially sends an 678 EAP-Request/Identity message to the peer, the NAS MUST copy the 679 contents of the Type-Data field of the EAP-Response/Identity received 680 from the peer into the User-Name attribute and MUST include the 681 Type-Data field of the EAP-Response/Identity in the User-Name 682 attribute in every subsequent Access-Request. 684 This suggests that the User-Name attribute should contain the 685 contents of the Type-Data field of the EAP-Response/Identity, even if 686 it is zero octets in length. 688 Note that [RFC4282] does not permit an NAI of zero octets, so that an 689 EAP-Response/Identity with a Type-Data field of zero octets MUST NOT 690 be construed as a request for privacy (e.g. anonymous NAI). 692 When a NAS receives an EAP-Response/Identity with a Type-Data field 693 that is zero octets in length, it is RECOMMENDED that it either omit 694 a User-Name attribute in the Access-Request or include the Calling- 695 Station-Id in the User-Name attribute, along with a Calling-Station- 696 Id attribute. 698 3. IANA Considerations 700 This specification does not create any new registries, nor does it 701 require assignment of any protocol parameters. 703 4. Security Considerations 705 Since this document describes the use of RADIUS for purposes of 706 authentication, authorization, and accounting in WLANs, it is 707 vulnerable to all of the threats that are present in other RADIUS 708 applications. For a discussion of these threats, see [RFC2865], [RFC 709 2607], [RFC3162], [RFC3576], [RFC3579], and [RFC3580]. 711 5. References 713 5.1. Informative references 715 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 716 Requirement Levels", RFC 2119, March, 1997. 718 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 719 Autoconfiguration", RFC 2462, December 1998. 721 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 722 Implementation in Roaming", RFC 2607, June 1999. 724 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 725 Authentication Dial In User Service (RADIUS)", RFC 2865, June 726 2000. 728 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 730 [RFC2867] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting 731 Modifications for Tunnel Protocol Support", RFC 2867, June 732 2000. 734 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. 735 and I. Goyret, "RADIUS Attributes for Tunnel Protocol 736 Support", RFC 2868, June 2000. 738 [RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", 739 RFC 2869, June 2000. 741 [RFC2882] Mitton, D., "Network Access Servers Requirements: Extended 742 RADIUS Practices", RFC 2882, July 2000. 744 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 745 3162, August 2001. 747 [RFC3575] Aboba, B., "IANA Considerations for RADIUS", RFC 3575, July 748 2003. 750 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, 751 "Dynamic Authorization Extensions to Remote Authentication 752 Dial In User Service (RADIUS)", RFC 3576, July 2003. 754 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 755 Authentication Protocol (EAP)", RFC 3579, September 2003. 757 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 758 "IEEE 802.1X Remote Authentication Dial In User Service 759 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 761 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 762 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 763 3748, June 2004. 765 [RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration 766 of IPv4 Link-Local Addresses", RFC 3927, May 2005. 768 [RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Network 769 Access Identifier", RFC 4282, December 2005. 771 Acknowledgments 773 The authors would like to acknowledge Glen Zorn for contributions to 774 this document. 776 Authors' Addresses 778 David B. Nelson 779 Enterasys Networks 780 50 Minuteman Road 781 Andover, MA 01810 783 EMail: dnelson@enterasys.com 784 Alan DeKok 785 Infoblox, Inc. 786 475 Potrero Ave 787 Sunnyvale, CA 94087 789 Email: adekok@infoblox.com 790 Phone: +1 408 716 4386 791 Fax: +1 408 716 4400 793 Bernard Aboba 794 Microsoft Corporation 795 One Microsoft Way 796 Redmond, WA 98052 798 EMail: bernarda@microsoft.com 799 Phone: +1 425 706 6605 800 Fax: +1 425 936 7329 802 Intellectual Property Statement 804 The IETF takes no position regarding the validity or scope of any 805 Intellectual Property Rights or other rights that might be claimed to 806 pertain to the implementation or use of the technology described in 807 this document or the extent to which any license under such rights 808 might or might not be available; nor does it represent that it has 809 made any independent effort to identify any such rights. Information 810 on the procedures with respect to rights in RFC documents can be 811 found in BCP 78 and BCP 79. 813 Copies of IPR disclosures made to the IETF Secretariat and any 814 assurances of licenses to be made available, or the result of an 815 attempt made to obtain a general license or permission for the use of 816 such proprietary rights by implementers or users of this 817 specification can be obtained from the IETF on-line IPR repository at 818 http://www.ietf.org/ipr. 820 The IETF invites any interested party to bring to its attention any 821 copyrights, patents or patent applications, or other proprietary 822 rights that may cover technology that may be required to implement 823 this standard. Please address the information to the IETF at ietf- 824 ipr@ietf.org. 826 Disclaimer of Validity 828 This document and the information contained herein are provided on an 829 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 830 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 831 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 832 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 833 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 834 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 836 Copyright Statement 838 Copyright (C) The Internet Society (2006). This document is subject 839 to the rights, licenses and restrictions contained in BCP 78, and 840 except as set forth therein, the authors retain all their rights. 842 Acknowledgment 844 Funding for the RFC Editor function is currently provided by the 845 Internet Society. 847 Open issues 849 Open issues relating to this specification are tracked on the 850 following web site: 852 http://www.drizzle.com/~aboba/RADEXT/