7 Network Working Group D. Nelson
8 Request for Comments: 5080 Elbrys Networks, Inc
9 Updates: 2865, 2866, 2869, 3579 A. DeKok
10 Category: Standards Track FreeRADIUS
14 Common Remote Authentication Dial In User Service (RADIUS)
15 Implementation Issues and Suggested Fixes
19 This document specifies an Internet standards track protocol for the
20 Internet community, and requests discussion and suggestions for
21 improvements. Please refer to the current edition of the "Internet
22 Official Protocol Standards" (STD 1) for the standardization state
23 and status of this protocol. Distribution of this memo is unlimited.
27 This document describes common issues seen in Remote Authentication
28 Dial In User Service (RADIUS) implementations and suggests some
29 fixes. Where applicable, ambiguities and errors in previous RADIUS
30 specifications are clarified.
58 Nelson & DeKok Standards Track [Page 1]
60 RFC 5080 RADIUS Issues & Fixes December 2007
65 1. Introduction ....................................................2
66 1.1. Terminology ................................................3
67 1.2. Requirements Language ......................................3
68 2. Issues ..........................................................3
69 2.1. Session Definition .........................................3
70 2.1.1. State Attribute .....................................3
71 2.1.2. Request-ID Supplementation ..........................6
72 2.2. Overload Conditions ........................................7
73 2.2.1. Retransmission Behavior .............................7
74 2.2.2. Duplicate Detection and Orderly Delivery ...........10
75 2.2.3. Server Response to Overload ........................11
76 2.3. Accounting Issues .........................................12
77 2.3.1. Attributes Allowed in an Interim Update ............12
78 2.3.2. Acct-Session-Id and Acct-Multi-Session-Id ..........12
79 2.3.3. Request Authenticator ..............................13
80 2.3.4. Interim-Accounting-Interval ........................13
81 2.3.5. Counter Values in the RADIUS Management
82 Information Base (MIB) .............................14
83 2.4. Multiple Filter-ID Attributes .............................15
84 2.5. Mandatory and Optional Attributes .........................16
85 2.6. Interpretation of Access-Reject ...........................18
86 2.6.1. Improper Use of Access-Reject ......................18
87 2.6.2. Service Request Denial .............................19
88 2.7. Addressing ................................................20
89 2.7.1. Link-Local Addresses ...............................20
90 2.7.2. Multiple Addresses .................................20
91 2.8. Idle-Timeout ..............................................21
92 2.9. Unknown Identity ..........................................21
93 2.10. Responses After Retransmissions ..........................22
94 2.11. Framed-IPv6-Prefix .......................................23
95 3. Security Considerations ........................................24
96 4. References .....................................................25
97 4.1. Normative References ......................................25
98 4.2. Informative References ....................................25
102 The last few years have seen an increase in the deployment of RADIUS
103 clients and servers. This document describes common issues seen in
104 RADIUS implementations and suggests some fixes. Where applicable,
105 ambiguities and errors in previous RADIUS specifications are
114 Nelson & DeKok Standards Track [Page 2]
116 RFC 5080 RADIUS Issues & Fixes December 2007
121 This document uses the following terms:
123 Network Access Server (NAS)
124 The device providing access to the network. Also known as the
125 Authenticator in IEEE 802.1X or Extensible Authentication Protocol
126 (EAP) terminology, or RADIUS client.
129 The NAS provides a service to the user, such as network access via
130 802.11 or Point to Point Protocol (PPP).
133 Each service provided by the NAS to a peer constitutes a session,
134 with the beginning of the session defined as the point where
135 service is first provided, and the end of the session is defined
136 as the point where service is ended. A peer may have multiple
137 sessions in parallel or series if the NAS supports that, with each
138 session generating a separate start and stop accounting record.
141 This means the implementation discards the packet without further
142 processing. The implementation SHOULD provide the capability of
143 logging the error, including the contents of the silently
144 discarded packet, and SHOULD record the event in a statistics
147 1.2. Requirements Language
149 In this document, several words are used to signify the requirements
150 of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
151 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
152 and "OPTIONAL" in this document are to be interpreted as described in
157 2.1. Session Definition
159 2.1.1. State Attribute
161 Regarding the State attribute, [RFC2865] Section 5.24 states:
163 This Attribute is available to be sent by the server to the client
164 in an Access-Challenge and MUST be sent unmodified from the client
165 to the server in the new Access-Request reply to that challenge,
170 Nelson & DeKok Standards Track [Page 3]
172 RFC 5080 RADIUS Issues & Fixes December 2007
175 This Attribute is available to be sent by the server to the client
176 in an Access-Accept that also includes a Termination-Action
177 Attribute with the value of RADIUS-Request. If the NAS performs
178 the Termination-Action by sending a new Access-Request upon
179 termination of the current session, it MUST include the State
180 attribute unchanged in that Access-Request.
182 Some RADIUS client implementations do not properly use the State
183 attribute in order to distinguish a restarted EAP authentication
184 process from the continuation of an ongoing process (by the same user
185 on the same NAS and port). Where an EAP-Message attribute is
186 included in an Access-Challenge or Access-Accept attribute, RADIUS
187 servers SHOULD also include a State attribute. See Section 2.1.2 on
188 Request ID supplementation for additional benefits to using the State
189 attribute in this fashion.
191 As defined in [RFC2865] Table 5.44, Access-Request packets may
192 contain a State attribute. The table does not qualify this
193 statement, while the text in Section 5.24 (quoted above) adds other
194 requirements not specified in that table.
196 We extend the requirements of [RFC2865] to say that Access-Requests
197 that are part of an ongoing Access-Request / Access-Challenge
198 authentication process SHOULD contain a State attribute. It is the
199 responsibility of the server, to send a State attribute in an
200 Access-Challenge packet, if that server needs a State attribute in a
201 subsequent Access-Request to tie multiple Access-Requests together
202 into one authentication session. As defined in [RFC2865] Section
203 5.24, the State MUST be sent unmodified from the client to the server
204 in the new Access-Request reply to that challenge, if any.
206 While most server implementations require the presence of a State
207 attribute in an Access-Challenge packet, some challenge-response
208 systems can distinguish the initial request from the response to the
209 challenge without using a State attribute to track an authentication
210 session. The Access-Challenge and subsequent Access-Request packets
211 for those systems do not need to contain a State attribute.
213 Other authentication mechanisms need to tie a sequence of Access-
214 Request / Access-Challenge packets together into one ongoing
215 authentication session. Servers implementing those authentication
216 mechanisms SHOULD include a State attribute in Access-Challenge
219 In general, if the authentication process involves one or more
220 Access-Request / Access-Challenge sequences, the State attribute
221 SHOULD be sent by the server in the Access-Challenge packets. Using
222 the State attribute to create a multi-packet session is the simplest
226 Nelson & DeKok Standards Track [Page 4]
228 RFC 5080 RADIUS Issues & Fixes December 2007
231 method available in RADIUS today. While other methods of creating
232 multi-packet sessions are possible (e.g., [RFC3579] Section 2.6.1),
233 those methods are NOT RECOMMENDED.
235 The only permissible values for a State attribute are values provided
236 in an Access-Accept, Access-Challenge, CoA-Request or Disconnect-
237 Request packet. A RADIUS client MUST use only those values for the
238 State attribute that it has previously received from a server. An
239 Access-Request sent as a result of a new or restarted authentication
240 run MUST NOT include the State attribute, even if a State attribute
241 has previously been received in an Access-Challenge for the same user
244 Access-Request packets that contain a Service-Type attribute with the
245 value Authorize Only (17) MUST contain a State attribute. Access-
246 Request packets that contain a Service-Type attribute with value Call
247 Check (10) SHOULD NOT contain a State attribute. Any other Access-
248 Request packet that performs authorization checks MUST contain a
249 State attribute. This last requirement often means that an Access-
250 Accept needs to contain a State attribute, which can then be used in
251 a later Access-Request that performs authorization checks.
253 The standard use case for Call Check is pre-screening authentication
254 based solely on the end-point identifier information, such as phone
255 number or Media Access Control (MAC) address in Calling-Station-ID
256 and optionally Called-Station-ID. In this use case, the NAS has no
257 way to obtain a State attribute suitable for inclusion in an Access-
258 Request. Other, non-standard, uses of Call Check may require or
259 permit the use of a State attribute, but are beyond the scope of this
262 In an Access-Request with a Service-Type Attribute with value Call
263 Check, it is NOT RECOMMENDED for the User-Name and User-Password
264 attributes to contain the same values (e.g., a MAC address).
265 Implementing MAC address checking without using a Service-Type of
266 Call Check is NOT RECOMMENDED. This practice gives an attacker both
267 the clear-text and cipher-text of the User-Password field, which
268 permits many attacks on the security of the RADIUS protocol. For
269 example, if the Request Authenticator does not satisfy the [RFC2865]
270 requirements on global and temporal uniqueness, the practice
271 described above may lead to the compromise of the User-Password
272 attribute in other Access-Requests for unrelated users. Access to
273 the cipher-text enables offline dictionary attacks, potentially
274 exposing the shared secret and compromising the entire RADIUS
282 Nelson & DeKok Standards Track [Page 5]
284 RFC 5080 RADIUS Issues & Fixes December 2007
287 Any Access-Request packet that performs authorization checks,
288 including Call Check, SHOULD contain a Message-Authenticator
289 attribute. Any response to an Access-Request performing an
290 authorization check MUST NOT contain confidential information about
291 any user (such as Tunnel-Password), unless that Access-Request
292 contains a State attribute. The use of State here permits the
293 authorization check to be tied to an earlier user authentication. In
294 that case, the server MAY respond to the NAS with confidential
295 information about that user. The server MUST NOT respond to that
296 authorization check with confidential information about any other
299 For an Access-Request packet performing an authorization check that
300 does not contain a State attribute, the server MUST respond with an
303 2.1.2. Request-ID Supplementation
305 [RFC3579] Section 2.6.1 states:
307 In EAP, each session has its own unique Identifier space. RADIUS
308 server implementations MUST be able to distinguish between EAP
309 packets with the same Identifier existing within distinct
310 sessions, originating on the same NAS. For this purpose, sessions
311 can be distinguished based on NAS and session identification
312 attributes. NAS identification attributes include NAS-Identifier,
313 NAS-IPv6-Address and NAS-IPv4-Address. Session identification
314 attributes include User-Name, NAS-Port, NAS-Port-Type, NAS-Port-
315 Id, Called-Station-Id, Calling-Station-Id and Originating-Line-
318 There are issues with the suggested algorithm. Since proxies may
319 modify Access-Request attributes such as NAS-IP-Address, depending on
320 any attribute under control of the NAS to distinguish request
321 identifiers can result in deployment problems.
323 The FreeRADIUS implementation does not track EAP identifiers by NAS-
324 IP-Address or other non-EAP attributes sent by the NAS. Instead, it
325 uses the EAP identifier, source Internet Protocol (IP) address, and
326 the State attribute as a "key" to uniquely identify each EAP session.
327 Since the State attribute is under the control of the RADIUS server,
328 the uniqueness of each session is controlled by the server, not the
329 NAS. The algorithm used in FreeRADIUS is as follows:
338 Nelson & DeKok Standards Track [Page 6]
340 RFC 5080 RADIUS Issues & Fixes December 2007
343 if (EAP start, or EAP identity) {
344 allocate unique State Attribute
345 insert session into "active session" table with
346 key=(EAP identifier, State, source IP)
348 look up active session in table, with above key
351 This algorithm appears to work well in a variety of situations,
352 including situations where home servers receive messages via
353 intermediate RADIUS proxies.
355 Implementations that do not use this algorithm are often restricted
356 to having an EAP Identifier space per NAS, or perhaps one that is
357 global to the implementation. These restrictions are unnecessary
358 when the above algorithm is used, which gives each session a unique
359 EAP Identifier space. The above algorithm SHOULD be used to track
360 EAP sessions in preference to any other method.
362 2.2. Overload Conditions
364 2.2.1. Retransmission Behavior
366 [RFC2865] Section 2.4 describes the retransmission requirements for
369 At one extreme, RADIUS does not require a "responsive" detection
370 of lost data. The user is willing to wait several seconds for the
371 authentication to complete. The generally aggressive Transmission
372 Control Protocol (TCP) retransmission (based on average round trip
373 time) is not required, nor is the acknowledgment overhead of TCP.
375 At the other extreme, the user is not willing to wait several
376 minutes for authentication. Therefore the reliable delivery of
377 TCP data two minutes later is not useful. The faster use of an
378 alternate server allows the user to gain access before giving up.
380 Some existing RADIUS clients implement excessively aggressive
381 retransmission behavior, utilizing default retransmission timeouts of
382 one second or less without support for congestive backoff. When
383 deployed at a large scale, these implementations are susceptible to
384 congestive collapse. For example, as the result of a power failure,
385 a network with 3,000 NAS devices with a fixed retransmission timer of
386 one second will continuously generate 3,000 RADIUS Access-Requests
387 per second. This is sufficient to overwhelm most RADIUS servers.
394 Nelson & DeKok Standards Track [Page 7]
396 RFC 5080 RADIUS Issues & Fixes December 2007
399 Suggested solutions include:
401 [a] Jitter. To avoid synchronization, a RADIUS client SHOULD
402 incorporate induced jitter within its retransmission
403 algorithm, as specified below.
405 [b] Congestive backoff. While it is not necessary for RADIUS
406 client implementations to implement complex retransmission
407 algorithms, implementations SHOULD support congestive
410 RADIUS retransmission timers are based on the model used in Dynamic
411 Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315]. Variables
412 used here are also borrowed from this specification. RADIUS is a
413 request/response-based protocol. The message exchange terminates
414 when the requester successfully receives the answer, or the message
415 exchange is considered to have failed according to the RECOMMENDED
416 retransmission mechanism described below. Other retransmission
417 mechanisms are possible, as long as they satisfy the requirements on
418 jitter and congestive backoff.
420 The following algorithms apply to any client that originates RADIUS
421 packets, including but not limited to Access-Request, Accounting-
422 Request, Disconnect-Request, and CoA-Request [RFC3576].
424 The retransmission behavior is controlled and described by the
427 RT Retransmission timeout
429 IRT Initial retransmission time (default 2 seconds)
431 MRC Maximum retransmission count (default 5 attempts)
433 MRT Maximum retransmission time (default 16 seconds)
435 MRD Maximum retransmission duration (default 30 seconds)
437 RAND Randomization factor
439 With each message transmission or retransmission, the sender sets RT
440 according to the rules given below. If RT expires before the message
441 exchange terminates, the sender re-computes RT and retransmits the
450 Nelson & DeKok Standards Track [Page 8]
452 RFC 5080 RADIUS Issues & Fixes December 2007
455 Each of the computations of a new RT include a randomization factor
456 (RAND), which is a random number chosen with a uniform distribution
457 between -0.1 and +0.1. The randomization factor is included to
458 minimize the synchronization of messages.
460 The algorithm for choosing a random number does not need to be
461 cryptographically sound. The algorithm SHOULD produce a different
462 sequence of random numbers from each invocation.
464 RT for the first message transmission is based on IRT:
468 RT for each subsequent message retransmission is based on the
469 previous value of RT:
471 RT = 2*RTprev + RAND*RTprev
473 MRT specifies an upper bound on the value of RT (disregarding the
474 randomization added by the use of RAND). If MRT has a value of 0,
475 there is no upper limit on the value of RT. Otherwise:
480 MRD specifies an upper bound on the length of time a sender may
481 retransmit a message. The message exchange fails once MRD seconds
482 have elapsed since the client first transmitted the message. MRD
483 MUST be set, and SHOULD have a value between 5 and 30 seconds. These
484 values mirror the values for a server's duplicate detection cache, as
485 described in the next section.
487 MRC specifies an upper bound on the number of times a sender may
488 retransmit a message. If MRC is zero, the message exchange fails
489 once MRD seconds have elapsed since the client first transmitted the
490 message. If MRC is non-zero, the message exchange fails when either
491 the sender has transmitted the message MRC times, or when MRD seconds
492 have elapsed since the client first transmitted the message.
494 For Accounting-Request packets, the default values for MRC, MRD, and
495 MRT SHOULD be zero. These settings will enable a RADIUS client to
496 continue sending accounting requests to a RADIUS server until the
497 request is acknowledged. If any of MRC, MRD, or MRT are non-zero,
498 then the accounting information could potentially be discarded
499 without being recorded.
506 Nelson & DeKok Standards Track [Page 9]
508 RFC 5080 RADIUS Issues & Fixes December 2007
511 2.2.2. Duplicate Detection and Orderly Delivery
513 When packets are retransmitted by a client, the server may receive
514 duplicate requests. The limitations of the transport protocol used
515 by RADIUS, the User Datagram Protocol (UDP), means that the Access-
516 Request packets may be received, and potentially processed, in an
517 order different from the order in which the packets were sent.
518 However, the discussion of the Identifier field in Section 3 of
521 The RADIUS server can detect a duplicate request if it has the
522 same client source IP address and source UDP port and Identifier
523 within a short span of time.
525 Also, Section 7 of [RFC4669] defines a
526 radiusAuthServDupAccessRequests object as:
528 The number of duplicate Access-Request packets received.
530 This text has a number of implications. First, without duplicate
531 detection, a RADIUS server may process an authentication request
532 twice, leading to an erroneous conclusion that a user has logged in
533 twice. That behavior is undesirable, so duplicate detection is
534 desirable. Second, the server may track not only the duplicate
535 request, but also the replies to those requests. This behavior
536 permits the server to send duplicate replies in response to duplicate
537 requests, increasing network stability.
539 Since Access-Request packets may also be sent by the client in
540 response to an Access-Challenge from the server, those packets form a
541 logically ordered stream, and, therefore have additional ordering
542 requirements over Access-Request packets for different sessions.
543 Implementing duplicate detection results in new packets being
544 processed only once, ensuring order.
546 RADIUS servers MUST therefore implement duplicate detection for
547 Access-Request packets, as described in Section 3 of [RFC2865].
548 Implementations MUST also cache the Responses (Access-Accept,
549 Access-Challenge, or Access-Reject) that they send in response to
550 Access-Request packets. If a server receives a valid duplicate
551 Access-Request for which it has already sent a Response, it MUST
552 resend its original Response without reprocessing the request. The
553 server MUST silently discard any duplicate Access-Requests for which
554 a Response has not yet been sent.
562 Nelson & DeKok Standards Track [Page 10]
564 RFC 5080 RADIUS Issues & Fixes December 2007
567 Each cache entry SHOULD be purged after a period of time. This time
568 SHOULD be no less than 5 seconds, and no more than 30 seconds. After
569 about 30 seconds, most RADIUS clients and end users will have given
570 up on the authentication request. Therefore, there is little value
571 in having a larger cache timeout.
573 Cache entries MUST also be purged if the server receives a valid
574 Access-Request packet that matches a cached Access-Request packet in
575 source address, source port, RADIUS Identifier, and receiving socket,
576 but where the Request Authenticator field is different from the one
577 in the cached packet. If the request contains a Message-
578 Authenticator attribute, the request MUST be processed as described
579 in [RFC3580] Section 3.2. Packets with invalid Message-
580 Authenticators MUST NOT affect the cache in any way.
582 However, Access-Request packets not containing a Message-
583 Authenticator attribute always affect the cache, even though they may
584 be trivially forged. To avoid this issue, server implementations may
585 be configured to require the presence of a Message-Authenticator
586 attribute in Access-Request packets. Requests not containing a
587 Message-Authenticator attribute MAY then be silently discarded.
589 Client implementations SHOULD include a Message-Authenticator
590 attribute in every Access-Request to further help mitigate this
593 When sending requests, RADIUS clients MUST NOT reuse Identifiers for
594 a source IP address and source UDP port until either a valid response
595 has been received, or the request has timed out. Clients SHOULD
596 allocate Identifiers via a least-recently-used (LRU) method for a
597 particular source IP address and source UDP port.
599 RADIUS clients do not have to perform duplicate detection. When a
600 client sends a request, it processes the first response that has a
601 valid Response Authenticator as defined in [RFC2865] Section 3. Any
602 later responses MUST be silently discarded, as they do not match a
603 pending request. That is, later responses are treated exactly the
604 same as unsolicited responses, and are silently discarded.
606 2.2.3. Server Response to Overload
608 Some RADIUS server implementations are not robust in response to
609 overload, dropping packets with even probability across multiple
610 sessions. In an overload situation, this results in a high failure
611 rate for multi-round authentication protocols such as EAP [RFC3579].
612 Typically, users will continually retry in an attempt to gain access,
613 increasing the load even further.
618 Nelson & DeKok Standards Track [Page 11]
620 RFC 5080 RADIUS Issues & Fixes December 2007
623 A more sensible approach is for a RADIUS server to preferentially
624 accept RADIUS Access-Request packets containing a valid State
625 attribute, so that multi-round authentication conversations, once
626 begun, will be more likely to succeed. Similarly, a server that is
627 proxying requests should preferentially process Access-Accept,
628 Access-Challenge, or Access-Reject packets from home servers before
629 processing new requests from a NAS.
631 These methods will allow some users to gain access to the network,
632 reducing the load created by ongoing access attempts.
634 2.3. Accounting Issues
636 2.3.1. Attributes Allowed in an Interim Update
638 [RFC2866] indicates that Acct-Input-Octets, Acct-Output-Octets,
639 Acct-Session-Time, Acct-Input-Packets, Acct-Output-Packets and Acct-
640 Terminate-Cause attributes "can only be present in Accounting-Request
641 records where the Acct-Status-Type is set to Stop".
643 However [RFC2869] Section 2.1 states:
645 It is envisioned that an Interim Accounting record (with Acct-
646 Status-Type = Interim-Update (3)) would contain all of the
647 attributes normally found in an Accounting Stop message with the
648 exception of the Acct-Term-Cause attribute.
650 Although [RFC2869] does not indicate that it updates [RFC2866], this
651 is an oversight, and the above attributes are allowable in an Interim
654 2.3.2. Acct-Session-Id and Acct-Multi-Session-Id
656 [RFC2866] Section 5.5 describes Acct-Session-Id as Text within the
657 figure summarizing the attribute format, but then goes on to state
658 that "The String field SHOULD be a string of UTF-8 encoded 10646
661 [RFC2865] defines the Text type as "containing UTF-8 encoded 10646
662 characters", which is compatible with the description of Acct-
663 Session-Id. Since other attributes are consistently described as
664 "Text" within both the figure summarizing the attribute format, and
665 the following attribute definition, it appears that this is a
666 typographical error, and that Acct-Session-Id is of type Text, and
674 Nelson & DeKok Standards Track [Page 12]
676 RFC 5080 RADIUS Issues & Fixes December 2007
679 The definition of the Acct-Multi-Session-Id attribute also has
680 typographical errors. It says:
682 A summary of the Acct-Session-Id attribute format ...
684 This text should read:
686 A summary of the Acct-Multi-Session-Id attribute format ...
688 The Acct-Multi-Session-Id attribute is also defined as being of type
689 String. However, the language in the text strongly recommends that
690 implementors consider the attribute as being of type Text. It is
691 unclear why the type String was chosen for this attribute when the
692 type Text would be sufficient. This attribute SHOULD be treated as
695 2.3.3. Request Authenticator
697 [RFC2866] Section 4.1 states:
699 The Request Authenticator of an Accounting-Request contains a 16-
700 octet MD5 hash value calculated according to the method described
701 in "Request Authenticator" above.
703 However, the text does not indicate any action to take when an
704 Accounting-Request packet contains an invalid Request Authenticator.
705 The following text should be considered to be part of the above
708 The Request Authenticator field MUST contain the correct data, as
709 given by the above calculation. Invalid packets are silently
710 discarded. Note that some early implementations always set the
711 Request Authenticator to all zeros. New implementations of RADIUS
712 clients MUST use the above algorithm to calculate the Request
713 Authenticator field. New RADIUS server implementations MUST
714 silently discard invalid packets.
716 2.3.4. Interim-Accounting-Interval
718 [RFC2869] Section 2.1 states:
720 It is also possible to statically configure an interim value on
721 the NAS itself. Note that a locally configured value on the NAS
722 MUST override the value found in an Access-Accept.
724 This requirement may be phrased too strongly. It is conceivable that
725 a NAS implementation has a setting for a "minimum" value of Interim-
726 Accounting-Interval, based on resource constraints in the NAS, and
730 Nelson & DeKok Standards Track [Page 13]
732 RFC 5080 RADIUS Issues & Fixes December 2007
735 network loading in the local environment of the NAS. In such cases,
736 the value administratively provisioned in the NAS should not be
737 over-ridden by a smaller value from an Access-Accept message. The
738 NAS's value could be over-ridden by a larger one, however. The
739 intent is that the NAS sends accounting information at fixed
740 intervals that are short enough so that the potential loss of
741 billable revenue is limited, but also that the accounting updates are
742 infrequent enough so that the NAS, network, and RADIUS server are not
745 2.3.5. Counter Values in the RADIUS Management Information Base (MIB)
747 The RADIUS Authentication and Authorization Client MIB module
748 ([RFC2618] [RFC4668]) includes counters of packet statistics. In the
749 descriptive text of the MIB module, formulas are provided for certain
750 counter objects. Implementors have noted apparent inconsistencies in
751 the formulas that could result in negative values.
753 Since the original MIB module specified in [RFC2618] had been widely
754 implemented, the RADEXT WG chose not to change the object definitions
755 or to create new ones within the revised MIB module [RFC4668].
756 However, this section explains the issues and provides guidance for
757 implementors regarding the interpretation of the textual description
758 and comments for certain MIB objects.
760 The issues raised can be summarized as follows:
764 -- TotalIncomingPackets = Accepts + Rejects + Challenges +
767 -- TotalIncomingPackets - MalformedResponses - BadAuthenticators -
768 -- UnknownTypes - PacketsDropped = Successfully received
770 -- AccessRequests + PendingRequests + ClientTimeouts =
771 -- Successfully Received
773 It appears that the value of "Successfully Received" could be
774 negative, since various counters are subtracted from
775 TotalIncomingPackets that are not included in the calculation of
776 TotalIncomingPackets.
778 It also appears that "AccessRequests + PendingRequests +
779 ClientTimeouts = Successfully Received" should read "AccessRequests +
780 PendingRequests + ClientTimeouts = Successfully Transmitted".
786 Nelson & DeKok Standards Track [Page 14]
788 RFC 5080 RADIUS Issues & Fixes December 2007
791 "TotalIncomingPackets" and "Successfully Received" are temporary
792 variables, i.e., not objects within the MIB module. The comment text
793 in the MIB modules is intended, therefore, to aid in understanding.
794 What's of consequence is the consistency of values of the objects in
795 the MIB module, and that does not appear to be impacted by the
796 inconsistencies noted above. It does appear, however, that the
797 "Successfully Received" variable should be labeled "Successfully
800 In addition, the definition of Accept, Reject or Challenge counters
801 indicates that they MUST be incremented before the message is
802 validated. If the message is invalid, one of MalformedResponses,
803 BadAuthenticators, or PacketsDropped counters will be additionally
804 incremented. In that case, the first two equations are consistent,
805 i.e., "Successfully Received" could not be negative.
809 It appears that the radiusAuthClientPendingRequests counter is
810 decremented upon retransmission. That would mean a retransmitted
811 packet is not considered as being pending, although such
812 retransmissions can still be considered as being pending requests.
814 The definition of this MIB object in [RFC2618] is as follows:
816 The number of RADIUS Access-Request packets destined for this
817 server that have not yet timed out or received a response. This
818 variable is incremented when an Access-Request is sent and
819 decremented due to receipt of an Access-Accept, Access-Reject or
820 Access-Challenge, a timeout or retransmission.
822 This object purports to count the number of pending request packets.
823 It is open to interpretation whether or not retransmissions of a
824 request are to be counted as additional pending packets. In either
825 event, it seems appropriate to treat retransmissions consistently
826 with respect to incrementing and decrementing this counter.
828 2.4. Multiple Filter-ID Attributes
830 [RFC2865] Section 5.11 states:
832 Zero or more Filter-Id attributes MAY be sent in an Access-Accept
842 Nelson & DeKok Standards Track [Page 15]
844 RFC 5080 RADIUS Issues & Fixes December 2007
847 In practice, the behavior of a RADIUS client receiving multiple
848 Filter-ID attributes is implementation dependent. For example, some
849 implementations treat multiple instances of the Filter-ID attribute
850 as alternative filters; the first Filter-ID attribute having a name
851 matching a locally defined filter is used, and the remaining ones are
852 discarded. Other implementations may combine matching filters.
854 As a result, the interpretation of multiple Filter-ID attributes is
855 undefined within RADIUS. The sending of multiple Filter-ID
856 attributes within an Access-Accept SHOULD be avoided within
857 heterogeneous deployments and roaming scenarios, where it is likely
858 to produce unpredictable results.
860 2.5. Mandatory and Optional Attributes
862 RADIUS attributes do not explicitly state whether they are optional
863 or mandatory. Nevertheless, there are instances where RADIUS
864 attributes need to be treated as mandatory.
866 [RFC2865] Section 1.1 states:
868 A NAS that does not implement a given service MUST NOT implement
869 the RADIUS attributes for that service. For example, a NAS that
870 is unable to offer Apple Remote Access Protocol (ARAP) service
871 MUST NOT implement the RADIUS attributes for ARAP. A NAS MUST
872 treat a RADIUS access-accept authorizing an unavailable service as
873 an access-reject instead.
875 With respect to the Service-Type attribute, [RFC2865] Section 5.6
878 This Attribute indicates the type of service the user has
879 requested, or the type of service to be provided. It MAY be used
880 in both Access-Request and Access-Accept packets. A NAS is not
881 required to implement all of these service types, and MUST treat
882 unknown or unsupported Service-Types as though an Access-Reject
883 had been received instead.
885 [RFC2865] Section 5 states:
887 A RADIUS server MAY ignore Attributes with an unknown Type.
889 A RADIUS client MAY ignore Attributes with an unknown Type.
898 Nelson & DeKok Standards Track [Page 16]
900 RFC 5080 RADIUS Issues & Fixes December 2007
903 With respect to Vendor-Specific Attributes (VSAs), [RFC2865] Section
906 Servers not equipped to interpret the vendor-specific information
907 sent by a client MUST ignore it (although it may be reported).
908 Clients which do not receive desired vendor-specific information
909 SHOULD make an attempt to operate without it, although they may do
910 so (and report they are doing so) in a degraded mode.
912 It is possible for either a standard attribute or a VSA to represent
913 a request for an unavailable service. However, where the Type,
914 Vendor-ID, or Vendor-Type is unknown, a RADIUS client will not know
915 whether or not the attribute defines a service.
917 In general, it is best for a RADIUS client to err on the side of
918 caution. On receiving an Access-Accept including an attribute of
919 known Type for an unimplemented service, a RADIUS client MUST treat
920 it as an Access-Reject, as directed in [RFC2865] Section 1.1. On
921 receiving an Access-Accept including an attribute of unknown Type, a
922 RADIUS client SHOULD assume that it is a potential service
923 definition, and treat it as an Access-Reject. Unknown VSAs SHOULD be
924 ignored by RADIUS clients.
926 In order to avoid introducing changes in default behavior, existing
927 implementations that do not obey this recommendation should make the
928 behavior configurable, with the legacy behavior being enabled by
929 default. A configuration flag such as "treat unknown attributes as
930 reject" can be exposed to the system administrator. If the flag is
931 set to true, then Access-Accepts containing unknown attributes are
932 treated as Access-Rejects. If the flag is set to false, then unknown
933 attributes in Access-Accepts are silently ignored.
935 On receiving a packet including an attribute of unknown Type, RADIUS
936 authentication server implementations SHOULD ignore such attributes.
937 However, RADIUS accounting server implementations typically do not
938 need to understand attributes in order to write them to stable
939 storage or pass them to the billing engine. Therefore, accounting
940 server implementations SHOULD be equipped to handle unknown
943 To avoid misinterpretation of service requests encoded within VSAs,
944 RADIUS servers SHOULD NOT send VSAs containing service requests to
945 RADIUS clients that are not known to understand them. For example, a
946 RADIUS server should not send a VSA encoding a filter without
947 knowledge that the RADIUS client supports the VSA.
954 Nelson & DeKok Standards Track [Page 17]
956 RFC 5080 RADIUS Issues & Fixes December 2007
959 2.6. Interpretation of Access-Reject
961 2.6.1. Improper Use of Access-Reject
963 The intent of an Access-Reject is to deny access to the requested
964 service. [RFC2865] Section 2 states:
966 If any condition is not met, the RADIUS server sends an "Access-
967 Reject" response indicating that this user request is invalid. If
968 desired, the server MAY include a text message in the Access-
969 Reject which MAY be displayed by the client to the user. No other
970 Attributes (except Proxy-State) are permitted in an Access-Reject.
972 This text makes it clear that RADIUS does not allow the provisioning
973 of services within an Access-Reject. If the desire is to allow
974 limited access, then an Access-Accept can be sent with attributes
975 provisioning limited access. Attributes within an Access-Reject are
976 restricted to those necessary to route the message (e.g., Proxy-
977 State), attributes providing the user with an indication that access
978 has been denied (e.g., an EAP-Message attribute containing an EAP-
979 Failure), or attributes conveying an error message (e.g., a Reply-
980 Message or Error-Cause attribute).
982 Unfortunately, there are examples where this requirement has been
983 misunderstood. [RFC2869] Section 2.2 states:
985 If that authentication fails, the RADIUS server should return an
986 Access-Reject packet to the NAS, with optional Password-Retry and
987 Reply-Messages attributes. The presence of Password-Retry
988 indicates the ARAP NAS MAY choose to initiate another challenge-
991 This paragraph is problematic from two perspectives. Firstly, a
992 Password-Retry attribute is being returned in an Access-Reject; this
993 attribute does not fit into the categories established in [RFC2865].
994 Secondly, an Access-Reject packet is being sent in the context of a
995 continuing authentication conversation; [RFC2865] requires use of an
996 Access-Challenge for this. [RFC2869] uses the phrase "challenge-
997 response" to describe this use of Access-Reject, indicating that the
998 semantics of Access-Challenge are being used.
1000 [RFC2865] Section 4.4 addresses the semantics of Access-Challenge
1001 being equivalent to Access-Reject in some cases:
1003 If the NAS does not support challenge/response, it MUST treat an
1004 Access-Challenge as though it had received an Access-Reject
1010 Nelson & DeKok Standards Track [Page 18]
1012 RFC 5080 RADIUS Issues & Fixes December 2007
1015 While it is difficult to correct existing deployments of [RFC2869],
1016 we make the following recommendations:
1018 [1] New RADIUS specifications and implementations MUST NOT use
1019 Access-Reject where the semantics of Access-Challenge are
1022 [2] Access-Reject MUST mean denial of access to the requested
1023 service. In response to an Access-Reject, the NAS MUST NOT
1024 send any additional Access-Request packets for that user
1027 [3] New deployments of ARAP [RFC2869] SHOULD use Access-
1028 Challenge instead of Access-Reject packets in the
1029 conversations described in [RFC2869] Section 2.2.
1031 We also note that the table of attributes in [RFC2869] Section 5.19
1032 has an error for the Password-Retry attribute. It says:
1034 Request Accept Reject Challenge # Attribute
1035 0 0 0-1 0 75 Password-Retry
1037 However, the text in [RFC2869], Section 2.3.2 says that Password-
1038 Retry can be included within an Access-Challenge packet for EAP
1039 authentication sessions. We recommend a correction to the table that
1040 removes the "0-1" from the Reject column, and moves it to the
1041 Challenge column. We also add a "Note 2" to follow the existing
1042 "Note 1" in the document to clarify the use of this attribute.
1044 Request Accept Reject Challenge # Attribute
1045 0 0 0 0-1 75 Password-Retry [Note 2]
1047 [Note 2] As per RFC 3579, the use of the Password-Retry in EAP
1048 authentications is deprecated. The Password-Retry attribute can be
1049 used only for ARAP authentication.
1051 2.6.2. Service Request Denial
1053 RADIUS has been deployed for purposes outside network access
1054 authentication, authorization, and accounting. For example, RADIUS
1055 has been deployed as a "back-end" for authenticating Voice Over IP
1056 (VOIP) connections, Hypertext Transfer Protocol (HTTP) sessions
1057 (e.g., Apache), File Transfer Protocol (FTP) sessions (e.g.,
1058 proftpd), and machine logins for multiple operating systems (e.g.,
1059 bsdi, pam, and gina). In those contexts, an Access-Reject sent to
1060 the RADIUS client MUST be interpreted as a rejection of the request
1061 for service, and the RADIUS client MUST NOT offer that service to the
1066 Nelson & DeKok Standards Track [Page 19]
1068 RFC 5080 RADIUS Issues & Fixes December 2007
1071 For example, when an authentication failure occurs in the context of
1072 an FTP session, the normal semantics for rejecting FTP services
1073 apply. The rejection does not necessarily cause the FTP server to
1074 terminate the underlying TCP connection, but the FTP server MUST NOT
1075 offer any services protected by user authentication.
1077 Users may request multiple services from the NAS. Where those
1078 services are independent, the deployment MUST treat the RADIUS
1079 sessions as being independent.
1081 For example, a NAS may offer multi-link services where a user may
1082 have multiple simultaneous network connections. In that case, an
1083 Access-Reject for a later multi-link connection request does not
1084 necessarily mean that earlier multi-link connections are torn down.
1085 Similarly, if a NAS offers both dialup and VOIP services, the
1086 rejection of a VOIP attempt does not mean that the dialup session is
1091 2.7.1. Link-Local Addresses
1093 Since Link-Local addresses are unique only on the local link, if the
1094 NAS and RADIUS server are not on the same link, then an IPv6 Link-
1095 Local address [RFC4862] or an IPv4 Link-Local Address [RFC3927]
1096 cannot be used to uniquely identify the NAS. A NAS SHOULD NOT
1097 utilize a link-scope address within a NAS-IPv6-Address or NAS-IP-
1098 Address attribute. A RADIUS server receiving a NAS-IPv6-Address or
1099 NAS-IP-Address attribute containing a Link-Local address SHOULD NOT
1100 count such an attribute toward satisfying the requirements of
1101 [RFC3162] Section 2.1:
1103 NAS-IPv6-Address and/or NAS-IP-Address MAY be present in an
1104 Access-Request packet; however, if neither attribute is present
1105 then NAS-Identifier MUST be present.
1107 2.7.2. Multiple Addresses
1109 There are situations in which a RADIUS client or server may have
1110 multiple addresses. For example, a dual stack host can have both
1111 IPv4 and IPv6 addresses; a host that is a member of multiple VLANs
1112 could have IPv4 and/or IPv6 addresses on each VLAN; a host can have
1113 multiple IPv4 or IPv6 addresses on a single interface. However,
1114 [RFC2865] Section 5.44 only permits zero or one NAS-IP-Address
1115 attributes within an Access-Request, and [RFC3162] Section 3 only
1116 permits zero or one NAS-IPv6-Address attributes within an Access-
1117 Request. When a NAS has more than one global address and no ability
1118 to determine which is used for identification in a particular
1122 Nelson & DeKok Standards Track [Page 20]
1124 RFC 5080 RADIUS Issues & Fixes December 2007
1127 request, it is RECOMMENDED that the NAS include the NAS-Identifier
1128 attribute in an Access-Request in order to identify itself to the
1131 [RFC2865] Section 3 states:
1133 A RADIUS server MUST use the source IP address of the RADIUS UDP
1134 packet to decide which shared secret to use, so that RADIUS
1135 requests can be proxied.
1137 Therefore, if a RADIUS client sends packets from more than one source
1138 address, a shared secret will need to be configured on both the
1139 client and server for each source address.
1143 With respect to the Idle-Timeout attribute, [RFC2865] Section 5.28
1146 This Attribute sets the maximum number of consecutive seconds of
1147 idle connection allowed to the user before termination of the
1148 session or prompt. This Attribute is available to be sent by the
1149 server to the client in an Access-Accept or Access-Challenge.
1151 [RFC3580] Section 3.12 states:
1153 The Idle-Timeout attribute is described in [RFC2865]. For IEEE
1154 802 media other than 802.11 the media are always on. As a result
1155 the Idle-Timeout attribute is typically only used with wireless
1156 media such as IEEE 802.11. It is possible for a wireless device
1157 to wander out of range of all Access Points. In this case, the
1158 Idle-Timeout attribute indicates the maximum time that a wireless
1159 device may remain idle.
1161 In the above paragraphs "idle" may not necessarily mean "no traffic";
1162 the NAS may support filters defining what traffic is included in the
1163 idle time determination. As a result, an "idle connection" is
1164 defined by local policy in the absence of other attributes.
1166 2.9. Unknown Identity
1168 [RFC3748] Section 5.1 states:
1170 If the Identity is unknown, the Identity Response field should be
1171 zero bytes in length.
1178 Nelson & DeKok Standards Track [Page 21]
1180 RFC 5080 RADIUS Issues & Fixes December 2007
1183 However, [RFC2865] Section 5.1 describes the User-Name attribute as
1186 The String field is one or more octets.
1188 How should the RADIUS client behave if it receives an EAP-
1189 Response/Identity that is zero octets in length?
1191 [RFC2865] Section 5.1 states:
1193 This Attribute indicates the name of the user to be authenticated.
1194 It MUST be sent in Access-Request packets if available.
1196 This suggests that the User-Name attribute may be omitted if it is
1199 However, [RFC3579] Section 2.1 states:
1201 In order to permit non-EAP aware RADIUS proxies to forward the
1202 Access-Request packet, if the NAS initially sends an EAP-
1203 Request/Identity message to the peer, the NAS MUST copy the
1204 contents of the Type-Data field of the EAP-Response/Identity
1205 received from the peer into the User-Name attribute and MUST
1206 include the Type-Data field of the EAP-Response/Identity in the
1207 User-Name attribute in every subsequent Access-Request.
1209 This suggests that the User-Name attribute should contain the
1210 contents of the Type-Data field of the EAP-Response/Identity, even if
1211 it is zero octets in length.
1213 Note that [RFC4282] does not permit a Network Access Identifier (NAI)
1214 of zero octets, so that an EAP-Response/Identity with a Type-Data
1215 field of zero octets MUST NOT be construed as a request for privacy
1216 (e.g., anonymous NAI).
1218 When a NAS receives an EAP-Response/Identity with a Type-Data field
1219 that is zero octets in length, it is RECOMMENDED that it either omit
1220 the User-Name attribute in the Access-Request or include the
1221 Calling-Station-Id in the User-Name attribute, along with a Calling-
1222 Station-Id attribute.
1224 2.10. Responses After Retransmissions
1226 Some implementations do not correctly handle the receipt of RADIUS
1227 responses after retransmissions. [RFC2865] Section 2.5 states:
1234 Nelson & DeKok Standards Track [Page 22]
1236 RFC 5080 RADIUS Issues & Fixes December 2007
1239 If the NAS is retransmitting a RADIUS request to the same server
1240 as before, and the attributes haven't changed, you MUST use the
1241 same Request Authenticator, ID, and source port. If any
1242 attributes have changed, you MUST use a new Request Authenticator
1245 Note that changing the Request ID for a retransmission may have
1246 undesirable side effects. Since RADIUS does not have a clear
1247 definition of a "session", it is perfectly valid for a RADIUS server
1248 to treat a retransmission as a new session request, and to reject it
1249 due to, for example, the enforcement of restrictions on multiple
1250 simultaneous logins.
1252 In that situation, the NAS may receive a belated Access-Accept for
1253 the first request, and an Access-Reject for the retransmitted
1254 request, both of which apply to the same "session".
1256 We suggest that the contents of Access-Request packets SHOULD NOT be
1257 changed during retransmissions. If they must be changed due to the
1258 inclusion of an Event-Timestamp attribute, for example, then
1259 responses to earlier transmissions MUST be silently discarded. Any
1260 response to the current request MUST be treated as the definitive
1261 response, even if as noted above, it disagrees with earlier
1264 This problem can be made worse by implementations that use a fixed
1265 retransmission timeout (30 seconds is common). We reiterate the
1266 suggestions in Section 2.1 about using congestive backoff. In that
1267 case, responses to earlier transmissions MAY be used as data points
1268 for congestive backoff, even if their contents are discarded.
1270 2.11. Framed-IPv6-Prefix
1272 [RFC3162] Section 2.3 says:
1274 This Attribute indicates an IPv6 prefix (and corresponding route)
1275 to be configured for the user. It MAY be used in Access-Accept
1276 packets, and can appear multiple times. It MAY be used in an
1277 Access-Request packet as a hint by the NAS to the server that it
1278 would prefer these prefix(es), but the server is not required to
1279 honor the hint. Since it is assumed that the NAS will plumb a
1280 route corresponding to the prefix, it is not necessary for the
1281 server to also send a Framed-IPv6-Route attribute for the same
1284 An Internet Service Provider (ISP) may desire to support Prefix
1285 Delegation [RFC4818] at the same time that it would like to assign a
1286 prefix for the link between the NAS and the user. The intent of the
1290 Nelson & DeKok Standards Track [Page 23]
1292 RFC 5080 RADIUS Issues & Fixes December 2007
1295 paragraph was to enable the NAS to advertise the prefix (such as via
1296 a Router Advertisement). If the Framed-Routing attribute is used, it
1297 is also possible that the prefix would be advertised in a routing
1298 protocol such as Routing Information Protocol Next Generation
1299 (RIPNG). RFC 2865 Section 5.10 describes the purpose of Framed-
1302 This Attribute indicates the routing method for the user, when the
1303 user is a router to a network. It is only used in Access-Accept
1306 The description of the Prefix-Length field in RFC 3162 indicates
1307 excessively wide latitude:
1309 The length of the prefix, in bits. At least 0 and no larger than
1312 This length appears too broad, because it is not clear what a NAS
1313 should do with a prefix of greater granularity than /64. For
1314 example, the Framed-IPv6-Prefix may contain a /128. This does not
1315 imply that the NAS should assign an IPv6 address to the end user,
1316 because RFC 3162 already defines a Framed-IPv6-Identifier attribute
1317 to handle the Identifier portion.
1319 It appears that the Framed-IPv6-Prefix is used for the link between
1320 the NAS and Customer Premises Equipment (CPE) only if a /64 prefix is
1321 assigned. When a /64 or larger prefix is sent, the intent is for the
1322 NAS to send a routing advertisement containing the information
1323 present in the Framed-IPv6-Prefix attribute.
1325 The CPE may also require a delegated prefix for its own use, if it is
1326 decrementing the Hop Limit field of IP headers. In that case, it
1327 should be delegated a prefix by the NAS via the Delegated-IPv6-Prefix
1328 attribute [RFC4818]. If the CPE is not decrementing Hop Limit, it
1329 does not require a delegated prefix.
1331 3. Security Considerations
1333 The contents of the State attribute are available to both the RADIUS
1334 client and observers of the RADIUS protocol. RADIUS server
1335 implementations should ensure that the State attribute does not
1336 disclose sensitive information to a RADIUS client or third parties
1337 observing the RADIUS protocol.
1339 The cache mechanism described in Section 2.2.2 is vulnerable to
1340 attacks when Access-Request packets do not contain a Message-
1341 Authenticator attribute. If the server accepts requests without a
1342 Message-Authenticator, then RADIUS packets can be trivially forged by
1346 Nelson & DeKok Standards Track [Page 24]
1348 RFC 5080 RADIUS Issues & Fixes December 2007
1351 an attacker. Cache entries can then be forcibly expired, negating
1352 the utility of the cache. This attack can be mitigated by following
1353 the suggestions in [RFC3579] Section 4, or by requiring the presence
1354 of Message-Authenticator, as described in Sections 2.1.1 and 2.2.2.
1356 Since this document describes the use of RADIUS for purposes of
1357 authentication, authorization, and accounting in a wide variety of
1358 networks, applications using these specifications are vulnerable to
1359 all of the threats that are present in other RADIUS applications.
1360 For a discussion of these threats, see [RFC2865], [RFC2607],
1361 [RFC3162], [RFC3579], and [RFC3580].
1365 4.1. Normative References
1367 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1368 Requirement Levels", BCP 14, RFC 2119, March 1997.
1370 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
1371 "Remote Authentication Dial In User Service (RADIUS)",
1372 RFC 2865, June 2000.
1374 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
1375 Attribute", RFC 4818, April 2007.
1377 4.2. Informative References
1379 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
1380 Implementation in Roaming", RFC 2607, June 1999.
1382 [RFC2618] Aboba, B. and G. Zorn, "RADIUS Authentication Client
1383 MIB", RFC 2618, June 1999.
1385 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
1387 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS
1388 Extensions", RFC 2869, June 2000.
1390 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
1391 RFC 3162, August 2001.
1393 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
1394 C., and M. Carney, "Dynamic Host Configuration Protocol
1395 for IPv6 (DHCPv6)", RFC 3315, July 2003.
1402 Nelson & DeKok Standards Track [Page 25]
1404 RFC 5080 RADIUS Issues & Fixes December 2007
1407 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
1408 Aboba, "Dynamic Authorization Extensions to Remote
1409 Authentication Dial In User Service (RADIUS)", RFC 3576,
1412 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
1413 Dial In User Service) Support For Extensible
1414 Authentication Protocol (EAP)", RFC 3579, September 2003.
1416 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J.
1417 Roese, "IEEE 802.1X Remote Authentication Dial In User
1418 Service (RADIUS) Usage Guidelines", RFC 3580, September
1421 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
1422 Levkowetz, Ed., "Extensible Authentication Protocol
1423 (EAP)", RFC 3748, June 2004.
1425 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
1426 Configuration of IPv4 Link-Local Addresses", RFC 3927,
1429 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
1430 Network Access Identifier", RFC 4282, December 2005.
1432 [RFC4668] Nelson, D., "RADIUS Authentication Client MIB for IPv6",
1433 RFC 4668, August 2006.
1435 [RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6",
1436 RFC 4669, August 2006.
1438 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
1439 Address Autoconfiguration", RFC 4862, September 2007.
1441 [PANA] Forsberg, D., Ohba, Y.,Ed., Patil, B., Tschofenig, H.,
1442 and A. Yegin, "Protocol for Carrying Authentication for
1443 Network Access (PANA)", Work in Progress.
1458 Nelson & DeKok Standards Track [Page 26]
1460 RFC 5080 RADIUS Issues & Fixes December 2007
1465 The authors would like to acknowledge Glen Zorn and Bernard Aboba for
1466 contributions to this document.
1468 The alternate algorithm to [RFC3579] Section 2.6.1 that is described
1469 in Section 2.1.2 of this document was designed by Raghu Dendukuri.
1471 The text discussing retransmissions in Section 2.2.1 is taken with
1472 minor edits from Section 9 of" Protocol for Carrying Authentication
1473 for Network Access (PANA)" [PANA].
1475 Alan DeKok wishes to acknowledge the support of Quiconnect Inc.,
1476 where he was employed during much of the work on this document.
1478 David Nelson wishes to acknowledge the support of Enterasys Networks,
1479 where he was employed during much of the work on this document.
1484 Elbrys Networks, Inc.
1485 75 Rochester Ave., Unit 3
1486 Portsmouth, N.H. 03801 USA
1488 Phone: +1.603.570.2636
1489 EMail: dnelson@elbrysnetworks.com
1493 The FreeRADIUS Server Project
1494 http://freeradius.org/
1496 EMail: aland@freeradius.org
1514 Nelson & DeKok Standards Track [Page 27]
1516 RFC 5080 RADIUS Issues & Fixes December 2007
1519 Full Copyright Statement
1521 Copyright (C) The IETF Trust (2007).
1523 This document is subject to the rights, licenses and restrictions
1524 contained in BCP 78, and except as set forth therein, the authors
1525 retain all their rights.
1527 This document and the information contained herein are provided on an
1528 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1529 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1530 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1531 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1532 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1533 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1535 Intellectual Property
1537 The IETF takes no position regarding the validity or scope of any
1538 Intellectual Property Rights or other rights that might be claimed to
1539 pertain to the implementation or use of the technology described in
1540 this document or the extent to which any license under such rights
1541 might or might not be available; nor does it represent that it has
1542 made any independent effort to identify any such rights. Information
1543 on the procedures with respect to rights in RFC documents can be
1544 found in BCP 78 and BCP 79.
1546 Copies of IPR disclosures made to the IETF Secretariat and any
1547 assurances of licenses to be made available, or the result of an
1548 attempt made to obtain a general license or permission for the use of
1549 such proprietary rights by implementers or users of this
1550 specification can be obtained from the IETF on-line IPR repository at
1551 http://www.ietf.org/ipr.
1553 The IETF invites any interested party to bring to its attention any
1554 copyrights, patents or patent applications, or other proprietary
1555 rights that may cover technology that may be required to implement
1556 this standard. Please address the information to the IETF at
1570 Nelson & DeKok Standards Track [Page 28]