idnits 2.17.1 draft-ietf-radext-fixes-08.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1253. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1230. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1237. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1243. 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 == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. (Using the creation date from RFC2865, updated by this document, for RFC5378 checks: 1999-03-04) (Using the creation date from RFC2869, updated by this document, for RFC5378 checks: 1998-04-10) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (13 September 2007) is 6042 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 831 -- Looks like a reference, but probably isn't: '2' on line 834 -- Looks like a reference, but probably isn't: '3' on line 838 == Missing Reference: 'Note 2' is mentioned on line 858, but not defined -- 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 3315 (Obsoleted by RFC 8415) -- 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 (~~), 3 warnings (==), 19 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: March 13, 2008 8 13 September 2007 10 Common Remote Authentication Dial In User Service (RADIUS) 11 Implementation Issues and Suggested Fixes 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 13, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes common issues seen in RADIUS implementations 43 and suggests some fixes. Where applicable, ambiguities and errors in 44 previous RADIUS specifications are clarified. 46 Table of Contents 48 1. Introduction ............................................. 3 49 1.1. Terminology ......................................... 3 50 1.2. Requirements Language ............................... 3 51 2. Issues ................................................... 4 52 2.1. Session Definition .................................. 4 53 2.1.1. State Attribute ................................ 4 54 2.1.2. Request-ID Supplementation ..................... 6 55 2.2. Overload Conditions ................................. 7 56 2.2.1. Retransmission Behavior ........................ 7 57 2.2.2. Duplicate detection and orderly delivery. ...... 10 58 2.2.3. Server Response to Overload .................... 11 59 2.3. Accounting Issues ................................... 12 60 2.3.1. Attributes allowed in an Interim Update ........ 12 61 2.3.2. Acct-Session-Id and Acct-Multi-Session-Id ...... 12 62 2.3.3. Request Authenticator .......................... 13 63 2.3.4. Interim-Accounting-Interval .................... 13 64 2.3.5. Counter values in the RADIUS Management Informat 14 65 2.4. Multiple Filter-ID Attributes ....................... 15 66 2.5. Mandatory and Optional Attributes ................... 16 67 2.6. Interpretation of Access-Reject ..................... 17 68 2.6.1. Improper Use of Access-Reject .................. 17 69 2.6.2. Service Request Denial ......................... 19 70 2.7. Addressing .......................................... 20 71 2.7.1. Link-Local Addresses ........................... 20 72 2.7.2. Multiple Addresses ............................. 20 73 2.8. Idle-Timeout ........................................ 21 74 2.9. Unknown Identity .................................... 21 75 2.10. Responses after retransmissions .................... 22 76 2.11. Framed-IPv6-Prefix ................................. 23 77 3. IANA Considerations ...................................... 24 78 4. Security Considerations .................................. 24 79 5. References ............................................... 24 80 5.1. Normative references ................................ 25 81 5.2. Informative references .............................. 25 82 Intellectual Property Statement .............................. 27 83 Disclaimer of Validity ....................................... 28 84 Full Copyright Statement ..................................... 28 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 in IEEE 802.1X or Extensible Authentication Protocol 100 (EAP) terminology, or RADIUS client. 102 service 103 The NAS provides a service to the user, such as network access via 104 802.11 or Point to Point Protocol (PPP). 106 session 107 Each service provided by the NAS to a peer constitutes a session, 108 with the beginning of the session defined as the point where 109 service is first provided and the end of the session defined as the 110 point where service is ended. A peer may have multiple sessions in 111 parallel or series if the NAS supports that, with each session 112 generating a separate start and stop accounting record. 114 silently discard 115 This means the implementation discards the packet without further 116 processing. The implementation SHOULD provide the capability of 117 logging the error, including the contents of the silently discarded 118 packet, and SHOULD record the event in a statistics counter. 120 1.2. Requirements Language 122 In this document, several words are used to signify the requirements 123 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 124 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 125 and "OPTIONAL" in this document are to be interpreted as described in 126 [RFC2119]. 128 2. Issues 130 2.1. Session Definition 132 2.1.1. State Attribute 134 Regarding the State attribute, [RFC2865] Section 5.24 states: 136 This Attribute is available to be sent by the server to the client 137 in an Access-Challenge and MUST be sent unmodified from the client 138 to the server in the new Access-Request reply to that challenge, 139 if any. 141 This Attribute is available to be sent by the server to the client 142 in an Access-Accept that also includes a Termination-Action 143 Attribute with the value of RADIUS-Request. If the NAS performs 144 the Termination-Action by sending a new Access-Request upon 145 termination of the current session, it MUST include the State 146 attribute unchanged in that Access-Request. 148 Some RADIUS client implementations do not properly use the State 149 attribute in order to distinguish a restarted EAP authentication 150 process from the continuation of an ongoing process (by the same user 151 on the same NAS and port). Where an EAP-Message attribute is 152 included in an Access-Challenge or Access-Accept attribute, RADIUS 153 servers SHOULD also include a State attribute. See Section 2.1.2 on 154 Request ID supplementation for additional benefits to using the State 155 attribute in this fashion. 157 As defined in [RFC2865] Table 5.44, Access-Request packets may 158 contain a State attribute. The table does not qualify this 159 statement, while the text in Section 5.24 quoted above adds other 160 requirements not specified in that table. 162 We extend the requirements of [RFC2865] to say that Access-Requests 163 which are part of an ongoing Access-Request / Access-Challenge 164 authentication process SHOULD contain a State attribute. It is the 165 responsibility of the server to send a State attribute in an Access- 166 Challenge packet, if that server needs a State attribute in a 167 subsequent Access-Request to tie multiple Access-Requests togther 168 into one authentication session. As defined in [RFC2865] Section 169 5.24, the State MUST be sent unmodified from the client to the server 170 in the new Access-Request reply to that challenge, if any. 172 While most server implementations require the presence of a State 173 attribute in an Access-Challenge packet, some challenge-response 174 systems can distinguish the initial request from the response to the 175 challenge without using a State attribute to track an authentication 176 session. The Access-Challenge and subsequent Access-Request packets 177 for those systems do not need to contain a State attribute. 179 Other authentication mechanisms need to tie a sequence of Access- 180 Request / Access-Challenge packets together into one ongoing 181 authentication session. Servers implementing those authentication 182 mechanisms SHOULD include a State attribute in Access-Challenge 183 packets. 185 In general, if the authentication process involves one or more 186 Access-Request / Access-Challenge sequences, the State attribute 187 SHOULD be sent by the server in the Access-Challenge packets. Using 188 the State attribute to create a multi-packet session is the simplest 189 method available in RADIUS today. While other methods of creating 190 multi-packet sessions are possible (e.g. [RFC3579] Section 2.6.1), 191 those methods are NOT RECOMMENDED. 193 The only permissible values for a State attribute are values provided 194 in an Access-Accept, Access-Challenge, CoA-Request or Disconnect- 195 Request packet. A RADIUS client MUST use only those values for the 196 State attribute that it has previously received from a server. An 197 Access-Request sent as a result of a new or restarted authentication 198 run MUST NOT include the State attribute, even if a State attribute 199 has previously been received in an Access-Challenge for the same user 200 and port. 202 Access-Request packets that contain a Service-Type attribute with 203 value Authorize Only (17) MUST contain a State attribute. Access- 204 Request packets that contain a Service-Type attribute with value Call 205 Check (10) SHOULD NOT contain a State attribute. Any other Access- 206 Request packet that performs authorization checks MUST contain a 207 State attribute. This last requirement often means that an Access- 208 Accept needs to contain a State attribute, which can then be used in 209 a later Access-Request that performs authorization checks. 211 The standard use case for Call-Check is pre-screening authentication 212 based solely on the end-point identifier information, such as phone 213 number or MAC address in Calling-Station-ID and optionally Called- 214 Station-ID. In this use case, the NAS has no way to obtain a State 215 Attribute suitable for inclusion in an Access-Request. Other, non- 216 standard, uses of Call-Check may require or permit the use of a State 217 Attribute, but are beyond the scope of this document. 219 In an Access-Request with a Service-Type Attribute with value "Call 220 Check", it is NOT RECOMMENDED for the User-Name and User-Password 221 attributes to contain the same values (e.g. a MAC address). 222 Implementing MAC address checking without using a Service-Type of 223 Call Check is NOT RECOMMENDED. This practice gives an attacker both 224 the clear-text and cipher-text of the User-Password field, which 225 permits many attacks on the security of the RADIUS protocol. For 226 example, if the Request Authenticator does not satisfy the [RFC2865] 227 requirements on global and temporal uniqueness, the practice 228 described above may lead to the compromise of the User-Password 229 attribute in other Access-Requests for unrelated users. Access to 230 the cipher-text enabes offline dictionary attacks, potentially 231 exposing the shared secret, and compromising the entire RADIUS 232 protocol. 234 Any Access-Request packet that performs authorization checks, 235 including Call Check, SHOULD contain a Message-Authenticator 236 attribute. Any response to an Access-Request performing an 237 authorization check MUST NOT contain confidential information about 238 any user (such as Tunnel-Password), unless that Access-Request 239 contains a State attribute. The use of State here permits the 240 authorization check to be tied to an earlier user authentication. In 241 that case, the server MAY respond to the NAS with confidential 242 information about that user. The server MUST NOT respond to that 243 authorization check with confidential information about any other 244 user. 246 For an Access-Request packet performing an authorization check that 247 does not contain a State attribute, the server MUST response with an 248 Access-Reject. 250 2.1.2. Request-ID Supplementation 252 [RFC3579] Section 2.6.1 states: 254 In EAP, each session has its own unique Identifier space. RADIUS 255 server implementations MUST be able to distinguish between EAP 256 packets with the same Identifier existing within distinct 257 sessions, originating on the same NAS. For this purpose, sessions 258 can be distinguished based on NAS and session identification 259 attributes. NAS identification attributes include NAS-Identifier, 260 NAS-IPv6-Address and NAS-IPv4-Address. Session identification 261 attributes include User-Name, NAS-Port, NAS-Port-Type, NAS-Port- 262 Id, Called-Station-Id, Calling-Station-Id and Originating-Line- 263 Info. 265 There are issues with the suggested algorithm. Since proxies may 266 modify Access-Request attributes such as NAS-IP-Address, depending on 267 any attribute under control of the NAS to distinguish request 268 identifiers can result in deployment problems. 270 The FreeRADIUS implementation does not track EAP identifiers by NAS- 271 IP-Address or other non-EAP attributes sent by the NAS. Instead, it 272 uses the EAP identifier, source Internet Protocol (IP) address, and 273 the State attribute as a "key" to uniquely identify each EAP session. 274 Since the State attribute is under the control of the RADIUS server, 275 this means that the uniqueness of each session is controlled by the 276 server, not the NAS. The algorithm used in FreeRADIUS is as follows: 278 if (EAP start, or EAP identity) { 279 allocate unique State Attribute 280 insert session into "active session" table with 281 key=(EAP identifier, State, source IP) 282 } else { 283 look up active session in table, with above key 284 } 286 This algorithm appears to work well in variety of situations, 287 including situations where home servers receive messages via 288 intermediate RADIUS proxies. 290 Implementations that do not use this algorithm are often restricted 291 to having an EAP Identifier space per NAS, or perhaps one that is 292 global to the implementation. These restrictions are unnecessary 293 when the above algorithm is used, which gives each session a unique 294 EAP Identifier space. The above algorithm SHOULD be used to track 295 EAP sessions in preference to any other method. 297 2.2. Overload Conditions 299 2.2.1. Retransmission Behavior 301 [RFC2865] Section 2.4 describes the retransmission requirements for 302 RADIUS clients: 304 At one extreme, RADIUS does not require a "responsive" detection 305 of lost data. The user is willing to wait several seconds for the 306 authentication to complete. The generally aggressive Transmission 307 Control Protocol (TCP) retransmission (based on average round trip 308 time) is not required, nor is the acknowledgment overhead of TCP. 310 At the other extreme, the user is not willing to wait several 311 minutes for authentication. Therefore the reliable delivery of 312 TCP data two minutes later is not useful. The faster use of an 313 alternate server allows the user to gain access before giving up. 315 Some existing RADIUS clients implement excessively aggressive 316 retransmission behavior, utilizing default retransmission timeouts of 317 one second or less without support for congestive backoff. When 318 deployed at large scale, these implementations are susceptible to 319 congestive collapse. For example, as the result of a power failure, 320 a network with 3000 NAS devices with a fixed retransmission timer of 321 one second will continuously generate 3000 RADIUS Access-Requests per 322 second. This is sufficient to overwhelm most RADIUS servers. 324 Suggested solutions include: 326 [a] Jitter. To avoid synchronization, a RADIUS client SHOULD 327 incorporate induced jitter within its retransmission algorithm, as 328 specified below. 330 [b] Congestive backoff. While it is not necessary for RADIUS client 331 implementations to implement complex retransmission algorithms, 332 implementations SHOULD support congestive backoff. 334 RADIUS retransmission timers are based on the model used in DHCPv6 335 [RFC3315]. Variables used here are also borrowed from this 336 specification. RADIUS is a request/response-based protocol. The 337 message exchange terminates when the requester successfully receives 338 the answer or the message exchange is considered to have failed 339 according to the RECOMMENDED retransmission mechanism described 340 below. Other retransmission mechanisms are possible, so long as they 341 satisfy the requirements on jitter and congestive backoff. 343 The following algorithms apply to any client that originates RADIUS 344 packets, including but not limited to Access-Request, Accounting- 345 Request, Disconnect-Request, and CoA-Request [RFC3576]. 347 The retransmission behavior is controlled and described by the 348 following variables: 350 RT Retransmission timeout 352 IRT Initial retransmission time (default 2 seconds) 354 MRC Maximum retransmission count (default 10 attempts) 356 MRT Maximum retransmission time (default 16 seconds) 358 MRD Maximum retransmission duration (default 30 seconds) 360 RAND Randomization factor 362 With each message transmission or retransmission, the sender sets RT 363 according to the rules given below. If RT expires before the message 364 exchange terminates, the sender recomputes RT and retransmits the 365 message. 367 Each of the computations of a new RT include a randomization factor 368 (RAND), which is a random number chosen with a uniform distribution 369 between -0.1 and +0.1. The randomization factor is included to 370 minimize synchronization of messages. 372 The algorithm for choosing a random number does not need to be 373 cryptographically sound. The algorithm SHOULD produce a different 374 sequence of random numbers from each invocation. 376 RT for the first message transmission is based on IRT: 378 RT = IRT + RAND*IRT 380 RT for each subsequent message retransmission is based on the 381 previous value of RT: 383 RT = 2*RTprev + RAND*RTprev 385 MRT specifies an upper bound on the value of RT (disregarding the 386 randomization added by the use of RAND). If MRT has a value of 0, 387 there is no upper limit on the value of RT. Otherwise: 389 if (RT > MRT) 390 RT = MRT + RAND*MRT 392 MRD specifies an upper bound on the length of time a sender may 393 retransmit a message. The message exchange fails once MRD seconds 394 have elapsed since the client first transmitted the message. MRD 395 MUST be set, and SHOULD have a value between 5 and 30 seconds. These 396 values mirror the values for a servers duplicate detection cache, as 397 described in the next section. 399 MRC specifies an upper bound on the number of times a sender may 400 retransmit a message. if MRC is zero, the message exchange fails 401 once MRD seconds have elapsed since the client first transmitted the 402 message. If MRC is non-zero, the message exchange fails when the 403 either the sender has transmitted the message MRC times, or when MRD 404 seconds have elapsed since the client first transmitted the message. 406 For Accounting-Request packets, the default values for MRC, MRD, and 407 MRT SHOULD be zero. These settings will enable a RADIUS client to 408 continue sending accounting requests to a RADIUS server until the 409 request is acknowledged. If any of MRC, MRD, or MRT are non-zero, 410 then the accounting information could potentially be discarded 411 without being recorded. 413 2.2.2. Duplicate detection and orderly delivery. 415 When packets are retransmitted by a client, the server may receive 416 duplicate requests. The limitations of the transport protocol used 417 by RADIUS, the User Datagram Protocol (UDP), means that the Access- 418 Request packets may be received, and potentially processed, in an 419 order different from the order in which the packets were sent. 420 However, the discussion of the Identifier field in Section 3 of 421 [RFC2865] says: 423 The RADIUS server can detect a duplicate request if it has the 424 same client source IP address and source UDP port and Identifier 425 within a short span of time. 427 Also, Section 7 of [RFC4669] defines a 428 radiusAuthServDupAccessRequests object, as 430 The number of duplicate Access-Request packets received. 432 This text has a number of implications. First, without duplicate 433 detection, a RADIUS server may process an authentication request 434 twice, leading to an erroneous conclusion that a user has logged in 435 twice. That behavior is undesirable, so duplicate detection is 436 desirable. Second, the server may track not only the duplicate 437 request, but also the replies to those requests. This behavior 438 permits the server to send duplicate replies in response to duplicate 439 requests, increasing network stability. 441 Since Access-Request packets may also be sent by the client in 442 response to an Access-Challenge from the server, those packets form a 443 logically ordered stream, and therefore have additional ordering 444 requirements over Access-Request packets for different sessions. 445 Implementing duplicate detection results in new packets being 446 processed only once, ensuring order. 448 RADIUS servers MUST therefore implement duplicate detection for 449 Access-Request packets, as described in Section 3 of [RFC2865]. 450 Implementations MUST also cache the Responses (Access-Accept, Access- 451 Challenge, or Access-Reject) that they send in response to Access- 452 Request packets. If a server receives a valid duplicate Access- 453 Request for which is already has sent a Response, it MUST resend its 454 original Response without reprocessing the request. The server MUST 455 silently discard any duplicate Access-Requests for which a Response 456 has not been sent yet. 458 Each cache entry SHOULD be purged after a period of time. This time 459 SHOULD be no less than 5 seconds, and no more than 30 seconds. After 460 about 30 seconds, most RADIUS clients and end users will have given 461 up on the authentication request. Therefore, there is little value 462 in having a larger cache timeout. 464 Cache entries MUST also be purged if the server receives a valid 465 Access-Request packet that matches a cached Access-Request packet in 466 source address, source port, RADIUS Identifier, and receiving socket, 467 but where the Request Authenticator field is different from the one 468 in the cached packet. If the request contains a Message- 469 Authenticator attribute, the request MUST be processed as described 470 in [RFC3580] Section 3.2. Packets with invalid Message- 471 Authenticators MUST NOT affect the cache in any way. 473 However, Access-Request packets not containing a Message- 474 Authenticator attribute always affect the cache, even though they may 475 be trivially forged. To avoid this issue, server implementations may 476 be configured to require the presence of a Message-Authenticator 477 attribute in Access-Request packets. Requests not containing a 478 Message-Authenticator attribute MAY then be silently discarded. 480 Client implementations SHOULD include a Message-Authenticator 481 attribute in every Access-Request, to further help mitigate this 482 issue. 484 When sending requests, RADIUS clients MUST NOT re-use Identifiers for 485 a source IP address and source UDP port until either a valid response 486 has been received, or the request has timed out. Clients SHOULD 487 allocate Identifiers via a least-recently-used (LRU) method for a 488 particular source IP address and source UDP port 490 RADIUS clients do not have to perform duplicate detection. When a 491 client sends a request, it processes the first response that has a 492 valid Response Authenticator as defined in [RFC2865] Section 3. Any 493 later responses MUST be silently discarded, as they do not match a 494 pending request. That is, later responses are treated exactly the 495 same as unsolicited responses, and are silently discarded. 497 2.2.3. Server Response to Overload 499 Some RADIUS server implementations are not robust in response to 500 overload, dropping packets with even probability across multiple 501 sessions. In an overload situation, this results in a high failure 502 rate for multi-round authentication protocols such as EAP [RFC3579]. 503 Typically, users will continually retry in an attempt to gain access, 504 increasing the load even further. 506 A more sensible approach is for a RADIUS server to preferentially 507 accept RADIUS Access-Request packets containing a valid State 508 attribute, so that multi-round authentication conversations, once 509 begun, will be more likely to succeed. Similarly, a server that is 510 proxying requests should preferentially process Access-Accept, 511 Access-Challenge, or Access-Reject packets from home servers, before 512 processing new requests from a NAS. 514 These methods will allow some users to gain access to the network, 515 reducing the load created by ongoing access attempts. 517 2.3. Accounting Issues 519 2.3.1. Attributes allowed in an Interim Update 521 [RFC2866] indicates that Acct-Input-Octets, Acct-Output-Octets, Acct- 522 Session-Time, Acct-Input-Packets, Acct-Output-Packets and Acct- 523 Terminate-Cause attributes "can only be present in Accounting-Request 524 records where the Acct-Status-Type is set to Stop." 526 However [RFC2869] Section 2.1 states: 528 It is envisioned that an Interim Accounting record (with Acct- 529 Status-Type = Interim-Update (3)) would contain all of the 530 attributes normally found in an Accounting Stop message with the 531 exception of the Acct-Term-Cause attribute. 533 Although [RFC2869] does not indicate that it updates [RFC2866], this 534 is an oversight, and the above attributes are allowable in an Interim 535 Accounting record. 537 2.3.2. Acct-Session-Id and Acct-Multi-Session-Id 539 [RFC2866] Section 5.5 describes Acct-Session-Id as Text within the 540 figure summarizing the attribute format, but then goes to state that 541 "The String field SHOULD be a string of UTF-8 encoded 10646 542 characters." 544 [RFC2865] defines the "Text" type as "containing UTF-8 encoded 10646 545 characters", which is compatible with the description of Acct- 546 Session-Id. Since other attributes are consistently described as 547 "Text" within both the figure summarizing the attribute format, and 548 the following attribute definition, it appears that this is a 549 typographical error, and that Acct-Session-Id is of type Text, and 550 not of type String. 552 The definition of the Acct-Multi-Session-Id attribute also has 553 typographical errors. It says 555 A summary of the Acct-Session-Id attribute format ... 557 This text should read 559 A summary of the Acct-Multi-Session-Id attribute format ... 561 The Acct-Multi-Session-Id attribute is also defined as being of type 562 "String". However, the language in the text strongly recommends that 563 implementors consider the attribute as being of type "Text". It is 564 unclear why the type "String" was chosen for this attribute when the 565 type "Text" would be sufficient. This attribute SHOULD be treated as 566 "Text". 568 2.3.3. Request Authenticator 570 [RFC2866] Section 4.1 states: 572 The Request Authenticator of an Accounting-Request contains a 573 16-octet MD5 hash value calculated according to the method 574 described in "Request Authenticator" above. 576 However, the text does not indicate any action to take when an 577 Accounting-Request packet contains an invalid Request Authenticator. 578 The following text should be considered to be part of the above 579 description: 581 The Request Authenticator field MUST contain the correct data, as 582 given by the above calculation. Invalid packets are silently 583 discarded. Note that some early implementations always set the 584 Request Authenticator to all zeros. New implementations of RADIUS 585 clients MUST use the above algorithm to calculate the Request 586 Authenticator field. New RADIUS server implementations MUST 587 silently discard invalid packets. 589 2.3.4. Interim-Accounting-Interval 591 [RFC2869] Section 2.1 states: 593 It is also possible to statically configure an interim value on 594 the NAS itself. Note that a locally configured value on the NAS 595 MUST override the value found in an Access-Accept. 597 This requirement may be phrased too strongly. It is conceivable that 598 a NAS implementation has a setting for a "minimum" value of Interim- 599 Accounting-Interval, based on resource constraints in the NAS, and 600 network loading in the local environment of the NAS. In such cases, 601 the value administratively provisioned in the NAS should not be over- 602 ridden by a smaller value from an Access-Accept message. The NAS's 603 value could be over-ridden by a larger one, however. The intent is 604 that the NAS sends accounting information at fixed intervals, short 605 enough such that the potential loss of billable revenue is limited, 606 but also that the accounting updates are infrequent enough such that 607 the NAS, network, and RADIUS server are not overloaded. 609 2.3.5. Counter values in the RADIUS Management Information Base (MIB) 611 The RADIUS Authentication and Authorization Client MIB module 612 [RFC2618], [RFC4668] includes counters of packet statistics. In the 613 descriptive text of the MIB module, formulas are provided for certain 614 counter objects. Implementors have noted apparent inconsistencies in 615 the formulas, which could result in negative values. 617 Since the original MIB module specified in [RFC2618] had been widely 618 implemented, the RADEXT WG chose not to change the object definitions 619 or to create new ones within the revised MIB module [RFC4668]. 620 However, this section explains the issues and provides guidance for 621 implementors regarding the interpretation of the textual description 622 and comments for certain MIB objects. 624 The issues raised can be summarized as follows: 626 Issue (1): 628 -- TotalIncomingPackets = Accepts + Rejects + Challenges + 629 UnknownTypes 630 -- 631 -- TotalIncomingPackets - MalformedResponses - BadAuthenticators - 632 -- UnknownTypes - PacketsDropped = Successfully received 633 -- 634 -- AccessRequests + PendingRequests + ClientTimeouts = 635 -- Successfully Received 637 It appears that the value of "Successfully Received" could be 638 negative, since various counters are subtracted from 639 TotalIncomingPackets that are not included in the calculation of 640 TotalIncomingPackets. 642 It also appears that "AccessRequests + PendingRequests + 643 ClientTimeouts = Successfully Received" should read "AccessRequests + 644 PendingRequests + ClientTimeouts = Successfully Transmitted". 646 "TotalIncomingPackets" and "Successfully Received" are temporary 647 variables, i.e. not objects within the MIB module. The comment text 648 in the MIB modules is intended, therefore, to aid in understanding. 649 What's of consequence is the consistency of values of the objects in 650 the MIB module, and that does not appear to be impacted by the 651 inconsistencies noted above. It does appear, however, that the 652 "Successfully Received" variable should be labeled "Successfully 653 Transmitted". 655 In addition, the definition of Accept, Reject or Challenge counters 656 indicates that they MUST be incremented before the message is 657 validated. If the message is invalid, one of MalformedResponses, 658 BadAuthenticators or PacketsDropped counters will be additionally 659 incremented. In that case the first two equations are consistent, 660 i.e. "Successfully Received" could not be negative. 662 Issue (2): 664 It appears that the radiusAuthClientPendingRequests counter is 665 decremented upon retransmission. That would mean a retransmitted 666 packet is not considered as being as pending, although such 667 retransmissions can still be considered as being pending requests. 669 The definition of this MIB object in [RFC2618] is as follows: 671 The number of RADIUS Access-Request packets destined for this 672 server that have not yet timed out or received a response. This 673 variable is incremented when an Access-Request is sent and 674 decremented due to receipt of an Access-Accept, Access-Reject or 675 Access-Challenge, a timeout or retransmission. 677 This object purports to count the number of pending request packets. 678 It is open to interpretation whether or not retransmissions of a 679 request are to be counted as additional pending packets. In either 680 event, it seems appropriate to treat retransmissions consistently 681 with respect to incrementing and decrementing this counter. 683 2.4. Multiple Filter-ID Attributes 685 [RFC2865] Section 5.11 states: 687 Zero or more Filter-Id attributes MAY be sent in an Access-Accept 688 packet. 690 In practice the behavior of a RADIUS client receiving multiple 691 Filter-ID attributes is implementation dependent. For example, some 692 implementations treat multiple instances of the Filter-ID attribute 693 as alternative filters; the first Filter-ID attribute having a name 694 matching a locally defined filter is used, and the remaining ones are 695 discarded. Other implementations may combine matching filters. 697 As a result, the interpretation of multiple Filter-ID attributes is 698 undefined within RADIUS. The sending of multiple Filter-ID 699 attributes within an Access-Accept SHOULD be avoided within 700 heterogeneous deployments and roaming scenarios, where it is likely 701 to produce unpredictable results. 703 2.5. Mandatory and Optional Attributes 705 RADIUS attributes do not explicitly state whether they are optional 706 or mandatory. Nevertheless there are instances where RADIUS 707 attributes need to be treated as mandatory. 709 [RFC2865] Section 1.1 states: 711 A NAS that does not implement a given service MUST NOT implement 712 the RADIUS attributes for that service. For example, a NAS that 713 is unable to offer Apple Remote Access Protocol (ARAP) service 714 MUST NOT implement the RADIUS attributes for ARAP. A NAS MUST 715 treat a RADIUS access-accept authorizing an unavailable service as 716 an access-reject instead. 718 With respect to the Service-Type attribute, [RFC2865] Section 5.6 719 says: 721 This Attribute indicates the type of service the user has 722 requested, or the type of service to be provided. It MAY be used 723 in both Access-Request and Access-Accept packets. A NAS is not 724 required to implement all of these service types, and MUST treat 725 unknown or unsupported Service-Types as though an Access-Reject 726 had been received instead. 728 [RFC2865] Section 5 states: 730 A RADIUS server MAY ignore Attributes with an unknown Type. 732 A RADIUS client MAY ignore Attributes with an unknown Type. 734 With respect to Vendor-Specific Attributes (VSAs), [RFC2865] Section 735 5.26 states: 737 Servers not equipped to interpret the vendor-specific information 738 sent by a client MUST ignore it (although it may be reported). 739 Clients which do not receive desired vendor-specific information 740 SHOULD make an attempt to operate without it, although they may do 741 so (and report they are doing so) in a degraded mode. 743 It is possible for either a standard attribute or VSA to represent a 744 request for an unavailable service. However, where the Type, Vendor- 745 ID, or Vendor-Type is unknown, a RADIUS client will not know whether 746 the attribute defines a service or not. 748 In general, it is best for a RADIUS clients to err on the side of 749 caution. On receiving an Access-Accept including an attribute of 750 known Type for an unimplemented service, a RADIUS client MUST treat 751 it as an Access-Reject, as directed in [RFC2865] Section 1.1. On 752 receiving an Access-Accept including an attribute of unknown Type, a 753 RADIUS client SHOULD assume that it is a potential service 754 definition, and treat it as an Access-Reject. Unknown VSAs SHOULD be 755 ignored by RADIUS clients. 757 In order to avoid introducing changes in default behavior, existing 758 implementations that do not obey this recommendation should make the 759 behavior configurable, with the legacy behavior being enabled by 760 default. A configuration flag such as "treat unknown attributes as 761 reject" can be exposed to the system administrator. If the flag is 762 set to true, then Access-Accepts containing unknown attributes are 763 treated as Access-Rejects. If the flag is set to false, then unknown 764 attributes in Access-Accepts are be silently ignored. 766 On receiving a packet including an attribute of unknown type, RADIUS 767 authentication server implementations SHOULD ignore such attributes. 768 However, RADIUS accounting server implementations typically do not 769 need to understand attributes in order to write them to stable 770 storage or pass them to the billing engine. Therefore, accounting 771 server implementations SHOULD be equipped to handle unknown 772 attributes. 774 To avoid misinterpretation of service requests encoded within VSAs, 775 RADIUS servers SHOULD NOT send VSAs containing service requests to 776 RADIUS clients that are not known to understand them. For example, a 777 RADIUS server should not send a VSA encoding a filter without 778 knowledge that the RADIUS client supports the VSA. 780 2.6. Interpretation of Access-Reject 782 2.6.1. Improper Use of Access-Reject 784 The intent of an Access-Reject is to deny access to the requested 785 service. [RFC2865] Section 2 states: 787 If any condition is not met, the RADIUS server sends an "Access- 788 Reject" response indicating that this user request is invalid. If 789 desired, the server MAY include a text message in the Access- 790 Reject which MAY be displayed by the client to the user. No other 791 Attributes (except Proxy-State) are permitted in an Access-Reject. 793 This text makes it clear that RADIUS does not allow the provisioning 794 of services within an Access-Reject. If the desire is to allow 795 limited access, then an Access-Accept can be sent with attributes 796 provisioning limited access. Attributes within an Access-Reject are 797 restricted to those necessary to route the message (e.g. Proxy- 798 State), attributes providing the user with an indication that access 799 has been denied (e.g. an EAP-Message attribute containing an EAP- 800 Failure) or attributes conveying an error message (e.g. a Reply- 801 Message or Error-Cause attribute). 803 Unfortunately, there are examples where this requirement has been 804 misunderstood. [RFC2869] Section 2.2 states: 806 If that authentication fails, the RADIUS server should return an 807 Access-Reject packet to the NAS, with optional Password-Retry and 808 Reply-Messages attributes. The presence of Password-Retry 809 indicates the ARAP NAS MAY choose to initiate another challenge- 810 response cycle, 812 This paragraph is problematic from two perspectives. Firstly, a 813 Password-Retry attribute is being returned in an Access-Reject; this 814 attribute does not fit into the categories established in [RFC2865]. 815 Secondly, an Access-Reject packet is being sent in the context of a 816 continuing authentication conversation; [RFC2865] requires use of an 817 Access-Challenge for this. [RFC2869] uses the phrase "challenge- 818 response" to describe this use of Access-Reject, indicating that the 819 semantics of Access-Challenge are being used. 821 [RFC2865] Section 4.4, addresses the semantics of Access-Challenge 822 being equivalent to Access-Reject in some cases: 824 If the NAS does not support challenge/response, it MUST treat an 825 Access-Challenge as though it had received an Access-Reject 826 instead. 828 While it is difficult to correct existing deployments of [RFC2869], 829 we make the following recommendations: 831 [1] New RADIUS specifications and implementations MUST NOT use Access- 832 Reject where the semantics of Access-Challenge are intended. 834 [2] Access-Reject MUST mean denial of access to the requested service. 835 In response to an Access-Reject, the NAS MUST NOT send any 836 additional Access-Request packets for that user session. 838 [3] New deployments of ARAP [RFC2869] SHOULD use Access-Challenge 839 instead of Access-Reject packets in the conversations described in 840 [RFC2869] Section 2.2. 842 We also note that the table of attributes [RFC2869] Section 5.19 has 843 an error for the Password-Retry attribute. It says: 845 Request Accept Reject Challenge # Attribute 846 0 0 0-1 0 75 Password-Retry 848 However, the text in [RFC2869] Section 2.3.2 says that Password-Retry 849 can be included within an Access-Challenge packet, for EAP 850 authentication sessions. We recommend a correction to the table, 851 which removes the "0-1" from the Reject column, moves it to the 852 Challenge column. We also add a "Note 2" to follow the existing 853 "Note 1" in the document, to clarify the use of this attribute. 855 Request Accept Reject Challenge # Attribute 856 0 0 0 0-1 75 Password-Retry [Note 2] 858 [Note 2] As per RFC 3579, the use of the Password-Retry in EAP 859 authentications is deprecated. The Password-Retry attribute can be 860 used only for ARAP authentication. 862 2.6.2. Service Request Denial 864 RADIUS has been deployed for purposes outside network access 865 authentication, authorization and accounting. For example, RADIUS 866 has been deployed as a "back-end" for authenticating Voice Over IP 867 (VOIP) connections, Hypertext Transfer Protocol (HTTP) sessions (e.g. 868 Apache), File Transfer Protocol (FTP) sessions (e.g. proftpd), and 869 machine logins for multiple operating systems (e.g. bsdi, pam, gina). 870 In those contexts, an Access-Reject sent to the RADIUS client MUST be 871 interpreted as a rejection of the request for service, and the RADIUS 872 client MUST NOT offer that service to the user. 874 For example, when an authentication failure occurs in the context of 875 an FTP session, the normal semantics for rejecting FTP services 876 apply. The rejection does not necessarily cause the FTP server to 877 terminate the underlying TCP connection, but the FTP server MUST NOT 878 offer any services protected by user authentication. 880 Users may request multiple services from the NAS. Where those 881 services are independent, the deployment MUST treat the RADIUS 882 sessions as being independent. 884 For example, a NAS may offer multi-link services, where a user may 885 have multiple simultaneous network connections. In that case, an 886 Access-Reject for a later multi-link connection request does not 887 necessarily mean that earlier multi-link connections are torn down. 888 Similarly, if a NAS offers both dialup and VOIP services, the 889 rejection of a VOIP attempt does not mean that the dialup session is 890 torn down. 892 2.7. Addressing 894 2.7.1. Link-Local Addresses 896 Since Link-Local addresses are unique only on the local link, if the 897 NAS and RADIUS server are not on the same link, then an IPv6 Link- 898 Local address [RFC2462] or an IPv4 Link-Local Address [RFC3927] 899 cannot be used to uniquely identify the NAS. A NAS SHOULD NOT 900 utilize a link-scope address within a NAS-IPv6-Address or NAS-IP- 901 Address attributes. A RADIUS server receiving a NAS-IPv6-Address or 902 NAS-IP-Address attribute containing a Link-Local address SHOULD NOT 903 count such an attribute toward satisfying the requirements of 904 [RFC3162] Section 2.1: 906 NAS-IPv6-Address and/or NAS-IP-Address MAY be present in an 907 Access-Request packet; however, if neither attribute is present 908 then NAS-Identifier MUST be present. 910 2.7.2. Multiple Addresses 912 There are situations in which a RADIUS client or server may have 913 multiple addresses. For example, a dual stack host can have both 914 IPv4 and IPv6 addresses; a host that is a member of multiple VLANs 915 could have IPv4 and/or IPv6 addresses on each VLAN; a host can have 916 multiple IPv4 or IPv6 addresses on a single interface. However, 917 [RFC2865] Section 5.44 only permits zero or one NAS-IP-Address 918 attribute within an Access-Request and [RFC3162] Section 3 only 919 permits zero or one NAS-IPv6-Address attribute within an Access- 920 Request. When a NAS has more than one global address and no ability 921 to determine which is used for identification in a particular 922 request, it is RECOMMENDED that the NAS include the NAS-Identifier 923 attribute in an Access-Request in order to identify itself to the 924 RADIUS server. 926 [RFC2865] Section 3 states: 928 A RADIUS server MUST use the source IP address of the RADIUS 929 UDP packet to decide which shared secret to use, so that 930 RADIUS requests can be proxied. 932 Therefore if a RADIUS client sends packets from more than one source 933 address, a shared secret will need to be configured on both the 934 client and server for each source address. 936 2.8. Idle-Timeout 938 With respect to the Idle-Timeout attribute, [RFC2865] Section 5.28 939 states: 941 This Attribute sets the maximum number of consecutive seconds of 942 idle connection allowed to the user before termination of the 943 session or prompt. This Attribute is available to be sent by the 944 server to the client in an Access-Accept or Access-Challenge. 946 [RFC3580] Section 3.12 states: 948 The Idle-Timeout attribute is described in [RFC2865]. For IEEE 949 802 media other than 802.11 the media are always on. As a result 950 the Idle-Timeout attribute is typically only used with wireless 951 media such as IEEE 802.11. It is possible for a wireless device 952 to wander out of range of all Access Points. In this case, the 953 Idle-Timeout attribute indicates the maximum time that a wireless 954 device may remain idle. 956 In the above paragraphs "idle" may not necessarily mean "no traffic"; 957 the NAS may support filters defining what traffic is included in the 958 idle time determination. As a result, an "idle connection" is 959 defined by local policy in the absence of other attributes. 961 2.9. Unknown Identity 963 [RFC3748] Section 5.1 states: 965 If the Identity is unknown, the Identity Response field 966 should be zero bytes in length. 968 However, [RFC2865] Section 5.1 describes the User-Name attribute as 969 follows: 971 The String field is one or more octets. 973 How should the RADIUS client behave if it receives an EAP- 974 Response/Identity that is zero octets in length? 976 [RFC2865] Section 5.1 states: 978 This Attribute indicates the name of the user to be authenticated. 979 It MUST be sent in Access-Request packets if available. 981 This suggests that the User-Name attribute may be ommitted if it is 982 unavailable. 984 However, [RFC3579] Section 2.1 states: 986 In order to permit non-EAP aware RADIUS proxies to forward the 987 Access-Request packet, if the NAS initially sends an 988 EAP-Request/Identity message to the peer, the NAS MUST copy the 989 contents of the Type-Data field of the EAP-Response/Identity 990 received from the peer into the User-Name attribute and MUST 991 include the Type-Data field of the EAP-Response/Identity in the 992 User-Name attribute in every subsequent Access-Request. 994 This suggests that the User-Name attribute should contain the 995 contents of the Type-Data field of the EAP-Response/Identity, even if 996 it is zero octets in length. 998 Note that [RFC4282] does not permit a Network Access Identifier (NAI) 999 of zero octets, so that an EAP-Response/Identity with a Type-Data 1000 field of zero octets MUST NOT be construed as a request for privacy 1001 (e.g. anonymous NAI). 1003 When a NAS receives an EAP-Response/Identity with a Type-Data field 1004 that is zero octets in length, it is RECOMMENDED that it either omit 1005 the User-Name attribute in the Access-Request or include the Calling- 1006 Station-Id in the User-Name attribute, along with a Calling-Station- 1007 Id attribute. 1009 2.10. Responses after retransmissions 1011 Some implementations do not correctly handle the receipt of RADIUS 1012 responses after retransmissions. [RFC2865] Section 2.5 states 1014 If the NAS is retransmitting a RADIUS request to the same server 1015 as before, and the attributes haven't changed, you MUST use the 1016 same Request Authenticator, ID, and source port. If any 1017 attributes have changed, you MUST use a new Request Authenticator 1018 and ID. 1020 Note that changing the Request ID for a retransmission may have 1021 undesirable side effects. Since RADIUS does not have a clear 1022 definition of a "session", it is perfectly valid for a RADIUS server 1023 to treat a retransmission as a new session request, and to reject it 1024 due to (say) multiple simultaneous login restrictions are enforced. 1025 In that situation, the NAS may receive a belated Access-Accept for 1026 the first request, and an Access-Reject for the retransmitted 1027 request, both of which apply to the same "session". 1029 We suggest that the contents of Access-Request packets SHOULD NOT be 1030 changed during retransmissions. If they must be changed due to the 1031 inclusion of an Event-Timestamp attribute, for example, then 1032 responses to earlier transmissions MUST be silently discarded. Any 1033 response to the current request MUST be treated as the definitive 1034 response, even if as noted above, it disagrees with earlier 1035 responses. 1037 This problem can be made worse by implementations that use a fixed 1038 retransmission timeout (30 seconds is common). We reiterate the 1039 suggestions above in Section 2.1 about using congestive backoff. In 1040 that case, responses to earlier transmissions MAY be used as data 1041 points for congestive backoff, even if their contents are discarded. 1043 2.11. Framed-IPv6-Prefix 1045 [RFC3162] Section 2.3 says 1047 This Attribute indicates an IPv6 prefix (and corresponding route) 1048 to be configured for the user. It MAY be used in Access-Accept 1049 packets, and can appear multiple times. It MAY be used in an 1050 Access-Request packet as a hint by the NAS to the server that it 1051 would prefer these prefix(es), but the server is not required to 1052 honor the hint. Since it is assumed that the NAS will plumb a 1053 route corresponding to the prefix, it is not necessary for the 1054 server to also send a Framed-IPv6-Route attribute for the same 1055 prefix. 1057 An Internet Service Provider (ISP) may desire to support Prefix 1058 Delegation [RFC4818] at the same time that it would like to assign a 1059 prefix for the link between the NAS and the user. The intent of the 1060 paragraph was to enable the NAS to advertise the prefix (such as via 1061 a Router Advertisement). If the Framed-Routing attribute is used, it 1062 is also possible that the prefix would be advertised in a routing 1063 protocol such as RIPNG. RFC 2865 Section 5.10 describes the purpose 1064 of Framed-Routing: 1066 This Attribute indicates the routing method for the user, when the 1067 user is a router to a network. It is only used in Access-Accept 1068 packets. 1070 The description of the Prefix-Length field in RFC 3162 indicates 1071 excessively wide latitude: 1073 The length of the prefix, in bits. At least 0 and no larger than 1074 128. 1076 This length appears too broad, because it is not clear what a NAS 1077 should do with a prefix of greater granularity than /64. For example, 1078 the Framed-IPv6-Prefix may contain a /128. This does not imply that 1079 the NAS should assign an IPv6 address to the end user, because RFC 1080 3162 already defines a Framed-IPv6-Identifier attribute to handle the 1081 Identifier portion. 1083 It appears that the Framed-IPv6-Prefix is used for the link between 1084 the NAS and CPE only if a /64 prefix is assigned. When a /64 or 1085 larger prefix is sent, the intent is for the NAS to send a routing 1086 advertisement containing the information present in the Framed- 1087 IPv6-Prefix attribute. 1089 The CPE may also require a delegated prefix for its own use, if it is 1090 decrementing the Hop Limit field of IP headers. In that case, it 1091 should be delegated a prefix by the NAS via the Delegated-IPv6-Prefix 1092 attribute. [RFC4818]. If the CPE is not decrementing Hop Limit, it 1093 does not require a delegated prefix. 1095 3. IANA Considerations 1097 This specification does not create any new registries, nor does it 1098 require assignment of any protocol parameters. 1100 4. Security Considerations 1102 The contents of the State attribute are available to both the RADIUS 1103 client and observers of the RADIUS protocol. RADIUS server 1104 implementations should ensure that the state attribute does not 1105 disclose sensitive information to a RADIUS client or third parties 1106 observing the RADIUS protocol. 1108 The cache mechanism described in Section 2.2.2 is vulnerable to 1109 attacks when Access-Request packets do not contain a Message- 1110 Authenticator attribute. If the server accepts requests without a 1111 Message-Authenticator, then RADIUS packets can be trivially forged by 1112 an attacker. Cache entries can then be forcibly expired, negating 1113 the utility of the cache. This attack can be mitigated by following 1114 the suggestions in [RFC3579] Section 4, or by requiring the presence 1115 of Message-Authenticator, as described in Sections 2.1.1 and 2.2.2. 1117 Since this document describes the use of RADIUS for purposes of 1118 authentication, authorization, and accounting in a wide variety of 1119 networks, applications using these specifications are vulnerable to 1120 all of the threats that are present in other RADIUS applications. 1121 For a discussion of these threats, see [RFC2865], [RFC2607], 1122 [RFC3162], [RFC3579], and [RFC3580]. 1124 5. References 1125 5.1. Normative references 1127 [RFC2865] 1128 Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote 1129 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 1131 [RFC4818] 1132 Salowey, J., Droms., R, "RADIUS Delegated-IPv6-Prefix Attribute", 1133 RFC 4818, April 2007. 1135 5.2. Informative references 1137 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1138 Requirement Levels", RFC 2119, March, 1997. 1140 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 1141 Autoconfiguration", RFC 2462, December 1998. 1143 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 1144 Implementation in Roaming", RFC 2607, June 1999. 1146 [RFC2618] Aboba, B. and G. Zorn, "RADIUS Authentication Client MIB", RFC 1147 2618, June 1999. 1149 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1151 [RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", 1152 RFC 2869, June 2000. 1154 [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 1155 3162, August 2001. 1157 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 1158 Carney, "Dynamic Host Configuration Protocol for IPv6 1159 (DHCPv6)", RFC 3315, July 2003. 1161 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, 1162 "Dynamic Authorization Extensions to Remote Authentication 1163 Dial In User Service (RADIUS)", RFC 3576, July 2003. 1165 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible 1166 Authentication Protocol (EAP)", RFC 3579, September 2003. 1168 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, 1169 "IEEE 802.1X Remote Authentication Dial In User Service 1170 (RADIUS) Usage Guidelines", RFC 3580, September 2003. 1172 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 1173 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 1174 3748, June 2004. 1176 [RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration 1177 of IPv4 Link-Local Addresses", RFC 3927, May 2005. 1179 [RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Network 1180 Access Identifier", RFC 4282, December 2005. 1182 [RFC4668] Nelson, D, "RADIUS Authentication Client MIB for IPv6", RFC 1183 4668, August 2006. 1185 [RFC4669] Nelson, D, "RADIUS Authentication Server MIB for IPv6", RFC 1186 4669, August 2006. 1188 Acknowledgments 1190 The authors would like to acknowledge Glen Zorn and Bernard Aboba for 1191 contributions to this document. 1193 The alternate algorithm to [RFC3579] Section 2.6.1 that is described 1194 in section 2.1.2 of this document was designed by Raghu Dendukuri. 1196 The text discussing retransmissions in Section 2.2.1 is taken with 1197 minor edits from Section 9 of draft-ietf-pana-pana-17.txt 1199 Alan DeKok wishes to acknowledge the support of Quiconnect Inc., 1200 where he was employed during much of the work on this document. 1202 David Nelson wishes to acknowledge the support of Enterasys Networks, 1203 where he was employed during much of the work on this document. 1205 Authors' Addresses 1207 David B. Nelson 1208 Elbrys Networks, Inc. 1209 75 Rochester Ave., Unit 3 1210 Portsmouth N.H. 03801 USA 1212 Phone: +1.603.570.2636 1214 Email: d.b.nelson@comcast.net 1216 Alan DeKok 1217 The FreeRADIUS Server Project 1218 http://freeradius.org/ 1219 Email: aland@freeradius.org 1221 Intellectual Property Statement 1223 The IETF takes no position regarding the validity or scope of any 1224 Intellectual Property Rights or other rights that might be claimed to 1225 pertain to the implementation or use of the technology described in 1226 this document or the extent to which any license under such rights 1227 might or might not be available; nor does it represent that it has 1228 made any independent effort to identify any such rights. Information 1229 on the procedures with respect to rights in RFC documents can be 1230 found in BCP 78 and BCP 79. 1232 Copies of IPR disclosures made to the IETF Secretariat and any 1233 assurances of licenses to be made available, or the result of an 1234 attempt made to obtain a general license or permission for the use of 1235 such proprietary rights by implementers or users of this 1236 specification can be obtained from the IETF on-line IPR repository at 1237 http://www.ietf.org/ipr. 1239 The IETF invites any interested party to bring to its attention any 1240 copyrights, patents or patent applications, or other proprietary 1241 rights that may cover technology that may be required to implement 1242 this standard. Please address the information to the IETF at ietf- 1243 ipr@ietf.org. 1245 Disclaimer of Validity 1247 This document and the information contained herein are provided on an 1248 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1249 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1250 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1251 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1252 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1253 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1255 Full Copyright Statement 1257 Copyright (C) The IETF Trust (2007). 1259 This document is subject to the rights, licenses and restrictions 1260 contained in BCP 78, and except as set forth therein, the authors 1261 retain all their rights. 1263 Acknowledgment 1265 Funding for the RFC Editor function is currently provided by the 1266 Internet Society. 1268 Open issues 1270 Open issues relating to this specification are tracked on the 1271 following web site: 1273 http://www.drizzle.com/~aboba/RADEXT/