idnits 2.17.1 draft-ietf-radext-fixes-02.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 1023. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1000. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1007. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1013. 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 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 (26 March 2007) is 6234 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 924 looks like a reference -- Missing reference section? 'RFC2865' on line 903 looks like a reference -- Missing reference section? 'RFC3579' on line 970 looks like a reference -- Missing reference section? 'RFC4669' on line 956 looks like a reference -- Missing reference section? 'RFC2866' on line 907 looks like a reference -- Missing reference section? 'RFC2869' on line 910 looks like a reference -- Missing reference section? 'RFC2618' on line 933 looks like a reference -- Missing reference section? 'RFC4668' on line 953 looks like a reference -- Missing reference section? '1' on line 627 looks like a reference -- Missing reference section? '2' on line 630 looks like a reference -- Missing reference section? '3' on line 634 looks like a reference -- Missing reference section? 'Note 2' on line 651 looks like a reference -- Missing reference section? 'RFC2462' on line 927 looks like a reference -- Missing reference section? 'RFC3927' on line 947 looks like a reference -- Missing reference section? 'RFC3162' on line 936 looks like a reference -- Missing reference section? 'RFC3580' on line 939 looks like a reference -- Missing reference section? 'RFC3748' on line 943 looks like a reference -- Missing reference section? 'RFC4282' on line 950 looks like a reference -- Missing reference section? 'PREFIX' on line 961 looks like a reference -- Missing reference section? 'RFC2607' on line 930 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, 3579 Alan DeKok 5 Category: Proposed Standard FreeRADIUS 6 7 26 March 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 ............................................. 3 47 1.1. Terminology ......................................... 3 48 1.2. Requirements Language ............................... 3 49 2. Issues ................................................... 4 50 2.1. Session Definition .................................. 4 51 2.1.1. State Attribute ................................ 4 52 2.1.2. Request-ID Supplementation ..................... 5 53 2.2. Overload Conditions ................................. 6 54 2.2.1. Retransmission Behavior ........................ 6 55 2.2.2. Duplicate detection and orderly delivery. ...... 6 56 2.2.3. Server Response to Overload .................... 7 57 2.3. Accounting Issues ................................... 8 58 2.3.1. Attributes allowed in an Interim Update ........ 8 59 2.3.2. Acct-Session-Id and Acct-Multi-Session-Id ...... 8 60 2.3.3. Request Authenticator .......................... 9 61 2.3.4. Interim-Accounting-Interval .................... 9 62 2.3.5. Counter values in the RADIUS MIBs .............. 10 63 2.4. Multiple Filter-ID Attributes ....................... 11 64 2.5. Mandatory and Optional Attributes ................... 12 65 2.6. Interpretation of Access-Reject ..................... 13 66 2.6.1. Improper Use of Access-Reject .................. 13 67 2.6.2. Service Request Denial ......................... 15 68 2.7. Addressing .......................................... 15 69 2.7.1. Link-Local Addresses ........................... 15 70 2.7.2. Multiple Addresses ............................. 16 71 2.8. Idle-Timeout ........................................ 16 72 2.9. Unknown Identity .................................... 17 73 2.10. Responses after retransmissions .................... 18 74 2.11. Framed-IPv6-Prefix ................................. 18 75 3. IANA Considerations ...................................... 20 76 4. Security Considerations .................................. 20 77 5. References ............................................... 20 78 5.1. Normative references. ............................... 20 79 5.2. Informative references. ............................. 20 80 6. RFC Editor instructions .................................. 21 81 Intellectual Property Statement .............................. 22 82 Disclaimer of Validity ....................................... 23 83 Full Copyright Statement ..................................... 23 84 1. Introduction 86 The last few years have seen an increase in the deployment of RADIUS 87 clients and servers. This document describes common issues seen in 88 RADIUS implementations and suggests some fixes. Where applicable, 89 ambiguities and errors in previous RADIUS specifications are 90 clarified. 92 1.1. Terminology 94 This document uses the following terms: 96 Network Access Server (NAS) 97 The device providing access to the network. Also known as the 98 Authenticator (IEEE 802.1X or EAP terminology) or RADIUS client. 100 service 101 The NAS provides a service to the user, such as network access via 102 802.11 or PPP. 104 session 105 Each service provided by the NAS to a peer constitutes a session, 106 with the beginning of the session defined as the point where 107 service is first provided and the end of the session defined as the 108 point where service is ended. A peer may have multiple sessions in 109 parallel or series if the NAS supports that, with each session 110 generating a separate start and stop accounting record. 112 silently discard 113 This means the implementation discards the packet without further 114 processing. The implementation SHOULD provide the capability of 115 logging the error, including the contents of the silently discarded 116 packet, and SHOULD record the event in a statistics counter. 118 1.2. Requirements Language 120 In this document, several words are used to signify the requirements 121 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 122 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 123 and "OPTIONAL" in this document are to be interpreted as described in 124 [RFC2119]. 126 2. Issues 128 2.1. Session Definition 130 2.1.1. State Attribute 132 Regarding the State attribute, [RFC2865] Section 5.24 states: 134 This Attribute is available to be sent by the server to the client 135 in an Access-Challenge and MUST be sent unmodified from the client 136 to the server in the new Access-Request reply to that challenge, 137 if any. 139 This Attribute is available to be sent by the server to the client 140 in an Access-Accept that also includes a Termination-Action 141 Attribute with the value of RADIUS-Request. If the NAS performs 142 the Termination-Action by sending a new Access-Request upon 143 termination of the current session, it MUST include the State 144 attribute unchanged in that Access-Request. 146 Some RADIUS client implementations do not properly use the State 147 attribute in order to distinguish a restarted EAP authentication 148 process from the continuation of an ongoing process (by the same user 149 on the same NAS and port). 151 Where an EAP-Message attribute is included in an Access-Challenge or 152 Access-Accept attribute, RADIUS servers SHOULD also include a State 153 attribute. See the following section for additional benefits to 154 using the State attribute in this fashion. 156 An Access-Request sent as a result of a new or restarted 157 authentication run MUST NOT include the State attribute, even if the 158 State attribute has previously been received in an Access-Challenge 159 for the same user and port. 161 Since a State attribute is always initially provided by the server in 162 an Access-Accept, Access-Challenge, CoA-Request or Disconnect- 163 Request, a RADIUS client MUST NOT insert a State attribute that it 164 has not previously received from the server. 166 A State attribute is REQUIRED in Access-Request packets neither 167 including an authentication attribute nor a Service-Type attribute 168 with the value Call Check (10). 170 2.1.2. Request-ID Supplementation 172 [RFC3579] Section 2.6.1 states: 174 In EAP, each session has its own unique Identifier space. RADIUS 175 server implementations MUST be able to distinguish between EAP 176 packets with the same Identifier existing within distinct 177 sessions, originating on the same NAS. For this purpose, sessions 178 can be distinguished based on NAS and session identification 179 attributes. NAS identification attributes include NAS-Identifier, 180 NAS-IPv6-Address and NAS-IPv4-Address. Session identification 181 attributes include User-Name, NAS-Port, NAS-Port-Type, NAS-Port- 182 Id, Called-Station-Id, Calling-Station-Id and Originating-Line- 183 Info. 185 There are issues with the suggested algorithm. Since proxies may 186 modify Access-Request attributes such as NAS-IP-Address, depending on 187 any attribute under control of the NAS to distinguish request 188 identifiers can result in deployment problems. 190 The FreeRADIUS implementation does not track EAP identifiers by NAS- 191 IP-Address or other non-EAP attributes sent by the NAS. Instead, it 192 uses the EAP identifier, source IP address, and the State attribute 193 as a "key" to uniquely identify each EAP session. Since the State 194 attribute is under the control of the RADIUS server, this means that 195 the uniqueness of each session is controlled by the server, not the 196 NAS. The algorithm used in FreeRADIUS is as follows: 198 if (EAP start, or EAP identity) { 199 allocate unique State Attribute 200 insert session into "active session" table with 201 key=(EAP identifier, State, source IP) 202 } else { 203 look up active session in table, with above key 204 } 206 This algorithm appears to work well in variety of situations, 207 including situations where home servers receive messages via 208 intermediate RADIUS proxies. 210 Implementations that do not use this algorithm are often restricted 211 to having an EAP Identifier space per NAS, or perhaps one that is 212 global to the implementation. These restrictions are unnecessary 213 when the above algorithm is used, which gives each session a unique 214 EAP Identifier space. The above algorithm SHOULD be used to track 215 EAP sessions in preference to any other method. 217 2.2. Overload Conditions 219 2.2.1. Retransmission Behavior 221 [RFC2865] Section 2.4 describes the retransmission requirements for 222 RADIUS clients: 224 At one extreme, RADIUS does not require a "responsive" detection 225 of lost data. The user is willing to wait several seconds for the 226 authentication to complete. The generally aggressive TCP 227 retransmission (based on average round trip time) is not required, 228 nor is the acknowledgment overhead of TCP. 230 At the other extreme, the user is not willing to wait several 231 minutes for authentication. Therefore the reliable delivery of 232 TCP data two minutes later is not useful. The faster use of an 233 alternate server allows the user to gain access before giving up. 235 Some existing RADIUS clients implement excessively aggressive 236 retransmission behavior, utilizing default retransmission timeouts of 237 one second or less without support for congestive backoff. When 238 deployed at large scale, these implementations are susceptible to 239 congestive collapse. For example, as the result of a power failure, 240 a network with 3000 NAS devices with a fixed retransmission timer of 241 one second will continuously generate 3000 RADIUS Access-Requests per 242 second. This is sufficient to overwhelm most RADIUS servers. 244 Suggested solutions include: 246 [a] Jitter. To avoid synchronization, a RADIUS client SHOULD 247 incorporate jitter within its retransmission algorithm. 249 [b] Congestive backoff. While it is not necessary for RADIUS client 250 implementations to implement complex retransmission algorithms, 251 implementations SHOULD support congestive backoff within the limits 252 suggested by [RFC2865] Section 2.4. For example, an implementation 253 SHOULD double the initial retransmission timer until a maximum 254 retransmission time is reached, after which the client will 255 failover to another RADIUS server. For example, if the initial 256 retransmission timer is one second, a maximum retransmission timer 257 of 16 seconds might be used. 259 2.2.2. Duplicate detection and orderly delivery. 261 When packets are retransmitted by a client, the server may receive 262 duplicate requests. The limitations of the transport protocol used 263 by RADIUS (UDP) means that the Access-Request packets may be 264 received, and potentially processed, in an order different from the 265 order in which the packets were sent. However, the discussion of the 266 Identifier field in Section 3 of [RFC2865] suys: 268 The RADIUS server can detect a duplicate request if it has the 269 same client source IP address and source UDP port and Identifier 270 within a short span of time. 271 Also, Section 7 of [RFC4669] defines a 272 radiusAuthServDupAccessRequests object, as 273 The number of duplicate Access-Request packets received. 274 This text has a number of implications. First, without duplicate 275 detection, a RADIUS server may process an authentication request 276 twice, leading to an erroneous conclusion that a user has logged in 277 twice. That behavior is undesirable, so duplicate detection is 278 desirable. Second, the server may track not only the duplicate 279 request, but also the replies to those requests. This behavior 280 permits the server to send duplicate replies in response to duplicate 281 requests, increasing network stability. 283 Since Access-Request packets may also be sent by the client in 284 response to an Access-Challenge from the server, those packets form a 285 logically ordered stream, and therefore have additional ordering 286 requirements over Access-Request packets for different sessions. 287 Implementing duplicate detection results in new packets being 288 processed only once, ensuring order. 290 RADIUS servers MUST therefore implement duplicate detection for 291 Access-Request packets, as described in Section 3 of [RFC2865]. 292 Implementations MUST also cache the Responses (Access-Accept, Access- 293 Challenge, or Access-Reject) that is sends for those Access-Request 294 packets. If a server receives a valid duplicate Access-Request for 295 which is already has sent a Response, it MUST resend its original 296 Response without reprocessing the request. The server MUST silently 297 discard any duplicate Access-Requests for which a Response has not 298 been sent yet. 300 Each cache entry SHOULD be purged after a period of time. This time 301 SHOULD be no less than 5 seconds, and no more than 30 seconds. 303 Cache entries MUST also be purged if the server receives an Access- 304 Request packet that matches a cached Access-Request packet in source 305 address, source port, RADIUS Identifier, and receiving socket, but 306 where the Request Authenticator field is different from the one in 307 the cached packet. 309 2.2.3. Server Response to Overload 311 Some RADIUS server implementations are not robust in response to 312 overload, dropping packets with even probability across multiple 313 sessions. In an overload situation, this results in a high failure 314 rate for multi-round authentication protocols such as EAP [RFC3579]. 315 Typically, users will continually retry in an attempt to gain access, 316 increasing the load even further. 318 A more sensible approach is for a RADIUS server to preferentially 319 accept RADIUS Access-Request packets containing a valid State 320 attribute, so that multi-round authentication conversations, once 321 begun, will be more likely to succeed. Similarly, a server that is 322 proxying requests should preferentially process Access-Accept, 323 Access-Challenge, or Access-Reject packets from home servers, before 324 processing new requests from a NAS. 326 These methods will allow some users to gain access to the network, 327 reducing the load created by ongoing access attempts. 329 2.3. Accounting Issues 331 2.3.1. Attributes allowed in an Interim Update 333 [RFC2866] indicates that Acct-Input-Octets, Acct-Output-Octets, Acct- 334 Session-Time, Acct-Input-Packets, Acct-Output-Packets and Acct- 335 Terminate-Cause attributes "can only be present in Accounting-Request 336 records where the Acct-Status-Type is set to Stop." 338 However [RFC2869] Section 2.1 states: 340 It is envisioned that an Interim Accounting record (with Acct- 341 Status-Type = Interim-Update (3)) would contain all of the 342 attributes normally found in an Accounting Stop message with the 343 exception of the Acct-Term-Cause attribute. 345 Although [RFC2869] does not indicate that it updates [RFC2866], this 346 is an oversight, and the above attributes are allowable in an Interim 347 Accounting record. 349 2.3.2. Acct-Session-Id and Acct-Multi-Session-Id 351 [RFC2866] Section 5.5 describes Acct-Session-Id as Text within the 352 figure summarizing the attribute format, but then goes to state that 353 "The String field SHOULD be a string of UTF-8 encoded 10646 354 characters." 356 [RFC2865] defines the "Text" type as "containing UTF-8 encoded 10646 357 characters", which is compatible with the description of Acct- 358 Session-Id. Since other attributes are consistently described as 359 "Text" within both the figure summarizing the attribute format, and 360 the following attribute definition, it appears that this is a 361 typographical error, and that Acct-Session-Id is of type Text, and 362 not of type String. 364 The definition of the Acct-Multi-Session-Id attribute also has 365 typographical errors. It says 367 A summary of the Acct-Session-Id attribute format ... 369 This text should read 371 A summary of the Acct-Multi-Session-Id attribute format ... 373 The Acct-Multi-Session-Id attribute is also defined as being of type 374 "String". However, the language in the text strongly recommends that 375 implementors consider the attribute as being of type "Text". It is 376 unclear why the type "String" was chosen for this attribute when the 377 type "Text" would be sufficient. 379 2.3.3. Request Authenticator 381 [RFC2866] Section 4.1 states: 383 The Request Authenticator of an Accounting-Request contains a 384 16-octet MD5 hash value calculated according to the method 385 described in "Request Authenticator" above. 387 However, the text does not indicate any action to take when an 388 Accounting-Request packet contains an invalid Request Authenticator. 389 The following text should be considered to be part of the above 390 description: 392 The Request Authenticator field MUST contain the correct data, as 393 given by the above calculation. Invalid packets are silently 394 discarded. Note that some early implementations always set the 395 Request Authenticator to all zeros. New implementations of RADIUS 396 clients MUST use the above algorithm to calculate the Request 397 Authenticator field. New RADIUS server implementations MUST 398 silently discard invalid packets. 400 2.3.4. Interim-Accounting-Interval 402 [RFC2869] Section 2.1 states: 404 It is also possible to statically configure an interim value on 405 the NAS itself. Note that a locally configured value on the NAS 406 MUST override the value found in an Access-Accept. 408 This requirement may be phrased too strongly. It is conceivable that 409 a NAS implementation has a setting for a "minimum" value of Interim- 410 Accounting-Interval, based on resource constraints in the NAS, and 411 network loading in the local environment of the NAS. In such cases, 412 the value administratively provisioned in the NAS should not be over- 413 ridden by a smaller value from an Access-Accept message. The NAS's 414 value could be over-ridden by a larger one, however. The intent is 415 that the NAS sends accounting information at fixed intervals, short 416 enough such that the potential loss of billable revenue is limited, 417 but also that the accounting updates are infrequent enough such that 418 the NAS, network, and RADIUS server are not overloaded. 420 2.3.5. Counter values in the RADIUS MIBs 422 The RADIUS Authentication and Authorization Client MIB module 423 [RFC2618], [RFC4668] includes counters of packet statistics. In the 424 descriptive text of the MIB module, formulas are provided for certain 425 counter objects. Implementors have noted apparent inconsistencies in 426 the formulas, which could result in negative values. 428 Since the original MIB module specified in [RFC2618] had been widely 429 implemented, the RADEXT WG chose not to change the object definitions 430 or to create new ones within the revised MIB module [RFC4668]. 431 However, this section explains the issues and provides guidance for 432 implementors regarding the interpretation of the textual description 433 and comments for certain MIB objects. 435 The issues raised can be summarized as follows: 437 Issue (1): 439 -- TotalIncomingPackets = Accepts + Rejects + Challenges + 440 UnknownTypes 441 -- 442 -- TotalIncomingPackets - MalformedResponses - BadAuthenticators - 443 -- UnknownTypes - PacketsDropped = Successfully received 444 -- 445 -- AccessRequests + PendingRequests + ClientTimeouts = 446 -- Successfully Received 448 It appears that the value of "Successfully Received" could be 449 negative, since various counters are subtracted from 450 TotalIncomingPackets that are not included in the calculation of 451 TotalIncomingPackets. 453 It also appears that "AccessRequests + PendingRequests + 454 ClientTimeouts = Successfully Received" should read "AccessRequests + 455 PendingRequests + ClientTimeouts = Successfully Transmitted". 457 "TotalIncomingPackets" and "Successfully Received" are temporary 458 variables, i.e. not objects within the MIB module. The comment text 459 in the MIB modules is intended, therefore, to aid in understanding. 460 What's of consequence is the consistency of values of the objects in 461 the MIB module, and that does not appear to be impacted by the 462 inconsistencies noted above. It does appear, however, that the 463 "Successfully Received" variable should be labeled "Successfully 464 Transmitted". 466 In addition, the definition of Accept, Reject or Challenge counters 467 indicates that they MUST be incremented before the message is 468 validated. If the message is invalid, one of MalformedResponses, 469 BadAuthenticators or PacketsDropped counters will be additionally 470 incremented. In that case the first two equations are consistent, 471 i.e. "Successfully Received" could not be negative. 473 Issue (2): 475 It appears that the radiusAuthClientPendingRequests counter is 476 decremented upon retransmission. That would mean a retransmitted 477 packet is not considered as being as pending, although such 478 retransmissions can still be considered as being pending requests. 480 The definition of this MIB object in [RFC2618] is as follows: 482 The number of RADIUS Access-Request packets destined for this 483 server that have not yet timed out or received a response. This 484 variable is incremented when an Access-Request is sent and 485 decremented due to receipt of an Access-Accept, Access-Reject or 486 Access-Challenge, a timeout or retransmission. 488 This object purports to count the number of pending request packets. 489 It is open to interpretation whether or not retransmissions of a 490 request are to be counted as additional pending packets. In either 491 event, it seems appropriate to treat retransmissions consistently 492 with respect to incrementing and decrementing this counter. 494 2.4. Multiple Filter-ID Attributes 496 [RFC2865] Section 5.11 states: 498 Zero or more Filter-Id attributes MAY be sent in an Access-Accept 499 packet. 501 In practice the behavior of a RADIUS client receiving multiple 502 Filter-ID attributes is implementation dependent. For example, some 503 implementations treat multiple instances of the Filter-ID attribute 504 as alternative filters; the first Filter-ID attribute having a name 505 matching a locally defined filter is used, and the remaining ones are 506 discarded. Other implementations may combine matching filters. 508 As a result, the interpretation of multiple Filter-ID attributes is 509 undefined within RADIUS. The sending of multiple Filter-ID 510 attributes within an Access-Accept SHOULD be avoided within 511 heterogeneous deployments and roaming scenarios, where it is likely 512 to produce unpredictable results. 514 2.5. Mandatory and Optional Attributes 516 RADIUS attributes do not explicitly state whether they are optional 517 or mandatory. Nevertheless there are instances where RADIUS 518 attributes need to be treated as mandatory. 520 [RFC2865] Section 1.1 states: 522 A NAS that does not implement a given service MUST NOT implement 523 the RADIUS attributes for that service. For example, a NAS that 524 is unable to offer ARAP service MUST NOT implement the RADIUS 525 attributes for ARAP. A NAS MUST treat a RADIUS access-accept 526 authorizing an unavailable service as an access-reject instead. 528 With respect to the Service-Type attribute, [RFC2865] Section 5.6 529 says: 531 This Attribute indicates the type of service the user has 532 requested, or the type of service to be provided. It MAY be used 533 in both Access-Request and Access-Accept packets. A NAS is not 534 required to implement all of these service types, and MUST treat 535 unknown or unsupported Service-Types as though an Access-Reject 536 had been received instead. 538 [RFC2865] Section 5 states: 540 A RADIUS server MAY ignore Attributes with an unknown Type. 541 A RADIUS client MAY ignore Attributes with an unknown Type. 543 With respect to Vendor-Specific Attributes (VSAs), [RFC2865] Section 544 5.26 states: 546 Servers not equipped to interpret the vendor-specific information 547 sent by a client MUST ignore it (although it may be reported). 548 Clients which do not receive desired vendor-specific information 549 SHOULD make an attempt to operate without it, although they may do 550 so (and report they are doing so) in a degraded mode. 552 It is possible for either a standard attribute or VSA to represent a 553 request for an unavailable service. However, where the Type or 554 Vendor-ID is unknown, a RADIUS client will not know whether the 555 attribute defines a service or not. 557 In general, it is best for RADIUS clients to err on the side of 558 caution. On receiving an Access-Accept including an attribute of 559 unknown Type, a RADIUS client SHOULD assume that it is a potential 560 service definition, and treat it as an Access-Reject. Unknown VSAs 561 SHOULD be ignored by RADIUS clients. 563 RADIUS authentication server implementations SHOULD ignore attributes 564 of unknown Type. Since RADIUS accounting server implementations 565 typically do not need to understand attributes in order to write them 566 to stable storage or pass them to the billing engine, accounting 567 server implementations SHOULD be equipped to handle unknown 568 attributes. 570 To avoid misinterpretation of service requests encoded within VSAs, 571 RADIUS servers SHOULD NOT send VSAs containing service requests to 572 RADIUS clients that are not known to understand them. For example, a 573 RADIUS server should not send a VSA encoding a filter without 574 knowledge that the RADIUS client supports the VSA. 576 2.6. Interpretation of Access-Reject 578 2.6.1. Improper Use of Access-Reject 580 The intent of an Access-Reject is to deny access to the requested 581 service. [RFC2865] Section 2 states: 583 If any condition is not met, the RADIUS server sends an "Access- 584 Reject" response indicating that this user request is invalid. If 585 desired, the server MAY include a text message in the Access- 586 Reject which MAY be displayed by the client to the user. No other 587 Attributes (except Proxy-State) are permitted in an Access-Reject. 589 This text makes it clear that RADIUS does not allow the provisioning 590 of services within an Access-Reject. If the desire is to allow 591 limited access, then an Access-Accept can be sent with attributes 592 provisioning limited access. Attributes within an Access-Reject are 593 restricted to those necessary to route the message (e.g. Proxy- 594 State), attributes providing the user with an indication that access 595 has been denied (e.g. an EAP-Message attribute containing an EAP- 596 Failure) or attributes conveying an error message (e.g. a Reply- 597 Message or Error-Cause attribute). 599 Unfortunately, there are examples where this requirement has been 600 misunderstood. [RFC2869] Section 2.2 states: 602 If that authentication fails, the RADIUS server should return an 603 Access-Reject packet to the NAS, with optional Password-Retry and 604 Reply-Messages attributes. The presence of Password-Retry 605 indicates the ARAP NAS MAY choose to initiate another challenge- 606 response cycle, 608 This paragraph is problematic from two perspectives. Firstly, a 609 Password-Retry attribute is being returned in an Access-Reject; this 610 attribute does not fit into the categories established in [RFC2865]. 611 Secondly, an Access-Reject packet is being sent in the context of a 612 continuing authentication conversation; [RFC2865] requires use of an 613 Access-Challenge for this. [RFC2869] uses the phrase "challenge- 614 response" to describe this use of Access-Reject, indicating that the 615 semantics of Access-Challenge are being used. 617 [RFC2865] Section 4.4, addresses the semantics of Access-Challenge 618 being equivalent to Access-Reject in some cases: 620 If the NAS does not support challenge/response, it MUST treat an 621 Access-Challenge as though it had received an Access-Reject 622 instead. 624 While it is difficult to correct existing deployments of [RFC2869], 625 we make the following recommendations: 627 [1] New RADIUS specifications and implementations MUST NOT use Access- 628 Reject where the semantics of Access-Challenge are intended. 630 [2] Access-Reject MUST mean denial of access to the requested service. 631 In response to an Access-Reject, the NAS MUST NOT send any 632 additional Access-Request packets for that user session. 634 [3] New deployments of ARAP [RFC2869] SHOULD use Access-Challenge 635 instead of Access-Reject packets in the conversations described in 636 [RFC2869] Section 2.2. 638 We also note that the table of attributes [RFC2869] Section 5.19 has 639 an error for the Password-Retry attribute. It says: 641 Request Accept Reject Challenge # Attribute 642 0 0 0-1 0 75 Password-Retry 644 However, the text in [RFC2869] Section 2.3.2 says that Password-Retry 645 can be included within an Access-Challenge packet, for EAP 646 authentication sessions. We recommend a correction to the table: 648 Request Accept Reject Challenge # Attribute 649 0 0 0 0-1 75 Password-Retry [Note 2] 651 [Note 2] As per RFC 3579, the use of the Password-Retry in EAP 652 authentications is deprecated. The Password-Retry attribute can be 653 used only for ARAP authentication. 655 2.6.2. Service Request Denial 657 RADIUS has been deployed for purposes outside network access 658 authentication, authorization and accounting. For example, RADIUS 659 has been deployed as a "back-end" for authenticating Voice Over IP 660 (VOIP) connections, HTTP sessions (e.g. Apache), FTP sessions (e.g. 661 proftpd), and machine logins for multiple operating systems (e.g. 662 bsdi, pam, gina). In those contexts, an Access-Reject sent to the 663 RADIUS client MUST be interpreted as a rejection of the request for 664 service, and the RADIUS client MUST NOT offer that service to the 665 user. 667 For example, when an authentication failure occurs in the context of 668 an FTP session, the normal semantics for rejecting FTP services 669 apply. The rejection does not necessarily cause the FTP server to 670 terminate the underlying TCP connection, but the FTP server MUST NOT 671 offer any services protected by user authentication. 673 Users may request multiple services from the NAS. Where those 674 services are independent, the deployment MUST treat the RADIUS 675 sessions as being independent. 677 For example, a NAS may offer multi-link services, where a user may 678 have multiple simultaneous network connections. In that case, an 679 Access-Reject for a later multi-link connection request does not 680 necessarily mean that earlier multi-link connections are torn down. 681 Similarly, if a NAS offers both dialup and VOIP services, the 682 rejection of a VOIP attempt does not mean that the dialup session is 683 torn down. 685 2.7. Addressing 687 2.7.1. Link-Local Addresses 689 Since Link-Local addresses are unique only on the local link, if the 690 NAS and RADIUS server are not on the same link, then an IPv6 Link- 691 Local address [RFC2462] or an IPv4 Link-Local Address [RFC3927] 692 cannot be used to uniquely identify the NAS. A NAS SHOULD NOT 693 utilize a link-scope address within a NAS-IPv6-Address or NAS-IP- 694 Address attributes. A RADIUS server receiving a NAS-IPv6-Address or 695 NAS-IP-Address attribute containing a Link-Local address SHOULD NOT 696 count such an attribute toward satisfying the requirements of 697 [RFC3162] Section 2.1: 699 NAS-IPv6-Address and/or NAS-IP-Address MAY be present in an 700 Access-Request packet; however, if neither attribute is present 701 then NAS-Identifier MUST be present. 703 2.7.2. Multiple Addresses 705 There are situations in which a RADIUS client or server may have 706 multiple addresses. For example, a dual stack host can have both 707 IPv4 and IPv6 addresses; a host that is a member of multiple VLANs 708 could have IPv4 and/or IPv6 addresses on each VLAN; a host can have 709 multiple IPv4 or IPv6 addresses on a single interface. However, 710 [RFC2865] Section 5.44 only permits zero or one NAS-IP-Address 711 attribute within an Access-Request and [RFC3162] Section 3 only 712 permits zero or one NAS-IPv6-Address attribute within an Access- 713 Request. When a NAS has more than one global address and no ability 714 to determine which is used for identification in a particular 715 request, it is RECOMMENDED that the NAS include the NAS-Identifier 716 attribute in an Access-Request in order to identify itself to the 717 RADIUS server. 719 [RFC2865] Section 3 states: 721 A RADIUS server MUST use the source IP address of the RADIUS 722 UDP packet to decide which shared secret to use, so that 723 RADIUS requests can be proxied. 725 Therefore if a RADIUS client sends packets from more than one source 726 address, a shared secret will need to be configured on both the 727 client and server for each source address. 729 2.8. Idle-Timeout 731 With respect to the Idle-Timeout attribute, [RFC2865] Section 5.28 732 states: 734 This Attribute sets the maximum number of consecutive seconds of 735 idle connection allowed to the user before termination of the 736 session or prompt. This Attribute is available to be sent by the 737 server to the client in an Access-Accept or Access-Challenge. 739 [RFC3580] Section 3.12 states: 741 The Idle-Timeout attribute is described in [RFC2865]. For IEEE 742 802 media other than 802.11 the media are always on. As a result 743 the Idle-Timeout attribute is typically only used with wireless 744 media such as IEEE 802.11. It is possible for a wireless device 745 to wander out of range of all Access Points. In this case, the 746 Idle-Timeout attribute indicates the maximum time that a wireless 747 device may remain idle. 749 In the above paragraphs "idle" may not necessarily mean "no traffic"; 750 the NAS may support filters defining what traffic is included in the 751 idle time determination. As a result, an "idle connection" is 752 defined by local policy in the absence of other attributes. 754 2.9. Unknown Identity 756 [RFC3748] Section 5.1 states: 758 If the Identity is unknown, the Identity Response field 759 should be zero bytes in length. 761 However, [RFC2865] Section 5.1 describes the User-Name attribute as 762 follows: 764 The String field is one or more octets. 766 How should the RADIUS client behave if it receives an EAP- 767 Response/Identity that is zero octets in length? 769 [RFC2865] Section 5.1 states: 771 This Attribute indicates the name of the user to be authenticated. 772 It MUST be sent in Access-Request packets if available. 774 This suggests that the User-Name attribute may be ommitted if it is 775 unavailable. 777 However, [RFC3579] Section 2.1 states: 779 In order to permit non-EAP aware RADIUS proxies to forward the 780 Access-Request packet, if the NAS initially sends an 781 EAP-Request/Identity message to the peer, the NAS MUST copy the 782 contents of the Type-Data field of the EAP-Response/Identity 783 received from the peer into the User-Name attribute and MUST 784 include the Type-Data field of the EAP-Response/Identity in the 785 User-Name attribute in every subsequent Access-Request. 787 This suggests that the User-Name attribute should contain the 788 contents of the Type-Data field of the EAP-Response/Identity, even if 789 it is zero octets in length. 791 Note that [RFC4282] does not permit an NAI of zero octets, so that an 792 EAP-Response/Identity with a Type-Data field of zero octets MUST NOT 793 be construed as a request for privacy (e.g. anonymous NAI). 795 When a NAS receives an EAP-Response/Identity with a Type-Data field 796 that is zero octets in length, it is RECOMMENDED that it either omit 797 a User-Name attribute in the Access-Request or include the Calling- 798 Station-Id in the User-Name attribute, along with a Calling-Station- 799 Id attribute. 801 2.10. Responses after retransmissions 803 Some implementations do not correctly handle the receipt of RADIUS 804 responses after retransmissions. [RFC2865] Section 2.5 states 806 If the NAS is retransmitting a RADIUS request to the same server 807 as before, and the attributes haven't changed, you MUST use the 808 same Request Authenticator, ID, and source port. If any 809 attributes have changed, you MUST use a new Request Authenticator 810 and ID. 812 Note that changing the Request ID for a retransmission may have 813 undesirable side effects. Since RADIUS does not have a clear 814 definition of a "session", it is perfectly valid for a RADIUS server 815 to treat a retransmission as a new session request, and to reject it 816 due to (say) multiple simultaneous login restrictions are enforced. 817 In that situation, the NAS may receive a belated Access-Accept for 818 the first request, and an Access-Reject for the retransmitted 819 request, both of which apply to the same "session". 821 We suggest that the contents of Access-Request packets SHOULD NOT be 822 changed during retransmissions. If they must be changed due to the 823 inclusion of an Event-Timestampt attribute, for example, then 824 responses to earlier transmissions MUST be silently discarded. Any 825 response to the current request MUST be treated as the definitive 826 response, even if as noted above, it disagrees with earlier 827 responses. 829 This problem can be made worse by implementations that use a fixed 830 retransmission timeout (30 seconds is common). We reiterate the 831 suggestions above in Section 2.1 about using congestive backoff. In 832 that case, responses to earlier transmissions MAY be used as data 833 points for congestive backoff, even if their contents are discarded. 835 2.11. Framed-IPv6-Prefix 837 [RFC3162] Section 2.3 says 839 This Attribute indicates an IPv6 prefix (and corresponding route) 840 to be configured for the user. It MAY be used in Access-Accept 841 packets, and can appear multiple times. It MAY be used in an 842 Access-Request packet as a hint by the NAS to the server that it 843 would prefer these prefix(es), but the server is not required to 844 honor the hint. Since it is assumed that the NAS will plumb a 845 route corresponding to the prefix, it is not necessary for the 846 server to also send a Framed-IPv6-Route attribute for the same 847 prefix. 849 An ISP may desire to support Prefix Delegation [PREFIX] at the same 850 time that it would like to assign a prefix for the link between the 851 NAS and the user. The intent of the paragraph was to enable the NAS 852 to advertise the prefix (such as via a Router Advertisement). If the 853 Framed-Routing attribute is used, it is also possible that the prefix 854 would be advertised in a routing protocol such as RIPNG. RFC 2865 855 Section 5.10 describes the purpose of Framed-Routing: 857 This Attribute indicates the routing method for the user, when the 858 user is a router to a network. It is only used in Access-Accept 859 packets. 861 The description of the Prefix-Length field in RFC 3162 indicates 862 excessively wide latitude: 864 The length of the prefix, in bits. At least 0 and no larger than 865 128. 867 This length appears too broad, because it is not clear what a NAS 868 should do with a prefix of greater granularity than /64. For example, 869 the Framed-IPv6-Prefix may contain a /128. This does not imply that 870 the NAS should assign an IPv6 address to the end user, because RFC 871 3162 already defines a Framed-IPv6-Identifier attribute to handle the 872 Identifier portion. 874 It appears that the Framed-IPv6-Prefix is used for the link between 875 the NAS and CPE only if a /64 prefix is assigned. When a /64 or 876 larger prefix is sent, the intent is for the NAS to send a routing 877 advertisement containing the information present in the Framed- 878 IPv6-Prefix attribute. 880 The CPE may also require a delegated prefix for its own use, if it is 881 decrementing the TTL field of IP headers. In that case, it should be 882 delegated a prefix by the NAS via the Delegated-IPv6-Prefix 883 attribute. [PREFIX]. If the CPE is not decrementing TTL, it does 884 not require a delegated prefix. 886 3. IANA Considerations 888 This specification does not create any new registries, nor does it 889 require assignment of any protocol parameters. 891 4. Security Considerations 893 Since this document describes the use of RADIUS for purposes of 894 authentication, authorization, and accounting in WLANs, it is 895 vulnerable to all of the threats that are present in other RADIUS 896 applications. For a discussion of these threats, see [RFC2865], 897 [RFC2607], [RFC3162], [RFC3579], and [RFC3580]. 899 5. References 901 5.1. Normative references. 903 [RFC2865] 904 Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 905 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 907 [RFC2866] 908 Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 910 [RFC2869] 911 Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC 912 2869, June 2000. 914 [RFC3579] 915 Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 916 Authentication Protocol (EAP)", RFC 3579, September 2003. 918 [PREFIX] 919 Salowey, J., Droms., R, "RADIUS Delegated-IPv6-Prefix Attribute", 920 drafty-ietf-radext-delegated-prefix-05.txt, October, 2006. 922 5.2. Informative references. 924 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 925 Requirement Levels", RFC 2119, March, 1997. 927 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 928 Autoconfiguration", RFC 2462, December 1998. 930 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 931 Implementation in Roaming", RFC 2607, June 1999. 933 [RFC2618] Aboba, B. and G. Zorn, "RADIUS Authentication Client MIB", RFC 934 2618, June 1999. 936 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 937 3162, August 2001. 939 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 940 "IEEE 802.1X Remote Authentication Dial In User Service 941 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 943 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 944 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 945 3748, June 2004. 947 [RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration 948 of IPv4 Link-Local Addresses", RFC 3927, May 2005. 950 [RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Network 951 Access Identifier", RFC 4282, December 2005. 953 [RFC4668] Nelson, D, "RADIUS Authentication Client MIB for IPv6", RFC 954 4668, August 2006. 956 [RFC4669] Nelson, D, "RADIUS Authentication Server MIB for IPv6", RFC 957 4669, August 2006. 959 6. RFC Editor instructions 961 The references to [PREFIX] should be replaced with a reference to the 962 RFC when it is issued, and this section deleted, prior to issuing 963 this document as an RFC. 965 Acknowledgments 967 The authors would like to acknowledge Glen Zorn and Bernard Aboba for 968 contributions to this document. 970 The alternate algorithm to [RFC3579] Section 2.6.1 that is described 971 in section 2.1.2 of this document was designed by Raghu Dendukuri. 973 David Nelson wishes to acknowledge the support of Enterasys Networks, 974 where he was employed during much of the work on this document. 976 Authors' Addresses 978 David B. Nelson 979 (Independent contributor) 980 72 Old Chester Road 981 Derry, NH 03038 983 Email: d.b.nelson@comcast.net 985 Alan DeKok 986 The FreeRADIUS Server Project 987 http://freeradius.org/ 989 Email: aland@freeradius.org 991 Intellectual Property Statement 993 The IETF takes no position regarding the validity or scope of any 994 Intellectual Property Rights or other rights that might be claimed to 995 pertain to the implementation or use of the technology described in 996 this document or the extent to which any license under such rights 997 might or might not be available; nor does it represent that it has 998 made any independent effort to identify any such rights. Information 999 on the procedures with respect to rights in RFC documents can be 1000 found in BCP 78 and BCP 79. 1002 Copies of IPR disclosures made to the IETF Secretariat and any 1003 assurances of licenses to be made available, or the result of an 1004 attempt made to obtain a general license or permission for the use of 1005 such proprietary rights by implementers or users of this 1006 specification can be obtained from the IETF on-line IPR repository at 1007 http://www.ietf.org/ipr. 1009 The IETF invites any interested party to bring to its attention any 1010 copyrights, patents or patent applications, or other proprietary 1011 rights that may cover technology that may be required to implement 1012 this standard. Please address the information to the IETF at ietf- 1013 ipr@ietf.org. 1015 Disclaimer of Validity 1017 This document and the information contained herein are provided on an 1018 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1019 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1020 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1021 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1022 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1023 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1025 Full Copyright Statement 1027 Copyright (C) The IETF Trust (2007). 1029 This document is subject to the rights, licenses and restrictions 1030 contained in BCP 78, and except as set forth therein, the authors 1031 retain all their rights. 1033 Acknowledgment 1035 Funding for the RFC Editor function is currently provided by the 1036 Internet Society. 1038 Open issues 1040 Open issues relating to this specification are tracked on the 1041 following web site: 1043 http://www.drizzle.com/~aboba/RADEXT/