Network Working Group B. Aboba INTERNET-DRAFT Microsoft Category: Informational P. Calhoun <draft-aboba-radius-rfc2869bis-15.txt> Airespace 13 April 2003 Updates: RFC 2869 RADIUS Support For Extensible Authentication Protocol (EAP) This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document defines RADIUS support for the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication mechanisms. While EAP was originally developed for use with PPP, it is also now used with IEEE 802. This document updates RFC 2869. Aboba & Calhoun Informational [Page 1]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 Table of Contents 1. Introduction .......................................... 3 1.1 Specification of Requirements ................... 3 1.2 Terminology ..................................... 4 2. RADIUS support for EAP ................................ 5 2.1 Protocol overview ............................... 5 2.2 Invalid packets ................................. 9 2.3 Retransmission .................................. 10 2.4 Fragmentation ................................... 10 2.5 Alternative uses ................................ 10 2.6 Usage guidelines ................................ 11 3. Attributes ............................................ 14 3.1 EAP-Message ..................................... 14 3.2 Message-Authenticator ........................... 16 3.3 Table of attributes ............................. 17 4. Security considerations ............................... 18 4.1 Security requirements ........................... 18 4.2 Security protocol ............................... 19 4.3 Security issues ................................ 22 5. IANA considerations .................................. 29 6. Normative references .................................. 29 7. Informative references ................................ 30 Appendix A - Examples ........................................ 32 Appendix B - Change log ...................................... 40 ACKNOWLEDGMENTS .............................................. 41 AUTHORS' ADDRESSES ........................................... 41 Intellectual property statement .............................. 41 Full Copyright Statement ..................................... 42 Aboba & Calhoun Informational [Page 2]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 1. Introduction The Remote Authentication Dial In User Service (RADIUS) is an authentication, authorization and accounting protocol used to control network access. RADIUS authentication and authorization is specified in [RFC2865], and RADIUS accounting is specified in [RFC2866]; RADIUS over IPv6 is specified in [RFC3162]. The Extensible Authentication Protocol (EAP), defined in [RFC2284], is an authentication framework which supports multiple authentication mechanisms. EAP may be used on dedicated links as well as switched circuits, and wired as well as wireless links. To date, EAP has been implemented with hosts and routers that connect via switched circuits or dial-up lines using PPP [RFC1661]. It has also been implemented with switches supporting [IEEE802]. EAP encapsulation on IEEE 802 wired media is described in [IEEE8021X]. This specification describes RADIUS attributes supporting the Extensible Authentication Protocol (EAP): EAP-Message and Message-Authenticator. These attributes now have extensive field experience. The purpose of this document is to provide clarification and resolve interoperability issues. As noted in [RFC2865], a Network Access Server (NAS) that does not implement a given service MUST NOT implement the RADIUS attributes for that service. This implies that a NAS that is unable to offer EAP service MUST NOT implement the RADIUS attributes for EAP. A NAS MUST treat a RADIUS Access-Accept requesting an unavailable service as an Access-Reject instead. All attributes are comprised of variable length Type-Length-Value 3-tuples. New attribute values can be added without disturbing existing implementations of the protocol. 1.1. Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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]. Aboba & Calhoun Informational [Page 3]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 1.2. Terminology This document frequently uses the following terms: authenticator The end of the link requiring the authentication. peer The other end of the point-to-point link (PPP), point-to-point LAN segment (IEEE 802.1X) or wireless link, which is being authenticated by the authenticator. In IEEE 802.1X, this end is known as the supplicant. Throughout this specification, the term "user" is used synonymously with peer. authentication server An authentication server is an entity that provides an authentication service to an authenticator. This service verifies from the credentials provided by the peer, the claim of identity made by the peer. Port Access Entity (PAE) The protocol entity associated with a physical or virtual port. A given PAE may support the protocol functionality associated with the authenticator, peer or both. 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. 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. service The NAS provides a service to the user, such as IEEE 802 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 Aboba & Calhoun Informational [Page 4]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 supports that, with each session generating a separate start and stop accounting record. 2. RADIUS Support for EAP The Extensible Authentication Protocol (EAP), described in [RFC2284], provides a standard mechanism for support of additional authentication methods without requiring additional functionality on the NAS. Through the use of EAP, support for a number of authentication schemes may be added, including smart cards, Kerberos [RFC1510], Public Key [RFC2716], One Time Passwords [RFC2284], and others. One of the advantages of the EAP architecture is its flexibility. EAP is used to select a specific authentication mechanism. Rather than requiring the NAS to be updated to support each new authentication method, EAP permits the use of an authentication server implementing authentication methods, with the NAS acting as a pass-through for some or all methods and peers. A NAS MAY authenticate local users while at the same time acting as a pass-through for non-local users and authentication methods it does not implement locally. A NAS implementing this specification is not required to use RADIUS to authenticate every peer. However, once the NAS begins acting as a pass-through for a particular session, it can no longer perform local authentication for that session. In order to support EAP within RADIUS, two new attributes, EAP-Message and Message-Authenticator, are introduced in this document. This section describes how these new attributes may be used for providing EAP support within RADIUS. 2.1. Protocol Overview In RADIUS/EAP, RADIUS is used to shuttle RADIUS-encapsulated EAP Packets between the NAS and an authentication server. The authenticating peer and the NAS begin the EAP conversation by negotiating use of EAP. Once EAP has been negotiated, the NAS SHOULD send an initial EAP-Request message to the authenticating peer. This will typically be an EAP-Request/Identity, although it could be an EAP- Request for an authentication method (Types 4 and greater). A NAS MAY be configured to initiate with a default authentication method. This is useful in cases where the identity is determined by another means (such as Called-Station-Id, Calling-Station-Id and/or Originating-Line-Info); where a single authentication method is required, which includes its own identity exchange; where identity hiding is desired, so that the identity is not requested until after a protected channel has been set up. Aboba & Calhoun Informational [Page 5]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 The peer replies with an EAP-Response. The NAS MAY determine from the Response that it should proceed with local authentication. Alternatively, it MAY act as a pass-through, encapsulating the EAP- Response within EAP-Message attribute(s) sent within a RADIUS Access- Request packet. If the NAS sends an EAP-Request/Identity message as the initial packet, the peer responds with an EAP-Response/Identity. The NAS may determine that the user is local and proceed with local authentication. If no match is found against the list of local users, the NAS encapsulates the EAP-Response/Identity message within an EAP- Message attribute, enclosed within an Access-Request packet. On receiving a valid Access-Request packet containing EAP-Message attribute(s), a RADIUS server compliant with this specification and wishing to authenticate with EAP MUST respond with an Access-Challenge packet containing EAP-Message attribute(s). If the RADIUS server does not support EAP or does not wish to authenticate with EAP, it MUST respond with an Access-Reject. EAP-Message attribute(s) encapsulate a single EAP packet which the NAS decapsulates and passes on to the authenticating peer. The peer then responds with an EAP-Response packet, which the NAS encapsulates within an Access-Request containing EAP-Message attribute(s). EAP is a 'lock step' protocol, so that other than the initial Request, a new Request cannot be sent prior to receiving a valid Response. The NAS MUST NOT "manufacture" a Success or Failure packet as the result of a timeout, instead of ending the conversation. The conversation continues until either a RADIUS Access-Reject or Access-Accept packet is received from the RADIUS server. Reception of a RADIUS Access-Reject packet MUST result in the NAS denying access to the authenticating peer. A RADIUS Access-Accept packet successfully ends the authentication phase. Using RADIUS, the NAS can act as a pass-through for an EAP conversation between the peer and authentication server, without needing to implement the EAP method used between them. Where the NAS initiates the conversation by sending an EAP-Request for an authentication method, it may not be required that the NAS fully implement the EAP method reflected in the initial EAP-Request. Depending on the initial method, it may be sufficient for the NAS to be configured with the initial packet to be sent to the peer, and for the NAS to act as a pass-through for subsequent messages. Note that since the NAS only encapsulates the EAP-Response in its initial Access-Request, the initial EAP-Request within the authentication method either is vestigial, so that the RADIUS server need not be made aware of it, or the relevant information from the initial EAP-Request (such as a nonce) needs to be reflected in the EAP-Response. Aboba & Calhoun Informational [Page 6]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 Where the initial EAP-Request sent by the NAS is for an authentication Type (4 or greater), the peer MAY respond with a Nak indicating that it would prefer another authentication method that is not implemented locally. In this case, the NAS SHOULD send Access-Request encapsulating the received EAP-Response/Nak. This provides the RADIUS server with a hint about the authentication method(s) preferred by the peer, although it does not provide information on the Type of the original Request. It also provides the server with the Identifier used in the initial EAP- Request, so that Identifier conflicts can be avoided. In order to evaluate whether the alternatives preferred by the peer are allowed, the RADIUS server will typically respond with an Access- Challenge containing EAP-Message attribute(s) encapsulating an EAP- Request/Identity (Type 1). This allows the RADIUS server to determine the peer identity, so as to be able to retrieve the associated authentication policy. Alternatively, an EAP-Request for an authentication method (Type 4 or greater) could be sent. Since the RADIUS server may not be aware of the Type of the initial EAP-Request, it is possible for the RADIUS server to choose an unacceptable method, and for the peer to respond with another Nak. 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. Since RADIUS proxies are assumed to act as a pass-through, they cannot be expected to parse an EAP-Response/Identity encapsulated within EAP-Message attribute(s). If the NAS initially sends an EAP-Request for an authentication method, and the user identity cannot be determined from the EAP-Response, then the User-Name attribute SHOULD be determined by another means. As noted in [RFC2865] Section 5.6, it is recommended that Access-Requests use the value of the Calling-Station-Id as the value of the User-Name attribute. Having the NAS send the initial EAP-Request packet has a number of advantages: [1] It saves a round trip between the NAS and RADIUS server. [2] An Access-Request is only sent to the RADIUS server if the authenticating peer sends an EAP-Response, confirming that it supports EAP. In situations where peers may be EAP unaware, initiating a RADIUS Access-Request on a "carrier sense" or "media up" indication may initiate many authentication exchanges that cannot complete successfully. For example, on wired networks [IEEE8021X] supplicants typically do not initiate the conversation Aboba & Calhoun Informational [Page 7]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 with an EAPOL-Start. Therefore an IEEE 802.1X-enabled switch cannot determine whether the peer supports EAP until it receives a Response to the initial EAP-Request. [3] It allows some users to be authenticated locally. Although having the NAS send the initial EAP-Request packet has substantial advantages, this technique cannot be universally employed. There are circumstances in which the user's identity is already known (such as when authentication and accounting is handled based on Called- Station-Id, Calling-Station-Id and/or Originating-Line-Info), but where the appropriate EAP method may vary based on that identity. Rather than sending an initial EAP-Request packet to the authenticating peer, on detecting the presence of the peer, the NAS MAY send an Access- Request packet to the RADIUS server containing an EAP-Message attribute signifying EAP-Start. The RADIUS server will typically respond with an Access-Challenge containing EAP-Message attribute(s) encapsulating an EAP-Request/Identity (Type 1). However, an EAP-Request for an authentication method (Type 4 or greater) can also be sent by the server. EAP-Start is indicated by sending an EAP-Message attribute with a length of 2 (no data). The Calling-Station-Id SHOULD be included in the User- Name attribute. This may result in a RADIUS Access-Request being sent by the NAS to the RADIUS server without first confirming that the peer supports EAP. Since this technique can result in a large number of uncompleted RADIUS conversations, in situations where EAP unaware peers are common, or where peer support for EAP cannot be determined on initial contact (e.g. [IEEE8021X] supplicants not initiating the conversation with an EAPOL-Start) it SHOULD NOT be employed by default. For proxied RADIUS requests, there are two methods of processing. If the domain is determined based on the Calling-Station-Id, Called- Station-Id and/or Originating-Line-Info, the RADIUS server may proxy the initial RADIUS Access-Request/EAP-Start. If the realm is determined based on the user's identity, the local RADIUS Server MUST respond with a RADIUS Access-Challenge including an EAP-Message attribute encapsulating an EAP-Request/Identity packet. The response from the authenticating peer SHOULD be proxied to the final authentication server. If an Access-Request is sent to a RADIUS server which does not support the EAP-Message attribute, then an Access-Reject MUST be sent in response. On receiving an Access-Reject, the NAS MUST deny access to the authenticating peer. Aboba & Calhoun Informational [Page 8]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 2.2. Invalid packets While acting as a pass-through, the NAS MUST validate the EAP header fields (Code, Identifier, Length) prior to forwarding an EAP packet to or from the RADIUS server. On receiving an EAP packet from the peer, the NAS checks the Code (2) and Length fields, and matches the Identifier value against the current Identifier, supplied by the RADIUS server in the most recently validated EAP-Request. On receiving an EAP packet from the RADIUS server (encapsulated within an Access-Challenge), the NAS checks the Code (1) and Length fields, then updates the current Identifier value. Pending EAP Responses that do not match the current Identifier value are silently discarded by the NAS. Despite these checks, since EAP method fields (Type, Type-Data) are typically not validated by a NAS operating as a pass-through, it is possible for a NAS to forward an invalid EAP packet to or from the RADIUS server. A RADIUS server receiving EAP-Message attribute(s) it does not understand SHOULD make the determination of whether the error is fatal or non-fatal based on the EAP Type. A RADIUS server determining that a fatal error has occurred MUST send an Access-Reject containing an EAP-Message attribute encapsulating EAP-Failure. A RADIUS server determining that a non-fatal error has occurred MAY send an Access-Challenge to the NAS including an Error-Cause attribute [DynAuth] with value 202 (decimal), "Invalid EAP Packet (Ignored)". The Access-Challenge SHOULD encapsulate within EAP-Message attribute(s) the most recently sent EAP-Request packet (including the same Identifier value). On receiving such an Access-Challenge, a legacy NAS decapsulates the EAP-Request and sends it to the EAP peer, which will retransmit the EAP-Response. A NAS compliant with this specification, on receiving an Access- Challenge with an Error-Cause attribute of value 202 (decimal) SHOULD discard the EAP-Response packet most recently transmitted to the RADIUS server and check whether additional EAP-Response packets have been received matching the current Identifier value. If so, a new EAP- Response packet, if available, MUST be sent to the RADIUS server within an Access-Request. If no EAP-Response packet is available, then the EAP-Request encapsulated within the Access-Challenge is sent to the EAP peer, and the retransmission timer is reset. In order to provide protection against Denial of Service (DoS) attacks, it is advisable for the NAS to allocate a finite buffer for EAP packets received from the peer, and to discard packets according to an appropriate policy once that buffer has been exceeded. Also, the RADIUS server is advised to permit only a modest number of invalid EAP packets within a single session, prior to terminating the session with an Access-Reject. By default a value of 5 invalid EAP packets is Aboba & Calhoun Informational [Page 9]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 recommended, prior to termination. 2.3. Retransmission As noted in [RFC2284], the EAP authenticator (NAS) is responsible for retransmission of packets between the authenticating peer and the NAS. If an EAP packet is lost in transit between the authenticating peer and the NAS (or vice versa), the NAS will retransmit. As in RADIUS [RFC2865], the RADIUS client is responsible for retransmission of packets between the RADIUS client and the RADIUS server. It may be necessary to adjust retransmission strategies and authentication timeouts in certain cases. For example, when a token card is used additional time may be required to allow the user to find the card and enter the token. Since the NAS will typically not have knowledge of the required parameters, these need to be provided by the RADIUS server. This can be accomplished by inclusion of Session-Timeout attribute within the Access-Challenge packet. If Session-Timeout is present in an Access-Challenge packet that also contains an EAP-Message, the value of the Session-Timeout is used to set the EAP retransmission timer for that EAP Request, and that Request alone. Once the EAP-Request has been sent, the NAS sets the retransmission timer, and if it expires without having received an EAP- Response corresponding to the Request, then the EAP-Request is retransmitted. 2.4. Fragmentation Using the EAP-Message attribute, it is possible for the RADIUS server to encapsulate an EAP packet that is larger than the MTU on the link between the NAS and the peer. Since it is not possible for the RADIUS server to use MTU discovery to ascertain the link MTU, the Framed-MTU attribute may be included in an Access-Request packet containing an EAP- Message attribute so as to provide the RADIUS server with this information. A RADIUS server having received a Framed-MTU attribute in an Access-Request packet MUST NOT send any subsequent packet in this EAP conversation containing EAP-Message attributes whose values, when concatenated, exceed the length specified by the Framed-MTU value, taking the link type (specified by the NAS-Port-Type attribute) into account. 2.5. Alternative uses Currently the conversation between security servers and the RADIUS server is often proprietary because of lack of standardization. In order to increase standardization and provide interoperability between RADIUS vendors and security vendors, it is recommended that RADIUS- Aboba & Calhoun Informational [Page 10]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 encapsulated EAP be used for this conversation. This has the advantage of allowing the RADIUS server to support EAP without the need for authentication-specific code within the RADIUS server. Authentication-specific code can then reside on a security server instead. In the case where RADIUS-encapsulated EAP is used in a conversation between a RADIUS server and a security server, the security server will typically return an Access-Accept message without inclusion of the expected attributes currently returned in an Access-Accept. This means that the RADIUS server MUST add these attributes prior to sending an Access-Accept message to the NAS. 2.6. Usage guidelines 2.6.1. Identifier space In EAP, each session has its own unique Identifier space. RADIUS server implementations MUST be able to distinguish between EAP Responses with the same Identifier existing within distinct sessions. For this purpose, sessions can be distinguished based upon the NAS-Port, User-Name, Called-Station-Id, and Calling-Station-Id attributes, in addition to the identity of the NAS (as defined by the NAS-Identifier, NAS-IPv6-Address or NAS-IPv4-Address attributes). 2.6.2. Role reversal Since EAP is a peer-to-peer protocol, an independent and simultaneous authentication may take place in the reverse direction. Both peers may act as authenticators and authenticatees at the same time. However, role reversal is not supported by this specification. A RADIUS server MUST respond to an Access-Request encapsulating an EAP-Request with an Access-Reject. In order to avoid retransmissions by the peer, the Access-Reject SHOULD include an EAP-Response/Nak packet indicating no preferred method, encapsulated within EAP-Message attribute(s). 2.6.3. Conflicting messages Access-Accept packets SHOULD have only ONE EAP-Message attribute in them, containing EAP Success; similarly, Access-Reject packets SHOULD only have ONE EAP-Message attribute in them, containing EAP Failure. Where the authentication result implied by the encapsulated EAP packet does not match the result implies by the RADIUS Packet Type, the authenticator MUST make its access control decision based on the RADIUS Packet Type (Access-Accept/Access-Reject), and not based on the contents Aboba & Calhoun Informational [Page 11]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 of the EAP packet encapsulated in one or more EAP-Message attributes, if present. Where the encapsulated EAP packet does not match the result implied by the RADIUS Packet Type, the combination is likely to cause confusion, because the NAS and peer will arrive at different conclusions as to the outcome of the authentication. For example, an EAP Failure packet may be encapsulated within an Access- Accept and an EAP Success packet may be encapsulated within an Access- Reject. Alternatively, an EAP-Message attribute may not be included within a RADIUS Access-Accept or Access-Reject. If the NAS receives an Access-Reject with an encapsulated EAP Success, it will not grant access to the peer. However, on receiving the EAP Success, the peer will be lead to believe that it authenticated successfully. If the NAS receives an Access-Accept with an encapsulated EAP Failure, it will grant access to the peer. However, on receiving an EAP Failure, the peer will be lead to believe that it failed authentication. If no EAP-Message attribute is included within an Access-Accept or Access- Reject, then the peer may not be informed as to the outcome of the authentication, while the NAS will take action to allow or deny access. As described in [RFC2284], the EAP Success and Failure packets are not acknowledged, and these packets terminate the EAP conversation. As a result, if these packets are encapsulated within an Access-Challenge, no response will be received, and therefore the NAS will send no further Access-Requests to the RADIUS server. As a result, the NAS will not be given an indication of whether to allow or deny access while the peer will be informed as to the outcome of the authentication. To avoid these conflicts, the following combinations SHOULD NOT be sent by a RADIUS server: Access-Accept/EAP-Message/EAP Failure Access-Accept/no EAP-Message attribute Access-Accept/EAP-Start Access-Reject/EAP-Message/EAP Success Access-Reject/no EAP-Message attribute Access-Reject/EAP-Start Access-Challenge/EAP-Message/EAP Success Access-Challenge/EAP-Message/EAP Failure Access-Challenge/no EAP-Message attribute Access-Challenge/EAP-Start Since the responsibility for avoiding conflicts lies with the RADIUS Aboba & Calhoun Informational [Page 12]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 server, the NAS MUST NOT "manufacture" EAP packets in order to correct contradictory messages that it receives. This behavior, originally mandated within [IEEE8021X], is now deprecated. 2.6.4. Priority In addition to containing EAP-Message attributes, RADIUS messages may also contain other attributes. In order to ensure the correct processing of RADIUS messages, on receiving an Access-Accept, Access-Reject or Access-Challenge, the NAS SHOULD process other attributes first, then decapsulate EAP-Message attribute(s), reconstitute the EAP packet and send it to the peer. 2.6.5. Displayable messages The Reply-Message attribute, defined in [RFC2865], Section 5.18, indicates text which may be displayed to the user. This is similar in concept to EAP Notification, defined in [RFC2284]. When sending a displayable message to a NAS during an EAP conversation, the RADIUS server MUST encapsulate displayable messages within EAP-Message/EAP- Request/Notification attribute(s). Reply-Message attribute(s) MUST NOT be included in any RADIUS message containing an EAP-Message attribute. An EAP-Message/EAP-Request/Notification SHOULD NOT be included within an Access-Accept or Access-Reject packet. In some existing implementations, a NAS receiving Reply-Message attribute(s) copies the Text field(s) into the Type-Data field of an EAP-Request/Notification packet, fills in the Identifier field, and sends this to the peer. However, several issues arise from this: [1] Unexpected Responses. On receiving an EAP-Request/Notification, the peer will send an EAP-Response/Notification, and the NAS will pass this on to the RADIUS server, encapsulated within EAP-Message attribute(s). However, the RADIUS server may not be expecting an Access-Request containing an EAP-Message/EAP-Response/Notification attribute. For example, consider what happens when a Reply-Message is included within an Access-Accept or Access-Reject packet with no EAP-Message attribute(s) present. If the value of the Reply-Message attribute is copied into the Type-Data of an EAP-Request/Notification and sent to the peer, this will result in an Access-Request containing an EAP-Message/EAP-Response/Notification attribute being sent by the NAS to the RADIUS server. Since an Access-Accept or Access- Reject packet terminates the RADIUS conversation, such an Access- Request would not be expected, and could be interpreted as the start of another conversation. Aboba & Calhoun Informational [Page 13]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 [2] Identifier conflicts. While the EAP-Request/Notification is an EAP packet containing an Identifier field, the Reply-Message attribute does not contain an Identifier field. As a result, a NAS receiving a Reply-Message attribute and wishing to translate this to an EAP- Request/Notification will need to choose an Identifier value. It is possible that the chosen Identifier value will conflict with a value chosen by the RADIUS server for another packet within the EAP conversation, potentially causing confusion between a new packet and a retransmission. To avoid these problems, a NAS receiving a Reply-Message attribute from the RADIUS server SHOULD silently discard the attribute. 3. Attributes The NAS-Port or NAS-Port-Id attributes SHOULD be included by the NAS in Access-Request packets, and either NAS-Identifier, NAS-IP-Address or NAS-IPv6-Address attributes MUST be included. In order to permit forwarding of the Access-Reply by EAP-unaware proxies, if a User-Name attribute was included in an Access-Request, the RADIUS server MUST include the User-Name attribute in subsequent Access-Accept packets. Without the User-Name attribute, accounting and billing becomes difficult to manage. 3.1. EAP-Message Description This attribute encapsulates EAP [RFC2284] packets so as to allow the NAS to authenticate users via EAP without having to understand the EAP method it is passing through. The NAS places EAP messages received from the authenticating peer into one or more EAP-Message attributes and forwards them to the RADIUS server within an Access-Request message. If multiple EAP- Message attributes are contained within an Access-Request or Access- Challenge packet, they MUST be in order and they MUST be consecutive attributes in the Access-Request or Access-Challenge packet. The RADIUS server can return EAP-Message attributes in Access-Challenge, Access-Accept and Access-Reject packets. When RADIUS is used to enable EAP authentication, Access-Request, Access-Challenge, Access-Accept, and Access-Reject packets SHOULD contain one or more EAP-Message attributes. Where more than one EAP- Message attribute is included, it is assumed that the attributes are to be concatenated to form a single EAP packet. Multiple EAP packets MUST NOT be encoded within EAP-Message attributes contained within a single Access-Challenge, Access-Accept, Access-Reject or Access- Aboba & Calhoun Informational [Page 14]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 Request packet. It is expected that EAP will be used to implement a variety of authentication methods, including methods involving strong cryptography. In order to prevent attackers from subverting EAP by attacking RADIUS/EAP, (for example, by modifying EAP Success or EAP Failure packets) it is necessary that RADIUS/EAP provide integrity protection. Therefore the Message-Authenticator attribute MUST be used to protect all Access-Request, Access-Challenge, Access-Accept, and Access- Reject packets containing an EAP-Message attribute. Access-Request packets including EAP-Message attribute(s) without a Message-Authenticator attribute SHOULD be silently discarded by the RADIUS server. A RADIUS server supporting the EAP-Message attribute MUST calculate the correct value of the Message-Authenticator and silently discard the packet if it does not match the value sent. A RADIUS server not supporting the EAP-Message attribute MUST return an Access-Reject if it receives an Access-Request containing an EAP- Message attribute. Access-Challenge, Access-Accept, or Access-Reject packets including EAP-Message attribute(s) without a Message-Authenticator attribute SHOULD be silently discarded by the NAS. A NAS supporting the EAP- Message attribute MUST calculate the correct value of the Message- Authenticator and silently discard the packet if it does not match the value sent. A summary of the EAP-Message attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 79 for EAP-Message. Length >= 3 String Aboba & Calhoun Informational [Page 15]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 The String field contains an EAP packet, as defined in [RFC2284]. If multiple EAP-Message attributes are present in a packet their values should be concatenated; this allows EAP packets longer than 253 octets to be transported by RADIUS. 3.2. Message-Authenticator Description This attribute MAY be used to authenticate and integrity-protect Access-Requests in order to prevent spoofing. It MAY be used in any Access-Request. It MUST be used in any Access-Request, Access- Accept, Access-Reject or Access-Challenge that includes an EAP- Message attribute. A RADIUS server receiving an Access-Request with a Message- Authenticator Attribute present MUST calculate the correct value of the Message-Authenticator and silently discard the packet if it does not match the value sent. A RADIUS Client receiving an Access-Accept, Access-Reject or Access- Challenge with a Message-Authenticator Attribute present MUST calculate the correct value of the Message-Authenticator and silently discard the packet if it does not match the value sent. A summary of the Message-Authenticator attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 80 for Message-Authenticator Length 18 String When present in an Access-Request packet, Message-Authenticator is an HMAC-MD5 [RFC2104] hash of the entire Access-Request packet, including Type, ID, Length and authenticator, using the shared secret as the key, as follows. Aboba & Calhoun Informational [Page 16]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes) When the message integrity check 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 message integrity check 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 message integrity check. The Message-Authenticator is calculated and inserted in the packet before the Response authenticator is calculated. This attribute is not needed if the User-Password attribute is present, but is useful for preventing attacks on other types of authentication. This attribute is intended to thwart attempts by an attacker to setup a "rogue" NAS, and perform online dictionary attacks against the RADIUS server. It does not afford protection against "offline" attacks where the attacker intercepts packets containing (for example) CHAP challenge and response, and performs a dictionary attack against those packets offline. 3.3. Table of Attributes The following table provides a guide to which attributes may be found in which kind of packets. The EAP-Message and Message-Authenticator attributes specified in this document MUST NOT be present in an Accounting-Request. The following table provides a guide to which attributes may be found in packets sent as part of an EAP conversation, and in what quantity. If a table entry is omitted, the values found in [RFC2548], [RFC2865],[RFC2868],[RFC2869] and [RFC3162] should be assumed. Aboba & Calhoun Informational [Page 17]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 Request Accept Reject Challenge # Attribute 0-1 0-1 0 0 1 User-Name 0 0 0 0 2 User-Password [Note 1] 0 0 0 0 3 CHAP-Password [Note 1] 0-1 0-1 0 0-1 6 Service-Type 0 0 0 0 18 Reply-Message 0-1 0-1 0 0-1 24 State 0 0+ 0 0 25 Class 0 0-1 0 0-1 27 Session-Timeout 0+ 0+ 0+ 0+ 33 Proxy-State 0 0 0 0 60 CHAP-Challenge 0 0 0 0 70 ARAP-Password [Note 1] 0 0 0 0 75 Password-Retry 1+ 1+ 1+ 1+ 79 EAP-Message [Note 1] 1 1 1 1 80 Message-Authenticator [Note 1] 0-1 0 0 0 94 Originating-Line-Info [Note 3] 0 0 0-1 0-1 TBD Error-Cause [Note 2] Request Accept Reject Challenge # Attribute [Note 1] An Access-Request that contains either a User-Password or CHAP- Password or ARAP-Password or one or more EAP-Message attributes MUST NOT contain more than one type of those four attributes. If it does not contain any of those four attributes, it SHOULD contain a Message- Authenticator. If any packet type contains an EAP-Message attribute it MUST also contain a Message-Authenticator. [Note 2] The Error-Cause attribute is defined in [DynAuth]. [Note 3] The Originating-Line-Info attribute is defined in [NASREQ]. The following table defines the meaning of the above table entries. 0 This attribute MUST NOT be present. 0+ Zero or more instances of this attribute MAY be present. 0-1 Zero or one instance of this attribute MAY be present. 1 Exactly one instance of this attribute MUST be present. 1+ One or more of these attributes MUST be present. 4. Security Considerations 4.1. Security requirements RADIUS/EAP is used in order to provide authentication and authorization for network access. As a result, both the RADIUS and EAP portions of the conversation are open to attack. Threats are discussed in [RFC2607], [RFC2865], and [RFC3162]. Examples include: [1] An adversary may attempt to acquire confidential data and Aboba & Calhoun Informational [Page 18]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 identities by snooping RADIUS packets. [2] An adversary may attempt to modify packets containing RADIUS messages. [3] An adversary may attempt to inject packets into a RADIUS conversation. [4] An adversary may launch a dictionary attack against the RADIUS shared secret. [5] An adversary may launch a known plaintext attack, hoping to recover the key stream corresponding to a Request Authenticator. [6] An adversary may attempt to replay a RADIUS exchange. [7] An adversary may attempt to disrupt the EAP negotiation, in order to weaken the authentication, or gain access to user passwords. [8] An authenticated NAS may attempt to forge attributes, including NAS-IP-Address, NAS-Identifier, Called-Station-Id, or Calling-Station-Id. [9] A rogue (unauthenticated) NAS may attempt to impersonate a legitimate NAS. [10] An attacker may attempt to act as a man-in-the-middle. To address these threats, it is necessary to support confidentiality, data origin authentication, integrity, and replay protection on a per- packet basis. Bi-directional authentication between the RADIUS client and server also needs to be provided. There is no requirement that the identities of RADIUS clients and servers be kept confidential (e.g., from a passive eavesdropper). 4.2. Security protocol To address the security threats for RADIUS/EAP, implementations of this specification SHOULD support IPsec [RFC2401] along with IKE [RFC2409] for key management. IPsec ESP [RFC2406] with non-null transform SHOULD be supported, and per-packet encryption, authentication, integrity and replay protection SHOULD be used, along with IKE for key management. Within RADIUS [RFC2865], a shared secret is used for hiding of attributes such as User-Password, as well as in computation of the Response Authenticator. In RADIUS accounting [RFC2866], the shared secret is used in computation of both the Request Authenticator and the Aboba & Calhoun Informational [Page 19]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 Response Authenticator. Since in RADIUS a shared secret is used to provide confidentiality as well as integrity protection and authentication, only use of IPsec ESP with a non-null transform can provide security services sufficient to substitute for RADIUS application-layer security. Therefore, where IPSEC AH or ESP null is used, it will typically still be necessary to configure a RADIUS shared secret. Where RADIUS is run over IPsec ESP with a non-null transform, the secret shared between the NAS and the RADIUS server may not be configured. In this case, a shared secret of zero length MUST be assumed. However, a RADIUS server that cannot know whether incoming traffic is IPsec- protected MUST be configured with a non-null RADIUS shared secret. When IPsec ESP is used with RADIUS, DES-CBC SHOULD NOT be used as the encryption transform, and per-packet authentication, integrity and replay protection MUST be used. A typical IPsec policy for an IPsec- capable RADIUS client is "Initiate IPsec, from me to any destination port UDP 1812". This causes an IPsec SA to be set up by the RADIUS client prior to sending RADIUS traffic. If some RADIUS servers contacted by the client do not support IPsec, then a more granular policy will be required: "Initiate IPsec, from me to IPsec-Capable-RADIUS-Server, destination port UDP 1812". For an IPsec-capable RADIUS server, a typical IPsec policy is "Accept IPsec, from any to me, destination port 1812". This causes the RADIUS server to accept (but not require) use of IPsec. It may not be appropriate to require IPsec for all RADIUS clients connecting to an IPsec-enabled RADIUS server, since some RADIUS clients may not support IPsec. Where IPsec is used for security, and no RADIUS shared secret is configured, it is important that trust be demonstrated between the RADIUS client and RADIUS server by some means. For example, before enabling an IKE-authenticated host to act as a RADIUS client, the RADIUS server should check whether the host is authorized to provide network access. Similarly, before enabling an IKE-authenticated host to act as a RADIUS server, the RADIUS client should check whether the host is authorized for that role. RADIUS servers can be configured with the IP addresses (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for certificate authentication) of RADIUS clients. Alternatively, if a separate CA exists for RADIUS clients, then the RADIUS server can configure this CA as a trusted root for use with IPsec. Aboba & Calhoun Informational [Page 20]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 Similarly, RADIUS clients can be configured with the IP addresses (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for certificate authentication) of RADIUS servers. Alternatively, if a separate CA exists for RADIUS servers, then the RADIUS client can configure this CA as a trusted root for use with IPsec. Since unlike SSL/TLS, IKE does not permit certificate policies to be set on a per-port basis, certificate policies need to apply to all uses of IPsec on RADIUS clients and servers. In IPsec deployment supporting only certificate authentication, a management station initiating an IPsec- protected telnet session to the RADIUS server would need to obtain a certificate chaining to the RADIUS client CA. Issuing such a certificate might not be appropriate if the management station was not authorized as a RADIUS client. Where RADIUS clients may obtain their IP address dynamically (such as an Access Point supporting DHCP), IKEv1 Main Mode with pre-shared keys [RFC2409] SHOULD NOT be used, since this requires use of a group pre- shared key; instead, Aggressive Mode SHOULD be used. IKEv2, a work in progress, may address this issue in the future. Where RADIUS client addresses are statically assigned either Aggressive Mode or Main Mode MAY be used. With certificate authentication, Main Mode SHOULD be used. Care needs to be taken with IKE Phase 1 Identity Payload selection in order to enable mapping of identities to pre-shared keys even with Aggressive Mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity Payloads are used and addresses are dynamically assigned, mapping of identities to keys is not possible, so that group pre-shared keys are still a practical necessity. As a result, the ID_FQDN identity payload SHOULD be employed in situations where Aggressive mode is utilized along with pre-shared keys and IP addresses are dynamically assigned. This approach also has other advantages, since it allows the RADIUS server and client to configure themselves based on the fully qualified domain name of their peers. Note that with IPsec, security services are negotiated at the granularity of an IPsec SA, so that RADIUS exchanges requiring a set of security services different from those negotiated with existing IPsec SAs will need to negotiate a new IPsec SA. Separate IPsec SAs are also advisable where quality of service considerations dictate different handling RADIUS conversations. Attempting to apply different quality of service to connections handled by the same IPsec SA can result in reordering, and falling outside the replay window. For a discussion of the issues, see [RFC2983]. Aboba & Calhoun Informational [Page 21]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 4.3. Security issues This section provides more detail on the vulnerabilities identified in Section 4.1, and how they may be mitigated. Vulnerabilities include: Privacy issues Message-Authenticator security Connection hijacking Dictionary attacks Known plaintext attacks Replay attacks Negotiation attacks Impersonation Man in the middle attacks Separation of EAP server and authenticator Multiple databases 4.3.1. Privacy issues Since RADIUS messages may contain the User-Name attribute as well as NAS-IP-Address or NAS-Identifier attributes, an attacker snooping on RADIUS traffic may be able to determine the geographic location of users in real time. In wireless networks, it is often assumed that RADIUS traffic is physically secure, since it typically travels over the wired network and that this limits the release of location information. However, it is possible for an authenticated attacker to spoof ARP packets from another Access Point so as to cause diversion of RADIUS traffic onto the wireless network. In this way an attacker may obtain RADIUS packets from which it can glean location information, or which it can subject to an offline dictionary attack. To address these vulnerabilities, implementations of this specification SHOULD use IPsec ESP with non-null transform and per-packet encryption, authentication, integrity and replay protection to protect both RADIUS authentication [RFC2865] and accounting [RFC2866] traffic. 4.3.2. Spoofing and hijacking Access-Request packets with a User-Password attribute establish the identity of both the user and the NAS sending the Access-Request, because of the way the shared secret between NAS and RADIUS server is used. Access-Request packets with CHAP-Password or EAP-Message attributes do not have a User-Password attribute, so the Message- Authenticator attribute SHOULD be used in Access-Request packets that do not have a User-Password attribute, in order to establish the identity of the NAS sending the request. The Message-Authenticator attribute MUST be present in all RADIUS/EAP packets. Aboba & Calhoun Informational [Page 22]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 An attacker may attempt to inject packets into the conversation between the NAS and the RADIUS server, or between the RADIUS server and the security server. RADIUS [RFC2865] does not support encryption other than attribute hiding, and as described in [RFC2865], only Access-Reply and Access-Challenge packets are integrity protected. Moreover, the integrity protection mechanism described in [RFC2865] is weaker than that likely to be used by some EAP methods, making it possible to subvert those methods by attacking EAP/RADIUS. In order to provide for authentication of all packets in the EAP exchange, all RADIUS/EAP packets MUST include the Message-Authenticator attribute. To provide stronger security implementations of this specification SHOULD use IPsec ESP with non-null transform and per- packet encryption, authentication, integrity and replay protection. 4.3.3. Dictionary attacks The RADIUS shared secret is vulnerable to offline dictionary attack, based on capture of the Response authenticator or Message-Authenticator attribute. In order to decrease the level of vulnerability, [RFC2865] recommends: The secret (password shared between the client and the RADIUS server) SHOULD be at least as large and unguessable as a well- chosen password. It is preferred that the secret be at least 16 octets. The risk of an offline dictionary attack can be further reduced by employing IPsec ESP with non-null transform in order to encrypt the RADIUS conversation, as described in Section 4.2. 4.3.4. Known plaintext attacks Since EAP [RFC2284] does not support PAP, the RADIUS User-Password attribute is not used to carry hidden user passwords within EAP conversations. The User-Password hiding mechanism, defined in [RFC2865] utilizes MD5, defined in [RFC1321], in order to generate a key stream based on the RADIUS shared secret and the Request authenticator. Where PAP is in use, it is possible to collect key streams corresponding to a given Request Authenticator value, by capturing RADIUS conversations corresponding to a PAP authentication attempt using a known password. Since the User-Password is known, the key stream corresponding to a given Request Authenticator can be determined and stored. Since the key stream may have been determined previously from a known plaintext attack, if the Request Authenticator repeats, attributes encrypted using the RADIUS attribute hiding mechanism should be considered compromised. In addition to the User-Password attribute, which is not used with EAP, this includes attributes such as Tunnel- Aboba & Calhoun Informational [Page 23]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 Password [RFC2868, section 3.5] and MS-MPPE-Send-Key and MS-MPPE-Recv- Key attributes [RFC2548, section 2.4], which include a Salt field as part of the hiding algorithm. To avoid this, [RFC2865], Section 3 advises: Since it is expected that the same secret MAY be used to authenticate with servers in disparate geographic regions, the Request Authenticator field SHOULD exhibit global and temporal uniqueness. Where the Request Authenticator repeats, the Salt field defined in [RFC2548], Section 2.4 does not provide protection against compromise. This is because MD5 [RFC1321], rather than HMAC-MD5 [RFC2104], is used to generate the key stream, which is calculated from the 128-bit RADIUS shared secret (S), the 128-bit Request Authenticator (R), and the Salt field (A), using the formula b(1) = MD5(S + R + A). Since the Salt field is placed at the end, if the Request Authenticator were to repeat on a network where PAP is in use, then the salted keystream could be calculated from the User-Password keystream by continuing the MD5 calculation based on the Salt field (A), which is sent in the clear. Even though EAP does not support PAP authentication, a security vulnerability can still exist where the same RADIUS shared secret is used for hiding User-Password as well as other attributes. This can occur, for example, if the same RADIUS proxy handles authentication requests for both EAP and PAP. The threat can be mitigated by protecting RADIUS with IPsec ESP with non-null transform, as described in Section 4.2. Where RADIUS shared secrets are configured, the RADIUS shared secret used by a NAS supporting EAP MUST NOT be reused by a NAS supporting PAP authentication, since improper shared secret hygiene could lead to compromise of hidden attributes. 4.3.5. Replay attacks The RADIUS protocol provides only limited support for replay protection. RADIUS Access-Requests include liveness via the 128-bit Request authenticator. However, the Request Authenticator is not a replay counter. Since RADIUS servers may not maintain a cache of previous Request Authenticators, the Request Authenticator does not provide replay protection. RADIUS accounting [RFC2866] does not support replay protection at the protocol level. Due to the need to support failover between RADIUS accounting servers, protocol-based replay protection is not sufficient to prevent duplicate accounting records. However, once accepted by the accounting server, duplicate accounting records can be detected by use Aboba & Calhoun Informational [Page 24]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 of the the Acct-Session-Id [RFC2866, section 5.5] and Event-Timestamp [RFC2869, section 5.3] attributes. Unlike RADIUS authentication, RADIUS accounting does not use the Request Authenticator as a nonce. Instead, the Request Authenticator contains an MD5 hash calculated over the Code, Identifier, Length, and request attributes of the Accounting Request packet, plus the shared secret. The Response Authenticator also contains an MD5 hash calculated over the Code, Identifier and Length, the Request Authenticator field from the Accounting-Request packet being replied to, the response attributes and the shared secret. Since the Accounting Response Authenticator depends in part on the Accounting Request Authenticator, it is not possible to replay an Accounting-Response unless the Request Authenticator repeats. While it is possible to utilize EAP methods such as EAP TLS [RFC2716] which include liveness checks on both sides, not all EAP messages will include liveness so that this provides incomplete protection. Strong replay protection for RADIUS authentication and accounting can be provided by enabling IPsec replay protection with RADIUS, as described in Section 4.2. 4.3.6. Negotiation attacks In a negotiation attack a rogue NAS, tunnel server, RADIUS proxy or RADIUS server attempts to cause the authenticating peer to choose a less secure authentication method. For example, a session that would normally be authenticated with EAP would instead authenticated via CHAP or PAP; alternatively, a connection that would normally be authenticated via a more secure EAP method such as EAP-TLS [RFC2716] might be made to occur via a less secure EAP method, such as MD5-Challenge. The threat posed by rogue devices, once thought to be remote, has gained currency given compromises of telephone company switching systems, such as those described in [Masters]. Protection against negotiation attacks requires the elimination of downward negotiations. The RADIUS exchange may be further protected by use of IPsec, as described in Section 4.2. Alternatively, where IPsec is not used, the vulnerability can be mitigated via implementation of per- connection policy on the part of the authenticating peer, and per-user policy on the part of the RADIUS server. For the authenticating peer, authentication policy should be set on a per-connection basis. Per- connection policy allows an authenticating peer to negotiate a strong EAP method when connecting to one service, while negotiating a weaker EAP method for another service. Aboba & Calhoun Informational [Page 25]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 With per-connection policy, an authenticating peer will only attempt to negotiate EAP for a session in which EAP support is expected. As a result, there is a presumption that an authenticating peer selecting EAP requires that level of security. If it cannot be provided, it is likely that there is some kind of misconfiguration, or even that the authenticating peer is contacting the wrong server. Should the NAS not be able to negotiate EAP, or should the EAP-Request sent by the NAS be of a different EAP type than what is expected, the authenticating peer MUST disconnect. An authenticating peer expecting EAP to be negotiated for a session MUST NOT negotiate a weaker method, such as CHAP or PAP. In wireless networks, the service advertisement itself may be spoof- able, so that an attacker could fool the peer into negotiating an authentication method suitable for a less secure network. For a NAS, it may not be possible to determine whether a peer is required to authenticate with EAP until the peer's identity is known. For example, for shared-uses NASes it is possible for one reseller to implement EAP while another does not. Alternatively, some peer might be authenticated locally by the NAS while other peers are authenticated via RADIUS. In such cases, if any peers of the NAS MUST do EAP, then the NAS MUST attempt to negotiate EAP for every session. This avoids forcing an EAP-capable client to support more than one authentication type, which could weaken security. If CHAP is negotiated, the NAS will pass the User-Name and CHAP- Password attributes to the RADIUS server in an Access-Request packet. If the user is not required to use EAP, then the RADIUS server will respond with an Access-Accept or Access-Reject packet as appropriate. However, if CHAP has been negotiated but EAP is required, the RADIUS server MUST respond with an Access-Reject, rather than an Access- Challenge/EAP-Message/EAP-Request packet. The authenticating peer MUST refuse to renegotiate authentication, even if the renegotiation is from CHAP to EAP. If EAP is negotiated but is not supported by the RADIUS proxy or server, then the server or proxy MUST respond with an Access-Reject. In these cases, a PPP NAS MUST send an LCP-Terminate and disconnect the user. This is the correct behavior since the authenticating peer is expecting EAP to be negotiated, and that expectation cannot be fulfilled. An EAP- capable authenticating peer MUST refuse to renegotiate the authentication protocol if EAP had initially been negotiated. Note that problems with a non-EAP capable RADIUS proxy could prove difficult to diagnose, since a user connecting from one location (with an EAP-capable proxy) might be able to successfully authenticate via EAP, while the same user connecting at another location (and encountering an EAP- incapable proxy) might be consistently disconnected. Aboba & Calhoun Informational [Page 26]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 4.3.7. Impersonation [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. When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or NAS-IPv6-Address attributes may not match the source address. Since the NAS-Identifier attribute need not contain an FQDN, this attribute also may not correspond to the source address, even indirectly, with or without a proxy present. As a result, the authenticity check performed by a RADIUS server or proxy does not verify the correctness of NAS identification attributes. This makes it possible for a rogue NAS to forge NAS-IP-Address, NAS- IPv6-Address or NAS-Identifier attributes within a RADIUS Access-Request in order to impersonate another NAS. It is also possible for a rogue NAS to forge session identification attributes such as Called-Station-Id, Calling-Station-Id, and Originating-Line-Info. This could fool the RADIUS server into subsequently sending Disconnect or CoA-Request messages [DynAuth] containing forged session identification attributes to a NAS targeted by an attacker. To address these vulnerabilities RADIUS proxies SHOULD check whether NAS identification attributes (NAS-IP-Address, NAS-IPv6-Address, NAS- Identifier) match the source address of packets originating from the NAS. Where a match is not found, an Access-Reject SHOULD be sent, and an error SHOULD be logged. However, such a check may not always be possible. Since the NAS- Identifier attribute need not correspond to an FQDN, it may not be resolvable to an IP address to be matched against the source address. Also, where a NAT exists between the RADIUS client and proxy, checking the NAS-IP-Address or NAS-IPv6-Address attributes may not be feasible. To allow verification of NAS and session identification parmeters, EAP methods can support the secure exchange of these parameters between the EAP peer and EAP server. NAS identification attributes include NAS-IP- Address, NAS-IPv6-Address and Called-Station-Id; session identification attributes include User-Name and Calling-Station-Id. The secure exchange of these parameters between the EAP peer and server enables the RADIUS server to check whether the attributes provided by the NAS match those provided by the EAP peer; similarly, the EAP peer can check the parameters provided by the NAS against those provided by the EAP server. This enables detection of a rogue NAS. Aboba & Calhoun Informational [Page 27]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 4.3.8. Man in the middle attacks RADIUS only provides security on a hop-by-hop basis, even where IPsec is utilized for transmission layer security. As a result, an attacker gaining control of a RADIUS proxy could attempt to modify EAP packets in transit. To protect against this, EAP methods SHOULD incorporate their own integrity protection and authentication mechanisms. 4.3.9. Separation of EAP server and authenticator It is possible for the EAP peer and authenticator to mutually authenticate, and derive a Master Session Key (MSK) for a ciphersuite used to protect subsequent data traffic. This does not present an issue on the peer, since the peer and EAP client reside on the same machine; all that is required is for the EAP client module to derive and pass a Transient Session Key (TSK) to the ciphersuite module. The situation is more complex when EAP is used with RADIUS, since the authenticator may not reside on the same host as the EAP server. For example, the EAP server may reside on a security server, or a module within a RADIUS server. In the case where the EAP server and authenticator reside on different machines, there are several implications for security. First, mutual authentication will occur between the peer and the EAP server, not between the peer and the authenticator. This means that it is not possible for the peer to validate the identity of the NAS or tunnel server that it is speaking to, using EAP alone. As described in Section 4, when EAP/RADIUS is used to encapsulate EAP packets, IPsec SHOULD be used to provide per-packet authentication, integrity, replay protection and confidentiality. The Message- Authenticator attribute is also required in EAP/RADIUS Access-Requests sent from the NAS or tunnel server to the RADIUS server. Since the Message-Authenticator attribute involves an HMAC-MD5 message integrity check, it is possible for the RADIUS server to verify the integrity of the Access-Request as well as the NAS or tunnel server's identity, even where IPsec is not used. Similarly, Access-Challenge packets sent from the RADIUS server to the NAS are also authenticated and integrity protected using an HMAC-MD5 message integrity check, enabling the NAS or tunnel server to determine the integrity of the packet and verify the identity of the RADIUS server, even where IPsec is not used. Moreover, EAP packets sent using methods that contain their own integrity protection cannot be successfully modified by a rogue NAS or tunnel server. The second issue that arises in the case of an EAP server and authenticator residing on different machines is that the EAP Master Aboba & Calhoun Informational [Page 28]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 Session Key (MSK) negotiated between the peer and EAP server will need to be transmitted to the authenticator. Therefore a mechanism needs to be provided to transmit the MSK from the EAP server to the authenticator or tunnel server that needs it. The specification of the key transport and wrapping mechanism is outside the scope of this document. 4.3.10. Multiple databases In many cases a security server will be deployed along with a RADIUS server in order to provide EAP services. Unless the security server also functions as a RADIUS server, two separate user databases will exist, each containing information about the security requirements for the user. This represents a weakness, since security may be compromised by a successful attack on either of the servers, or their databases. With multiple user databases, adding a new user may require multiple operations, increasing the chances for error. The problems are further magnified in the case where user information is also being kept in an LDAP server. In this case, three stores of user information may exist. In order to address these threats, consolidation of databases is recommended. This can be achieved by having both the RADIUS server and security server store information in the same database; by having the security server provide a full RADIUS implementation; or by consolidating both the security server and the RADIUS server onto the same machine. 5. IANA considerations This specification does not create any new registries, or define any new RADIUS attributes or values. 6. Normative references [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [RFC2284] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. Aboba & Calhoun Informational [Page 29]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 [RFC2401] Atkinson, R., Kent, S., "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2406] Kent, S., Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3162] Aboba, B., Zorn, G., Mitton, D., "RADIUS and IP6", RFC 3162, August 2001. [DynAuth] Chiba, M., et al.,"Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", draft-chiba-radius-dynamic-authorization-14.txt, Internet draft (work in progress), April 2003. 7. Informative references [RFC1510] Kohl, J., Neuman, C., "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999. [RFC2607] Aboba, B., Vollbrecht, J., "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999. [RFC2716] Aboba, B., Simon, D.,"PPP EAP TLS Authentication Protocol", RFC 2716, October 1999. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2867] Zorn, G., Aboba, B., Mitton, D., "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000. [RFC2868] Zorn, G. et. al, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000. Aboba & Calhoun Informational [Page 30]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 [RFC2869] Rigney, C., Willats, W., Calhoun, P., "RADIUS Extensions", RFC 2869, June 2000. [RFC2983] Black, D. "Differentiated Services and Tunnels", RFC 2983, October 2000. [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, ANSI/IEEE Std 802, 1990. [IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2001, June 2001. [Masters] Slatalla, M., and Quittner, J., "Masters of Deception." HarperCollins, New York, 1995. [NASREQ] Calhoun, P., et al., "Diameter Network Access Server Application", draft-ietf-aaa-diameter-nasreq-11.txt, Internet draft (work in progress), February 2003. Aboba & Calhoun Informational [Page 31]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 Appendix A - Examples The examples below illustrate conversations between an authenticating peer, NAS, and RADIUS server. The OTP and EAP-TLS protocols are used only for illustrative purposes; other authentication protocols could also have been used, although they might show somewhat different behavior. Where the NAS sends an EAP-Request/Identity as the initial packet, the exchange appears as follows: Authenticating peer NAS RADIUS server ------------------- --- ------------- <- EAP-Request/ Identity EAP-Response/ Identity (MyID) -> RADIUS Access-Request/ EAP-Message/EAP-Response/ (MyID) -> <- RADIUS Access-Challenge/ EAP-Message/EAP-Request OTP/OTP Challenge <- EAP-Request/ OTP/OTP Challenge EAP-Response/ OTP, OTPpw -> RADIUS Access-Request/ EAP-Message/EAP-Response/ OTP, OTPpw -> <- RADIUS Access-Accept/ EAP-Message/EAP-Success (other attributes) <- EAP-Success Aboba & Calhoun Informational [Page 32]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 In the case where the NAS initiates with an EAP-Request for EAP TLS [RFC2716], and the identity is determined based on the contents of the client certificate, the exchange will appear as follows: Authenticating peer NAS RADIUS server ------------------- --- ------------- <- EAP-Request/ EAP-Type=EAP-TLS (TLS Start, S bit set) EAP-Response/ EAP-Type=EAP-TLS (TLS client_hello)-> RADIUS Access-Request/ EAP-Message/EAP-Response/ EAP-Type=EAP-TLS-> <-RADIUS Access-Challenge/ EAP-Message/ EAP-Request/ EAP-Type=EAP-TLS <- EAP-Request/ EAP-Type=EAP-TLS (TLS server_hello, TLS certificate, [TLS server_key_exchange,] [TLS certificate_request,] TLS server_hello_done) EAP-Response/ EAP-Type=EAP-TLS (TLS certificate, TLS client_key_exchange, [TLS certificate_verify,] TLS change_cipher_spec, TLS finished)-> RADIUS Access-Request/ EAP-Message/EAP-Response/ EAP-Type=EAP-TLS-> <-RADIUS Access-Challenge/ EAP-Message/ EAP-Request/ EAP-Type=EAP-TLS <- EAP-Request/ EAP-Type=EAP-TLS (TLS change_cipher_spec, TLS finished) EAP-Response/ EAP-Type=EAP-TLS -> RADIUS Access-Request/ EAP-Message/EAP-Response/ Aboba & Calhoun Informational [Page 33]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 EAP-Type=EAP-TLS-> <-RADIUS Access-Accept/ EAP-Message/EAP-Success (other attributes) <- EAP-Success In the case where the NAS first sends an EAP-Start packet to the RADIUS server, the conversation would appear as follows: Authenticating peer NAS RADIUS server ------------------- --- ------------- RADIUS Access-Request/ EAP-Message/Start -> <- RADIUS Access-Challenge/ EAP-Message/EAP-Request/ Identity <- EAP-Request/ Identity EAP-Response/ Identity (MyID) -> RADIUS Access-Request/ EAP-Message/EAP-Response/ Identity (MyID) -> <- RADIUS Access-Challenge/ EAP-Message/EAP-Request/ OTP/OTP Challenge <- EAP-Request/ OTP/OTP Challenge EAP-Response/ OTP, OTPpw -> RADIUS Access-Request/ EAP-Message/EAP-Response/ OTP, OTPpw -> <- RADIUS Access-Accept/ EAP-Message/EAP-Success (other attributes) <- EAP-Success Aboba & Calhoun Informational [Page 34]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 In the case where the NAS initiates with an EAP-Request for EAP TLS [RFC2716], but the peer responds with a Nak, indicating that it would prefer another method not implemented locally on the NAS, the exchange will appear as follows: Authenticating peer NAS RADIUS server ------------------- --- ------------- <- EAP-Request/ EAP-Type=EAP-TLS (TLS Start, S bit set) EAP-Response/ EAP-Type=Nak (Alternative(s))-> RADIUS Access-Request/ EAP-Message/EAP-Response/ Nak -> <- RADIUS Access-Challenge/ EAP-Message/EAP-Request/ Identity <- EAP-Request/ Identity EAP-Response/ Identity (MyID) -> RADIUS Access-Request/ EAP-Message/EAP-Response/ (MyID) -> <- RADIUS Access-Challenge/ EAP-Message/EAP-Request OTP/OTP Challenge <- EAP-Request/ OTP/OTP Challenge EAP-Response/ OTP, OTPpw -> RADIUS Access-Request/ EAP-Message/EAP-Response/ OTP, OTPpw -> <- RADIUS Access-Accept/ EAP-Message/EAP-Success (other attributes) <- EAP-Success Aboba & Calhoun Informational [Page 35]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 In the case where the authenticating peer attempts to authenticate the NAS, the conversation would appear as follows: Authenticating Peer NAS RADIUS Server ------------------- --- ------------- EAP-Request/ Challenge, MD5 -> RADIUS Access-Request/ EAP-Message/EAP-Request/ Challenge, MD5 -> <- RADIUS Access-Reject/ EAP-Message/ EAP-Response/ Nak (no alternative) <- EAP-Response/Nak (no alternative) EAP-Failure -> In the case where an invalid EAP Response is inserted by an attacker, the conversation would appear as follows: Authenticating peer NAS RADIUS server ------------------- --- ------------- <- EAP-Request/ EAP-Type=Foo EAP-Response/ EAP-Type=Foo -> RADIUS Access-Request/ EAP-Message/EAP-Response/ EAP-Type=Foo -> <- RADIUS Access-Challenge/ EAP-Message/EAP-Request/ EAP-Type=Foo <- EAP-Request/ EAP-Type=Foo Attacker spoof: EAP-Response/ EAP-Type=Bar -> Good guy: EAP-Response/ EAP-Type=Foo -> RADIUS Access-Request/ EAP-Message/EAP-Response/ EAP-Type=Bar -> Aboba & Calhoun Informational [Page 36]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 <- RADIUS Access-Challenge/ EAP-Message/EAP-Request/ EAP-Type=Foo, Error-Cause="Invalid EAP Packet (Ignored)" RADIUS Access-Request/ EAP-Message/EAP-Response/ EAP-Type=Foo -> <- Access-Accept/ EAP-Message/Success <- EAP Success In the case where the client fails EAP authentication, and an error message is sent prior to disconnection, the conversation would appear as follows: Authenticating peer NAS RADIUS server ------------------- --- ------------- RADIUS Access-Request/ EAP-Message/Start -> <- RADIUS Access-Challenge/ EAP-Message/EAP-Response/ Identity <- EAP-Request/ Identity EAP-Response/ Identity (MyID) -> RADIUS Access-Request/ EAP-Message/EAP-Response/ (MyID) -> <- RADIUS Access-Challenge/ EAP-Message/EAP-Request OTP/OTP Challenge <- EAP-Request/ OTP/OTP Challenge EAP-Response/ OTP, OTPpw -> RADIUS Access-Request/ EAP-Message/EAP-Response/ OTP, OTPpw -> <- RADIUS Access-Challenge/ EAP-Message/EAP-Request/ Notification <- EAP-Request/ Aboba & Calhoun Informational [Page 37]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 Notification EAP-Response/ Notification -> RADIUS Access-Request/ EAP-Message/EAP-Response/ Notification -> <- RADIUS Access-Reject/ EAP-Message/EAP-Failure <- EAP-Failure (client disconnected) In the case that the RADIUS server or proxy does not support EAP- Message, but no error message is sent, the conversation would appear as follows: Authenticating peer NAS RADIUS server ------------------- --- ------------- RADIUS Access-Request/ EAP-Message/Start -> <- RADIUS Access-Reject (User Disconnected) In the case where the local RADIUS server does support EAP-Message, but the remote RADIUS server does not, the conversation would appear as follows: Authenticating peer NAS RADIUS server ------------------- --- ------------- RADIUS Access-Request/ EAP-Message/Start -> <- RADIUS Access-Challenge/ EAP-Message/EAP-Response/ Identity <- EAP-Request/ Identity EAP-Response/ Identity (MyID) -> RADIUS Access-Request/ EAP-Message/EAP-Response/ (MyID) -> <- RADIUS Access-Reject (proxied from remote Aboba & Calhoun Informational [Page 38]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 RADIUS server) (User Disconnected) In the case where PPP is the link and the authenticating peer does not support EAP, but where EAP is required for that user, the conversation would appear as follows: Authenticating peer NAS RADIUS server ------------------- --- ------------- <- PPP LCP Request-EAP auth PPP LCP NAK-EAP auth -> <- PPP LCP Request-CHAP auth PPP LCP ACK-CHAP auth -> <- PPP CHAP Challenge PPP CHAP Response -> RADIUS Access-Request/ User-Name, CHAP-Password -> <- RADIUS Access-Reject <- PPP LCP Terminate (User Disconnected) In the case where PPP is the link, the NAS does not support EAP, but where EAP is required for that user, the conversation would appear as follows: Authenticating peer NAS RADIUS server ------------------- --- ------------- <- PPP LCP Request-CHAP auth PP LCP ACK-CHAP auth -> <- PPP CHAP Challenge PPP CHAP Response -> RADIUS Access-Request/ User-Name, CHAP-Password -> <- RADIUS Access-Reject <- PPP LCP Terminate (User Disconnected) Aboba & Calhoun Informational [Page 39]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 Appendix B - Change log The following changes have been made from RFC 2869: A NAS may simultaneously support both local authentication and pass- through; once the NAS enters pass-through mode within a session, it cannot revert back to local authentication. Also EAP is explicitly described as a 'lock step' protocol. (Section 2). The NAS may initiate with an EAP-Request for an authentication Type. If the Request is NAK'd, the NAS should send an initial Access-Request with an EAP-Message attribute containing an EAP-Response/Nak. The RADIUS server may treat an invalid EAP Response as a non-fatal error (Section 2.2) For use with RADIUS/EAP, the Password-Retry (Section 2.3) and Reply- Message (2.6.5) attributes are deprecated. Each EAP session has a unique Identifier space (Section 2.6.1). Role reversal is not supported (Section 2.6.2). Message combinations (e.g. Access-Accept/EAP-Failure) that conflict are discouraged (Section 2.6.3). EAP-Message attributes are processed last (Section 2.6.4). Only a single EAP packet may be encapsulated within a RADIUS message (Section 3.1). The Originating-Line-Info attribute is supported (Section 3.3) IPsec ESP with non-null transform SHOULD be used and the usage model is described in detail (Section 4.2). Additional discussion of security vulnerabilities (Section 4.1) and potential fixes (Section 4.3). Separated normative (Section 5) and informative (Section 6) references. Added additional examples (Appendix A): a NAS initiating with an EAP- Request for an authentication Type; attempted role reversal. Aboba & Calhoun Informational [Page 40]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 Acknowledgments Thanks to Dave Dawson and Karl Fox of Ascend, Glen Zorn of Cisco Systems, Jari Arkko of Ericsson and Ashwin Palekar, Tim Moore and Narendra Gidwani of Microsoft for useful discussions of this problem space. The authors would also like to acknowledge Tony Jeffree, Chair of IEEE 802.1 for his assistance in resolving RADIUS/EAP issues in IEEE 802.1X-2001. Author's Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: +1 425 706 6605 Fax: +1 425 936 7329 EMail: bernarda@microsoft.com Pat R. Calhoun Airespace 250 Cambridge Avenue, Suite 200 Palo Alto, California, 94306 USA Phone: +1 650-617-2932 Fax: +1 650-786-6445 E-mail: pcalhoun@airespace.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights Aboba & Calhoun Informational [Page 41]
INTERNET-DRAFT RADIUS & EAP 13 April 2003 which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." Open issues Open issues relating to this specification are tracked on the following web site: http://www.drizzle.com/~aboba/EAP/eapissues.html Expiration Date This memo is filed as <draft-aboba-radius-rfc2869bis-15.txt>, and expires October 24, 2003. Aboba & Calhoun Informational [Page 42]
