diff options
Diffstat (limited to 'doc/rfc/rfc3579.txt')
| -rw-r--r-- | doc/rfc/rfc3579.txt | 2579 |
1 files changed, 2579 insertions, 0 deletions
diff --git a/doc/rfc/rfc3579.txt b/doc/rfc/rfc3579.txt new file mode 100644 index 0000000..5eb72c7 --- /dev/null +++ b/doc/rfc/rfc3579.txt @@ -0,0 +1,2579 @@ + + + + + + +Network Working Group B. Aboba +Request for Comments: 3579 Microsoft +Updates: 2869 P. Calhoun +Category: Informational Airespace + September 2003 + + + RADIUS (Remote Authentication Dial In User Service) + Support For Extensible Authentication Protocol (EAP) + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document defines Remote Authentication Dial In User Service + (RADIUS) support for the Extensible Authentication Protocol (EAP), an + authentication framework which supports multiple authentication + mechanisms. In the proposed scheme, the Network Access Server (NAS) + forwards EAP packets to and from the RADIUS server, encapsulated + within EAP-Message attributes. This has the advantage of allowing + the NAS to support any EAP authentication method, without the need + for method-specific code, which resides on the RADIUS server. While + EAP was originally developed for use with PPP, it is now also in use + with IEEE 802. + + This document updates RFC 2869. + + + + + + + + + + + + + + + + + +Aboba & Calhoun Informational [Page 1] + +RFC 3579 RADIUS & EAP September 2003 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Specification of Requirements. . . . . . . . . . . . . . 3 + 1.2. Terminology. . . . . . . . . . . . . . . . . . . . . . . 3 + 2. RADIUS Support for EAP . . . . . . . . . . . . . . . . . . . . 4 + 2.1. Protocol Overview. . . . . . . . . . . . . . . . . . . . 5 + 2.2. Invalid Packets. . . . . . . . . . . . . . . . . . . . . 9 + 2.3. Retransmission . . . . . . . . . . . . . . . . . . . . . 10 + 2.4. Fragmentation. . . . . . . . . . . . . . . . . . . . . . 10 + 2.5. Alternative uses . . . . . . . . . . . . . . . . . . . . 11 + 2.6. Usage Guidelines . . . . . . . . . . . . . . . . . . . . 11 + 3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 3.1. EAP-Message. . . . . . . . . . . . . . . . . . . . . . . 15 + 3.2. Message-Authenticator. . . . . . . . . . . . . . . . . . 16 + 3.3. Table of Attributes. . . . . . . . . . . . . . . . . . . 18 + 4. Security Considerations. . . . . . . . . . . . . . . . . . . . 19 + 4.1. Security Requirements. . . . . . . . . . . . . . . . . . 19 + 4.2. Security Protocol. . . . . . . . . . . . . . . . . . . . 20 + 4.3. Security Issues. . . . . . . . . . . . . . . . . . . . . 22 + 5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 30 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 + 6.1. Normative References . . . . . . . . . . . . . . . . . . 30 + 6.2. Informative References . . . . . . . . . . . . . . . . . 32 + Appendix A - Examples. . . . . . . . . . . . . . . . . . . . . . . 34 + Appendix B - Change Log. . . . . . . . . . . . . . . . . . . . . . 43 + Intellectual Property Statement. . . . . . . . . . . . . . . . . . 44 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 44 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 46 + +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, 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 bridges supporting [IEEE802]. EAP + encapsulation on IEEE 802 wired media is described in [IEEE8021X]. + + + +Aboba & Calhoun Informational [Page 2] + +RFC 3579 RADIUS & EAP September 2003 + + + RADIUS attributes are comprised of variable length Type-Length-Value + 3-tuples. New attribute values can be added without disturbing + existing implementations of the protocol. 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. + +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]. + +1.2. Terminology + + This document frequently uses the following terms: + + authenticator + The end of the link requiring the authentication. Also + known as the Network Access Server (NAS) or RADIUS client. + Within IEEE 802.1X terminology, the term Authenticator is + used. + + 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. + + authentication server + An authentication server is an entity that provides an + authentication service to an authenticator (NAS). This + service verifies from the credentials provided by the peer, + the claim of identity made by the peer; it also may provide + credentials allowing the peer to verify the identity of the + authentication server. Within this document it is assumed + that the NAS operates as a pass-through, forwarding EAP + packets between the RADIUS server and the EAP peer. + + + +Aboba & Calhoun Informational [Page 3] + +RFC 3579 RADIUS & EAP September 2003 + + + Therefore the RADIUS server operates as an authentication + server. + + 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. 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 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 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 the NAS to be upgraded to support each + new method. 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. + + + +Aboba & Calhoun Informational [Page 4] + +RFC 3579 RADIUS & EAP September 2003 + + + A NAS MAY authenticate local peers while at the same time acting as a + pass-through for non-local peers 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. + + The peer replies with an EAP-Response. The NAS MAY determine from + the Response that it should proceed with local authentication. + Alternatively, the NAS MAY act as a pass-through, encapsulating the + EAP-Response within EAP-Message attribute(s) sent to the RADIUS + server 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 peer + 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. + + + +Aboba & Calhoun Informational [Page 5] + +RFC 3579 RADIUS & EAP September 2003 + + + 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 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. The NAS MUST NOT + "manufacture" a Success or Failure packet as the result of a timeout. + After a suitable number of timeouts have elapsed, the NAS SHOULD + instead end the EAP conversation. + + 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 is not available to the RADIUS server. For the RADIUS server + to be able to continue the conversation, either the initial + EAP-Request is vestigial, so that the RADIUS server need not be aware + of it, or the relevant information from the initial EAP-Request (such + as a nonce) is reflected in the initial EAP-Response, so that the + RADIUS server can obtain it without having received the initial + EAP-Request. + + 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. + + + + + + +Aboba & Calhoun Informational [Page 6] + +RFC 3579 RADIUS & EAP September 2003 + + + In order to evaluate whether the alternatives preferred by the + authenticating 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 peer 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 result in many authentication + exchanges that cannot complete successfully. For example, on + wired networks [IEEE8021X] Supplicants typically do not initiate + the 802.1X conversation with an EAPOL-Start. Therefore an IEEE + 802.1X-enabled bridge may not be able to determine whether the + peer supports EAP until it receives a Response to the initial + EAP-Request. + + [3] It allows some peers to be authenticated locally. + + + + + + +Aboba & Calhoun Informational [Page 7] + +RFC 3579 RADIUS & EAP September 2003 + + + 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 peer 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 peer 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] + +RFC 3579 RADIUS & EAP September 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. + + Since EAP method fields (Type, Type-Data) are typically not validated + by a NAS operating as a pass-through, despite these checks 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 EAP-Message + attribute(s) as well as an Error-Cause attribute [RFC3576] 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 NAS implementing previous + versions of this specification will decapsulate the EAP-Request and + send it to the 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, and the EAP-Message attribute(s) + included within the Access-Challenge are silently discarded. If no + EAP-Response packet is available, then the EAP-Request encapsulated + within the Access-Challenge is sent to the peer, and the + retransmission timer is reset. + + + + + + +Aboba & Calhoun Informational [Page 9] + +RFC 3579 RADIUS & EAP September 2003 + + + 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 recommended. + +2.3. Retransmission + + As noted in [RFC2284], if an EAP packet is lost in transit between + the authenticating peer and the NAS (or vice versa), the NAS will + retransmit. + + 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. For example, as noted in + [RFC3580] Section 3.10, for a NAS-Port-Type value of IEEE 802.11, the + + + + + +Aboba & Calhoun Informational [Page 10] + +RFC 3579 RADIUS & EAP September 2003 + + + RADIUS server may send an EAP packet as large as Framed-MTU minus + four (4) octets, taking into account the additional overhead for the + IEEE 802.1X Version (1), Type (1) and Body Length (2) fields. + +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- 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 + 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. + +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 + + + + +Aboba & Calhoun Informational [Page 11] + +RFC 3579 RADIUS & EAP September 2003 + + + 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 + + The NAS MUST make its access control decision based solely on the + RADIUS Packet Type (Access-Accept/Access-Reject). The access control + decision MUST NOT be based on the contents of the EAP packet + encapsulated in one or more EAP-Message attributes, if present. + + Access-Accept packets SHOULD have only one EAP-Message attribute in + them, containing EAP Success; similarly, Access-Reject packets SHOULD + have only one EAP-Message attribute in them, containing EAP Failure. + + 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, 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 for the + session. As a result, the RADIUS server will not indicate to the NAS + whether to allow or deny access, while the peer will be informed as + to the outcome of the authentication. + + + + + + + + + + +Aboba & Calhoun Informational [Page 12] + +RFC 3579 RADIUS & EAP September 2003 + + + 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 + server, the NAS MUST NOT "manufacture" EAP packets in order to + correct contradictory messages that it receives. This behavior, + originally mandated within [IEEE8021X], will be deprecated in the + future. + +2.6.4. Priority + + A RADIUS Access-Accept or Access-Reject packet may contain EAP- + Message attribute(s). In order to ensure the correct processing of + RADIUS packets, the NAS MUST first process the attributes, including + the EAP-Message attribute(s), prior to processing the Accept/Reject + indication. + +2.6.5. Displayable Messages + + The Reply-Message attribute, defined in [RFC2865], Section 5.18, + indicates text which may be displayed to the peer. 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: + + + + + + +Aboba & Calhoun Informational [Page 13] + +RFC 3579 RADIUS & EAP September 2003 + + + [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. + + [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, rather + than attempting to translate it to an EAP Notification Request. + +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. The User-Name attribute within the Access- + Accept packet need not be the same as the User-Name attribute in the + Access-Request. + + + + + + +Aboba & Calhoun Informational [Page 14] + +RFC 3579 RADIUS & EAP September 2003 + + +3.1. EAP-Message + + Description + + This attribute encapsulates EAP [RFC2284] packets so as to allow + the NAS to authenticate peers 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-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 provide + per-packet authentication and 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 MUST 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. + + + + + +Aboba & Calhoun Informational [Page 15] + +RFC 3579 RADIUS & EAP September 2003 + + + 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 MUST 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 + + 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. + + + + + + +Aboba & Calhoun Informational [Page 16] + +RFC 3579 RADIUS & EAP September 2003 + + + 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. + + This attribute is not required in Access-Requests which include + the User-Password attribute, 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. + + 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. + + 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. + + + + + + + +Aboba & Calhoun Informational [Page 17] + +RFC 3579 RADIUS & EAP September 2003 + + + 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. + +3.3. Table of Attributes + + The following table provides a guide to which attributes may be found + in packets including EAP-Message attribute(s), and in what quantity. + The EAP-Message and Message-Authenticator attributes specified in + this document MUST NOT be present in an Accounting-Request. If a + table entry is omitted, the values found in [RFC2548], [RFC2865], + [RFC2868], [RFC2869] and [RFC3162] should be assumed. + +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 0 0 0 18 Reply-Message +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 101 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. A RADIUS + server receiving an Access-Request not containing any of those four + attributes and also not containing a Message-Authenticator attribute + SHOULD silently discard it. + + + + +Aboba & Calhoun Informational [Page 18] + +RFC 3579 RADIUS & EAP September 2003 + + + [Note 2] The Error-Cause attribute is defined in [RFC3576]. + + [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 potential targets of an attack. + Threats are discussed in [RFC2607], [RFC2865], and [RFC3162]. + Examples include: + + [1] An adversary may attempt to acquire confidential data and + 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 peer + passwords. + + [8] An authenticated NAS may attempt to forge NAS or session + identification attributes, + + [9] A rogue (unauthenticated) NAS may attempt to impersonate a + legitimate NAS. + + + +Aboba & Calhoun Informational [Page 19] + +RFC 3579 RADIUS & EAP September 2003 + + + [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 vulnerabilities of 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 IPsec ESP with a + non-null encryption transform and authentication support SHOULD be + used to provide per-packet confidentiality, authentication, integrity + and replay protection. IKE SHOULD be used 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 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, per-packet authentication, + integrity and replay protection MUST be used. 3DES-CBC MUST be + supported as an encryption transform and AES-CBC SHOULD be supported. + AES-CBC SHOULD be offered as a preferred encryption transform if + supported. HMAC-SHA1-96 MUST be supported as an authentication + transform. DES-CBC SHOULD NOT be used as the encryption transform. + + + + + + +Aboba & Calhoun Informational [Page 20] + +RFC 3579 RADIUS & EAP September 2003 + + + 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 the RADIUS client and server perform + an authorization check. Before enabling a host to act as a RADIUS + client, the RADIUS server SHOULD check whether the host is authorized + to provide network access. Similarly, before enabling a 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 + Certification Authority (CA) exists for RADIUS clients, then the + RADIUS server can configure this CA as a trust anchor [RFC3280] for + use with IPsec. + + 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 trust anchor 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 deployments + 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), IKE Main Mode with pre-shared keys + [RFC2409] SHOULD NOT be used, since this requires use of a group + + + +Aboba & Calhoun Informational [Page 21] + +RFC 3579 RADIUS & EAP September 2003 + + + 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]. + +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 + Spoofing and hijacking + Dictionary attacks + Known plaintext attacks + Replay attacks + Negotiation attacks + Impersonation + Man in the middle attacks + Separation of authenticator and authentication server + Multiple databases + + + + + + + +Aboba & Calhoun Informational [Page 22] + +RFC 3579 RADIUS & EAP September 2003 + + +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 + peers 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 [RFC826] 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 peer location information, or which it can + subject to a known plaintext or 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, as described in Section 4.2. + +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 the NAS and RADIUS + server is used. Access-Request packets with CHAP-Password or + EAP-Message attributes do not have a User-Password attribute. As a + result, 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. + + 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. As described in [RFC2865], + only Access-Reply and Access-Challenge packets are integrity + protected. Moreover, the per-packet authentication and integrity + protection mechanism described in [RFC2865] has known weaknesses + [MD5Attack], making it a tempting target for attackers looking to + subvert RADIUS/EAP. + + To provide stronger security, the Message-Authenticator attribute + MUST be used in all RADIUS packets containing an EAP-Message + attribute. Implementations of this specification SHOULD use IPsec + ESP with non-null transform and per-packet encryption, + authentication, integrity and replay protection, as described in + Section 4.2. + + + +Aboba & Calhoun Informational [Page 23] + +RFC 3579 RADIUS & EAP September 2003 + + +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 + RADIUS/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-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. + + + + + + +Aboba & Calhoun Informational [Page 24] + +RFC 3579 RADIUS & EAP September 2003 + + + 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 utilizing the + User-Password attribute, 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 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 + + + +Aboba & Calhoun Informational [Page 25] + +RFC 3579 RADIUS & EAP September 2003 + + + 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 be 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-peer 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. + + 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 + + + +Aboba & Calhoun Informational [Page 26] + +RFC 3579 RADIUS & EAP September 2003 + + + 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 a peer 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 peer 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 peer. 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 peer connecting from one + location (with an EAP-capable proxy) might be able to successfully + authenticate via EAP, while the same peer connecting at another + location (and encountering an EAP-incapable proxy) might be + consistently disconnected. + +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. + + + + +Aboba & Calhoun Informational [Page 27] + +RFC 3579 RADIUS & EAP September 2003 + + + 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 [RFC3576] 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 parameters, + 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 peer; + similarly, the 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 28] + +RFC 3579 RADIUS & EAP September 2003 + + +4.3.8. Man in the Middle Attacks + + RADIUS only provides security on a hop-by-hop basis, even where IPsec + is used. 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 per-packet integrity + protection and authentication mechanisms. + +4.3.9. Separation of Authenticator and Authentication Server + + As noted in [RFC2716], 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 and authentication server may not reside on the same + host. + + In the case where the authenticator and authentication server reside + on different machines, there are several implications for security. + First, mutual authentication will occur between the peer and the + authentication 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.2, when RADIUS/EAP 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 RADIUS + Access-Requests containing an EAP-Message attribute 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 containing an EAP-Message attribute 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. + + + +Aboba & Calhoun Informational [Page 29] + +RFC 3579 RADIUS & EAP September 2003 + + + The second issue that arises where the authenticator and + authentication server reside on separate hosts is that the EAP Master + Session Key (MSK) negotiated between the peer and authentication + server will need to be transmitted to the authenticator. Therefore a + mechanism needs to be provided to transmit the MSK from the + authentication server to the NAS or tunnel server that needs it. The + specification of the key transport and wrapping mechanism is outside + the scope of this document. However, it is expected that the + wrapping mechanism will provide confidentiality, integrity and replay + protection, and data origin authentication. + +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. References + +6.1. 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. + + + + +Aboba & Calhoun Informational [Page 30] + +RFC 3579 RADIUS & EAP September 2003 + + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible + Authentication Protocol (EAP)", RFC 2284, March 1998. + + [RFC2401] Atkinson, R. and S. Kent, "Security Architecture for + the Internet Protocol", RFC 2401, November 1998. + + [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security + Payload (ESP)", RFC 2406, November 1998. + + [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange + (IKE)", RFC 2409, November 1998. + + [RFC2486] Aboba, B. and M. Beadles, "The Network Access + Identifier", RFC 2486, January 1999. + + [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, + "Remote Authentication Dial In User Service (RADIUS)", + RFC 2865, June 2000. + + [RFC2988] Paxson, V. and M. Allman, "Computing TCP's + Retransmission Timer", RFC 2988, November 2000. + + [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IP6", + RFC 3162, August 2001. + + [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet + X.509 Public Key Infrastructure Certificate and + Certificate Revocation List (CRL) Profile", RFC 3280, + April 2002. + + [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. + + + + + + + + + + + +Aboba & Calhoun Informational [Page 31] + +RFC 3579 RADIUS & EAP September 2003 + + +6.2. Informative References + + [RFC826] Plummer, D., "An Ethernet Address Resolution + Protocol", STD 37, RFC 826, November 1982. + + [RFC1510] Kohl, J. and C. Neuman, "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. and J. Vollbrecht, "Proxy Chaining and + Policy Implementation in Roaming", RFC 2607, June + 1999. + + [RFC2716] Aboba, B. and D. Simon,"PPP EAP TLS Authentication + Protocol", RFC 2716, October 1999. + + [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. + + [RFC2983] Black, D. "Differentiated Services and Tunnels", RFC + 2983, October 2000. + + [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. + + [IEEE802] IEEE Standards for Local and Metropolitan Area + Networks: Overview and Architecture, ANSI/IEEE Std + 802, 1990. + + + + + +Aboba & Calhoun Informational [Page 32] + +RFC 3579 RADIUS & EAP September 2003 + + + [IEEE8021X] IEEE Standards for Local and Metropolitan Area + Networks: Port based Network Access Control, IEEE Std + 802.1X-2001, June 2001. + + [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent + Attack", CryptoBytes Vol.2 No.2, Summer 1996. + + [Masters] Slatalla, M. and J. Quittner, "Masters of Deception." + HarperCollins, New York, 1995. + + [NASREQ] Calhoun, P., et al., "Diameter Network Access Server + Application", Work in Progress. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Aboba & Calhoun Informational [Page 33] + +RFC 3579 RADIUS & EAP September 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 34] + +RFC 3579 RADIUS & EAP September 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) + + + + + + + +Aboba & Calhoun Informational [Page 35] + +RFC 3579 RADIUS & EAP September 2003 + + +EAP-Response/ +EAP-Type=EAP-TLS -> + RADIUS Access-Request/ + EAP-Message/EAP-Response/ + 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 36] + +RFC 3579 RADIUS & EAP September 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 37] + +RFC 3579 RADIUS & EAP September 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 -> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Aboba & Calhoun Informational [Page 38] + +RFC 3579 RADIUS & EAP September 2003 + + + 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 -> + + <- 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 + + + + + + + + + + +Aboba & Calhoun Informational [Page 39] + +RFC 3579 RADIUS & EAP September 2003 + + + 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/ + Notification + +EAP-Response/ +Notification -> + RADIUS Access-Request/ + EAP-Message/EAP-Response/ + Notification -> + <- RADIUS + Access-Reject/ + EAP-Message/EAP-Failure + <- EAP-Failure + (client disconnected) + + + + +Aboba & Calhoun Informational [Page 40] + +RFC 3579 RADIUS & EAP September 2003 + + + 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 + RADIUS server) + (User Disconnected) + + + + + + + + + + + + +Aboba & Calhoun Informational [Page 41] + +RFC 3579 RADIUS & EAP September 2003 + + + 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 42] + +RFC 3579 RADIUS & EAP September 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). + + Only a single EAP packet may be encapsulated within a RADIUS message + (Section 3.1). + + An Access-Request lacking explicit authentication as well as a + Message- Authenticator attribute SHOULD be silently discarded + (Section 3.3). + + 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 6.1) and informative (Section 6.2) + references. + + + + + + + +Aboba & Calhoun Informational [Page 43] + +RFC 3579 RADIUS & EAP September 2003 + + + Added additional examples (Appendix A): a NAS initiating with an + EAP-Request for an authentication Type; attempted role reversal. + +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 which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + +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. + + + + + + + + + + + + + + + + + + +Aboba & Calhoun Informational [Page 44] + +RFC 3579 RADIUS & EAP September 2003 + + +Authors' 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 + 110 Nortech Parkway + San Jose, California, 95134 + USA + + Phone: +1 408 635 2023 + Fax: +1 408 635 2020 + EMail: pcalhoun@airespace.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Aboba & Calhoun Informational [Page 45] + +RFC 3579 RADIUS & EAP September 2003 + + +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 assignees. + + 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Aboba & Calhoun Informational [Page 46] + |