diff options
Diffstat (limited to 'doc/rfc/rfc5080.txt')
| -rw-r--r-- | doc/rfc/rfc5080.txt | 1571 |
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] + |