idnits 2.17.1 draft-ietf-radext-fixes-00.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 855. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 832. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 839. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 845. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 19 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages 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 RFC3576, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2869, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3579, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC2865, updated by this document, for RFC5378 checks: 1999-03-04) (Using the creation date from RFC2869, updated by this document, for RFC5378 checks: 1998-04-10) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (19 December 2006) is 6331 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 465 -- Looks like a reference, but probably isn't: '2' on line 468 -- Looks like a reference, but probably isn't: '3' on line 472 == Missing Reference: 'Note 2' is mentioned on line 489, but not defined == Unused Reference: 'RFC2867' is defined on line 759, but no explicit reference was found in the text == Unused Reference: 'RFC2868' is defined on line 763, but no explicit reference was found in the text == Unused Reference: 'RFC2882' is defined on line 770, but no explicit reference was found in the text == Unused Reference: 'RFC3575' is defined on line 776, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2462 (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 3576 (Obsoleted by RFC 5176) -- Obsolete informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group David Nelson 3 INTERNET-DRAFT Enterasys Networks 4 Updates: 2865, 2866, 2869, 3576, 3579 Alan DeKok 5 Category: Proposed Standard FreeRADIUS 6 7 19 December 2006 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 June 19, 2007. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2006). All rights reserved. 38 Abstract 40 This document describes common issues seen in RADIUS implementations 41 and suggests some fixes. Where applicable, ambiguities and errors in 42 previous RADIUS specifications are clarified. 44 Table of Contents 46 1. Introduction .......................................... 3 47 1.1 Terminology ..................................... 3 48 1.2 Requirements Language ........................... 3 49 2. Issues ................................................ 4 50 2.1 Session Definition .............................. 4 51 2.2 Overload Conditions ............................. 6 52 2.3 Accounting Issues ............................... 7 53 2.4 Multiple Filter-ID Attributes ................... 9 54 2.5 Mandatory and Optional Attributes ............... 9 55 2.6 Interpretation of Access-Reject ................. 10 56 2.7 Addressing ...................................... 12 57 2.8 Idle Timeout .................................... 13 58 2.9 Unknown Identity ................................ 14 59 2.10 Responses after retransmissions ................. 15 60 2.11 Framed-IPv6-Prefix .............................. 15 61 3. IANA Considerations ................................... 16 62 4. Security Considerations ............................... 16 63 5. References ............................................ 17 64 5.1 Informative References ................................ 17 65 ACKNOWLEDGMENTS .............................................. 18 66 AUTHORS' ADDRESSES ........................................... 18 67 Intellectual Property Statement .............................. 19 68 Disclaimer of Validity ....................................... 22 69 Copyright Statement .......................................... 22 70 1. Introduction 72 The last few years have seen an increase in the deployment of RADIUS 73 clients and servers. This document describes common issues seen in 74 RADIUS implementations and suggests some fixes. Where applicable, 75 ambiguities and errors in previous RADIUS specifications are 76 clarified. 78 1.1. Terminology 80 This document uses the following terms: 82 Network Access Server (NAS) 83 The device providing access to the network. Also known as the 84 Authenticator (IEEE 802.1X or EAP terminology) or RADIUS client. 86 service 87 The NAS provides a service to the user, such as network access via 88 802.11 or PPP. 90 session 91 Each service provided by the NAS to a peer constitutes a session, 92 with the beginning of the session defined as the point where 93 service is first provided and the end of the session defined as the 94 point where service is ended. A peer may have multiple sessions in 95 parallel or series if the NAS supports that, with each session 96 generating a separate start and stop accounting record. 98 silently discard 99 This means the implementation discards the packet without further 100 processing. The implementation SHOULD provide the capability of 101 logging the error, including the contents of the silently discarded 102 packet, and SHOULD record the event in a statistics counter. 104 1.2. Requirements Language 106 In this document, several words are used to signify the requirements 107 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 108 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 109 and "OPTIONAL" in this document are to be interpreted as described in 110 [RFC2119]. 112 2. Issues 114 2.1. Session Definition 116 2.1.1. State Attribute 118 Regarding the State attribute, [RFC2865] Section 5.24 states: 120 This Attribute is available to be sent by the server to the client 121 in an Access-Challenge and MUST be sent unmodified from the client 122 to the server in the new Access-Request reply to that challenge, 123 if any. 125 This Attribute is available to be sent by the server to the client 126 in an Access-Accept that also includes a Termination-Action 127 Attribute with the value of RADIUS-Request. If the NAS performs 128 the Termination-Action by sending a new Access-Request upon 129 termination of the current session, it MUST include the State 130 attribute unchanged in that Access-Request. 132 Some RADIUS client implementations do not properly use the State 133 attribute in order to distinguish a restarted EAP authentication 134 process from the continuation of an ongoing process (by the same user 135 on the same NAS and port). 137 Where an EAP-Message attribute is included in an Access-Challenge or 138 Access-Accept attribute, RADIUS servers SHOULD also include a State 139 attribute. 141 An Access-Request sent as a result of a new or restarted 142 authentication run MUST NOT include the State attribute, even if the 143 State attribute has previously been received in an Access-Challenge 144 for the same user and port. 146 Since a State attribute is always initially provided by the server in 147 an Access-Accept, Access-Challenge, CoA-Request or Disconnect- 148 Request, a RADIUS client MUST NOT insert a State attribute that it 149 has not previously received from the server. 151 A State attribute is REQUIRED in Access-Request packets neither 152 including an authentication attribute nor a Service-Type attribute 153 with the value Call Check (10). 155 2.1.2. Request-ID Supplementation 157 [RFC3579] Section 2.6.1 states: 159 In EAP, each session has its own unique Identifier space. RADIUS 160 server implementations MUST be able to distinguish between EAP 161 packets with the same Identifier existing within distinct 162 sessions, originating on the same NAS. For this purpose, sessions 163 can be distinguished based on NAS and session identification 164 attributes. NAS identification attributes include NAS-Identifier, 165 NAS-IPv6-Address and NAS-IPv4-Address. Session identification 166 attributes include User-Name, NAS-Port, NAS-Port-Type, NAS-Port- 167 Id, Called-Station-Id, Calling-Station-Id and Originating-Line- 168 Info. 170 There are issues with the suggested algorithm. Since proxies may 171 modify Access-Request attributes such as NAS-IP-Address, depending on 172 any attribute under control of the NAS to distinguish request 173 identifiers can result in deployment problems. 175 The FreeRADIUS implementation does not track EAP identifiers by NAS- 176 IP-Address or other non-EAP attributes sent by the NAS. Instead, it 177 uses the EAP identifier, source IP address, and the State attribute 178 as a "key" to uniquely identify each EAP session. Since the State 179 attribute is under the control of the RADIUS server, this means that 180 the uniqueness of each session is controlled by the server, not the 181 NAS. The algorithm used in FreeRADIUS is as follows: 183 if (EAP start, or EAP identity) { 184 allocate unique State Attribute 185 insert session into "active session" table 186 with key (EAP identifier, State, source IP) 187 } else { 188 look up active session in table, with above key 189 } 191 This algorithm appears to work well in variety of situations, 192 including situations where home servers receive messages via 193 intermediate RADIUS proxies. 195 2.2. Overload Conditions 197 2.2.1. Retransmission Behavior 199 [RFC2865] Section 2.4 describes the retransmission requirements for 200 RADIUS clients: 202 At one extreme, RADIUS does not require a "responsive" detection 203 of lost data. The user is willing to wait several seconds for the 204 authentication to complete. The generally aggressive TCP 205 retransmission (based on average round trip time) is not required, 206 nor is the acknowledgment overhead of TCP. 208 At the other extreme, the user is not willing to wait several 209 minutes for authentication. Therefore the reliable delivery of 210 TCP data two minutes later is not useful. The faster use of an 211 alternate server allows the user to gain access before giving up. 213 Some existing RADIUS clients implement excessively aggressive 214 retransmission behavior, utilizing default retransmission timeouts of 215 one second or less without support for congestive backoff. When 216 deployed at large scale, these implementations are susceptible to 217 congestive collapse. For example, as the result of a power failure, 218 a network with 3000 NAS devices with a fixed retransmission timer of 219 one second will continuously generate 3000 RADIUS Access-Requests per 220 second. This is sufficient to overwhelm most RADIUS servers. 222 Suggested solutions include: 224 [a] Jitter. To avoid synchronization, a RADIUS client SHOULD 225 incorporate jitter within its retransmission algorithm. 227 [b] Congestive backoff. While it is not necessary for RADIUS client 228 implementations to implement complex retransmission algorithms, 229 implementations SHOULD support congestive backoff within the limits 230 suggested by [RFC2865] Section 2.4. For example, an implementation 231 SHOULD double the initial retransmission timer until a maximum 232 retransmission time is reached, after which the client will 233 failover to another RADIUS server. For example, if the initial 234 retransmission timer is one second, a maximum retransmission timer 235 of 16 seconds might be used. 237 2.2.2. Server Response to Overload 239 Some RADIUS server implementations are not robust in response to 240 overload, dropping packets with even probability across multiple 241 sessions. In an overload situation, this results in a high failure 242 rate for multi-round authentication protocols such as EAP [RFC3579]. 243 Typically, users will continually retry in an attempt to gain access, 244 increasing the load even further. 246 A more sensible approach is for a RADIUS server to preferentially 247 accept RADIUS Access-Request packets containing a valid State 248 attribute, so that multi-round authentication conversations, once 249 begun, will be more likely to succeed. Similarly, a server that is 250 proxying requests should preferentially process Access-Accept, 251 Access-Challenge, or Access-Reject packets from home servers, before 252 processing new requests from a NAS. 254 These methods will allow some users to gain access to the network, 255 reducing the load created by ongoing access attempts. 257 2.3. Accounting Issues 259 2.3.1. Attributes allowed in an Interim Update 261 [RFC2866] indicates that Acct-Input-Octets, Acct-Output-Octets, Acct- 262 Session-Time, Acct-Input-Packets, Acct-Output-Packets and Acct- 263 Terminate-Cause attributes "can only be present in Accounting-Request 264 records where the Acct-Status-Type is set to Stop." 266 However [RFC2869] Section 2.1 states: 268 It is envisioned that an Interim Accounting record (with Acct- 269 Status-Type = Interim-Update (3)) would contain all of the 270 attributes normally found in an Accounting Stop message with the 271 exception of the Acct-Term-Cause attribute. 273 Although [RFC2869] does not indicate that it updates [RFC2866], this 274 is an oversight, and the above attributes are allowable in an Interim 275 Accounting record. 277 2.3.2. NAS handling of Acct-Interim-Update 279 [RFC2869] Section 2.1 states 281 It is also possible to statically configure an interim value on 282 the NAS itself. Note that a locally configured value on the NAS 283 MUST override the value found in an Access-Accept. 285 This requirement may be too strong in practice. If an implementator 286 chooses to permit the Acct-Interim-Interval in an Access-Accept to 287 override a global default for that value, then the implementation 288 MUST enforce a minimum acceptable value on the Acct-Interim-Interval 289 in an Access-Accept. The alternative would be to accept 290 inappropriately small values, which may have performance impact on 291 the NAS. 293 This minimum SHOULD be configurable on the NAS, as a "minimim 294 acceptable Acct-Intim-Interval". 296 2.3.3. Acct-Session-Id and Acct-Multi-Session-Id 298 [RFC2866] Section 5.5 describes Acct-Session-Id as Text within the 299 description, but also states that "The String field SHOULD be a 300 string of UTF-8 encoded 10646 characters." 302 Since Acct-Multi-Session-Id is consistently described as a String, it 303 appears that this is a typographical error, and that Acct-Session-Id 304 is of type String. 306 The implication is that a robust implementation SHOULD support the 307 String fields within Acct-Session-Id and Acct-Multi-Session-Id as 308 undistinguished octets. 310 2.3.4. Request Authenticator 312 [RFC2866] Section 4.1 states: 314 The Request Authenticator of an Accounting-Request contains a 315 16-octet MD5 hash value calculated according to the method 316 described in "Request Authenticator" above. 318 However, the text does not indicate any action to take when an 319 Accounting-Request packet contains an invalid Request Authenticator. 320 The following text should be considered to be part of the above 321 description: 323 The Request Authenticator field MUST contain the correct data, as 324 given by the above calculation. Invalid packets are silently 325 discarded. Note that some early implementations always set the 326 Request Authenticator to all zeros. New implementations of RADIUS 327 clients MUST use the above algorithm to calculate the Request 328 Authenticator field. New RADIUS server implementations MUST 329 silently discard invalid packets. 331 2.4. Multiple Filter-ID Attributes 333 [RFC2865] Section 5.11 states: 335 Zero or more Filter-Id attributes MAY be sent in an Access-Accept 336 packet. 338 In practice the behavior of a RADIUS client receiving multiple 339 Filter-ID attributes is implementation dependent. For example, some 340 implementations treat multiple instances of the Filter-ID attribute 341 as alternative filters; the first Filter-ID attribute having a name 342 matching a locally defined filter is used, and the remaining ones are 343 discarded. Other implementations may combine matching filters. 345 As a result, the interpretation of multiple Filter-ID attributes is 346 undefined within RADIUS. The sending of multiple Filter-ID 347 attributes within an Access-Accept SHOULD be avoided within 348 heterogeneous deployments and roaming scenarios, where it is likely 349 to produce unpredictable results. 351 2.5. Mandatory and Optional Attributes 353 RADIUS attributes do not explicitly state whether they are optional 354 or mandatory. Nevertheless there are instances where RADIUS 355 attributes need to be treated as mandatory. 357 [RFC2865] Section 1.1 states: 359 A NAS that does not implement a given service MUST NOT implement 360 the RADIUS attributes for that service. For example, a NAS that 361 is unable to offer ARAP service MUST NOT implement the RADIUS 362 attributes for ARAP. A NAS MUST treat a RADIUS access-accept 363 authorizing an unavailable service as an access-reject instead. 365 With respect to the Service-Type attribute, [RFC2865] Section 5.6 366 says: 368 This Attribute indicates the type of service the user has 369 requested, or the type of service to be provided. It MAY be used 370 in both Access-Request and Access-Accept packets. A NAS is not 371 required to implement all of these service types, and MUST treat 372 unknown or unsupported Service-Types as though an Access-Reject 373 had been received instead. 375 [RFC2865] Section 5 states: 377 A RADIUS server MAY ignore Attributes with an unknown Type. 378 A RADIUS client MAY ignore Attributes with an unknown Type. 380 With respect to Vendor-Specific Attributes (VSAs), [RFC2865] Section 381 5.26 states: 383 Servers not equipped to interpret the vendor-specific information 384 sent by a client MUST ignore it (although it may be reported). 385 Clients which do not receive desired vendor-specific information 386 SHOULD make an attempt to operate without it, although they may do 387 so (and report they are doing so) in a degraded mode. 389 It is possible for either a standard attribute or VSA to represent a 390 request for an unavailable service. However, where the Type or 391 Vendor-ID is unknown, a RADIUS client will not know whether the 392 attribute defines a service or not. 394 In general, it is best for RADIUS clients to err on the side of 395 caution. On receiving an Access-Accept including an attribute of 396 unknown Type, a RADIUS client SHOULD assume that it is a potential 397 service definition, and treat it as an Access-Reject. Unknown VSAs 398 SHOULD be ignored by RADIUS clients. 400 RADIUS authentication server implementations SHOULD ignore attributes 401 of unknown Type. Since RADIUS accounting server implementations 402 typically do not need to understand attributes in order to write them 403 to stable storage or pass them to the billing engine, accounting 404 server implementations SHOULD be equipped to handle unknown 405 attributes. 407 To avoid misinterpretation of service requests encoded within VSAs, 408 RADIUS servers SHOULD NOT send VSAs containing service requests to 409 RADIUS clients that are not known to understand them. For example, a 410 RADIUS server should not send a VSA encoding a filter without 411 knowledge that the RADIUS client supports the VSA. 413 2.6. Interpretation of Access-Reject 415 2.6.1. Improper Use of Access-Reject 417 The intent of an Access-Reject is to deny access to the requested 418 service. [RFC2865] Section 2 states: 420 If any condition is not met, the RADIUS server sends an "Access- 421 Reject" response indicating that this user request is invalid. If 422 desired, the server MAY include a text message in the Access- 423 Reject which MAY be displayed by the client to the user. No other 424 Attributes (except Proxy-State) are permitted in an Access-Reject. 426 This text makes it clear that RADIUS does not allow the provisioning 427 of services within an Access-Reject. If the desire is to allow 428 limited access, then an Access-Accept can be sent with attributes 429 provisioning limited access. Attributes within an Access-Reject are 430 restricted to those necessary to route the message (e.g. Proxy- 431 State), attributes providing the user with an indication that access 432 has been denied (e.g. an EAP-Message attribute containing an EAP- 433 Failure) or attributes conveying an error message (e.g. a Reply- 434 Message or Error-Cause attribute). 436 Unfortunately, there are examples where this requirement has been 437 misunderstood. [RFC2869] Section 2.2 states: 439 If that authentication fails, the RADIUS server should return an 440 Access-Reject packet to the NAS, with optional Password-Retry and 441 Reply-Messages attributes. The presence of Password-Retry 442 indicates the ARAP NAS MAY choose to initiate another challenge- 443 response cycle, 445 This paragraph is problematic from two perspectives. Firstly, a 446 Password-Retry attribute is being returned in an Access-Reject; this 447 attribute does not fit into the categories established in [RFC2865]. 449 Secondly, an Access-Reject packet is being sent in the context of a 450 continuing authentication conversation; [RFC2865] requires use of an 451 Access-Challenge for this. [RFC2869] uses the phrase "challenge- 452 response" to describe this use of Access-Reject, indicating that the 453 semantics of Access-Challenge are being used. 455 [RFC2865] Section 4.4, addresses the semantics of Access-Challenge 456 being equivalent to Access-Reject in some cases: 458 If the NAS does not support challenge/response, it MUST treat an 459 Access-Challenge as though it had received an Access-Reject 460 instead. 462 While it is difficult to correct existing deployments of [RFC2869], 463 we make the following recommendations: 465 [1] New RADIUS specifications and implementations MUST NOT use Access- 466 Reject where the semantics of Access-Challenge are intended. 468 [2] Access-Reject MUST mean denial of access to the requested service. 469 In response to an Access-Reject, the NAS MUST NOT send any 470 additional Access-Request packets for that user session. 472 [3] New deployments of ARAP [RFC2869] SHOULD use Access-Challenge 473 instead of Access-Reject packets in the conversations described in 474 [RFC2869] Section 2.2. 476 We also note that the table of attributes [RFC2869] Section 5.19 has 477 an error for the Password-Retry attribute. It says: 479 Request Accept Reject Challenge # Attribute 480 0 0 0-1 0 75 Password-Retry 482 However, the text in [RFC2869] Section 2.3.2 says that Password-Retry 483 can be included within an Access-Challenge packet, for EAP 484 authentication sessions. We recommend a correction to the table: 486 Request Accept Reject Challenge # Attribute 487 0 0 0 0-1 75 Password-Retry [Note 2] 489 [Note 2] As per RFC 3579, the use of the Password-Retry in EAP 490 authentications is deprecated. The Password-Retry attribute can be 491 used only for ARAP authentication. 493 2.6.2. Service Request Denial 495 RADIUS has been deployed for purposes outside network access 496 authentication, authorization and accounting. For example, RADIUS 497 has been deployed as a "back-end" for authenticating VOIP 498 connections, HTTP sessions (e.g. Apache), FTP sessions (e.g. 499 proftpd), and machine logins for multiple operating systems (e.g. 500 bsdi, pam, gina). In those contexts, an Access-Reject sent to the 501 RADIUS client MUST be interpreted as a rejection of the request for 502 service, and the RADIUS client MUST NOT offer that service to the 503 user. 505 For example, when an authentication failure occurs in the context of 506 an FTP session, the normal semantics for rejecting FTP services 507 apply. The rejection does not necessarily cause the FTP server to 508 terminate the underlying TCP connection, but the FTP server MUST NOT 509 offer any services protected by user authentication. 511 Users may request multiple services from the NAS. Where those 512 services are independent, the deployment MUST treat the RADIUS 513 sessions as being independent. 515 For example, a NAS may offer multi-link services, where a user may 516 have multiple simultaneous network connections. In that case, an 517 Access-Reject for a later multi-link connection request does not 518 necessarily mean that earlier multi-link connections are torn down. 519 Similarly, if a NAS offers both dialup and VOIP services, the 520 rejection of a VOIP attempt does not mean that the dialup session is 521 torn down. 523 Where a NAS offers multiple services, confusion may result with 524 respect to interpretation of a Disconnect-Request [RFC3576]. In 525 order to prevent confusion a RADIUS Server SHOULD identify the 526 session that it desires to terminate as specifically as possible. 527 For example, an Acct-Session-Id attribute SHOULD be included in 528 Disconnect-Request and CoA-Request packets, rather than just the 529 User-Name attribute. 531 2.7. Addressing 533 2.7.1. Link-Local Addresses 535 Since Link-Local addresses are unique only on the local link, if the 536 NAS and RADIUS server are not on the same link, then an IPv6 Link- 537 Local address [RFC2462] or an IPv4 Link-Local Address [RFC3927] 538 cannot be used to uniquely identify the NAS. A RADIUS server 539 receiving a NAS-IPv6-Address or NAS-IP-Address attribute containing a 540 Link-Local address SHOULD NOT count such an attribute toward 541 satisfying the requirements of [RFC3162] Section 2.1: 543 NAS-IPv6-Address and/or NAS-IP-Address MAY be present in an 544 Access-Request packet; however, if neither attribute is present 545 then NAS-Identifier MUST be present. 547 2.7.2. Multiple Addresses 549 There are situations in which a RADIUS client or server may have 550 multiple addresses. For example, a dual stack host can have both 551 IPv4 and IPv6 addresses; a host that is a member of multiple VLANs 552 could have IPv4 and/or IPv6 addresses on each VLAN; a host can have 553 multiple IPv4 or IPv6 addresses on a single interface. However, 554 [RFC2865] Section 5.44 only permits zero or one NAS-IP-Address 555 attribute within an Access-Request and [RFC3162] Section 3 only 556 permits zero or one NAS-IPv6-Address attribute within an Access- 557 Request. When a NAS has more than one global address and no ability 558 to determine which is used for identification in a particular 559 request, it is RECOMMENDED that the NAS include the NAS-Identifier 560 attribute in an Access-Request in order to identify itself to the 561 RADIUS server. 563 [RFC2865] Section 3 states: 565 A RADIUS server MUST use the source IP address of the RADIUS 566 UDP packet to decide which shared secret to use, so that 567 RADIUS requests can be proxied. 569 Therefore if a RADIUS client sends packets from more than one source 570 address, a shared secret will need to be configured on both the 571 client and server for each source address. 573 2.8. Idle-Timeout 575 With respect to the Idle-Timeout attribute, [RFC2865] Section 5.28 576 states: 578 This Attribute sets the maximum number of consecutive seconds of 579 idle connection allowed to the user before termination of the 580 session or prompt. This Attribute is available to be sent by the 581 server to the client in an Access-Accept or Access-Challenge. 583 [RFC3580] Section 3.12 states: 585 The Idle-Timeout attribute is described in [RFC2865]. For IEEE 586 802 media other than 802.11 the media are always on. As a result 587 the Idle-Timeout attribute is typically only used with wireless 588 media such as IEEE 802.11. It is possible for a wireless device 589 to wander out of range of all Access Points. In this case, the 590 Idle-Timeout attribute indicates the maximum time that a wireless 591 device may remain idle. 593 In the above paragraphs "idle" may not necessarily mean "no traffic"; 594 the NAS may support filters defining what traffic is included in the 595 idle time determination. As a result, an "idle connection" is 596 defined by local policy in the absence of other attributes. 598 2.9. Unknown Identity 600 [RFC3748] Section 5.1 states: 602 If the Identity is unknown, the Identity Response field 603 should be zero bytes in length. 605 However, [RFC2865] Section 5.1 describes the User-Name attribute as 606 follows: 608 The String field is one or more octets. 610 How should the RADIUS client behave if it receives an EAP- 611 Response/Identity that is zero octets in length? 613 [RFC2865] Section 5.1 states: 615 This Attribute indicates the name of the user to be authenticated. 616 It MUST be sent in Access-Request packets if available. 618 This suggests that the User-Name attribute may be ommitted if it is 619 unavailable. 621 However, [RFC3579] Section 2.1 states: 623 In order to permit non-EAP aware RADIUS proxies to forward the 624 Access-Request packet, if the NAS initially sends an 625 EAP-Request/Identity message to the peer, the NAS MUST copy the 626 contents of the Type-Data field of the EAP-Response/Identity 627 received from the peer into the User-Name attribute and MUST 628 include the Type-Data field of the EAP-Response/Identity in the 629 User-Name attribute in every subsequent Access-Request. 631 This suggests that the User-Name attribute should contain the 632 contents of the Type-Data field of the EAP-Response/Identity, even if 633 it is zero octets in length. 635 Note that [RFC4282] does not permit an NAI of zero octets, so that an 636 EAP-Response/Identity with a Type-Data field of zero octets MUST NOT 637 be construed as a request for privacy (e.g. anonymous NAI). 639 When a NAS receives an EAP-Response/Identity with a Type-Data field 640 that is zero octets in length, it is RECOMMENDED that it either omit 641 a User-Name attribute in the Access-Request or include the Calling- 642 Station-Id in the User-Name attribute, along with a Calling-Station- 643 Id attribute. 645 2.10. Responses after retransmissions. 647 Some implementations do not correctly handle the receipt of RADIUS 648 responses after retransmissions. [RFC2865] Section 2.5 states 650 If the NAS is retransmitting a RADIUS request to the same server 651 as before, and the attributes haven't changed, you MUST use the 652 same Request Authenticator, ID, and source port. If any 653 attributes have changed, you MUST use a new Request Authenticator 654 and ID. 656 Note that changing the Request ID for a retransmission may have 657 undesirable side effects. Since RADIUS does not have a clear 658 definition of a "session", it is perfectly valid for a RADIUS server 659 to treat a retransmission as a new session request, and to reject it 660 due to (say) multiple simultaneous login restrictions are enforced. 661 In that situation, the NAS may receive a belated Access-Accept for 662 the first request, and an Access-Reject for the retransmitted 663 request, both of which apply to the same "session". 665 We suggest that the contents of Access-Request packets SHOULD NOT be 666 changed during retransmissions. If they must be changed due to the 667 inclusion of an Event-Timestampt attribute, for example, then 668 responses to earlier transmissions MUST be silently discarded. Any 669 response to the current request MUST be treated as the definitive 670 response, even if as noted above, it disagrees with earlier 671 responses. 673 This problem can be made worse by implementations that use a fixed 674 retransmission timeout (30 seconds is common). We reiterate the 675 suggestions above in Section 2.1 about using congestive backoff. In 676 that case, responses to earlier transmissions MAY be used as data 677 points for congestive backoff, even if their contents are discarded. 679 2.11. Framed-IPv6-Prefix 681 [RFC3162] Section 2.3 says 683 This Attribute indicates an IPv6 prefix (and corresponding route) 684 to be configured for the user. It MAY be used in Access-Accept 685 packets, and can appear multiple times. It MAY be used in an 686 Access-Request packet as a hint by the NAS to the server that it 687 would prefer these prefix(es), but the server is not required to 688 honor the hint. Since it is assumed that the NAS will plumb a 689 route corresponding to the prefix, it is not necessary for the 690 server to also send a Framed-IPv6-Route attribute for the same 691 prefix. 693 If an ISP desires to support Prefix Delegation at the same time that 694 it would like to assign a prefix for the link between the NAS and 695 customer premises equipment (CPE). In this situation, the sematics of 696 Framed-IPv6-Prefix may be unclear, in that it is difficult to know 697 which prefixes are to be used for delegation, and which one is to be 698 used for the link. The intent of the paragraph was to enable the NAS 699 to advertise the prefix (such as via a Router Advertisement). If the 700 Framed-Routing attribute is used, it is also possible that the prefix 701 would be advertised in a routing protocol such as RIPNG. RFC 2865 702 Section 5.10 describes the purpose of Framed-Routing: 704 This Attribute indicates the routing method for the user, when the 705 user is a router to a network. It is only used in Access-Accept 706 packets. 708 The description of the Prefix-Length field in RFC 3162 indicates 709 excessively wide latitude: 711 The length of the prefix, in bits. At least 0 and no larger than 712 128. 714 This length appears too broad, because it is not clear what a NAS 715 should do with a prefix of greater granularity than /64. For example, 716 the Framed-IPv6-Prefix may contain a /128. This does not imply that 717 the NAS should assign an IPv6 address to the end user, because RFC 718 3162 already defines a Framed-IPv6-Identifier attribute to handle the 719 Identifier portion. 721 It appears that the Framed-IPv6-Prefix is used for the link between 722 the NAS and CPE only if a /64 prefix is assigned. When a larger 723 prefix is sent, the intent is to provide the entire prefix to the 724 CPE, enabling the CPE to assign sub-prefixes if it wishes to do so. 726 3. IANA Considerations 728 This specification does not create any new registries, nor does it 729 require assignment of any protocol parameters. 731 4. Security Considerations 733 Since this document describes the use of RADIUS for purposes of 734 authentication, authorization, and accounting in WLANs, it is 735 vulnerable to all of the threats that are present in other RADIUS 736 applications. For a discussion of these threats, see [RFC2865], 738 [RFC2607], [RFC3162], [RFC3576], [RFC3579], and [RFC3580]. 740 5. References 742 5.1. Informative references 744 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 745 Requirement Levels", RFC 2119, March, 1997. 747 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 748 Autoconfiguration", RFC 2462, December 1998. 750 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 751 Implementation in Roaming", RFC 2607, June 1999. 753 [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 754 Authentication Dial In User Service (RADIUS)", RFC 2865, June 755 2000. 757 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 759 [RFC2867] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting 760 Modifications for Tunnel Protocol Support", RFC 2867, June 761 2000. 763 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. 764 and I. Goyret, "RADIUS Attributes for Tunnel Protocol 765 Support", RFC 2868, June 2000. 767 [RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", 768 RFC 2869, June 2000. 770 [RFC2882] Mitton, D., "Network Access Servers Requirements: Extended 771 RADIUS Practices", RFC 2882, July 2000. 773 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 774 3162, August 2001. 776 [RFC3575] Aboba, B., "IANA Considerations for RADIUS", RFC 3575, July 777 2003. 779 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, 780 "Dynamic Authorization Extensions to Remote Authentication 781 Dial In User Service (RADIUS)", RFC 3576, July 2003. 783 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 784 Authentication Protocol (EAP)", RFC 3579, September 2003. 786 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 787 "IEEE 802.1X Remote Authentication Dial In User Service 788 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 790 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 791 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 792 3748, June 2004. 794 [RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration 795 of IPv4 Link-Local Addresses", RFC 3927, May 2005. 797 [RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Network 798 Access Identifier", RFC 4282, December 2005. 800 Acknowledgments 802 The authors would like to acknowledge Glen Zorn for contributions to 803 this document. 805 The alternate algorithm to [RFC3579] Section 2.6.1 that is described 806 in section 2.1.2 of this document was designed by Raghu Dendukuri. 808 Authors' Addresses 810 David B. Nelson 811 Enterasys Networks 812 50 Minuteman Road 813 Andover, MA 01810 815 Email: dnelson@enterasys.com 817 Alan DeKok 818 The FreeRADIUS Server Project 819 http://freeradius.org/ 821 Email: aland@freeradius.org 823 Intellectual Property Statement 825 The IETF takes no position regarding the validity or scope of any 826 Intellectual Property Rights or other rights that might be claimed to 827 pertain to the implementation or use of the technology described in 828 this document or the extent to which any license under such rights 829 might or might not be available; nor does it represent that it has 830 made any independent effort to identify any such rights. Information 831 on the procedures with respect to rights in RFC documents can be 832 found in BCP 78 and BCP 79. 834 Copies of IPR disclosures made to the IETF Secretariat and any 835 assurances of licenses to be made available, or the result of an 836 attempt made to obtain a general license or permission for the use of 837 such proprietary rights by implementers or users of this 838 specification can be obtained from the IETF on-line IPR repository at 839 http://www.ietf.org/ipr. 841 The IETF invites any interested party to bring to its attention any 842 copyrights, patents or patent applications, or other proprietary 843 rights that may cover technology that may be required to implement 844 this standard. Please address the information to the IETF at ietf- 845 ipr@ietf.org. 847 Disclaimer of Validity 849 This document and the information contained herein are provided on an 850 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 851 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 852 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 853 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 854 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 855 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 857 Copyright Statement 859 Copyright (C) The IETF Trust (2006). This document is subject to the 860 rights, licenses and restrictions contained in BCP 78, and except as 861 set forth therein, the authors retain all their rights. 863 Acknowledgment 865 Funding for the RFC Editor function is currently provided by the 866 Internet Society. 868 Open issues 870 Open issues relating to this specification are tracked on the 871 following web site: 873 http://www.drizzle.com/~aboba/RADEXT/