doc: Add RFC documents

1 files changed, 1571 insertions, 0 deletions

diff --git a/doc/rfc/rfc5080.txt b/doc/rfc/rfc5080.txt
new file mode 100644
index 0000000..9f00807
--- /dev/null
+++ b/doc/rfc/rfc5080.txt
@@ -0,0 +1,1571 @@
+
+
+
+
+
+
+Network Working Group                                          D. Nelson
+Request for Comments: 5080                          Elbrys Networks, Inc
+Updates: 2865, 2866, 2869, 3579                                 A. DeKok
+Category: Standards Track                                     FreeRADIUS
+                                                           December 2007
+
+
+       Common Remote Authentication Dial In User Service (RADIUS)
+               Implementation Issues and Suggested Fixes
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This document describes common issues seen in Remote Authentication
+   Dial In User Service (RADIUS) implementations and suggests some
+   fixes.  Where applicable, ambiguities and errors in previous RADIUS
+   specifications are clarified.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nelson & DeKok              Standards Track                     [Page 1]
+
+RFC 5080                 RADIUS Issues & Fixes             December 2007
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Terminology ................................................3
+      1.2. Requirements Language ......................................3
+   2. Issues ..........................................................3
+      2.1. Session Definition .........................................3
+           2.1.1. State Attribute .....................................3
+           2.1.2. Request-ID Supplementation ..........................6
+      2.2. Overload Conditions ........................................7
+           2.2.1. Retransmission Behavior .............................7
+           2.2.2. Duplicate Detection and Orderly Delivery ...........10
+           2.2.3. Server Response to Overload ........................11
+      2.3. Accounting Issues .........................................12
+           2.3.1. Attributes Allowed in an Interim Update ............12
+           2.3.2. Acct-Session-Id and Acct-Multi-Session-Id ..........12
+           2.3.3. Request Authenticator ..............................13
+           2.3.4. Interim-Accounting-Interval ........................13
+           2.3.5. Counter Values in the RADIUS Management
+                  Information Base (MIB) .............................14
+      2.4. Multiple Filter-ID Attributes .............................15
+      2.5. Mandatory and Optional Attributes .........................16
+      2.6. Interpretation of Access-Reject ...........................18
+           2.6.1. Improper Use of Access-Reject ......................18
+           2.6.2. Service Request Denial .............................19
+      2.7. Addressing ................................................20
+           2.7.1. Link-Local Addresses ...............................20
+           2.7.2. Multiple Addresses .................................20
+      2.8. Idle-Timeout ..............................................21
+      2.9. Unknown Identity ..........................................21
+      2.10. Responses After Retransmissions ..........................22
+      2.11. Framed-IPv6-Prefix .......................................23
+   3. Security Considerations ........................................24
+   4. References .....................................................25
+      4.1. Normative References ......................................25
+      4.2. Informative References ....................................25
+
+1.  Introduction
+
+   The last few years have seen an increase in the deployment of RADIUS
+   clients and servers.  This document describes common issues seen in
+   RADIUS implementations and suggests some fixes.  Where applicable,
+   ambiguities and errors in previous RADIUS specifications are
+   clarified.
+
+
+
+
+
+
+
+Nelson & DeKok              Standards Track                     [Page 2]
+
+RFC 5080                 RADIUS Issues & Fixes             December 2007
+
+
+1.1.  Terminology
+
+   This document uses the following terms:
+
+   Network Access Server (NAS)
+      The device providing access to the network.  Also known as the
+      Authenticator in IEEE 802.1X or Extensible Authentication Protocol
+      (EAP) terminology, or RADIUS client.
+
+   service
+      The NAS provides a service to the user, such as network access via
+      802.11 or Point to Point Protocol (PPP).
+
+   session
+      Each service provided by the NAS to a peer constitutes a session,
+      with the beginning of the session defined as the point where
+      service is first provided, and the end of the session is defined
+      as the point where service is ended.  A peer may have multiple
+      sessions in parallel or series if the NAS supports that, with each
+      session generating a separate start and stop accounting record.
+
+   silently discard
+      This means the implementation discards the packet without further
+      processing.  The implementation SHOULD provide the capability of
+      logging the error, including the contents of the silently
+      discarded packet, and SHOULD record the event in a statistics
+      counter.
+
+1.2.  Requirements Language
+
+   In this document, several words are used to signify the requirements
+   of the specification.  The key words "MUST", "MUST NOT", "REQUIRED",
+   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY",
+   and "OPTIONAL" in this document are to be interpreted as described in
+   [RFC2119].
+
+2.  Issues
+
+2.1.  Session Definition
+
+2.1.1.  State Attribute
+
+   Regarding the State attribute, [RFC2865] Section 5.24 states:
+
+      This Attribute is available to be sent by the server to the client
+      in an Access-Challenge and MUST be sent unmodified from the client
+      to the server in the new Access-Request reply to that challenge,
+      if any.
+
+
+
+Nelson & DeKok              Standards Track                     [Page 3]
+
+RFC 5080                 RADIUS Issues & Fixes             December 2007
+
+
+      This Attribute is available to be sent by the server to the client
+      in an Access-Accept that also includes a Termination-Action
+      Attribute with the value of RADIUS-Request.  If the NAS performs
+      the Termination-Action by sending a new Access-Request upon
+      termination of the current session, it MUST include the State
+      attribute unchanged in that Access-Request.
+
+   Some RADIUS client implementations do not properly use the State
+   attribute in order to distinguish a restarted EAP authentication
+   process from the continuation of an ongoing process (by the same user
+   on the same NAS and port).  Where an EAP-Message attribute is
+   included in an Access-Challenge or Access-Accept attribute, RADIUS
+   servers SHOULD also include a State attribute.  See Section 2.1.2 on
+   Request ID supplementation for additional benefits to using the State
+   attribute in this fashion.
+
+   As defined in [RFC2865] Table 5.44, Access-Request packets may
+   contain a State attribute.  The table does not qualify this
+   statement, while the text in Section 5.24 (quoted above) adds other
+   requirements not specified in that table.
+
+   We extend the requirements of [RFC2865] to say that Access-Requests
+   that are part of an ongoing Access-Request / Access-Challenge
+   authentication process SHOULD contain a State attribute.  It is the
+   responsibility of the server, to send a State attribute in an
+   Access-Challenge packet, if that server needs a State attribute in a
+   subsequent Access-Request to tie multiple Access-Requests together
+   into one authentication session.  As defined in [RFC2865] Section
+   5.24, the State MUST be sent unmodified from the client to the server
+   in the new Access-Request reply to that challenge, if any.
+
+   While most server implementations require the presence of a State
+   attribute in an Access-Challenge packet, some challenge-response
+   systems can distinguish the initial request from the response to the
+   challenge without using a State attribute to track an authentication
+   session.  The Access-Challenge and subsequent Access-Request packets
+   for those systems do not need to contain a State attribute.
+
+   Other authentication mechanisms need to tie a sequence of Access-
+   Request / Access-Challenge packets together into one ongoing
+   authentication session.  Servers implementing those authentication
+   mechanisms SHOULD include a State attribute in Access-Challenge
+   packets.
+
+   In general, if the authentication process involves one or more
+   Access-Request / Access-Challenge sequences, the State attribute
+   SHOULD be sent by the server in the Access-Challenge packets.  Using
+   the State attribute to create a multi-packet session is the simplest
+
+
+
+Nelson & DeKok              Standards Track                     [Page 4]
+
+RFC 5080                 RADIUS Issues & Fixes             December 2007
+
+
+   method available in RADIUS today.  While other methods of creating
+   multi-packet sessions are possible (e.g., [RFC3579] Section 2.6.1),
+   those methods are NOT RECOMMENDED.
+
+   The only permissible values for a State attribute are values provided
+   in an Access-Accept, Access-Challenge, CoA-Request or Disconnect-
+   Request packet.  A RADIUS client MUST use only those values for the
+   State attribute that it has previously received from a server.  An
+   Access-Request sent as a result of a new or restarted authentication
+   run MUST NOT include the State attribute, even if a State attribute
+   has previously been received in an Access-Challenge for the same user
+   and port.
+
+   Access-Request packets that contain a Service-Type attribute with the
+   value Authorize Only (17) MUST contain a State attribute.  Access-
+   Request packets that contain a Service-Type attribute with value Call
+   Check (10) SHOULD NOT contain a State attribute.  Any other Access-
+   Request packet that performs authorization checks MUST contain a
+   State attribute.  This last requirement often means that an Access-
+   Accept needs to contain a State attribute, which can then be used in
+   a later Access-Request that performs authorization checks.
+
+   The standard use case for Call Check is pre-screening authentication
+   based solely on the end-point identifier information, such as phone
+   number or Media Access Control (MAC) address in Calling-Station-ID
+   and optionally Called-Station-ID.  In this use case, the NAS has no
+   way to obtain a State attribute suitable for inclusion in an Access-
+   Request.  Other, non-standard, uses of Call Check may require or
+   permit the use of a State attribute, but are beyond the scope of this
+   document.
+
+   In an Access-Request with a Service-Type Attribute with value Call
+   Check, it is NOT RECOMMENDED for the User-Name and User-Password
+   attributes to contain the same values (e.g., a MAC address).
+   Implementing MAC address checking without using a Service-Type of
+   Call Check is NOT RECOMMENDED.  This practice gives an attacker both
+   the clear-text and cipher-text of the User-Password field, which
+   permits many attacks on the security of the RADIUS protocol.  For
+   example, if the Request Authenticator does not satisfy the [RFC2865]
+   requirements on global and temporal uniqueness, the practice
+   described above may lead to the compromise of the User-Password
+   attribute in other Access-Requests for unrelated users.  Access to
+   the cipher-text enables offline dictionary attacks, potentially
+   exposing the shared secret and compromising the entire RADIUS
+   protocol.
+
+
+
+
+
+
+Nelson & DeKok              Standards Track                     [Page 5]
+
+RFC 5080                 RADIUS Issues & Fixes             December 2007
+
+
+   Any Access-Request packet that performs authorization checks,
+   including Call Check, SHOULD contain a Message-Authenticator
+   attribute.  Any response to an Access-Request performing an
+   authorization check MUST NOT contain confidential information about
+   any user (such as Tunnel-Password), unless that Access-Request
+   contains a State attribute.  The use of State here permits the
+   authorization check to be tied to an earlier user authentication.  In
+   that case, the server MAY respond to the NAS with confidential
+   information about that user.  The server MUST NOT respond to that
+   authorization check with confidential information about any other
+   user.
+
+   For an Access-Request packet performing an authorization check that
+   does not contain a State attribute, the server MUST respond with an
+   Access-Reject.
+
+2.1.2.  Request-ID Supplementation
+
+   [RFC3579] Section 2.6.1 states:
+
+      In EAP, each session has its own unique Identifier space.  RADIUS
+      server implementations MUST be able to distinguish between EAP
+      packets with the same Identifier existing within distinct
+      sessions, originating on the same NAS.  For this purpose, sessions
+      can be distinguished based on NAS and session identification
+      attributes.  NAS identification attributes include NAS-Identifier,
+      NAS-IPv6-Address and NAS-IPv4-Address.  Session identification
+      attributes include User-Name, NAS-Port, NAS-Port-Type, NAS-Port-
+      Id, Called-Station-Id, Calling-Station-Id and Originating-Line-
+      Info.
+
+   There are issues with the suggested algorithm.  Since proxies may
+   modify Access-Request attributes such as NAS-IP-Address, depending on
+   any attribute under control of the NAS to distinguish request
+   identifiers can result in deployment problems.
+
+   The FreeRADIUS implementation does not track EAP identifiers by NAS-
+   IP-Address or other non-EAP attributes sent by the NAS.  Instead, it
+   uses the EAP identifier, source Internet Protocol (IP) address, and
+   the State attribute as a "key" to uniquely identify each EAP session.
+   Since the State attribute is under the control of the RADIUS server,
+   the uniqueness of each session is controlled by the server, not the
+   NAS.  The algorithm used in FreeRADIUS is as follows:
+
+
+
+
+
+
+
+
+Nelson & DeKok              Standards Track                     [Page 6]
+
+RFC 5080                 RADIUS Issues & Fixes             December 2007
+
+
+      if (EAP start, or EAP identity) {
+        allocate unique State Attribute
+        insert session into "active session" table with
+             key=(EAP identifier, State, source IP)
+      } else {
+        look up active session in table, with above key
+      }
+
+   This algorithm appears to work well in a variety of situations,
+   including situations where home servers receive messages via
+   intermediate RADIUS proxies.
+
+   Implementations that do not use this algorithm are often restricted
+   to having an EAP Identifier space per NAS, or perhaps one that is
+   global to the implementation.  These restrictions are unnecessary
+   when the above algorithm is used, which gives each session a unique
+   EAP Identifier space.  The above algorithm SHOULD be used to track
+   EAP sessions in preference to any other method.
+
+2.2.  Overload Conditions
+
+2.2.1.  Retransmission Behavior
+
+   [RFC2865] Section 2.4 describes the retransmission requirements for
+   RADIUS clients:
+
+      At one extreme, RADIUS does not require a "responsive" detection
+      of lost data.  The user is willing to wait several seconds for the
+      authentication to complete.  The generally aggressive Transmission
+      Control Protocol (TCP) retransmission (based on average round trip
+      time) is not required, nor is the acknowledgment overhead of TCP.
+
+      At the other extreme, the user is not willing to wait several
+      minutes for authentication.  Therefore the reliable delivery of
+      TCP data two minutes later is not useful.  The faster use of an
+      alternate server allows the user to gain access before giving up.
+
+   Some existing RADIUS clients implement excessively aggressive
+   retransmission behavior, utilizing default retransmission timeouts of
+   one second or less without support for congestive backoff.  When
+   deployed at a large scale, these implementations are susceptible to
+   congestive collapse.  For example, as the result of a power failure,
+   a network with 3,000 NAS devices with a fixed retransmission timer of
+   one second will continuously generate 3,000 RADIUS Access-Requests
+   per second.  This is sufficient to overwhelm most RADIUS servers.
+
+
+
+
+
+
+Nelson & DeKok              Standards Track                     [Page 7]
+
+RFC 5080                 RADIUS Issues & Fixes             December 2007
+
+
+   Suggested solutions include:
+
+      [a]   Jitter.  To avoid synchronization, a RADIUS client SHOULD
+            incorporate induced jitter within its retransmission
+            algorithm, as specified below.
+
+      [b]   Congestive backoff.  While it is not necessary for RADIUS
+            client implementations to implement complex retransmission
+            algorithms, implementations SHOULD support congestive
+            backoff.
+
+   RADIUS retransmission timers are based on the model used in Dynamic
+   Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315].  Variables
+   used here are also borrowed from this specification.  RADIUS is a
+   request/response-based protocol.  The message exchange terminates
+   when the requester successfully receives the answer, or the message
+   exchange is considered to have failed according to the RECOMMENDED
+   retransmission mechanism described below.  Other retransmission
+   mechanisms are possible, as long as they satisfy the requirements on
+   jitter and congestive backoff.
+
+   The following algorithms apply to any client that originates RADIUS
+   packets, including but not limited to Access-Request, Accounting-
+   Request, Disconnect-Request, and CoA-Request [RFC3576].
+
+   The retransmission behavior is controlled and described by the
+   following variables:
+
+         RT     Retransmission timeout
+
+         IRT    Initial retransmission time  (default 2 seconds)
+
+         MRC    Maximum retransmission count (default 5 attempts)
+
+         MRT    Maximum retransmission time (default 16 seconds)
+
+         MRD    Maximum retransmission duration (default 30 seconds)
+
+         RAND   Randomization factor
+
+   With each message transmission or retransmission, the sender sets RT
+   according to the rules given below.  If RT expires before the message
+   exchange terminates, the sender re-computes RT and retransmits the
+   message.
+
+
+
+
+
+
+
+Nelson & DeKok              Standards Track                     [Page 8]
+
+RFC 5080                 RADIUS Issues & Fixes             December 2007
+
+
+   Each of the computations of a new RT include a randomization factor
+   (RAND), which is a random number chosen with a uniform distribution
+   between -0.1 and +0.1.  The randomization factor is included to
+   minimize the synchronization of messages.
+
+   The algorithm for choosing a random number does not need to be
+   cryptographically sound.  The algorithm SHOULD produce a different
+   sequence of random numbers from each invocation.
+
+   RT for the first message transmission is based on IRT:
+
+         RT = IRT + RAND*IRT
+
+   RT for each subsequent message retransmission is based on the
+   previous value of RT:
+
+         RT = 2*RTprev + RAND*RTprev
+
+   MRT specifies an upper bound on the value of RT (disregarding the
+   randomization added by the use of RAND).  If MRT has a value of 0,
+   there is no upper limit on the value of RT.  Otherwise:
+
+         if (RT > MRT)
+            RT = MRT + RAND*MRT
+
+   MRD specifies an upper bound on the length of time a sender may
+   retransmit a message.  The message exchange fails once MRD seconds
+   have elapsed since the client first transmitted the message.  MRD
+   MUST be set, and SHOULD have a value between 5 and 30 seconds.  These
+   values mirror the values for a server's duplicate detection cache, as
+   described in the next section.
+
+   MRC specifies an upper bound on the number of times a sender may
+   retransmit a message.  If MRC is zero, the message exchange fails
+   once MRD seconds have elapsed since the client first transmitted the
+   message.  If MRC is non-zero, the message exchange fails when either
+   the sender has transmitted the message MRC times, or when MRD seconds
+   have elapsed since the client first transmitted the message.
+
+   For Accounting-Request packets, the default values for MRC, MRD, and
+   MRT SHOULD be zero.  These settings will enable a RADIUS client to
+   continue sending accounting requests to a RADIUS server until the
+   request is acknowledged.  If any of MRC, MRD, or MRT are non-zero,
+   then the accounting information could potentially be discarded
+   without being recorded.
+
+
+
+
+
+
+Nelson & DeKok              Standards Track                     [Page 9]
+
+RFC 5080                 RADIUS Issues & Fixes             December 2007
+
+
+2.2.2.  Duplicate Detection and Orderly Delivery
+
+   When packets are retransmitted by a client, the server may receive
+   duplicate requests.  The limitations of the transport protocol used
+   by RADIUS, the User Datagram Protocol (UDP), means that the Access-
+   Request packets may be received, and potentially processed, in an
+   order different from the order in which the packets were sent.
+   However, the discussion of the Identifier field in Section 3 of
+   [RFC2865] says:
+
+      The RADIUS server can detect a duplicate request if it has the
+      same client source IP address and source UDP port and Identifier
+      within a short span of time.
+
+   Also, Section 7 of [RFC4669] defines a
+   radiusAuthServDupAccessRequests object as:
+
+      The number of duplicate Access-Request packets received.
+
+   This text has a number of implications.  First, without duplicate
+   detection, a RADIUS server may process an authentication request
+   twice, leading to an erroneous conclusion that a user has logged in
+   twice.  That behavior is undesirable, so duplicate detection is
+   desirable.  Second, the server may track not only the duplicate
+   request, but also the replies to those requests.  This behavior
+   permits the server to send duplicate replies in response to duplicate
+   requests, increasing network stability.
+
+   Since Access-Request packets may also be sent by the client in
+   response to an Access-Challenge from the server, those packets form a
+   logically ordered stream, and, therefore have additional ordering
+   requirements over Access-Request packets for different sessions.
+   Implementing duplicate detection results in new packets being
+   processed only once, ensuring order.
+
+   RADIUS servers MUST therefore implement duplicate detection for
+   Access-Request packets, as described in Section 3 of [RFC2865].
+   Implementations MUST also cache the Responses (Access-Accept,
+   Access-Challenge, or Access-Reject) that they send in response to
+   Access-Request packets.  If a server receives a valid duplicate
+   Access-Request for which it has already sent a Response, it MUST
+   resend its original Response without reprocessing the request.  The
+   server MUST silently discard any duplicate Access-Requests for which
+   a Response has not yet been sent.
+
+
+
+
+
+
+
+Nelson & DeKok              Standards Track                    [Page 10]
+
+RFC 5080                 RADIUS Issues & Fixes             December 2007
+
+
+   Each cache entry SHOULD be purged after a period of time.  This time
+   SHOULD be no less than 5 seconds, and no more than 30 seconds.  After
+   about 30 seconds, most RADIUS clients and end users will have given
+   up on the authentication request.  Therefore, there is little value
+   in having a larger cache timeout.
+
+   Cache entries MUST also be purged if the server receives a valid
+   Access-Request packet that matches a cached Access-Request packet in
+   source address, source port, RADIUS Identifier, and receiving socket,
+   but where the Request Authenticator field is different from the one
+   in the cached packet.  If the request contains a Message-
+   Authenticator attribute, the request MUST be processed as described
+   in [RFC3580] Section 3.2.  Packets with invalid Message-
+   Authenticators MUST NOT affect the cache in any way.
+
+   However, Access-Request packets not containing a Message-
+   Authenticator attribute always affect the cache, even though they may
+   be trivially forged.  To avoid this issue, server implementations may
+   be configured to require the presence of a Message-Authenticator
+   attribute in Access-Request packets.  Requests not containing a
+   Message-Authenticator attribute MAY then be silently discarded.
+
+   Client implementations SHOULD include a Message-Authenticator
+   attribute in every Access-Request to further help mitigate this
+   issue.
+
+   When sending requests, RADIUS clients MUST NOT reuse Identifiers for
+   a source IP address and source UDP port until either a valid response
+   has been received, or the request has timed out.  Clients SHOULD
+   allocate Identifiers via a least-recently-used (LRU) method for a
+   particular source IP address and source UDP port.
+
+   RADIUS clients do not have to perform duplicate detection.  When a
+   client sends a request, it processes the first response that has a
+   valid Response Authenticator as defined in [RFC2865] Section 3.  Any
+   later responses MUST be silently discarded, as they do not match a
+   pending request.  That is, later responses are treated exactly the
+   same as unsolicited responses, and are silently discarded.
+
+2.2.3.  Server Response to Overload
+
+   Some RADIUS server implementations are not robust in response to
+   overload, dropping packets with even probability across multiple
+   sessions.  In an overload situation, this results in a high failure
+   rate for multi-round authentication protocols such as EAP [RFC3579].
+   Typically, users will continually retry in an attempt to gain access,
+   increasing the load even further.
+
+
+
+
+Nelson & DeKok              Standards Track                    [Page 11]
+
+RFC 5080                 RADIUS Issues & Fixes             December 2007
+
+
+   A more sensible approach is for a RADIUS server to preferentially
+   accept RADIUS Access-Request packets containing a valid State
+   attribute, so that multi-round authentication conversations, once
+   begun, will be more likely to succeed.  Similarly, a server that is
+   proxying requests should preferentially process Access-Accept,
+   Access-Challenge, or Access-Reject packets from home servers before
+   processing new requests from a NAS.
+
+   These methods will allow some users to gain access to the network,
+   reducing the load created by ongoing access attempts.
+
+2.3.  Accounting Issues
+
+2.3.1.  Attributes Allowed in an Interim Update
+
+   [RFC2866] indicates that Acct-Input-Octets, Acct-Output-Octets,
+   Acct-Session-Time, Acct-Input-Packets, Acct-Output-Packets and Acct-
+   Terminate-Cause attributes "can only be present in Accounting-Request
+   records where the Acct-Status-Type is set to Stop".
+
+   However [RFC2869] Section 2.1 states:
+
+      It is envisioned that an Interim Accounting record (with Acct-
+      Status-Type = Interim-Update (3)) would contain all of the
+      attributes normally found in an Accounting Stop message with the
+      exception of the Acct-Term-Cause attribute.
+
+   Although [RFC2869] does not indicate that it updates [RFC2866], this
+   is an oversight, and the above attributes are allowable in an Interim
+   Accounting record.
+
+2.3.2.  Acct-Session-Id and Acct-Multi-Session-Id
+
+   [RFC2866] Section 5.5 describes Acct-Session-Id as Text within the
+   figure summarizing the attribute format, but then goes on to state
+   that "The String field SHOULD be a string of UTF-8 encoded 10646
+   characters".
+
+   [RFC2865] defines the Text type as "containing UTF-8 encoded 10646
+   characters", which is compatible with the description of Acct-
+   Session-Id.  Since other attributes are consistently described as
+   "Text" within both the figure summarizing the attribute format, and
+   the following attribute definition, it appears that this is a
+   typographical error, and that Acct-Session-Id is of type Text, and
+   not of type String.
+
+
+
+
+
+
+Nelson & DeKok              Standards Track                    [Page 12]
+
+RFC 5080                 RADIUS Issues & Fixes             December 2007
+
+
+   The definition of the Acct-Multi-Session-Id attribute also has
+   typographical errors.  It says:
+
+      A summary of the Acct-Session-Id attribute format ...
+
+   This text should read:
+
+      A summary of the Acct-Multi-Session-Id attribute format ...
+
+   The Acct-Multi-Session-Id attribute is also defined as being of type
+   String.  However, the language in the text strongly recommends that
+   implementors consider the attribute as being of type Text.  It is
+   unclear why the type String was chosen for this attribute when the
+   type Text would be sufficient.  This attribute SHOULD be treated as
+   Text.
+
+2.3.3.  Request Authenticator
+
+   [RFC2866] Section 4.1 states:
+
+      The Request Authenticator of an Accounting-Request contains a 16-
+      octet MD5 hash value calculated according to the method described
+      in "Request Authenticator" above.
+
+   However, the text does not indicate any action to take when an
+   Accounting-Request packet contains an invalid Request Authenticator.
+   The following text should be considered to be part of the above
+   description:
+
+      The Request Authenticator field MUST contain the correct data, as
+      given by the above calculation.  Invalid packets are silently
+      discarded.  Note that some early implementations always set the
+      Request Authenticator to all zeros.  New implementations of RADIUS
+      clients MUST use the above algorithm to calculate the Request
+      Authenticator field.  New RADIUS server implementations MUST
+      silently discard invalid packets.
+
+2.3.4.  Interim-Accounting-Interval
+
+   [RFC2869] Section 2.1 states:
+
+      It is also possible to statically configure an interim value on
+      the NAS itself.  Note that a locally configured value on the NAS
+      MUST override the value found in an Access-Accept.
+
+   This requirement may be phrased too strongly.  It is conceivable that
+   a NAS implementation has a setting for a "minimum" value of Interim-
+   Accounting-Interval, based on resource constraints in the NAS, and
+
+
+
+Nelson & DeKok              Standards Track                    [Page 13]
+
+RFC 5080                 RADIUS Issues & Fixes             December 2007
+
+
+   network loading in the local environment of the NAS.  In such cases,
+   the value administratively provisioned in the NAS should not be
+   over-ridden by a smaller value from an Access-Accept message.  The
+   NAS's value could be over-ridden by a larger one, however.  The
+   intent is that the NAS sends accounting information at fixed
+   intervals that are short enough so that the potential loss of
+   billable revenue is limited, but also that the accounting updates are
+   infrequent enough so that the NAS, network, and RADIUS server are not
+   overloaded.
+
+2.3.5.  Counter Values in the RADIUS Management Information Base (MIB)
+
+   The RADIUS Authentication and Authorization Client MIB module
+   ([RFC2618] [RFC4668]) includes counters of packet statistics.  In the
+   descriptive text of the MIB module, formulas are provided for certain
+   counter objects.  Implementors have noted apparent inconsistencies in
+   the formulas that could result in negative values.
+
+   Since the original MIB module specified in [RFC2618] had been widely
+   implemented, the RADEXT WG chose not to change the object definitions
+   or to create new ones within the revised MIB module [RFC4668].
+   However, this section explains the issues and provides guidance for
+   implementors regarding the interpretation of the textual description
+   and comments for certain MIB objects.
+
+   The issues raised can be summarized as follows:
+
+   Issue (1):
+
+   -- TotalIncomingPackets = Accepts + Rejects + Challenges +
+   UnknownTypes
+   --
+   -- TotalIncomingPackets - MalformedResponses - BadAuthenticators -
+   -- UnknownTypes - PacketsDropped = Successfully received
+   --
+   -- AccessRequests + PendingRequests + ClientTimeouts =
+   -- Successfully Received
+
+   It appears that the value of "Successfully Received" could be
+   negative, since various counters are subtracted from
+   TotalIncomingPackets that are not included in the calculation of
+   TotalIncomingPackets.
+
+   It also appears that "AccessRequests + PendingRequests +
+   ClientTimeouts = Successfully Received" should read "AccessRequests +
+   PendingRequests + ClientTimeouts = Successfully Transmitted".
+
+
+
+
+
+Nelson & DeKok              Standards Track                    [Page 14]
+
+RFC 5080                 RADIUS Issues & Fixes             December 2007
+
+
+   "TotalIncomingPackets" and "Successfully Received" are temporary
+   variables, i.e., not objects within the MIB module.  The comment text
+   in the MIB modules is intended, therefore, to aid in understanding.
+   What's of consequence is the consistency of values of the objects in
+   the MIB module, and that does not appear to be impacted by the
+   inconsistencies noted above.  It does appear, however, that the
+   "Successfully Received" variable should be labeled "Successfully
+   Transmitted".
+
+   In addition, the definition of Accept, Reject or Challenge counters
+   indicates that they MUST be incremented before the message is
+   validated.  If the message is invalid, one of MalformedResponses,
+   BadAuthenticators, or PacketsDropped counters will be additionally
+   incremented.  In that case, the first two equations are consistent,
+   i.e., "Successfully Received" could not be negative.
+
+   Issue (2):
+
+   It appears that the radiusAuthClientPendingRequests counter is
+   decremented upon retransmission.  That would mean a retransmitted
+   packet is not considered as being pending, although such
+   retransmissions can still be considered as being pending requests.
+
+   The definition of this MIB object in [RFC2618] is as follows:
+
+      The number of RADIUS Access-Request packets destined for this
+      server that have not yet timed out or received a response.  This
+      variable is incremented when an Access-Request is sent and
+      decremented due to receipt of an Access-Accept, Access-Reject or
+      Access-Challenge, a timeout or retransmission.
+
+   This object purports to count the number of pending request packets.
+   It is open to interpretation whether or not retransmissions of a
+   request are to be counted as additional pending packets.  In either
+   event, it seems appropriate to treat retransmissions consistently
+   with respect to incrementing and decrementing this counter.
+
+2.4.  Multiple Filter-ID Attributes
+
+   [RFC2865] Section 5.11 states:
+
+      Zero or more Filter-Id attributes MAY be sent in an Access-Accept
+      packet.
+
+
+
+
+
+
+
+
+Nelson & DeKok              Standards Track                    [Page 15]
+
+RFC 5080                 RADIUS Issues & Fixes             December 2007
+
+
+   In practice, the behavior of a RADIUS client receiving multiple
+   Filter-ID attributes is implementation dependent.  For example, some
+   implementations treat multiple instances of the Filter-ID attribute
+   as alternative filters; the first Filter-ID attribute having a name
+   matching a locally defined filter is used, and the remaining ones are
+   discarded.  Other implementations may combine matching filters.
+
+   As a result, the interpretation of multiple Filter-ID attributes is
+   undefined within RADIUS.  The sending of multiple Filter-ID
+   attributes within an Access-Accept SHOULD be avoided within
+   heterogeneous deployments and roaming scenarios, where it is likely
+   to produce unpredictable results.
+
+2.5.  Mandatory and Optional Attributes
+
+   RADIUS attributes do not explicitly state whether they are optional
+   or mandatory.  Nevertheless, there are instances where RADIUS
+   attributes need to be treated as mandatory.
+
+   [RFC2865] Section 1.1 states:
+
+      A NAS that does not implement a given service MUST NOT implement
+      the RADIUS attributes for that service.  For example, a NAS that
+      is unable to offer Apple Remote Access Protocol (ARAP) service
+      MUST NOT implement the RADIUS attributes for ARAP.  A NAS MUST
+      treat a RADIUS access-accept authorizing an unavailable service as
+      an access-reject instead.
+
+   With respect to the Service-Type attribute, [RFC2865] Section 5.6
+   says:
+
+      This Attribute indicates the type of service the user has
+      requested, or the type of service to be provided.  It MAY be used
+      in both Access-Request and Access-Accept packets.  A NAS is not
+      required to implement all of these service types, and MUST treat
+      unknown or unsupported Service-Types as though an Access-Reject
+      had been received instead.
+
+   [RFC2865] Section 5 states:
+
+      A RADIUS server MAY ignore Attributes with an unknown Type.
+
+      A RADIUS client MAY ignore Attributes with an unknown Type.
+
+
+
+
+
+
+
+
+Nelson & DeKok              Standards Track                    [Page 16]
+
+RFC 5080                 RADIUS Issues & Fixes             December 2007
+
+
+   With respect to Vendor-Specific Attributes (VSAs), [RFC2865] Section
+   5.26 states:
+
+      Servers not equipped to interpret the vendor-specific information
+      sent by a client MUST ignore it (although it may be reported).
+      Clients which do not receive desired vendor-specific information
+      SHOULD make an attempt to operate without it, although they may do
+      so (and report they are doing so) in a degraded mode.
+
+   It is possible for either a standard attribute or a VSA to represent
+   a request for an unavailable service.  However, where the Type,
+   Vendor-ID, or Vendor-Type is unknown, a RADIUS client will not know
+   whether or not the attribute defines a service.
+
+   In general, it is best for a RADIUS client to err on the side of
+   caution.  On receiving an Access-Accept including an attribute of
+   known Type for an unimplemented service, a RADIUS client MUST treat
+   it as an Access-Reject, as directed in [RFC2865] Section 1.1.  On
+   receiving an Access-Accept including an attribute of unknown Type, a
+   RADIUS client SHOULD assume that it is a potential service
+   definition, and treat it as an Access-Reject.  Unknown VSAs SHOULD be
+   ignored by RADIUS clients.
+
+   In order to avoid introducing changes in default behavior, existing
+   implementations that do not obey this recommendation should make the
+   behavior configurable, with the legacy behavior being enabled by
+   default.  A configuration flag such as "treat unknown attributes as
+   reject" can be exposed to the system administrator.  If the flag is
+   set to true, then Access-Accepts containing unknown attributes are
+   treated as Access-Rejects.  If the flag is set to false, then unknown
+   attributes in Access-Accepts are silently ignored.
+
+   On receiving a packet including an attribute of unknown Type, RADIUS
+   authentication server implementations SHOULD ignore such attributes.
+   However, RADIUS accounting server implementations typically do not
+   need to understand attributes in order to write them to stable
+   storage or pass them to the billing engine.  Therefore, accounting
+   server implementations SHOULD be equipped to handle unknown
+   attributes.
+
+   To avoid misinterpretation of service requests encoded within VSAs,
+   RADIUS servers SHOULD NOT send VSAs containing service requests to
+   RADIUS clients that are not known to understand them.  For example, a
+   RADIUS server should not send a VSA encoding a filter without
+   knowledge that the RADIUS client supports the VSA.
+
+
+
+
+
+
+Nelson & DeKok              Standards Track                    [Page 17]
+
+RFC 5080                 RADIUS Issues & Fixes             December 2007
+
+
+2.6.  Interpretation of Access-Reject
+
+2.6.1.  Improper Use of Access-Reject
+
+   The intent of an Access-Reject is to deny access to the requested
+   service.  [RFC2865] Section 2 states:
+
+      If any condition is not met, the RADIUS server sends an "Access-
+      Reject" response indicating that this user request is invalid.  If
+      desired, the server MAY include a text message in the Access-
+      Reject which MAY be displayed by the client to the user.  No other
+      Attributes (except Proxy-State) are permitted in an Access-Reject.
+
+   This text makes it clear that RADIUS does not allow the provisioning
+   of services within an Access-Reject.  If the desire is to allow
+   limited access, then an Access-Accept can be sent with attributes
+   provisioning limited access.  Attributes within an Access-Reject are
+   restricted to those necessary to route the message (e.g., Proxy-
+   State), attributes providing the user with an indication that access
+   has been denied (e.g., an EAP-Message attribute containing an EAP-
+   Failure), or attributes conveying an error message (e.g., a Reply-
+   Message or Error-Cause attribute).
+
+   Unfortunately, there are examples where this requirement has been
+   misunderstood.  [RFC2869] Section 2.2 states:
+
+      If that authentication fails, the RADIUS server should return an
+      Access-Reject packet to the NAS, with optional Password-Retry and
+      Reply-Messages attributes.  The presence of Password-Retry
+      indicates the ARAP NAS MAY choose to initiate another challenge-
+      response cycle...
+
+   This paragraph is problematic from two perspectives.  Firstly, a
+   Password-Retry attribute is being returned in an Access-Reject; this
+   attribute does not fit into the categories established in [RFC2865].
+   Secondly, an Access-Reject packet is being sent in the context of a
+   continuing authentication conversation; [RFC2865] requires use of an
+   Access-Challenge for this.  [RFC2869] uses the phrase "challenge-
+   response" to describe this use of Access-Reject, indicating that the
+   semantics of Access-Challenge are being used.
+
+   [RFC2865] Section 4.4 addresses the semantics of Access-Challenge
+   being equivalent to Access-Reject in some cases:
+
+      If the NAS does not support challenge/response, it MUST treat an
+      Access-Challenge as though it had received an Access-Reject
+      instead.
+
+
+
+
+Nelson & DeKok              Standards Track                    [Page 18]
+
+RFC 5080                 RADIUS Issues & Fixes             December 2007
+
+
+   While it is difficult to correct existing deployments of [RFC2869],
+   we make the following recommendations:
+
+      [1]   New RADIUS specifications and implementations MUST NOT use
+            Access-Reject where the semantics of Access-Challenge are
+            intended.
+
+      [2]   Access-Reject MUST mean denial of access to the requested
+            service.  In response to an Access-Reject, the NAS MUST NOT
+            send any additional Access-Request packets for that user
+            session.
+
+      [3]   New deployments of ARAP [RFC2869] SHOULD use Access-
+            Challenge instead of Access-Reject packets in the
+            conversations described in [RFC2869] Section 2.2.
+
+   We also note that the table of attributes in [RFC2869] Section 5.19
+   has an error for the Password-Retry attribute.  It says:
+
+   Request  Accept  Reject  Challenge   #    Attribute
+   0        0       0-1     0           75   Password-Retry
+
+   However, the text in [RFC2869], Section 2.3.2 says that Password-
+   Retry can be included within an Access-Challenge packet for EAP
+   authentication sessions.  We recommend a correction to the table that
+   removes the "0-1" from the Reject column, and moves it to the
+   Challenge column.  We also add a "Note 2" to follow the existing
+   "Note 1" in the document to clarify the use of this attribute.
+
+   Request  Accept  Reject  Challenge   #    Attribute
+   0        0       0       0-1         75   Password-Retry [Note 2]
+
+   [Note 2] As per RFC 3579, the use of the Password-Retry in EAP
+   authentications is deprecated.  The Password-Retry attribute can be
+   used only for ARAP authentication.
+
+2.6.2.  Service Request Denial
+
+   RADIUS has been deployed for purposes outside network access
+   authentication, authorization, and accounting.  For example, RADIUS
+   has been deployed as a "back-end" for authenticating Voice Over IP
+   (VOIP) connections, Hypertext Transfer Protocol (HTTP) sessions
+   (e.g., Apache), File Transfer Protocol (FTP) sessions (e.g.,
+   proftpd), and machine logins for multiple operating systems (e.g.,
+   bsdi, pam, and gina).  In those contexts, an Access-Reject sent to
+   the RADIUS client MUST be interpreted as a rejection of the request
+   for service, and the RADIUS client MUST NOT offer that service to the
+   user.
+
+
+
+Nelson & DeKok              Standards Track                    [Page 19]
+
+RFC 5080                 RADIUS Issues & Fixes             December 2007
+
+
+   For example, when an authentication failure occurs in the context of
+   an FTP session, the normal semantics for rejecting FTP services
+   apply.  The rejection does not necessarily cause the FTP server to
+   terminate the underlying TCP connection, but the FTP server MUST NOT
+   offer any services protected by user authentication.
+
+   Users may request multiple services from the NAS.  Where those
+   services are independent, the deployment MUST treat the RADIUS
+   sessions as being independent.
+
+   For example, a NAS may offer multi-link services where a user may
+   have multiple simultaneous network connections.  In that case, an
+   Access-Reject for a later multi-link connection request does not
+   necessarily mean that earlier multi-link connections are torn down.
+   Similarly, if a NAS offers both dialup and VOIP services, the
+   rejection of a VOIP attempt does not mean that the dialup session is
+   torn down.
+
+2.7.  Addressing
+
+2.7.1.  Link-Local Addresses
+
+   Since Link-Local addresses are unique only on the local link, if the
+   NAS and RADIUS server are not on the same link, then an IPv6 Link-
+   Local address [RFC4862] or an IPv4 Link-Local Address [RFC3927]
+   cannot be used to uniquely identify the NAS.  A NAS SHOULD NOT
+   utilize a link-scope address within a NAS-IPv6-Address or NAS-IP-
+   Address attribute.  A RADIUS server receiving a NAS-IPv6-Address or
+   NAS-IP-Address attribute containing a Link-Local address SHOULD NOT
+   count such an attribute toward satisfying the requirements of
+   [RFC3162] Section 2.1:
+
+      NAS-IPv6-Address and/or NAS-IP-Address MAY be present in an
+      Access-Request packet; however, if neither attribute is present
+      then NAS-Identifier MUST be present.
+
+2.7.2.  Multiple Addresses
+
+   There are situations in which a RADIUS client or server may have
+   multiple addresses.  For example, a dual stack host can have both
+   IPv4 and IPv6 addresses; a host that is a member of multiple VLANs
+   could have IPv4 and/or IPv6 addresses on each VLAN; a host can have
+   multiple IPv4 or IPv6 addresses on a single interface.  However,
+   [RFC2865] Section 5.44 only permits zero or one NAS-IP-Address
+   attributes within an Access-Request, and [RFC3162] Section 3 only
+   permits zero or one NAS-IPv6-Address attributes within an Access-
+   Request.  When a NAS has more than one global address and no ability
+   to determine which is used for identification in a particular
+
+
+
+Nelson & DeKok              Standards Track                    [Page 20]
+
+RFC 5080                 RADIUS Issues & Fixes             December 2007
+
+
+   request, it is RECOMMENDED that the NAS include the NAS-Identifier
+   attribute in an Access-Request in order to identify itself to the
+   RADIUS server.
+
+   [RFC2865] Section 3 states:
+
+      A RADIUS server MUST use the source IP address of the RADIUS UDP
+      packet to decide which shared secret to use, so that RADIUS
+      requests can be proxied.
+
+   Therefore, if a RADIUS client sends packets from more than one source
+   address, a shared secret will need to be configured on both the
+   client and server for each source address.
+
+2.8.  Idle-Timeout
+
+   With respect to the Idle-Timeout attribute, [RFC2865] Section 5.28
+   states:
+
+      This Attribute sets the maximum number of consecutive seconds of
+      idle connection allowed to the user before termination of the
+      session or prompt.  This Attribute is available to be sent by the
+      server to the client in an Access-Accept or Access-Challenge.
+
+   [RFC3580] Section 3.12 states:
+
+      The Idle-Timeout attribute is described in [RFC2865].  For IEEE
+      802 media other than 802.11 the media are always on.  As a result
+      the Idle-Timeout attribute is typically only used with wireless
+      media such as IEEE 802.11.  It is possible for a wireless device
+      to wander out of range of all Access Points.  In this case, the
+      Idle-Timeout attribute indicates the maximum time that a wireless
+      device may remain idle.
+
+   In the above paragraphs "idle" may not necessarily mean "no traffic";
+   the NAS may support filters defining what traffic is included in the
+   idle time determination.  As a result, an "idle connection" is
+   defined by local policy in the absence of other attributes.
+
+2.9.  Unknown Identity
+
+   [RFC3748] Section 5.1 states:
+
+      If the Identity is unknown, the Identity Response field should be
+      zero bytes in length.
+
+
+
+
+
+
+Nelson & DeKok              Standards Track                    [Page 21]
+
+RFC 5080                 RADIUS Issues & Fixes             December 2007
+
+
+   However, [RFC2865] Section 5.1 describes the User-Name attribute as
+   follows:
+
+      The String field is one or more octets.
+
+   How should the RADIUS client behave if it receives an EAP-
+   Response/Identity that is zero octets in length?
+
+   [RFC2865] Section 5.1 states:
+
+      This Attribute indicates the name of the user to be authenticated.
+      It MUST be sent in Access-Request packets if available.
+
+   This suggests that the User-Name attribute may be omitted if it is
+   unavailable.
+
+   However, [RFC3579] Section 2.1 states:
+
+      In order to permit non-EAP aware RADIUS proxies to forward the
+      Access-Request packet, if the NAS initially sends an EAP-
+      Request/Identity message to the peer, the NAS MUST copy the
+      contents of the Type-Data field of the EAP-Response/Identity
+      received from the peer into the User-Name attribute and MUST
+      include the Type-Data field of the EAP-Response/Identity in the
+      User-Name attribute in every subsequent Access-Request.
+
+   This suggests that the User-Name attribute should contain the
+   contents of the Type-Data field of the EAP-Response/Identity, even if
+   it is zero octets in length.
+
+   Note that [RFC4282] does not permit a Network Access Identifier (NAI)
+   of zero octets, so that an EAP-Response/Identity with a Type-Data
+   field of zero octets MUST NOT be construed as a request for privacy
+   (e.g., anonymous NAI).
+
+   When a NAS receives an EAP-Response/Identity with a Type-Data field
+   that is zero octets in length, it is RECOMMENDED that it either omit
+   the User-Name attribute in the Access-Request or include the
+   Calling-Station-Id in the User-Name attribute, along with a Calling-
+   Station-Id attribute.
+
+2.10.  Responses After Retransmissions
+
+   Some implementations do not correctly handle the receipt of RADIUS
+   responses after retransmissions. [RFC2865] Section 2.5 states:
+
+
+
+
+
+
+Nelson & DeKok              Standards Track                    [Page 22]
+
+RFC 5080                 RADIUS Issues & Fixes             December 2007
+
+
+      If the NAS is retransmitting a RADIUS request to the same server
+      as before, and the attributes haven't changed, you MUST use the
+      same Request Authenticator, ID, and source port.  If any
+      attributes have changed, you MUST use a new Request Authenticator
+      and ID.
+
+   Note that changing the Request ID for a retransmission may have
+   undesirable side effects.  Since RADIUS does not have a clear
+   definition of a "session", it is perfectly valid for a RADIUS server
+   to treat a retransmission as a new session request, and to reject it
+   due to, for example, the enforcement of restrictions on multiple
+   simultaneous logins.
+
+   In that situation, the NAS may receive a belated Access-Accept for
+   the first request, and an Access-Reject for the retransmitted
+   request, both of which apply to the same "session".
+
+   We suggest that the contents of Access-Request packets SHOULD NOT be
+   changed during retransmissions.  If they must be changed due to the
+   inclusion of an Event-Timestamp attribute, for example, then
+   responses to earlier transmissions MUST be silently discarded.  Any
+   response to the current request MUST be treated as the definitive
+   response, even if as noted above, it disagrees with earlier
+   responses.
+
+   This problem can be made worse by implementations that use a fixed
+   retransmission timeout (30 seconds is common).  We reiterate the
+   suggestions in Section 2.1 about using congestive backoff.  In that
+   case, responses to earlier transmissions MAY be used as data points
+   for congestive backoff, even if their contents are discarded.
+
+2.11.  Framed-IPv6-Prefix
+
+   [RFC3162] Section 2.3 says:
+
+      This Attribute indicates an IPv6 prefix (and corresponding route)
+      to be configured for the user.  It MAY be used in Access-Accept
+      packets, and can appear multiple times.  It MAY be used in an
+      Access-Request packet as a hint by the NAS to the server that it
+      would prefer these prefix(es), but the server is not required to
+      honor the hint.  Since it is assumed that the NAS will plumb a
+      route corresponding to the prefix, it is not necessary for the
+      server to also send a Framed-IPv6-Route attribute for the same
+      prefix.
+
+   An Internet Service Provider (ISP) may desire to support Prefix
+   Delegation [RFC4818] at the same time that it would like to assign a
+   prefix for the link between the NAS and the user.  The intent of the
+
+
+
+Nelson & DeKok              Standards Track                    [Page 23]
+
+RFC 5080                 RADIUS Issues & Fixes             December 2007
+
+
+   paragraph was to enable the NAS to advertise the prefix (such as via
+   a Router Advertisement).  If the Framed-Routing attribute is used, it
+   is also possible that the prefix would be advertised in a routing
+   protocol such as Routing Information Protocol Next Generation
+   (RIPNG).  RFC 2865 Section 5.10 describes the purpose of Framed-
+   Routing:
+
+      This Attribute indicates the routing method for the user, when the
+      user is a router to a network.  It is only used in Access-Accept
+      packets.
+
+   The description of the Prefix-Length field in RFC 3162 indicates
+   excessively wide latitude:
+
+      The length of the prefix, in bits.  At least 0 and no larger than
+      128.
+
+   This length appears too broad, because it is not clear what a NAS
+   should do with a prefix of greater granularity than /64.  For
+   example, the Framed-IPv6-Prefix may contain a /128.  This does not
+   imply that the NAS should assign an IPv6 address to the end user,
+   because RFC 3162 already defines a Framed-IPv6-Identifier attribute
+   to handle the Identifier portion.
+
+   It appears that the Framed-IPv6-Prefix is used for the link between
+   the NAS and Customer Premises Equipment (CPE) only if a /64 prefix is
+   assigned.  When a /64 or larger prefix is sent, the intent is for the
+   NAS to send a routing advertisement containing the information
+   present in the Framed-IPv6-Prefix attribute.
+
+   The CPE may also require a delegated prefix for its own use, if it is
+   decrementing the Hop Limit field of IP headers.  In that case, it
+   should be delegated a prefix by the NAS via the Delegated-IPv6-Prefix
+   attribute [RFC4818].  If the CPE is not decrementing Hop Limit, it
+   does not require a delegated prefix.
+
+3.  Security Considerations
+
+   The contents of the State attribute are available to both the RADIUS
+   client and observers of the RADIUS protocol.  RADIUS server
+   implementations should ensure that the State attribute does not
+   disclose sensitive information to a RADIUS client or third parties
+   observing the RADIUS protocol.
+
+   The cache mechanism described in Section 2.2.2 is vulnerable to
+   attacks when Access-Request packets do not contain a Message-
+   Authenticator attribute.  If the server accepts requests without a
+   Message-Authenticator, then RADIUS packets can be trivially forged by
+
+
+
+Nelson & DeKok              Standards Track                    [Page 24]
+
+RFC 5080                 RADIUS Issues & Fixes             December 2007
+
+
+   an attacker.  Cache entries can then be forcibly expired, negating
+   the utility of the cache.  This attack can be mitigated by following
+   the suggestions in [RFC3579] Section 4, or by requiring the presence
+   of Message-Authenticator, as described in Sections 2.1.1 and 2.2.2.
+
+   Since this document describes the use of RADIUS for purposes of
+   authentication, authorization, and accounting in a wide variety of
+   networks, applications using these specifications are vulnerable to
+   all of the threats that are present in other RADIUS applications.
+   For a discussion of these threats, see [RFC2865], [RFC2607],
+   [RFC3162], [RFC3579], and [RFC3580].
+
+4.  References
+
+4.1.  Normative References
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2865]   Rigney, C., Willens, S., Rubens, A., and W. Simpson,
+               "Remote Authentication Dial In User Service (RADIUS)",
+               RFC 2865, June 2000.
+
+   [RFC4818]   Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
+               Attribute", RFC 4818, April 2007.
+
+4.2.  Informative References
+
+   [RFC2607]   Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
+               Implementation in Roaming", RFC 2607, June 1999.
+
+   [RFC2618]   Aboba, B. and G. Zorn, "RADIUS Authentication Client
+               MIB", RFC 2618, June 1999.
+
+   [RFC2866]   Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
+
+   [RFC2869]   Rigney, C., Willats, W., and P. Calhoun, "RADIUS
+               Extensions", RFC 2869, June 2000.
+
+   [RFC3162]   Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
+               RFC 3162, August 2001.
+
+   [RFC3315]   Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
+               C., and M. Carney, "Dynamic Host Configuration Protocol
+               for IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+
+
+
+
+
+Nelson & DeKok              Standards Track                    [Page 25]
+
+RFC 5080                 RADIUS Issues & Fixes             December 2007
+
+
+   [RFC3576]   Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
+               Aboba, "Dynamic Authorization Extensions to Remote
+               Authentication Dial In User Service (RADIUS)", RFC 3576,
+               July 2003.
+
+   [RFC3579]   Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
+               Dial In User Service) Support For Extensible
+               Authentication Protocol (EAP)", RFC 3579, September 2003.
+
+   [RFC3580]   Congdon, P., Aboba, B., Smith, A., Zorn, G., and J.
+               Roese, "IEEE 802.1X Remote Authentication Dial In User
+               Service (RADIUS) Usage Guidelines", RFC 3580, September
+               2003.
+
+   [RFC3748]   Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
+               Levkowetz, Ed., "Extensible Authentication Protocol
+               (EAP)", RFC 3748, June 2004.
+
+   [RFC3927]   Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
+               Configuration of IPv4 Link-Local Addresses", RFC 3927,
+               May 2005.
+
+   [RFC4282]   Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
+               Network Access Identifier", RFC 4282, December 2005.
+
+   [RFC4668]   Nelson, D., "RADIUS Authentication Client MIB for IPv6",
+               RFC 4668, August 2006.
+
+   [RFC4669]   Nelson, D., "RADIUS Authentication Server MIB for IPv6",
+               RFC 4669, August 2006.
+
+   [RFC4862]   Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
+               Address Autoconfiguration", RFC 4862, September 2007.
+
+   [PANA]      Forsberg, D., Ohba, Y.,Ed., Patil, B., Tschofenig, H.,
+               and A. Yegin, "Protocol for Carrying Authentication for
+               Network Access (PANA)", Work in Progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nelson & DeKok              Standards Track                    [Page 26]
+
+RFC 5080                 RADIUS Issues & Fixes             December 2007
+
+
+Acknowledgments
+
+   The authors would like to acknowledge Glen Zorn and Bernard Aboba for
+   contributions to this document.
+
+   The alternate algorithm to [RFC3579] Section 2.6.1 that is described
+   in Section 2.1.2 of this document was designed by Raghu Dendukuri.
+
+   The text discussing retransmissions in Section 2.2.1 is taken with
+   minor edits from Section 9 of" Protocol for Carrying Authentication
+   for Network Access (PANA)" [PANA].
+
+   Alan DeKok wishes to acknowledge the support of Quiconnect Inc.,
+   where he was employed during much of the work on this document.
+
+   David Nelson wishes to acknowledge the support of Enterasys Networks,
+   where he was employed during much of the work on this document.
+
+Authors' Addresses
+
+   David B. Nelson
+   Elbrys Networks, Inc.
+   75 Rochester Ave., Unit 3
+   Portsmouth, N.H. 03801 USA
+
+   Phone: +1.603.570.2636
+   EMail: dnelson@elbrysnetworks.com
+
+
+   Alan DeKok
+   The FreeRADIUS Server Project
+   http://freeradius.org/
+
+   EMail: aland@freeradius.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nelson & DeKok              Standards Track                    [Page 27]
+
+RFC 5080                 RADIUS Issues & Fixes             December 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Nelson & DeKok              Standards Track                    [Page 28]
+