idnits 2.17.1 draft-ietf-radext-fixes-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1022. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 999. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1006. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1012. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates 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 (10 April 2007) is 6227 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 628 -- Looks like a reference, but probably isn't: '2' on line 631 -- Looks like a reference, but probably isn't: '3' on line 635 == Missing Reference: 'Note 2' is mentioned on line 652, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'PREFIX' -- Obsolete informational reference (is this intentional?): RFC 2462 (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 2618 (Obsoleted by RFC 4668) -- Obsolete informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group David Nelson 3 INTERNET-DRAFT Elbrys Networks, Inc 4 Updates: 2865, 2866, 2869, 3579 Alan DeKok 5 Category: Proposed Standard FreeRADIUS 6 7 Expires: September 10, 2007 8 10 April 2007 10 Common RADIUS Implementation Issues and Suggested Fixes 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 10, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document describes common issues seen in RADIUS implementations 42 and suggests some fixes. Where applicable, ambiguities and errors in 43 previous RADIUS specifications are clarified. 45 Table of Contents 47 1. Introduction ............................................. 3 48 1.1. Terminology ......................................... 3 49 1.2. Requirements Language ............................... 3 50 2. Issues ................................................... 4 51 2.1. Session Definition .................................. 4 52 2.1.1. State Attribute ................................ 4 53 2.1.2. Request-ID Supplementation ..................... 5 54 2.2. Overload Conditions ................................. 6 55 2.2.1. Retransmission Behavior ........................ 6 56 2.2.2. Duplicate detection and orderly delivery. ...... 6 57 2.2.3. Server Response to Overload .................... 7 58 2.3. Accounting Issues ................................... 8 59 2.3.1. Attributes allowed in an Interim Update ........ 8 60 2.3.2. Acct-Session-Id and Acct-Multi-Session-Id ...... 8 61 2.3.3. Request Authenticator .......................... 9 62 2.3.4. Interim-Accounting-Interval .................... 9 63 2.3.5. Counter values in the RADIUS MIBs .............. 10 64 2.4. Multiple Filter-ID Attributes ....................... 11 65 2.5. Mandatory and Optional Attributes ................... 12 66 2.6. Interpretation of Access-Reject ..................... 13 67 2.6.1. Improper Use of Access-Reject .................. 13 68 2.6.2. Service Request Denial ......................... 15 69 2.7. Addressing .......................................... 15 70 2.7.1. Link-Local Addresses ........................... 15 71 2.7.2. Multiple Addresses ............................. 16 72 2.8. Idle-Timeout ........................................ 16 73 2.9. Unknown Identity .................................... 17 74 2.10. Responses after retransmissions .................... 18 75 2.11. Framed-IPv6-Prefix ................................. 18 76 3. IANA Considerations ...................................... 20 77 4. Security Considerations .................................. 20 78 5. References ............................................... 20 79 5.1. Normative references ................................ 20 80 5.2. Informative references .............................. 20 81 6. RFC Editor instructions .................................. 21 82 Intellectual Property Statement .............................. 22 83 Disclaimer of Validity ....................................... 23 84 Full Copyright Statement ..................................... 23 85 1. Introduction 87 The last few years have seen an increase in the deployment of RADIUS 88 clients and servers. This document describes common issues seen in 89 RADIUS implementations and suggests some fixes. Where applicable, 90 ambiguities and errors in previous RADIUS specifications are 91 clarified. 93 1.1. Terminology 95 This document uses the following terms: 97 Network Access Server (NAS) 98 The device providing access to the network. Also known as the 99 Authenticator (IEEE 802.1X or EAP terminology) or RADIUS client. 101 service 102 The NAS provides a service to the user, such as network access via 103 802.11 or PPP. 105 session 106 Each service provided by the NAS to a peer constitutes a session, 107 with the beginning of the session defined as the point where 108 service is first provided and the end of the session defined as the 109 point where service is ended. A peer may have multiple sessions in 110 parallel or series if the NAS supports that, with each session 111 generating a separate start and stop accounting record. 113 silently discard 114 This means the implementation discards the packet without further 115 processing. The implementation SHOULD provide the capability of 116 logging the error, including the contents of the silently discarded 117 packet, and SHOULD record the event in a statistics counter. 119 1.2. Requirements Language 121 In this document, several words are used to signify the requirements 122 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 123 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 124 and "OPTIONAL" in this document are to be interpreted as described in 125 [RFC2119]. 127 2. Issues 129 2.1. Session Definition 131 2.1.1. State Attribute 133 Regarding the State attribute, [RFC2865] Section 5.24 states: 135 This Attribute is available to be sent by the server to the client 136 in an Access-Challenge and MUST be sent unmodified from the client 137 to the server in the new Access-Request reply to that challenge, 138 if any. 140 This Attribute is available to be sent by the server to the client 141 in an Access-Accept that also includes a Termination-Action 142 Attribute with the value of RADIUS-Request. If the NAS performs 143 the Termination-Action by sending a new Access-Request upon 144 termination of the current session, it MUST include the State 145 attribute unchanged in that Access-Request. 147 Some RADIUS client implementations do not properly use the State 148 attribute in order to distinguish a restarted EAP authentication 149 process from the continuation of an ongoing process (by the same user 150 on the same NAS and port). 152 Where an EAP-Message attribute is included in an Access-Challenge or 153 Access-Accept attribute, RADIUS servers SHOULD also include a State 154 attribute. See the following section for additional benefits to 155 using the State attribute in this fashion. 157 An Access-Request sent as a result of a new or restarted 158 authentication run MUST NOT include the State attribute, even if the 159 State attribute has previously been received in an Access-Challenge 160 for the same user and port. 162 Since a State attribute is always initially provided by the server in 163 an Access-Accept, Access-Challenge, CoA-Request or Disconnect- 164 Request, a RADIUS client MUST NOT insert a State attribute that it 165 has not previously received from the server. 167 A State attribute is REQUIRED in Access-Request packets neither 168 including an authentication attribute nor a Service-Type attribute 169 with the value Call Check (10). 171 2.1.2. Request-ID Supplementation 173 [RFC3579] Section 2.6.1 states: 175 In EAP, each session has its own unique Identifier space. RADIUS 176 server implementations MUST be able to distinguish between EAP 177 packets with the same Identifier existing within distinct 178 sessions, originating on the same NAS. For this purpose, sessions 179 can be distinguished based on NAS and session identification 180 attributes. NAS identification attributes include NAS-Identifier, 181 NAS-IPv6-Address and NAS-IPv4-Address. Session identification 182 attributes include User-Name, NAS-Port, NAS-Port-Type, NAS-Port- 183 Id, Called-Station-Id, Calling-Station-Id and Originating-Line- 184 Info. 186 There are issues with the suggested algorithm. Since proxies may 187 modify Access-Request attributes such as NAS-IP-Address, depending on 188 any attribute under control of the NAS to distinguish request 189 identifiers can result in deployment problems. 191 The FreeRADIUS implementation does not track EAP identifiers by NAS- 192 IP-Address or other non-EAP attributes sent by the NAS. Instead, it 193 uses the EAP identifier, source IP address, and the State attribute 194 as a "key" to uniquely identify each EAP session. Since the State 195 attribute is under the control of the RADIUS server, this means that 196 the uniqueness of each session is controlled by the server, not the 197 NAS. The algorithm used in FreeRADIUS is as follows: 199 if (EAP start, or EAP identity) { 200 allocate unique State Attribute 201 insert session into "active session" table with 202 key=(EAP identifier, State, source IP) 203 } else { 204 look up active session in table, with above key 205 } 207 This algorithm appears to work well in variety of situations, 208 including situations where home servers receive messages via 209 intermediate RADIUS proxies. 211 Implementations that do not use this algorithm are often restricted 212 to having an EAP Identifier space per NAS, or perhaps one that is 213 global to the implementation. These restrictions are unnecessary 214 when the above algorithm is used, which gives each session a unique 215 EAP Identifier space. The above algorithm SHOULD be used to track 216 EAP sessions in preference to any other method. 218 2.2. Overload Conditions 220 2.2.1. Retransmission Behavior 222 [RFC2865] Section 2.4 describes the retransmission requirements for 223 RADIUS clients: 225 At one extreme, RADIUS does not require a "responsive" detection 226 of lost data. The user is willing to wait several seconds for the 227 authentication to complete. The generally aggressive TCP 228 retransmission (based on average round trip time) is not required, 229 nor is the acknowledgment overhead of TCP. 231 At the other extreme, the user is not willing to wait several 232 minutes for authentication. Therefore the reliable delivery of 233 TCP data two minutes later is not useful. The faster use of an 234 alternate server allows the user to gain access before giving up. 236 Some existing RADIUS clients implement excessively aggressive 237 retransmission behavior, utilizing default retransmission timeouts of 238 one second or less without support for congestive backoff. When 239 deployed at large scale, these implementations are susceptible to 240 congestive collapse. For example, as the result of a power failure, 241 a network with 3000 NAS devices with a fixed retransmission timer of 242 one second will continuously generate 3000 RADIUS Access-Requests per 243 second. This is sufficient to overwhelm most RADIUS servers. 245 Suggested solutions include: 247 [a] Jitter. To avoid synchronization, a RADIUS client SHOULD 248 incorporate jitter within its retransmission algorithm. 250 [b] Congestive backoff. While it is not necessary for RADIUS client 251 implementations to implement complex retransmission algorithms, 252 implementations SHOULD support congestive backoff within the limits 253 suggested by [RFC2865] Section 2.4. For example, an implementation 254 SHOULD double the initial retransmission timer until a maximum 255 retransmission time is reached, after which the client will 256 failover to another RADIUS server. For example, if the initial 257 retransmission timer is one second, a maximum retransmission timer 258 of 16 seconds might be used. 260 2.2.2. Duplicate detection and orderly delivery. 262 When packets are retransmitted by a client, the server may receive 263 duplicate requests. The limitations of the transport protocol used 264 by RADIUS (UDP) means that the Access-Request packets may be 265 received, and potentially processed, in an order different from the 266 order in which the packets were sent. However, the discussion of the 267 Identifier field in Section 3 of [RFC2865] suys: 269 The RADIUS server can detect a duplicate request if it has the 270 same client source IP address and source UDP port and Identifier 271 within a short span of time. 272 Also, Section 7 of [RFC4669] defines a 273 radiusAuthServDupAccessRequests object, as 274 The number of duplicate Access-Request packets received. 275 This text has a number of implications. First, without duplicate 276 detection, a RADIUS server may process an authentication request 277 twice, leading to an erroneous conclusion that a user has logged in 278 twice. That behavior is undesirable, so duplicate detection is 279 desirable. Second, the server may track not only the duplicate 280 request, but also the replies to those requests. This behavior 281 permits the server to send duplicate replies in response to duplicate 282 requests, increasing network stability. 284 Since Access-Request packets may also be sent by the client in 285 response to an Access-Challenge from the server, those packets form a 286 logically ordered stream, and therefore have additional ordering 287 requirements over Access-Request packets for different sessions. 288 Implementing duplicate detection results in new packets being 289 processed only once, ensuring order. 291 RADIUS servers MUST therefore implement duplicate detection for 292 Access-Request packets, as described in Section 3 of [RFC2865]. 293 Implementations MUST also cache the Responses (Access-Accept, Access- 294 Challenge, or Access-Reject) that is sends for those Access-Request 295 packets. If a server receives a valid duplicate Access-Request for 296 which is already has sent a Response, it MUST resend its original 297 Response without reprocessing the request. The server MUST silently 298 discard any duplicate Access-Requests for which a Response has not 299 been sent yet. 301 Each cache entry SHOULD be purged after a period of time. This time 302 SHOULD be no less than 5 seconds, and no more than 30 seconds. 304 Cache entries MUST also be purged if the server receives an Access- 305 Request packet that matches a cached Access-Request packet in source 306 address, source port, RADIUS Identifier, and receiving socket, but 307 where the Request Authenticator field is different from the one in 308 the cached packet. 310 2.2.3. Server Response to Overload 312 Some RADIUS server implementations are not robust in response to 313 overload, dropping packets with even probability across multiple 314 sessions. In an overload situation, this results in a high failure 315 rate for multi-round authentication protocols such as EAP [RFC3579]. 316 Typically, users will continually retry in an attempt to gain access, 317 increasing the load even further. 319 A more sensible approach is for a RADIUS server to preferentially 320 accept RADIUS Access-Request packets containing a valid State 321 attribute, so that multi-round authentication conversations, once 322 begun, will be more likely to succeed. Similarly, a server that is 323 proxying requests should preferentially process Access-Accept, 324 Access-Challenge, or Access-Reject packets from home servers, before 325 processing new requests from a NAS. 327 These methods will allow some users to gain access to the network, 328 reducing the load created by ongoing access attempts. 330 2.3. Accounting Issues 332 2.3.1. Attributes allowed in an Interim Update 334 [RFC2866] indicates that Acct-Input-Octets, Acct-Output-Octets, Acct- 335 Session-Time, Acct-Input-Packets, Acct-Output-Packets and Acct- 336 Terminate-Cause attributes "can only be present in Accounting-Request 337 records where the Acct-Status-Type is set to Stop." 339 However [RFC2869] Section 2.1 states: 341 It is envisioned that an Interim Accounting record (with Acct- 342 Status-Type = Interim-Update (3)) would contain all of the 343 attributes normally found in an Accounting Stop message with the 344 exception of the Acct-Term-Cause attribute. 346 Although [RFC2869] does not indicate that it updates [RFC2866], this 347 is an oversight, and the above attributes are allowable in an Interim 348 Accounting record. 350 2.3.2. Acct-Session-Id and Acct-Multi-Session-Id 352 [RFC2866] Section 5.5 describes Acct-Session-Id as Text within the 353 figure summarizing the attribute format, but then goes to state that 354 "The String field SHOULD be a string of UTF-8 encoded 10646 355 characters." 357 [RFC2865] defines the "Text" type as "containing UTF-8 encoded 10646 358 characters", which is compatible with the description of Acct- 359 Session-Id. Since other attributes are consistently described as 360 "Text" within both the figure summarizing the attribute format, and 361 the following attribute definition, it appears that this is a 362 typographical error, and that Acct-Session-Id is of type Text, and 363 not of type String. 365 The definition of the Acct-Multi-Session-Id attribute also has 366 typographical errors. It says 368 A summary of the Acct-Session-Id attribute format ... 370 This text should read 372 A summary of the Acct-Multi-Session-Id attribute format ... 374 The Acct-Multi-Session-Id attribute is also defined as being of type 375 "String". However, the language in the text strongly recommends that 376 implementors consider the attribute as being of type "Text". It is 377 unclear why the type "String" was chosen for this attribute when the 378 type "Text" would be sufficient. 380 2.3.3. Request Authenticator 382 [RFC2866] Section 4.1 states: 384 The Request Authenticator of an Accounting-Request contains a 385 16-octet MD5 hash value calculated according to the method 386 described in "Request Authenticator" above. 388 However, the text does not indicate any action to take when an 389 Accounting-Request packet contains an invalid Request Authenticator. 390 The following text should be considered to be part of the above 391 description: 393 The Request Authenticator field MUST contain the correct data, as 394 given by the above calculation. Invalid packets are silently 395 discarded. Note that some early implementations always set the 396 Request Authenticator to all zeros. New implementations of RADIUS 397 clients MUST use the above algorithm to calculate the Request 398 Authenticator field. New RADIUS server implementations MUST 399 silently discard invalid packets. 401 2.3.4. Interim-Accounting-Interval 403 [RFC2869] Section 2.1 states: 405 It is also possible to statically configure an interim value on 406 the NAS itself. Note that a locally configured value on the NAS 407 MUST override the value found in an Access-Accept. 409 This requirement may be phrased too strongly. It is conceivable that 410 a NAS implementation has a setting for a "minimum" value of Interim- 411 Accounting-Interval, based on resource constraints in the NAS, and 412 network loading in the local environment of the NAS. In such cases, 413 the value administratively provisioned in the NAS should not be over- 414 ridden by a smaller value from an Access-Accept message. The NAS's 415 value could be over-ridden by a larger one, however. The intent is 416 that the NAS sends accounting information at fixed intervals, short 417 enough such that the potential loss of billable revenue is limited, 418 but also that the accounting updates are infrequent enough such that 419 the NAS, network, and RADIUS server are not overloaded. 421 2.3.5. Counter values in the RADIUS MIBs 423 The RADIUS Authentication and Authorization Client MIB module 424 [RFC2618], [RFC4668] includes counters of packet statistics. In the 425 descriptive text of the MIB module, formulas are provided for certain 426 counter objects. Implementors have noted apparent inconsistencies in 427 the formulas, which could result in negative values. 429 Since the original MIB module specified in [RFC2618] had been widely 430 implemented, the RADEXT WG chose not to change the object definitions 431 or to create new ones within the revised MIB module [RFC4668]. 432 However, this section explains the issues and provides guidance for 433 implementors regarding the interpretation of the textual description 434 and comments for certain MIB objects. 436 The issues raised can be summarized as follows: 438 Issue (1): 440 -- TotalIncomingPackets = Accepts + Rejects + Challenges + 441 UnknownTypes 442 -- 443 -- TotalIncomingPackets - MalformedResponses - BadAuthenticators - 444 -- UnknownTypes - PacketsDropped = Successfully received 445 -- 446 -- AccessRequests + PendingRequests + ClientTimeouts = 447 -- Successfully Received 449 It appears that the value of "Successfully Received" could be 450 negative, since various counters are subtracted from 451 TotalIncomingPackets that are not included in the calculation of 452 TotalIncomingPackets. 454 It also appears that "AccessRequests + PendingRequests + 455 ClientTimeouts = Successfully Received" should read "AccessRequests + 456 PendingRequests + ClientTimeouts = Successfully Transmitted". 458 "TotalIncomingPackets" and "Successfully Received" are temporary 459 variables, i.e. not objects within the MIB module. The comment text 460 in the MIB modules is intended, therefore, to aid in understanding. 461 What's of consequence is the consistency of values of the objects in 462 the MIB module, and that does not appear to be impacted by the 463 inconsistencies noted above. It does appear, however, that the 464 "Successfully Received" variable should be labeled "Successfully 465 Transmitted". 467 In addition, the definition of Accept, Reject or Challenge counters 468 indicates that they MUST be incremented before the message is 469 validated. If the message is invalid, one of MalformedResponses, 470 BadAuthenticators or PacketsDropped counters will be additionally 471 incremented. In that case the first two equations are consistent, 472 i.e. "Successfully Received" could not be negative. 474 Issue (2): 476 It appears that the radiusAuthClientPendingRequests counter is 477 decremented upon retransmission. That would mean a retransmitted 478 packet is not considered as being as pending, although such 479 retransmissions can still be considered as being pending requests. 481 The definition of this MIB object in [RFC2618] is as follows: 483 The number of RADIUS Access-Request packets destined for this 484 server that have not yet timed out or received a response. This 485 variable is incremented when an Access-Request is sent and 486 decremented due to receipt of an Access-Accept, Access-Reject or 487 Access-Challenge, a timeout or retransmission. 489 This object purports to count the number of pending request packets. 490 It is open to interpretation whether or not retransmissions of a 491 request are to be counted as additional pending packets. In either 492 event, it seems appropriate to treat retransmissions consistently 493 with respect to incrementing and decrementing this counter. 495 2.4. Multiple Filter-ID Attributes 497 [RFC2865] Section 5.11 states: 499 Zero or more Filter-Id attributes MAY be sent in an Access-Accept 500 packet. 502 In practice the behavior of a RADIUS client receiving multiple 503 Filter-ID attributes is implementation dependent. For example, some 504 implementations treat multiple instances of the Filter-ID attribute 505 as alternative filters; the first Filter-ID attribute having a name 506 matching a locally defined filter is used, and the remaining ones are 507 discarded. Other implementations may combine matching filters. 509 As a result, the interpretation of multiple Filter-ID attributes is 510 undefined within RADIUS. The sending of multiple Filter-ID 511 attributes within an Access-Accept SHOULD be avoided within 512 heterogeneous deployments and roaming scenarios, where it is likely 513 to produce unpredictable results. 515 2.5. Mandatory and Optional Attributes 517 RADIUS attributes do not explicitly state whether they are optional 518 or mandatory. Nevertheless there are instances where RADIUS 519 attributes need to be treated as mandatory. 521 [RFC2865] Section 1.1 states: 523 A NAS that does not implement a given service MUST NOT implement 524 the RADIUS attributes for that service. For example, a NAS that 525 is unable to offer ARAP service MUST NOT implement the RADIUS 526 attributes for ARAP. A NAS MUST treat a RADIUS access-accept 527 authorizing an unavailable service as an access-reject instead. 529 With respect to the Service-Type attribute, [RFC2865] Section 5.6 530 says: 532 This Attribute indicates the type of service the user has 533 requested, or the type of service to be provided. It MAY be used 534 in both Access-Request and Access-Accept packets. A NAS is not 535 required to implement all of these service types, and MUST treat 536 unknown or unsupported Service-Types as though an Access-Reject 537 had been received instead. 539 [RFC2865] Section 5 states: 541 A RADIUS server MAY ignore Attributes with an unknown Type. 542 A RADIUS client MAY ignore Attributes with an unknown Type. 544 With respect to Vendor-Specific Attributes (VSAs), [RFC2865] Section 545 5.26 states: 547 Servers not equipped to interpret the vendor-specific information 548 sent by a client MUST ignore it (although it may be reported). 549 Clients which do not receive desired vendor-specific information 550 SHOULD make an attempt to operate without it, although they may do 551 so (and report they are doing so) in a degraded mode. 553 It is possible for either a standard attribute or VSA to represent a 554 request for an unavailable service. However, where the Type or 555 Vendor-ID is unknown, a RADIUS client will not know whether the 556 attribute defines a service or not. 558 In general, it is best for RADIUS clients to err on the side of 559 caution. On receiving an Access-Accept including an attribute of 560 unknown Type, a RADIUS client SHOULD assume that it is a potential 561 service definition, and treat it as an Access-Reject. Unknown VSAs 562 SHOULD be ignored by RADIUS clients. 564 RADIUS authentication server implementations SHOULD ignore attributes 565 of unknown Type. Since RADIUS accounting server implementations 566 typically do not need to understand attributes in order to write them 567 to stable storage or pass them to the billing engine, accounting 568 server implementations SHOULD be equipped to handle unknown 569 attributes. 571 To avoid misinterpretation of service requests encoded within VSAs, 572 RADIUS servers SHOULD NOT send VSAs containing service requests to 573 RADIUS clients that are not known to understand them. For example, a 574 RADIUS server should not send a VSA encoding a filter without 575 knowledge that the RADIUS client supports the VSA. 577 2.6. Interpretation of Access-Reject 579 2.6.1. Improper Use of Access-Reject 581 The intent of an Access-Reject is to deny access to the requested 582 service. [RFC2865] Section 2 states: 584 If any condition is not met, the RADIUS server sends an "Access- 585 Reject" response indicating that this user request is invalid. If 586 desired, the server MAY include a text message in the Access- 587 Reject which MAY be displayed by the client to the user. No other 588 Attributes (except Proxy-State) are permitted in an Access-Reject. 590 This text makes it clear that RADIUS does not allow the provisioning 591 of services within an Access-Reject. If the desire is to allow 592 limited access, then an Access-Accept can be sent with attributes 593 provisioning limited access. Attributes within an Access-Reject are 594 restricted to those necessary to route the message (e.g. Proxy- 595 State), attributes providing the user with an indication that access 596 has been denied (e.g. an EAP-Message attribute containing an EAP- 597 Failure) or attributes conveying an error message (e.g. a Reply- 598 Message or Error-Cause attribute). 600 Unfortunately, there are examples where this requirement has been 601 misunderstood. [RFC2869] Section 2.2 states: 603 If that authentication fails, the RADIUS server should return an 604 Access-Reject packet to the NAS, with optional Password-Retry and 605 Reply-Messages attributes. The presence of Password-Retry 606 indicates the ARAP NAS MAY choose to initiate another challenge- 607 response cycle, 609 This paragraph is problematic from two perspectives. Firstly, a 610 Password-Retry attribute is being returned in an Access-Reject; this 611 attribute does not fit into the categories established in [RFC2865]. 612 Secondly, an Access-Reject packet is being sent in the context of a 613 continuing authentication conversation; [RFC2865] requires use of an 614 Access-Challenge for this. [RFC2869] uses the phrase "challenge- 615 response" to describe this use of Access-Reject, indicating that the 616 semantics of Access-Challenge are being used. 618 [RFC2865] Section 4.4, addresses the semantics of Access-Challenge 619 being equivalent to Access-Reject in some cases: 621 If the NAS does not support challenge/response, it MUST treat an 622 Access-Challenge as though it had received an Access-Reject 623 instead. 625 While it is difficult to correct existing deployments of [RFC2869], 626 we make the following recommendations: 628 [1] New RADIUS specifications and implementations MUST NOT use Access- 629 Reject where the semantics of Access-Challenge are intended. 631 [2] Access-Reject MUST mean denial of access to the requested service. 632 In response to an Access-Reject, the NAS MUST NOT send any 633 additional Access-Request packets for that user session. 635 [3] New deployments of ARAP [RFC2869] SHOULD use Access-Challenge 636 instead of Access-Reject packets in the conversations described in 637 [RFC2869] Section 2.2. 639 We also note that the table of attributes [RFC2869] Section 5.19 has 640 an error for the Password-Retry attribute. It says: 642 Request Accept Reject Challenge # Attribute 643 0 0 0-1 0 75 Password-Retry 645 However, the text in [RFC2869] Section 2.3.2 says that Password-Retry 646 can be included within an Access-Challenge packet, for EAP 647 authentication sessions. We recommend a correction to the table: 649 Request Accept Reject Challenge # Attribute 650 0 0 0 0-1 75 Password-Retry [Note 2] 652 [Note 2] As per RFC 3579, the use of the Password-Retry in EAP 653 authentications is deprecated. The Password-Retry attribute can be 654 used only for ARAP authentication. 656 2.6.2. Service Request Denial 658 RADIUS has been deployed for purposes outside network access 659 authentication, authorization and accounting. For example, RADIUS 660 has been deployed as a "back-end" for authenticating Voice Over IP 661 (VOIP) connections, HTTP sessions (e.g. Apache), FTP sessions (e.g. 662 proftpd), and machine logins for multiple operating systems (e.g. 663 bsdi, pam, gina). In those contexts, an Access-Reject sent to the 664 RADIUS client MUST be interpreted as a rejection of the request for 665 service, and the RADIUS client MUST NOT offer that service to the 666 user. 668 For example, when an authentication failure occurs in the context of 669 an FTP session, the normal semantics for rejecting FTP services 670 apply. The rejection does not necessarily cause the FTP server to 671 terminate the underlying TCP connection, but the FTP server MUST NOT 672 offer any services protected by user authentication. 674 Users may request multiple services from the NAS. Where those 675 services are independent, the deployment MUST treat the RADIUS 676 sessions as being independent. 678 For example, a NAS may offer multi-link services, where a user may 679 have multiple simultaneous network connections. In that case, an 680 Access-Reject for a later multi-link connection request does not 681 necessarily mean that earlier multi-link connections are torn down. 682 Similarly, if a NAS offers both dialup and VOIP services, the 683 rejection of a VOIP attempt does not mean that the dialup session is 684 torn down. 686 2.7. Addressing 688 2.7.1. Link-Local Addresses 690 Since Link-Local addresses are unique only on the local link, if the 691 NAS and RADIUS server are not on the same link, then an IPv6 Link- 692 Local address [RFC2462] or an IPv4 Link-Local Address [RFC3927] 693 cannot be used to uniquely identify the NAS. A NAS SHOULD NOT 694 utilize a link-scope address within a NAS-IPv6-Address or NAS-IP- 695 Address attributes. A RADIUS server receiving a NAS-IPv6-Address or 696 NAS-IP-Address attribute containing a Link-Local address SHOULD NOT 697 count such an attribute toward satisfying the requirements of 698 [RFC3162] Section 2.1: 700 NAS-IPv6-Address and/or NAS-IP-Address MAY be present in an 701 Access-Request packet; however, if neither attribute is present 702 then NAS-Identifier MUST be present. 704 2.7.2. Multiple Addresses 706 There are situations in which a RADIUS client or server may have 707 multiple addresses. For example, a dual stack host can have both 708 IPv4 and IPv6 addresses; a host that is a member of multiple VLANs 709 could have IPv4 and/or IPv6 addresses on each VLAN; a host can have 710 multiple IPv4 or IPv6 addresses on a single interface. However, 711 [RFC2865] Section 5.44 only permits zero or one NAS-IP-Address 712 attribute within an Access-Request and [RFC3162] Section 3 only 713 permits zero or one NAS-IPv6-Address attribute within an Access- 714 Request. When a NAS has more than one global address and no ability 715 to determine which is used for identification in a particular 716 request, it is RECOMMENDED that the NAS include the NAS-Identifier 717 attribute in an Access-Request in order to identify itself to the 718 RADIUS server. 720 [RFC2865] Section 3 states: 722 A RADIUS server MUST use the source IP address of the RADIUS 723 UDP packet to decide which shared secret to use, so that 724 RADIUS requests can be proxied. 726 Therefore if a RADIUS client sends packets from more than one source 727 address, a shared secret will need to be configured on both the 728 client and server for each source address. 730 2.8. Idle-Timeout 732 With respect to the Idle-Timeout attribute, [RFC2865] Section 5.28 733 states: 735 This Attribute sets the maximum number of consecutive seconds of 736 idle connection allowed to the user before termination of the 737 session or prompt. This Attribute is available to be sent by the 738 server to the client in an Access-Accept or Access-Challenge. 740 [RFC3580] Section 3.12 states: 742 The Idle-Timeout attribute is described in [RFC2865]. For IEEE 743 802 media other than 802.11 the media are always on. As a result 744 the Idle-Timeout attribute is typically only used with wireless 745 media such as IEEE 802.11. It is possible for a wireless device 746 to wander out of range of all Access Points. In this case, the 747 Idle-Timeout attribute indicates the maximum time that a wireless 748 device may remain idle. 750 In the above paragraphs "idle" may not necessarily mean "no traffic"; 751 the NAS may support filters defining what traffic is included in the 752 idle time determination. As a result, an "idle connection" is 753 defined by local policy in the absence of other attributes. 755 2.9. Unknown Identity 757 [RFC3748] Section 5.1 states: 759 If the Identity is unknown, the Identity Response field 760 should be zero bytes in length. 762 However, [RFC2865] Section 5.1 describes the User-Name attribute as 763 follows: 765 The String field is one or more octets. 767 How should the RADIUS client behave if it receives an EAP- 768 Response/Identity that is zero octets in length? 770 [RFC2865] Section 5.1 states: 772 This Attribute indicates the name of the user to be authenticated. 773 It MUST be sent in Access-Request packets if available. 775 This suggests that the User-Name attribute may be ommitted if it is 776 unavailable. 778 However, [RFC3579] Section 2.1 states: 780 In order to permit non-EAP aware RADIUS proxies to forward the 781 Access-Request packet, if the NAS initially sends an 782 EAP-Request/Identity message to the peer, the NAS MUST copy the 783 contents of the Type-Data field of the EAP-Response/Identity 784 received from the peer into the User-Name attribute and MUST 785 include the Type-Data field of the EAP-Response/Identity in the 786 User-Name attribute in every subsequent Access-Request. 788 This suggests that the User-Name attribute should contain the 789 contents of the Type-Data field of the EAP-Response/Identity, even if 790 it is zero octets in length. 792 Note that [RFC4282] does not permit an NAI of zero octets, so that an 793 EAP-Response/Identity with a Type-Data field of zero octets MUST NOT 794 be construed as a request for privacy (e.g. anonymous NAI). 796 When a NAS receives an EAP-Response/Identity with a Type-Data field 797 that is zero octets in length, it is RECOMMENDED that it either omit 798 a User-Name attribute in the Access-Request or include the Calling- 799 Station-Id in the User-Name attribute, along with a Calling-Station- 800 Id attribute. 802 2.10. Responses after retransmissions 804 Some implementations do not correctly handle the receipt of RADIUS 805 responses after retransmissions. [RFC2865] Section 2.5 states 807 If the NAS is retransmitting a RADIUS request to the same server 808 as before, and the attributes haven't changed, you MUST use the 809 same Request Authenticator, ID, and source port. If any 810 attributes have changed, you MUST use a new Request Authenticator 811 and ID. 813 Note that changing the Request ID for a retransmission may have 814 undesirable side effects. Since RADIUS does not have a clear 815 definition of a "session", it is perfectly valid for a RADIUS server 816 to treat a retransmission as a new session request, and to reject it 817 due to (say) multiple simultaneous login restrictions are enforced. 818 In that situation, the NAS may receive a belated Access-Accept for 819 the first request, and an Access-Reject for the retransmitted 820 request, both of which apply to the same "session". 822 We suggest that the contents of Access-Request packets SHOULD NOT be 823 changed during retransmissions. If they must be changed due to the 824 inclusion of an Event-Timestampt attribute, for example, then 825 responses to earlier transmissions MUST be silently discarded. Any 826 response to the current request MUST be treated as the definitive 827 response, even if as noted above, it disagrees with earlier 828 responses. 830 This problem can be made worse by implementations that use a fixed 831 retransmission timeout (30 seconds is common). We reiterate the 832 suggestions above in Section 2.1 about using congestive backoff. In 833 that case, responses to earlier transmissions MAY be used as data 834 points for congestive backoff, even if their contents are discarded. 836 2.11. Framed-IPv6-Prefix 838 [RFC3162] Section 2.3 says 840 This Attribute indicates an IPv6 prefix (and corresponding route) 841 to be configured for the user. It MAY be used in Access-Accept 842 packets, and can appear multiple times. It MAY be used in an 843 Access-Request packet as a hint by the NAS to the server that it 844 would prefer these prefix(es), but the server is not required to 845 honor the hint. Since it is assumed that the NAS will plumb a 846 route corresponding to the prefix, it is not necessary for the 847 server to also send a Framed-IPv6-Route attribute for the same 848 prefix. 850 An ISP may desire to support Prefix Delegation [PREFIX] at the same 851 time that it would like to assign a prefix for the link between the 852 NAS and the user. The intent of the paragraph was to enable the NAS 853 to advertise the prefix (such as via a Router Advertisement). If the 854 Framed-Routing attribute is used, it is also possible that the prefix 855 would be advertised in a routing protocol such as RIPNG. RFC 2865 856 Section 5.10 describes the purpose of Framed-Routing: 858 This Attribute indicates the routing method for the user, when the 859 user is a router to a network. It is only used in Access-Accept 860 packets. 862 The description of the Prefix-Length field in RFC 3162 indicates 863 excessively wide latitude: 865 The length of the prefix, in bits. At least 0 and no larger than 866 128. 868 This length appears too broad, because it is not clear what a NAS 869 should do with a prefix of greater granularity than /64. For example, 870 the Framed-IPv6-Prefix may contain a /128. This does not imply that 871 the NAS should assign an IPv6 address to the end user, because RFC 872 3162 already defines a Framed-IPv6-Identifier attribute to handle the 873 Identifier portion. 875 It appears that the Framed-IPv6-Prefix is used for the link between 876 the NAS and CPE only if a /64 prefix is assigned. When a /64 or 877 larger prefix is sent, the intent is for the NAS to send a routing 878 advertisement containing the information present in the Framed- 879 IPv6-Prefix attribute. 881 The CPE may also require a delegated prefix for its own use, if it is 882 decrementing the TTL field of IP headers. In that case, it should be 883 delegated a prefix by the NAS via the Delegated-IPv6-Prefix 884 attribute. [PREFIX]. If the CPE is not decrementing TTL, it does 885 not require a delegated prefix. 887 3. IANA Considerations 889 This specification does not create any new registries, nor does it 890 require assignment of any protocol parameters. 892 4. Security Considerations 894 Since this document describes the use of RADIUS for purposes of 895 authentication, authorization, and accounting in WLANs, it is 896 vulnerable to all of the threats that are present in other RADIUS 897 applications. For a discussion of these threats, see [RFC2865], 898 [RFC2607], [RFC3162], [RFC3579], and [RFC3580]. 900 5. References 902 5.1. Normative references 904 [RFC2865] 905 Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 906 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 908 [PREFIX] 909 Salowey, J., Droms., R, "RADIUS Delegated-IPv6-Prefix Attribute", 910 drafty-ietf-radext-delegated-prefix-05.txt, October, 2006. 912 5.2. Informative references 914 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 915 Requirement Levels", RFC 2119, March, 1997. 917 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 918 Autoconfiguration", RFC 2462, December 1998. 920 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 921 Implementation in Roaming", RFC 2607, June 1999. 923 [RFC2618] Aboba, B. and G. Zorn, "RADIUS Authentication Client MIB", RFC 924 2618, June 1999. 926 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 928 [RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", 929 RFC 2869, June 2000. 931 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 932 3162, August 2001. 934 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 935 Authentication Protocol (EAP)", RFC 3579, September 2003. 937 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 938 "IEEE 802.1X Remote Authentication Dial In User Service 939 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 941 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 942 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 943 3748, June 2004. 945 [RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration 946 of IPv4 Link-Local Addresses", RFC 3927, May 2005. 948 [RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Network 949 Access Identifier", RFC 4282, December 2005. 951 [RFC4668] Nelson, D, "RADIUS Authentication Client MIB for IPv6", RFC 952 4668, August 2006. 954 [RFC4669] Nelson, D, "RADIUS Authentication Server MIB for IPv6", RFC 955 4669, August 2006. 957 6. RFC Editor instructions 959 The references to [PREFIX] should be replaced with a reference to the 960 RFC when it is issued, and this section deleted, prior to issuing 961 this document as an RFC. 963 Acknowledgments 965 The authors would like to acknowledge Glen Zorn and Bernard Aboba for 966 contributions to this document. 968 The alternate algorithm to [RFC3579] Section 2.6.1 that is described 969 in section 2.1.2 of this document was designed by Raghu Dendukuri. 971 David Nelson wishes to acknowledge the support of Enterasys Networks, 972 where he was employed during much of the work on this document. 974 Authors' Addresses 976 David B. Nelson 977 Elbrys Networks, Inc. 978 75 Rochester Ave., Unit 3 979 Portsmouth N.H. 03801 USA 981 Phone: +1.603.570.2636 982 Email: d.b.nelson@comcast.net 984 Alan DeKok 985 The FreeRADIUS Server Project 986 http://freeradius.org/ 988 Email: aland@freeradius.org 990 Intellectual Property Statement 992 The IETF takes no position regarding the validity or scope of any 993 Intellectual Property Rights or other rights that might be claimed to 994 pertain to the implementation or use of the technology described in 995 this document or the extent to which any license under such rights 996 might or might not be available; nor does it represent that it has 997 made any independent effort to identify any such rights. Information 998 on the procedures with respect to rights in RFC documents can be 999 found in BCP 78 and BCP 79. 1001 Copies of IPR disclosures made to the IETF Secretariat and any 1002 assurances of licenses to be made available, or the result of an 1003 attempt made to obtain a general license or permission for the use of 1004 such proprietary rights by implementers or users of this 1005 specification can be obtained from the IETF on-line IPR repository at 1006 http://www.ietf.org/ipr. 1008 The IETF invites any interested party to bring to its attention any 1009 copyrights, patents or patent applications, or other proprietary 1010 rights that may cover technology that may be required to implement 1011 this standard. Please address the information to the IETF at ietf- 1012 ipr@ietf.org. 1014 Disclaimer of Validity 1016 This document and the information contained herein are provided on an 1017 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1018 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1019 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1020 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1021 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1022 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1024 Full Copyright Statement 1026 Copyright (C) The IETF Trust (2007). 1028 This document is subject to the rights, licenses and restrictions 1029 contained in BCP 78, and except as set forth therein, the authors 1030 retain all their rights. 1032 Acknowledgment 1034 Funding for the RFC Editor function is currently provided by the 1035 Internet Society. 1037 Open issues 1039 Open issues relating to this specification are tracked on the 1040 following web site: 1042 http://www.drizzle.com/~aboba/RADEXT/