Network Working Group David Nelson INTERNET-DRAFT Enterasys Networks Category: Informational Alan DeKok Infoblox, Inc. 23 October 2005 Bernard Aboba Microsoft Corporation Common RADIUS Implementation Issues and Suggested Fixes By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 10, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes common issues seen in RADIUS implementations and suggests some fixes. Where applicable, violations of recommendations from RADIUS RFCs are mentioned. Nelson, et al. Informational [Page 1] INTERNET-DRAFT RADIUS Issues & Fixes 23 October 2005 Table of Contents 1. Introduction .......................................... 3 1.1 Terminology ..................................... 3 1.2 Requirements Language ........................... 3 2. Issues ................................................ 4 2.1 Session Definition .............................. 4 2.2 Overload Conditions ............................. 5 2.3 Accounting Issues ............................... 6 2.4 Multiple Filter-ID Attributes ................... 7 2.5 Mandatory and Optional Attributes ............... 8 2.6 Interpretation of Access-Reject ................. 9 2.7 Addressing ...................................... 12 2.8 State Attribute ................................. 13 2.9 Idle Timeout .................................... 14 2.10 RFC 3576 Issues ................................. 14 3. IANA Considerations ................................... 16 4. Security Considerations ............................... 16 5. References ............................................ 17 5.1 Informative References ................................ 17 ACKNOWLEDGMENTS .............................................. 18 AUTHORS' ADDRESSES ........................................... 18 Intellectual Property Statement .............................. 18 Disclaimer of Validity ....................................... 19 Copyright Statement .......................................... 19 Nelson, et al. Informational [Page 2] INTERNET-DRAFT RADIUS Issues & Fixes 23 October 2005 1. Introduction The last few years have seen an increase in the deployment of RADIUS clients and servers. Various implementations and versions of these implementations interact with each other, creating a variety of implementation problems. This document is an attempt to document known issues with RADIUS implementations so that the community will know what problems to watch out for and how to address the problems. 1.1. Terminology This document uses the following terms: displayable message This is interpreted to be a human readable string of characters, and MUST NOT affect operation of the protocol. The message encoding MUST follow the UTF-8 transformation format [RFC2279]. Network Access Server (NAS) The device providing access to the network. Also known as the Authenticator (IEEE 802.1X or EAP terminology) or RADIUS client. service The NAS provides a service to the user, such as network access via 802.11 or 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 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 Nelson, et al. Informational [Page 3] INTERNET-DRAFT RADIUS Issues & Fixes 23 October 2005 [RFC2119]. 2. Issues 2.1. Session Definition 2.1.1. Session State 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). The following rules specify how the State attribute is used with RADIUS EAP [RFC3579]: o RADIUS servers SHOULD always include the State attribute in an Access-Challenge, Access-Accept, or Access-Reject message. o Normally, a NAS copies the received State attribute to an Access-Request sent as a response to an Access-Challenge [RFC2865], Section 5.24. Note that an Access-Request sent as a result of a new or restarted authentication run MUST NOT include the State attribute, even if the State attribute has previously been received in an Access-Challenge for the same user and port. 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 translate 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. Nelson, et al. Informational [Page 4] INTERNET-DRAFT RADIUS Issues & Fixes 23 October 2005 The FreeRADIUS implementation does not track EAP identifiers by NAS- IP-Address or other attributes sent by the NAS. Instead, it uses the EAP identifier, source IP address, and the State attribute. Since the State attribute is under the control of the RADIUS server, this means that the uniqueness of each session is controlled by the server, not the NAS. The algorithm used in FreeRADIUS is as follows: if (EAP start, or EAP identity) { allocate unique State Attribute insert into "active" queue, with key (EAP identifier, State, source IP) } else { look up active session in queue, with above key } This algorithm appears to work well in variety of situations, including situations where home servers receive messages via intermediate RADIUS proxies. 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 TCP retransmission (based on average round trip time) is not required, nor is the acknowledgement 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 large scale, these implementations are susceptible to congestive collapse. For example, as the result of a power failure, a network with 3000 NAS devices with a fixed retransmission timer of one second continuously generated 3000 RADIUS Access-Requests per second. This is sufficient to overwhelm most RADIUS servers. Suggested solutions include: Nelson, et al. Informational [Page 5] INTERNET-DRAFT RADIUS Issues & Fixes 23 October 2005 [b] Jitter. To avoid synchronization, RADIUS clients SHOULD incorporate jitter within its retransmission algorithm. [a] Congestive backoff. While it is not necessary for RADIUS client implementations to implement complex retransmission algorithms, implementations SHOULD support congestive backoff within the limits suggested by [RFC2865] Section 2.4. For example, an implementation SHOULD double the initial retransmission timer until a maximum retransmission time is reached, after which the client will failover to another RADIUS server. For example, if the initial retransmission timer is one second, a maximum retransmission timer of 16 seconds might be used. 2.2.2. 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. 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. This 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. 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. Nelson, et al. Informational [Page 6] INTERNET-DRAFT RADIUS Issues & Fixes 23 October 2005 2.3.2. Acct-Session-ID and Acct-Multi-Session-ID [RFC2866] Section 5.5 describes Acct-Session-ID as Text within the description, but also states that "The String field SHOULD be a string of UTF-8 encoded 10646 characters." Since Acct-Multi-Session-ID is consistently described as a String, it appears that this is a typographical error, and that Acct-Session-ID is of type String. The implication is that a robust implementation SHOULD support the String fields within Acct-Session-ID and Acct-Multi-Session-ID as undistinguished octets. 2.3.3. Request Authenticator [RFC2866] Section 4.1 states: Request Authenticator 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 implementations of RADIUS servers MUST silently discard invalid packets. 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. However in practice the behavior of a RADIUS client receiving multiple Filter-ID attributes is implementation dependent. For Nelson, et al. Informational [Page 7] INTERNET-DRAFT RADIUS Issues & Fixes 23 October 2005 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 exhibit different behavior, such as combining 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 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. However, [RFC2865] Section 5 states: A RADIUS server MAY ignore Attributes with an unknown Type. A RADIUS client MAY ignore Attributes with an unknown Type. 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 Nelson, et al. Informational [Page 8] INTERNET-DRAFT RADIUS Issues & Fixes 23 October 2005 so (and report they are doing so) in a degraded mode. How are we to interpret the former two excerpts with respect to the latter two? The excerpts overlap in their recommendations because it is possible for an attribute with an unknown Type to represent a request for an unavailable service. It is also possible for a VSA to represent a request for an unavailable service. However, where the Type or Vendor-ID is unknown, a RADIUS client cannot know whether the attribute defines a service or not. Our interpretation is that the text from Sections 1.1 and 5.6 refer to the behavior of a RADIUS client with respect to known attributes requesting an unavailable service. A RADIUS client is responsible for treating as an Access-Reject any service-defining attribute documented in a published RFC prior to implementation. For example, a RADIUS client implemented after the publication of [RFC2868] which does not implement Tunnel Attributes is required to treat received Tunnel Attributes as an Access-Reject. However, a RADIUS client implementation created prior to the publication of [RFC2868] may ignore Tunnel attributes, since it has no way of knowing that these attributes defined a service. Overall however, it is best for RADIUS clients to err on the side of caution. RADIUS clients SHOULD assume that an Attribute of unknown Type is a potential service definition, and treat it as an Access- Reject. Unknown VSAs SHOULD be ignored by RADIUS clients. The recommended behavior of a RADIUS server is different since the [RFC2865] text relating to unavailable services applies only to RADIUS clients. RADIUS authentication server implementations SHOULD ignore Attributes of unknown Type. Since 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, accounting server implementations SHOULD NOT ignore 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. 2.6. Interpretation of Access-Reject Nelson, et al. Informational [Page 9] INTERNET-DRAFT RADIUS Issues & Fixes 23 October 2005 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 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. While it is difficult to correct existing deployments of [RFC2869], we make the following recommendations: Nelson, et al. Informational [Page 10] INTERNET-DRAFT RADIUS Issues & Fixes 23 October 2005 [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 [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, based on [RFC3579]: 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 VOIP connections [digest], HTTP sessions [apache], FTP sessions [proftpd], and machine logins for multiple operating systems [bsdi, pam, 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 client MUST NOT offer that service to the user. 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 Nelson, et al. Informational [Page 11] INTERNET-DRAFT RADIUS Issues & Fixes 23 October 2005 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. Where a NAS offers multiple services, confusion may result with respect to interpretation of a Disconnect-Request [RFC3576]. In order to prevent confusion a RADIUS Server SHOULD identify the session that it desires to terminate as specifically as possible. For example, an Account-Session-ID attribute SHOULD be included in Disconnect-Request and CoA-Request packets, rather than just the User-Name attribute. 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 [RFC2462] or an IPv4 Link-Local Address [RFC3927] cannot be used to uniquely identify the NAS. 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-IPv4-Address attributes within an Access-Request and [RFC3162] Section 3 only permits zero or one NAS-IPv6-Address attributes within an Access- Request. Where a NAS has more than one global address, it is RECOMMENDED that the NAS include the NAS-Identifier attribute in an Access-Request in order to identify itself to the RADIUS server. Nelson, et al. Informational [Page 12] INTERNET-DRAFT RADIUS Issues & Fixes 23 October 2005 [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. State Attribute [RFC2865] Section 5.44 states: An Access-Request MUST contain either a User-Password or a CHAP- Password or State. An Access-Request MUST NOT contain both a User-Password and a CHAP-Password. If future extensions allow other kinds of authentication information to be conveyed, the attribute for that can be used in an Access-Request instead of User-Password or CHAP-Password. A State attribute is therefore REQUIRED in Access-Request packets lacking an authentication attribute. Such a state attribute can be obtained via several mechanisms. For example, [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. 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. [RFC3576] defines the Service-Type value of "Authorize-Only". This Service-Type can be included within Disconnect or CoA-Request packets. A NAS receiving such a Request will send an Access-Request packet containing a Service-Type attribute with value "Authorize- Only" and no authentication attributes. In order to satisfy the requirements of [RFC2865], an Access-Request with Service- Type="Authorize-Only" MUST contain a State attribute. In order to provide a State attribute to the NAS, Disconnect and CoA- Request packets containing a Service-Type of value "Authorize-Only" Nelson, et al. Informational [Page 13] INTERNET-DRAFT RADIUS Issues & Fixes 23 October 2005 MUST also contain a State attribute, and the NAS MUST include the State attribute unchanged in the Access-Request. A NAS receiving a Disconnect or CoA-Request containing a Service-Type value of "Authorize-Only" but lacking a State attribute MUST send a Disconnect or CoA-NAK and SHOULD include an Error-Cause attribute with value 402 (Missing Attribute). 2.9. 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.10. RFC 3576 Issues 2.10.1. Calculation of Message-Authenticator [RFC2869] Section 5.19 indicates that the Message-Authenticator attribute may be included in Access-Request, Accept, Reject and Challenge packets, and Section 5.14 describes how the Message- Authenticator attribute is calculated for these packets: When present in an Access-Request packet, Message-Authenticator is an HMAC-MD5 [9] checksum of the entire Access-Request packet, including Type, ID, Length and authenticator, using the shared secret as the key, as follows. Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes) Nelson, et al. Informational [Page 14] INTERNET-DRAFT RADIUS Issues & Fixes 23 October 2005 When the checksum is calculated the signature string should be considered to be sixteen octets of zero. For Access-Challenge, Access-Accept, and Access-Reject packets, the Message-Authenticator is calculated as follows, using the Request-Authenticator from the Access-Request this packet is in reply to: Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes) When the checksum is calculated the signature string should be considered to be sixteen octets of zero. The shared secret is used as the key for the HMAC-MD5 hash. The is calculated and inserted in the packet before the Response Authenticator is calculated. [RFC3576] Section 3.2 indicates that a Message-Authenticator attribute may be included within a Disconnect or CoA-Request, ACK or NAK. However [RFC2869] does not describe how a Message-Authenticator attribute is calculated for these RADIUS packets, or for Accounting- Request or Response packets. The algorithm described in [RFC2869] Section 5.14 cannot be applied because in a Disconnect, CoA or Accounting-Request packet the Request Authenticator is not a nonce, but rather represents a keyed MD5 hash over the packet. This creates a circular dependency -- the Request Authenticator depends on Message-Authenticator and Message- Authenticator depends on the Response Authenticator. As a result, in Accounting, CoA or Disconnect-Request or Response packets the Message-Authenticator attribute is calculated as follows: Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Authenticator, Attributes) When the HMAC-MD5 hash is calculated the Authenticator field and Message-Authenticator attribute should be considered to be sixteen octets of zero. The Message-Authenticator is calculated and inserted in the packet before the Authenticator is calculated. 2.10.2. Proxy-State [RFC3576] Section 2.3 states: When using a forwarding proxy, the proxy must be able to alter the packet as it passes through in each direction. When the proxy forwards a Disconnect or CoA-Request, it MAY add a Proxy-State Nelson, et al. Informational [Page 15] INTERNET-DRAFT RADIUS Issues & Fixes 23 October 2005 Attribute, and when the proxy forwards a response, it MUST remove its Proxy-State Attribute if it added one. Proxy-State is always added or removed after any other Proxy-States, but no other assumptions regarding its location within the list of Attributes can be made. Since Disconnect and CoA responses are authenticated on the entire packet contents, the stripping of the Proxy-State Attribute invalidates the integrity check - so the proxy needs to recompute it. A forwarding proxy MUST NOT modify existing Proxy- State, State, or Class Attributes present in the packet. While this text describes how a proxy handles Proxy-State attributes within Disconnect or CoA messages, it does not describe how a NAS should process a Proxy-State attribute included within a Disconnect or CoA-Request. A NAS receiving a Proxy-State attribute in a Disconnect or CoA-Request MUST return it unmodified in the Disconnect-ACK/NAK or CoA-ACK/NAK. 2.10.3. "Authorization-Only" Service-type [RFC3576] introduces the Service-Type value of "Authorization-Only" in order to enable improved compatibility between RADIUS and Diameter. A Service-Type attribute with value "Authorization-Only" MAY be included in a Disconnect or CoA Request/ACK/NAK or within an Access-Request, Access-Accept or Accounting-Request packet. However, as described in [RFC2865] Section 5.44, a Service-Type attribute MUST NOT be included in an Access-Challenge or Access-Reject packet. [RFC3576] Section 3.2 Note 6 is in error with respect to the utility of a Disconnect-Request with a Service-Type of "Authorization-Only": This enables a usage model akin to that supported in Diameter, thus easing translation between the two protocols. In fact, Diameter session termination is analogous to a Disconnect- Request without a Service-Type of "Authorization-Only" so that use of this Service-Type value provides no translation benefits and in fact makes translation between RADIUS and Diameter more difficult. 3. IANA Considerations This specification does not create any new registries, nor does it require assignment of any protocol parameters. 4. Security Considerations Since this document describes the use of RADIUS for purposes of authentication, authorization, and accounting in WLANs, it is vulnerable to all of the threats that are present in other RADIUS Nelson, et al. Informational [Page 16] INTERNET-DRAFT RADIUS Issues & Fixes 23 October 2005 applications. For a discussion of these threats, see [RFC2607], [RFC2865], [RFC3162], [RFC3576], [RFC3579], and [RFC3580]. 5. References 5.1. Informative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March, 1997. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999. [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2867] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000. [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000. [RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000. [RFC2882] Mitton, D., "Network Access Servers Requirements: Extended RADIUS Practices", RFC 2882, July 2000. [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001. [RFC3575] Aboba, B., "IANA Considerations for RADIUS", RFC 3575, July 2003. [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 Support for Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. Nelson, et al. Informational [Page 17] INTERNET-DRAFT RADIUS Issues & Fixes 23 October 2005 [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, "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. Acknowledgments The authors would like to acknowledge Glen Zorn for contributions to this document. Authors' Addresses David B. Nelson Enterasys Networks 50 Minuteman Road Andover, MA 01810 EMail: dnelson@enterasys.com Alan DeKok Infoblox, Inc. 475 Potrero Ave Sunnyvale, CA 94087 Email: adekok@infoblox.com Phone: +1 408 716 4386 Fax: +1 408 716 4400 Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: bernarda@microsoft.com Phone: +1 425 706 6605 Fax: +1 425 936 7329 Intellectual Property Statement 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 Nelson, et al. Informational [Page 18] INTERNET-DRAFT RADIUS Issues & Fixes 23 October 2005 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Open issues Open issues relating to this specification are tracked on the following web site: http://www.drizzle.com/~aboba/RADEXT/ Nelson, et al. Informational [Page 19]