idnits 2.17.1 draft-ietf-radext-fixes-01.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, updated by RFC 4748 on line 942. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 919. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 926. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 932. 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. -- 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 IETF Trust Copyright Line does not match the current year (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.) -- The document date (13 February 2007) is 6281 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) -- Missing reference section? 'RFC2119' on line 852 looks like a reference -- Missing reference section? 'RFC2865' on line 830 looks like a reference -- Missing reference section? 'RFC3579' on line 889 looks like a reference -- Missing reference section? 'RFC2866' on line 834 looks like a reference -- Missing reference section? 'RFC2869' on line 837 looks like a reference -- Missing reference section? 'RFC2618' on line 861 looks like a reference -- Missing reference section? 'RFC4668' on line 881 looks like a reference -- Missing reference section? '1' on line 552 looks like a reference -- Missing reference section? '2' on line 555 looks like a reference -- Missing reference section? '3' on line 559 looks like a reference -- Missing reference section? 'Note 2' on line 576 looks like a reference -- Missing reference section? 'RFC3576' on line 841 looks like a reference -- Missing reference section? 'RFC2462' on line 855 looks like a reference -- Missing reference section? 'RFC3927' on line 875 looks like a reference -- Missing reference section? 'RFC3162' on line 864 looks like a reference -- Missing reference section? 'RFC3580' on line 867 looks like a reference -- Missing reference section? 'RFC3748' on line 871 looks like a reference -- Missing reference section? 'RFC4282' on line 878 looks like a reference -- Missing reference section? 'RFC2607' on line 858 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 31 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group David Nelson 3 INTERNET-DRAFT Individual contributor 4 Updates: 2865, 2866, 2869, 3576, 3579 Alan DeKok 5 Category: Proposed Standard FreeRADIUS 6 7 13 February 2007 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 August 14, 2007. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 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 ............................................. 2 47 1.1. Terminology ......................................... 2 48 1.2. Requirements Language ............................... 2 49 2. Issues ................................................... 3 50 2.1. Session Definition .................................. 3 51 2.1.1. State Attribute ................................ 3 52 2.1.2. Request-ID Supplementation ..................... 4 53 2.2. Overload Conditions ................................. 4 54 2.2.1. Retransmission Behavior ........................ 4 55 2.2.2. Server Response to Overload .................... 5 56 2.3. Accounting Issues ................................... 6 57 2.3.1. Attributes allowed in an Interim Update ........ 6 58 2.3.2. Acct-Session-Id and Acct-Multi-Session-Id ...... 6 59 2.3.3. Request Authenticator .......................... 6 60 2.3.4. Interim-Accounting-Interval .................... 7 61 2.3.5. Counter values in the RADIUS MIBs .............. 7 62 2.4. Multiple Filter-ID Attributes ....................... 9 63 2.5. Mandatory and Optional Attributes ................... 9 64 2.6. Interpretation of Access-Reject ..................... 11 65 2.6.1. Improper Use of Access-Reject .................. 11 66 2.6.2. Service Request Denial ......................... 12 67 2.7. Addressing .......................................... 13 68 2.7.1. Link-Local Addresses ........................... 13 69 2.7.2. Multiple Addresses ............................. 13 70 2.8. Idle-Timeout ........................................ 14 71 2.9. Unknown Identity .................................... 14 72 2.10. Responses after retransmissions .................... 15 73 2.11. Framed-IPv6-Prefix ................................. 16 74 3. IANA Considerations ...................................... 17 75 4. Security Considerations .................................. 17 76 5. References ............................................... 17 77 5.1. Normative references. ............................... 17 78 5.2. Informative references. ............................. 18 79 Intellectual Property Statement .............................. 19 80 Disclaimer of Validity ....................................... 21 81 Full Copyright Statement ..................................... 21 82 1. Introduction 84 The last few years have seen an increase in the deployment of RADIUS 85 clients and servers. This document describes common issues seen in 86 RADIUS implementations and suggests some fixes. Where applicable, 87 ambiguities and errors in previous RADIUS specifications are 88 clarified. 90 1.1. Terminology 92 This document uses the following terms: 94 Network Access Server (NAS) 95 The device providing access to the network. Also known as the 96 Authenticator (IEEE 802.1X or EAP terminology) or RADIUS client. 98 service 99 The NAS provides a service to the user, such as network access via 100 802.11 or PPP. 102 session 103 Each service provided by the NAS to a peer constitutes a session, 104 with the beginning of the session defined as the point where 105 service is first provided and the end of the session defined as the 106 point where service is ended. A peer may have multiple sessions in 107 parallel or series if the NAS supports that, with each session 108 generating a separate start and stop accounting record. 110 silently discard 111 This means the implementation discards the packet without further 112 processing. The implementation SHOULD provide the capability of 113 logging the error, including the contents of the silently discarded 114 packet, and SHOULD record the event in a statistics counter. 116 1.2. Requirements Language 118 In this document, several words are used to signify the requirements 119 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 120 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 121 and "OPTIONAL" in this document are to be interpreted as described in 122 [RFC2119]. 124 2. Issues 126 2.1. Session Definition 128 2.1.1. State Attribute 130 Regarding the State attribute, [RFC2865] Section 5.24 states: 132 This Attribute is available to be sent by the server to the client 133 in an Access-Challenge and MUST be sent unmodified from the client 134 to the server in the new Access-Request reply to that challenge, 135 if any. 137 This Attribute is available to be sent by the server to the client 138 in an Access-Accept that also includes a Termination-Action 139 Attribute with the value of RADIUS-Request. If the NAS performs 140 the Termination-Action by sending a new Access-Request upon 141 termination of the current session, it MUST include the State 142 attribute unchanged in that Access-Request. 144 Some RADIUS client implementations do not properly use the State 145 attribute in order to distinguish a restarted EAP authentication 146 process from the continuation of an ongoing process (by the same user 147 on the same NAS and port). 149 Where an EAP-Message attribute is included in an Access-Challenge or 150 Access-Accept attribute, RADIUS servers SHOULD also include a State 151 attribute. See the following section for additional benefits to 152 using the State attribute in this fashion. 154 An Access-Request sent as a result of a new or restarted 155 authentication run MUST NOT include the State attribute, even if the 156 State attribute has previously been received in an Access-Challenge 157 for the same user and port. 159 Since a State attribute is always initially provided by the server in 160 an Access-Accept, Access-Challenge, CoA-Request or Disconnect- 161 Request, a RADIUS client MUST NOT insert a State attribute that it 162 has not previously received from the server. 164 A State attribute is REQUIRED in Access-Request packets neither 165 including an authentication attribute nor a Service-Type attribute 166 with the value Call Check (10). 168 2.1.2. Request-ID Supplementation 170 [RFC3579] Section 2.6.1 states: 172 In EAP, each session has its own unique Identifier space. RADIUS 173 server implementations MUST be able to distinguish between EAP 174 packets with the same Identifier existing within distinct 175 sessions, originating on the same NAS. For this purpose, sessions 176 can be distinguished based on NAS and session identification 177 attributes. NAS identification attributes include NAS-Identifier, 178 NAS-IPv6-Address and NAS-IPv4-Address. Session identification 179 attributes include User-Name, NAS-Port, NAS-Port-Type, NAS-Port- 180 Id, Called-Station-Id, Calling-Station-Id and Originating-Line- 181 Info. 183 There are issues with the suggested algorithm. Since proxies may 184 modify Access-Request attributes such as NAS-IP-Address, depending on 185 any attribute under control of the NAS to distinguish request 186 identifiers can result in deployment problems. 188 The FreeRADIUS implementation does not track EAP identifiers by NAS- 189 IP-Address or other non-EAP attributes sent by the NAS. Instead, it 190 uses the EAP identifier, source IP address, and the State attribute 191 as a "key" to uniquely identify each EAP session. Since the State 192 attribute is under the control of the RADIUS server, this means that 193 the uniqueness of each session is controlled by the server, not the 194 NAS. The algorithm used in FreeRADIUS is as follows: 196 if (EAP start, or EAP identity) { 197 allocate unique State Attribute 198 insert session into "active session" table with 199 key=(EAP identifier, State, source IP) 200 } else { 201 look up active session in table, with above key 202 } 204 This algorithm appears to work well in variety of situations, 205 including situations where home servers receive messages via 206 intermediate RADIUS proxies. 208 2.2. Overload Conditions 210 2.2.1. Retransmission Behavior 212 [RFC2865] Section 2.4 describes the retransmission requirements for 213 RADIUS clients: 215 At one extreme, RADIUS does not require a "responsive" detection 216 of lost data. The user is willing to wait several seconds for the 217 authentication to complete. The generally aggressive TCP 218 retransmission (based on average round trip time) is not required, 219 nor is the acknowledgment overhead of TCP. 221 At the other extreme, the user is not willing to wait several 222 minutes for authentication. Therefore the reliable delivery of 223 TCP data two minutes later is not useful. The faster use of an 224 alternate server allows the user to gain access before giving up. 226 Some existing RADIUS clients implement excessively aggressive 227 retransmission behavior, utilizing default retransmission timeouts of 228 one second or less without support for congestive backoff. When 229 deployed at large scale, these implementations are susceptible to 230 congestive collapse. For example, as the result of a power failure, 231 a network with 3000 NAS devices with a fixed retransmission timer of 232 one second will continuously generate 3000 RADIUS Access-Requests per 233 second. This is sufficient to overwhelm most RADIUS servers. 235 Suggested solutions include: 237 [a] Jitter. To avoid synchronization, a RADIUS client SHOULD 238 incorporate jitter within its retransmission algorithm. 240 [b] Congestive backoff. While it is not necessary for RADIUS client 241 implementations to implement complex retransmission algorithms, 242 implementations SHOULD support congestive backoff within the limits 243 suggested by [RFC2865] Section 2.4. For example, an implementation 244 SHOULD double the initial retransmission timer until a maximum 245 retransmission time is reached, after which the client will 246 failover to another RADIUS server. For example, if the initial 247 retransmission timer is one second, a maximum retransmission timer 248 of 16 seconds might be used. 250 2.2.2. Server Response to Overload 252 Some RADIUS server implementations are not robust in response to 253 overload, dropping packets with even probability across multiple 254 sessions. In an overload situation, this results in a high failure 255 rate for multi-round authentication protocols such as EAP [RFC3579]. 256 Typically, users will continually retry in an attempt to gain access, 257 increasing the load even further. 259 A more sensible approach is for a RADIUS server to preferentially 260 accept RADIUS Access-Request packets containing a valid State 261 attribute, so that multi-round authentication conversations, once 262 begun, will be more likely to succeed. Similarly, a server that is 263 proxying requests should preferentially process Access-Accept, 264 Access-Challenge, or Access-Reject packets from home servers, before 265 processing new requests from a NAS. 267 These methods will allow some users to gain access to the network, 268 reducing the load created by ongoing access attempts. 270 2.3. Accounting Issues 272 2.3.1. Attributes allowed in an Interim Update 274 [RFC2866] indicates that Acct-Input-Octets, Acct-Output-Octets, Acct- 275 Session-Time, Acct-Input-Packets, Acct-Output-Packets and Acct- 276 Terminate-Cause attributes "can only be present in Accounting-Request 277 records where the Acct-Status-Type is set to Stop." 279 However [RFC2869] Section 2.1 states: 281 It is envisioned that an Interim Accounting record (with Acct- 282 Status-Type = Interim-Update (3)) would contain all of the 283 attributes normally found in an Accounting Stop message with the 284 exception of the Acct-Term-Cause attribute. 286 Although [RFC2869] does not indicate that it updates [RFC2866], this 287 is an oversight, and the above attributes are allowable in an Interim 288 Accounting record. 290 2.3.2. Acct-Session-Id and Acct-Multi-Session-Id 292 [RFC2866] Section 5.5 describes Acct-Session-Id as Text within the 293 description, but also states that "The String field SHOULD be a 294 string of UTF-8 encoded 10646 characters." 296 Since Acct-Multi-Session-Id is consistently described as a String, it 297 appears that this is a typographical error, and that Acct-Session-Id 298 is of type String. 300 The implication is that a robust implementation SHOULD support the 301 String fields within Acct-Session-Id and Acct-Multi-Session-Id as 302 undistinguished octets. 304 2.3.3. Request Authenticator 306 [RFC2866] Section 4.1 states: 308 The Request Authenticator of an Accounting-Request contains a 309 16-octet MD5 hash value calculated according to the method 310 described in "Request Authenticator" above. 312 However, the text does not indicate any action to take when an 313 Accounting-Request packet contains an invalid Request Authenticator. 314 The following text should be considered to be part of the above 315 description: 317 The Request Authenticator field MUST contain the correct data, as 318 given by the above calculation. Invalid packets are silently 319 discarded. Note that some early implementations always set the 320 Request Authenticator to all zeros. New implementations of RADIUS 321 clients MUST use the above algorithm to calculate the Request 322 Authenticator field. New RADIUS server implementations MUST 323 silently discard invalid packets. 325 2.3.4. Interim-Accounting-Interval 327 [RFC2869] Section 2.1 states: 329 It is also possible to statically configure an interim value on 330 the NAS itself. Note that a locally configured value on the NAS 331 MUST override the value found in an Access-Accept. 333 This requirement may be phrased too strongly. It is conceivable that 334 a NAS implementation has a setting for a "minimum" value of Interim- 335 Accounting-Interval, based on resource constraints in the NAS, and 336 network loading in the local environment of the NAS. In such cases, 337 the value administratively provisioned in the NAS should not be over- 338 ridden by a smaller value from an Access-Accept message. The NAS's 339 value could be over-ridden by a larger one, however. The intent is 340 that the NAS sends accounting information at fixed intervals, short 341 enough such that the potential loss of billable revenue is limited, 342 but also that the accounting updates are infrequent enough such that 343 the NAS, network, and RADIUS server are not overloaded. 345 2.3.5. Counter values in the RADIUS MIBs 347 The RADIUS Authentication and Authorization Client MIB module 348 [RFC2618], [RFC4668] includes counters of packet statistics. In the 349 descriptive text of the MIB module, formulas are provided for certain 350 counter objects. Implementors have noted apparent inconsistencies in 351 the formulas, which could result in negative values. 353 Since the original MIB module specified in [RFC2618] had been widely 354 implemented, the RADEXT WG chose not to change the object definitions 355 or to create new ones within the revised MIB module [RFC4668]. 356 However, this section explains the issues and provides guidance for 357 implementors regarding the interpretation of the textual description 358 and comments for certain MIB objects. 360 The issues raised can be summarized as follows: 362 Issue (1): 364 -- TotalIncomingPackets = Accepts + Rejects + Challenges + 365 UnknownTypes 366 -- 367 -- TotalIncomingPackets - MalformedResponses - BadAuthenticators - 368 -- UnknownTypes - PacketsDropped = Successfully received 369 -- 370 -- AccessRequests + PendingRequests + ClientTimeouts = 371 -- Successfully Received 373 It appears that the value of "Successfully Received" could be 374 negative, since various counters are subtracted from 375 TotalIncomingPackets that are not included in the calculation of 376 TotalIncomingPackets. 378 It also appears that "AccessRequests + PendingRequests + 379 ClientTimeouts = Successfully Received" should read "AccessRequests + 380 PendingRequests + ClientTimeouts = Successfully Transmitted". 382 "TotalIncomingPackets" and "Successfully Received" are temporary 383 variables, i.e. not objects within the MIB module. The comment text 384 in the MIB modules is intended, therefore, to aid in understanding. 385 What's of consequence is the consistency of values of the objects in 386 the MIB module, and that does not appear to be impacted by the 387 inconsistencies noted above. It does appear, however, that the 388 "Successfully Received" variable should be labeled "Successfully 389 Transmitted". 391 In addition, the definition of Accept, Reject or Challenge counters 392 indicates that they MUST be incremented before the message is 393 validated. If the message is invalid, one of MalformedResponses, 394 BadAuthenticators or PacketsDropped counters will be additionally 395 incremented. In that case the first two equations are consistent, 396 i.e. "Successfully Received" could not be negative. 398 Issue (2): 400 It appears that the radiusAuthClientPendingRequests counter is 401 decremented upon retransmission. That would mean a retransmitted 402 packet is not considered as being as pending, although such 403 retransmissions can still be considered as being pending requests. 405 The definition of this MIB object in [RFC2618] is as follows: 407 The number of RADIUS Access-Request packets destined for this 408 server that have not yet timed out or received a response. This 409 variable is incremented when an Access-Request is sent and 410 decremented due to receipt of an Access-Accept, Access-Reject or 411 Access-Challenge, a timeout or retransmission. 413 This object purports to count the number of pending request packets. 414 It is open to interpretation whether or not retransmissions of a 415 request are to be counted as additional pending packets. In either 416 event, it seems appropriate to treat retransmissions consistently 417 with respect to incrementing and decrementing this counter. 419 2.4. Multiple Filter-ID Attributes 421 [RFC2865] Section 5.11 states: 423 Zero or more Filter-Id attributes MAY be sent in an Access-Accept 424 packet. 426 In practice the behavior of a RADIUS client receiving multiple 427 Filter-ID attributes is implementation dependent. For example, some 428 implementations treat multiple instances of the Filter-ID attribute 429 as alternative filters; the first Filter-ID attribute having a name 430 matching a locally defined filter is used, and the remaining ones are 431 discarded. Other implementations may combine matching filters. 433 As a result, the interpretation of multiple Filter-ID attributes is 434 undefined within RADIUS. The sending of multiple Filter-ID 435 attributes within an Access-Accept SHOULD be avoided within 436 heterogeneous deployments and roaming scenarios, where it is likely 437 to produce unpredictable results. 439 2.5. Mandatory and Optional Attributes 441 RADIUS attributes do not explicitly state whether they are optional 442 or mandatory. Nevertheless there are instances where RADIUS 443 attributes need to be treated as mandatory. 445 [RFC2865] Section 1.1 states: 447 A NAS that does not implement a given service MUST NOT implement 448 the RADIUS attributes for that service. For example, a NAS that 449 is unable to offer ARAP service MUST NOT implement the RADIUS 450 attributes for ARAP. A NAS MUST treat a RADIUS access-accept 451 authorizing an unavailable service as an access-reject instead. 453 With respect to the Service-Type attribute, [RFC2865] Section 5.6 454 says: 456 This Attribute indicates the type of service the user has 457 requested, or the type of service to be provided. It MAY be used 458 in both Access-Request and Access-Accept packets. A NAS is not 459 required to implement all of these service types, and MUST treat 460 unknown or unsupported Service-Types as though an Access-Reject 461 had been received instead. 463 [RFC2865] Section 5 states: 465 A RADIUS server MAY ignore Attributes with an unknown Type. 466 A RADIUS client MAY ignore Attributes with an unknown Type. 468 With respect to Vendor-Specific Attributes (VSAs), [RFC2865] Section 469 5.26 states: 471 Servers not equipped to interpret the vendor-specific information 472 sent by a client MUST ignore it (although it may be reported). 473 Clients which do not receive desired vendor-specific information 474 SHOULD make an attempt to operate without it, although they may do 475 so (and report they are doing so) in a degraded mode. 477 It is possible for either a standard attribute or VSA to represent a 478 request for an unavailable service. However, where the Type or 479 Vendor-ID is unknown, a RADIUS client will not know whether the 480 attribute defines a service or not. 482 In general, it is best for RADIUS clients to err on the side of 483 caution. On receiving an Access-Accept including an attribute of 484 unknown Type, a RADIUS client SHOULD assume that it is a potential 485 service definition, and treat it as an Access-Reject. Unknown VSAs 486 SHOULD be ignored by RADIUS clients. 488 RADIUS authentication server implementations SHOULD ignore attributes 489 of unknown Type. Since RADIUS accounting server implementations 490 typically do not need to understand attributes in order to write them 491 to stable storage or pass them to the billing engine, accounting 492 server implementations SHOULD be equipped to handle unknown 493 attributes. 495 To avoid misinterpretation of service requests encoded within VSAs, 496 RADIUS servers SHOULD NOT send VSAs containing service requests to 497 RADIUS clients that are not known to understand them. For example, a 498 RADIUS server should not send a VSA encoding a filter without 499 knowledge that the RADIUS client supports the VSA. 501 2.6. Interpretation of Access-Reject 503 2.6.1. Improper Use of Access-Reject 505 The intent of an Access-Reject is to deny access to the requested 506 service. [RFC2865] Section 2 states: 508 If any condition is not met, the RADIUS server sends an "Access- 509 Reject" response indicating that this user request is invalid. If 510 desired, the server MAY include a text message in the Access- 511 Reject which MAY be displayed by the client to the user. No other 512 Attributes (except Proxy-State) are permitted in an Access-Reject. 514 This text makes it clear that RADIUS does not allow the provisioning 515 of services within an Access-Reject. If the desire is to allow 516 limited access, then an Access-Accept can be sent with attributes 517 provisioning limited access. Attributes within an Access-Reject are 518 restricted to those necessary to route the message (e.g. Proxy- 519 State), attributes providing the user with an indication that access 520 has been denied (e.g. an EAP-Message attribute containing an EAP- 521 Failure) or attributes conveying an error message (e.g. a Reply- 522 Message or Error-Cause attribute). 524 Unfortunately, there are examples where this requirement has been 525 misunderstood. [RFC2869] Section 2.2 states: 527 If that authentication fails, the RADIUS server should return an 528 Access-Reject packet to the NAS, with optional Password-Retry and 529 Reply-Messages attributes. The presence of Password-Retry 530 indicates the ARAP NAS MAY choose to initiate another challenge- 531 response cycle, 533 This paragraph is problematic from two perspectives. Firstly, a 534 Password-Retry attribute is being returned in an Access-Reject; this 535 attribute does not fit into the categories established in [RFC2865]. 536 Secondly, an Access-Reject packet is being sent in the context of a 537 continuing authentication conversation; [RFC2865] requires use of an 538 Access-Challenge for this. [RFC2869] uses the phrase "challenge- 539 response" to describe this use of Access-Reject, indicating that the 540 semantics of Access-Challenge are being used. 542 [RFC2865] Section 4.4, addresses the semantics of Access-Challenge 543 being equivalent to Access-Reject in some cases: 545 If the NAS does not support challenge/response, it MUST treat an 546 Access-Challenge as though it had received an Access-Reject 547 instead. 549 While it is difficult to correct existing deployments of [RFC2869], 550 we make the following recommendations: 552 [1] New RADIUS specifications and implementations MUST NOT use Access- 553 Reject where the semantics of Access-Challenge are intended. 555 [2] Access-Reject MUST mean denial of access to the requested service. 556 In response to an Access-Reject, the NAS MUST NOT send any 557 additional Access-Request packets for that user session. 559 [3] New deployments of ARAP [RFC2869] SHOULD use Access-Challenge 560 instead of Access-Reject packets in the conversations described in 561 [RFC2869] Section 2.2. 563 We also note that the table of attributes [RFC2869] Section 5.19 has 564 an error for the Password-Retry attribute. It says: 566 Request Accept Reject Challenge # Attribute 567 0 0 0-1 0 75 Password-Retry 569 However, the text in [RFC2869] Section 2.3.2 says that Password-Retry 570 can be included within an Access-Challenge packet, for EAP 571 authentication sessions. We recommend a correction to the table: 573 Request Accept Reject Challenge # Attribute 574 0 0 0 0-1 75 Password-Retry [Note 2] 576 [Note 2] As per RFC 3579, the use of the Password-Retry in EAP 577 authentications is deprecated. The Password-Retry attribute can be 578 used only for ARAP authentication. 580 2.6.2. Service Request Denial 582 RADIUS has been deployed for purposes outside network access 583 authentication, authorization and accounting. For example, RADIUS 584 has been deployed as a "back-end" for authenticating Voice Over IP 585 (VOIP) connections, HTTP sessions (e.g. Apache), FTP sessions (e.g. 586 proftpd), and machine logins for multiple operating systems (e.g. 587 bsdi, pam, gina). In those contexts, an Access-Reject sent to the 588 RADIUS client MUST be interpreted as a rejection of the request for 589 service, and the RADIUS client MUST NOT offer that service to the 590 user. 592 For example, when an authentication failure occurs in the context of 593 an FTP session, the normal semantics for rejecting FTP services 594 apply. The rejection does not necessarily cause the FTP server to 595 terminate the underlying TCP connection, but the FTP server MUST NOT 596 offer any services protected by user authentication. 598 Users may request multiple services from the NAS. Where those 599 services are independent, the deployment MUST treat the RADIUS 600 sessions as being independent. 602 For example, a NAS may offer multi-link services, where a user may 603 have multiple simultaneous network connections. In that case, an 604 Access-Reject for a later multi-link connection request does not 605 necessarily mean that earlier multi-link connections are torn down. 606 Similarly, if a NAS offers both dialup and VOIP services, the 607 rejection of a VOIP attempt does not mean that the dialup session is 608 torn down. 610 Where a NAS offers multiple services, confusion may result with 611 respect to interpretation of a Disconnect-Request [RFC3576]. In 612 order to prevent confusion a RADIUS Server SHOULD identify the 613 session that it desires to terminate as specifically as possible. 614 For example, an Acct-Session-Id attribute SHOULD be included in 615 Disconnect-Request and CoA-Request packets, rather than just the 616 User-Name attribute. 618 2.7. Addressing 620 2.7.1. Link-Local Addresses 622 Since Link-Local addresses are unique only on the local link, if the 623 NAS and RADIUS server are not on the same link, then an IPv6 Link- 624 Local address [RFC2462] or an IPv4 Link-Local Address [RFC3927] 625 cannot be used to uniquely identify the NAS. A NAS SHOULD NOT 626 utilize a link-scope address within a NAS-IPv6-Address or NAS-IP- 627 Address attributes. A RADIUS server receiving a NAS-IPv6-Address or 628 NAS-IP-Address attribute containing a Link-Local address SHOULD NOT 629 count such an attribute toward satisfying the requirements of 630 [RFC3162] Section 2.1: 632 NAS-IPv6-Address and/or NAS-IP-Address MAY be present in an 633 Access-Request packet; however, if neither attribute is present 634 then NAS-Identifier MUST be present. 636 2.7.2. Multiple Addresses 638 There are situations in which a RADIUS client or server may have 639 multiple addresses. For example, a dual stack host can have both 640 IPv4 and IPv6 addresses; a host that is a member of multiple VLANs 641 could have IPv4 and/or IPv6 addresses on each VLAN; a host can have 642 multiple IPv4 or IPv6 addresses on a single interface. However, 643 [RFC2865] Section 5.44 only permits zero or one NAS-IP-Address 644 attribute within an Access-Request and [RFC3162] Section 3 only 645 permits zero or one NAS-IPv6-Address attribute within an Access- 646 Request. When a NAS has more than one global address and no ability 647 to determine which is used for identification in a particular 648 request, it is RECOMMENDED that the NAS include the NAS-Identifier 649 attribute in an Access-Request in order to identify itself to the 650 RADIUS server. 652 [RFC2865] Section 3 states: 654 A RADIUS server MUST use the source IP address of the RADIUS 655 UDP packet to decide which shared secret to use, so that 656 RADIUS requests can be proxied. 658 Therefore if a RADIUS client sends packets from more than one source 659 address, a shared secret will need to be configured on both the 660 client and server for each source address. 662 2.8. Idle-Timeout 664 With respect to the Idle-Timeout attribute, [RFC2865] Section 5.28 665 states: 667 This Attribute sets the maximum number of consecutive seconds of 668 idle connection allowed to the user before termination of the 669 session or prompt. This Attribute is available to be sent by the 670 server to the client in an Access-Accept or Access-Challenge. 672 [RFC3580] Section 3.12 states: 674 The Idle-Timeout attribute is described in [RFC2865]. For IEEE 675 802 media other than 802.11 the media are always on. As a result 676 the Idle-Timeout attribute is typically only used with wireless 677 media such as IEEE 802.11. It is possible for a wireless device 678 to wander out of range of all Access Points. In this case, the 679 Idle-Timeout attribute indicates the maximum time that a wireless 680 device may remain idle. 682 In the above paragraphs "idle" may not necessarily mean "no traffic"; 683 the NAS may support filters defining what traffic is included in the 684 idle time determination. As a result, an "idle connection" is 685 defined by local policy in the absence of other attributes. 687 2.9. Unknown Identity 689 [RFC3748] Section 5.1 states: 691 If the Identity is unknown, the Identity Response field 692 should be zero bytes in length. 694 However, [RFC2865] Section 5.1 describes the User-Name attribute as 695 follows: 697 The String field is one or more octets. 699 How should the RADIUS client behave if it receives an EAP- 700 Response/Identity that is zero octets in length? 702 [RFC2865] Section 5.1 states: 704 This Attribute indicates the name of the user to be authenticated. 705 It MUST be sent in Access-Request packets if available. 707 This suggests that the User-Name attribute may be ommitted if it is 708 unavailable. 710 However, [RFC3579] Section 2.1 states: 712 In order to permit non-EAP aware RADIUS proxies to forward the 713 Access-Request packet, if the NAS initially sends an 714 EAP-Request/Identity message to the peer, the NAS MUST copy the 715 contents of the Type-Data field of the EAP-Response/Identity 716 received from the peer into the User-Name attribute and MUST 717 include the Type-Data field of the EAP-Response/Identity in the 718 User-Name attribute in every subsequent Access-Request. 720 This suggests that the User-Name attribute should contain the 721 contents of the Type-Data field of the EAP-Response/Identity, even if 722 it is zero octets in length. 724 Note that [RFC4282] does not permit an NAI of zero octets, so that an 725 EAP-Response/Identity with a Type-Data field of zero octets MUST NOT 726 be construed as a request for privacy (e.g. anonymous NAI). 728 When a NAS receives an EAP-Response/Identity with a Type-Data field 729 that is zero octets in length, it is RECOMMENDED that it either omit 730 a User-Name attribute in the Access-Request or include the Calling- 731 Station-Id in the User-Name attribute, along with a Calling-Station- 732 Id attribute. 734 2.10. Responses after retransmissions 736 Some implementations do not correctly handle the receipt of RADIUS 737 responses after retransmissions. [RFC2865] Section 2.5 states 739 If the NAS is retransmitting a RADIUS request to the same server 740 as before, and the attributes haven't changed, you MUST use the 741 same Request Authenticator, ID, and source port. If any 742 attributes have changed, you MUST use a new Request Authenticator 743 and ID. 745 Note that changing the Request ID for a retransmission may have 746 undesirable side effects. Since RADIUS does not have a clear 747 definition of a "session", it is perfectly valid for a RADIUS server 748 to treat a retransmission as a new session request, and to reject it 749 due to (say) multiple simultaneous login restrictions are enforced. 750 In that situation, the NAS may receive a belated Access-Accept for 751 the first request, and an Access-Reject for the retransmitted 752 request, both of which apply to the same "session". 754 We suggest that the contents of Access-Request packets SHOULD NOT be 755 changed during retransmissions. If they must be changed due to the 756 inclusion of an Event-Timestampt attribute, for example, then 757 responses to earlier transmissions MUST be silently discarded. Any 758 response to the current request MUST be treated as the definitive 759 response, even if as noted above, it disagrees with earlier 760 responses. 762 This problem can be made worse by implementations that use a fixed 763 retransmission timeout (30 seconds is common). We reiterate the 764 suggestions above in Section 2.1 about using congestive backoff. In 765 that case, responses to earlier transmissions MAY be used as data 766 points for congestive backoff, even if their contents are discarded. 768 2.11. Framed-IPv6-Prefix 770 [RFC3162] Section 2.3 says 772 This Attribute indicates an IPv6 prefix (and corresponding route) 773 to be configured for the user. It MAY be used in Access-Accept 774 packets, and can appear multiple times. It MAY be used in an 775 Access-Request packet as a hint by the NAS to the server that it 776 would prefer these prefix(es), but the server is not required to 777 honor the hint. Since it is assumed that the NAS will plumb a 778 route corresponding to the prefix, it is not necessary for the 779 server to also send a Framed-IPv6-Route attribute for the same 780 prefix. 782 An ISP may desire to support Prefix Delegation at the same time that 783 it would like to assign a prefix for the link between the NAS and the 784 user. The intent of the paragraph was to enable the NAS to advertise 785 the prefix (such as via a Router Advertisement). If the Framed- 786 Routing attribute is used, it is also possible that the prefix would 787 be advertised in a routing protocol such as RIPNG. RFC 2865 Section 788 5.10 describes the purpose of Framed-Routing: 790 This Attribute indicates the routing method for the user, when the 791 user is a router to a network. It is only used in Access-Accept 792 packets. 794 The description of the Prefix-Length field in RFC 3162 indicates 795 excessively wide latitude: 797 The length of the prefix, in bits. At least 0 and no larger than 798 128. 800 This length appears too broad, because it is not clear what a NAS 801 should do with a prefix of greater granularity than /64. For example, 802 the Framed-IPv6-Prefix may contain a /128. This does not imply that 803 the NAS should assign an IPv6 address to the end user, because RFC 804 3162 already defines a Framed-IPv6-Identifier attribute to handle the 805 Identifier portion. 807 It appears that the Framed-IPv6-Prefix is used for the link between 808 the NAS and CPE only if a /64 prefix is assigned. When a larger 809 prefix is sent, the intent is for the NAS to send a routing 810 advertisement containing the information present in the Framed- 811 IPv6-Prefix attribute. 813 3. IANA Considerations 815 This specification does not create any new registries, nor does it 816 require assignment of any protocol parameters. 818 4. Security Considerations 820 Since this document describes the use of RADIUS for purposes of 821 authentication, authorization, and accounting in WLANs, it is 822 vulnerable to all of the threats that are present in other RADIUS 823 applications. For a discussion of these threats, see [RFC2865], 824 [RFC2607], [RFC3162], [RFC3576], [RFC3579], and [RFC3580]. 826 5. References 828 5.1. Normative references. 830 [RFC2865] 831 Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 832 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 834 [RFC2866] 835 Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 837 [RFC2869] 838 Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC 839 2869, June 2000. 841 [RFC3576] 842 Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, 843 "Dynamic Authorization Extensions to Remote Authentication Dial In 844 User Service (RADIUS)", RFC 3576, July 2003. 846 [RFC3579] 847 Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 848 Authentication Protocol (EAP)", RFC 3579, September 2003. 850 5.2. Informative references. 852 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 853 Requirement Levels", RFC 2119, March, 1997. 855 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 856 Autoconfiguration", RFC 2462, December 1998. 858 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 859 Implementation in Roaming", RFC 2607, June 1999. 861 [RFC2618] Aboba, B. and G. Zorn, "RADIUS Authentication Client MIB", RFC 862 2618, June 1999. 864 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 865 3162, August 2001. 867 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 868 "IEEE 802.1X Remote Authentication Dial In User Service 869 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 871 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 872 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 873 3748, June 2004. 875 [RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration 876 of IPv4 Link-Local Addresses", RFC 3927, May 2005. 878 [RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Network 879 Access Identifier", RFC 4282, December 2005. 881 [RFC4668] Nelson, D, "RADIUS Authentication Client MIB for IPv6", RFC 882 4668, August 2006. 884 Acknowledgments 886 The authors would like to acknowledge Glen Zorn and Bernard Aboba for 887 contributions to this document. 889 The alternate algorithm to [RFC3579] Section 2.6.1 that is described 890 in section 2.1.2 of this document was designed by Raghu Dendukuri. 892 David Nelson wishes to acknowledge the support of Enterasys Networks, 893 where he was employed during much of the work on this document. 895 Authors' Addresses 897 David B. Nelson 898 (Independent contributor) 899 72 Old Chester Road 900 Derry, NH 03038 902 Email: d.b.nelson@comcast.net 904 Alan DeKok 905 The FreeRADIUS Server Project 906 http://freeradius.org/ 908 Email: aland@freeradius.org 910 Intellectual Property Statement 912 The IETF takes no position regarding the validity or scope of any 913 Intellectual Property Rights or other rights that might be claimed to 914 pertain to the implementation or use of the technology described in 915 this document or the extent to which any license under such rights 916 might or might not be available; nor does it represent that it has 917 made any independent effort to identify any such rights. Information 918 on the procedures with respect to rights in RFC documents can be 919 found in BCP 78 and BCP 79. 921 Copies of IPR disclosures made to the IETF Secretariat and any 922 assurances of licenses to be made available, or the result of an 923 attempt made to obtain a general license or permission for the use of 924 such proprietary rights by implementers or users of this 925 specification can be obtained from the IETF on-line IPR repository at 926 http://www.ietf.org/ipr. 928 The IETF invites any interested party to bring to its attention any 929 copyrights, patents or patent applications, or other proprietary 930 rights that may cover technology that may be required to implement 931 this standard. Please address the information to the IETF at ietf- 932 ipr@ietf.org. 934 Disclaimer of Validity 936 This document and the information contained herein are provided on an 937 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 938 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 939 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 940 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 941 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 942 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 944 Full Copyright Statement 946 Copyright (C) The IETF Trust (2007). 948 This document is subject to the rights, licenses and restrictions 949 contained in BCP 78, and except as set forth therein, the authors 950 retain all their rights. 952 Acknowledgment 954 Funding for the RFC Editor function is currently provided by the 955 Internet Society. 957 Open issues 959 Open issues relating to this specification are tracked on the 960 following web site: 962 http://www.drizzle.com/~aboba/RADEXT/