Network Working Group B. Aboba INTERNET-DRAFT Microsoft Category: Informational P. Calhoun Black Storm Networks 27 May 2002 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 (2002). All Rights Reserved. Abstract This document defines RADIUS support for the Extensible Authentication Protocol (EAP), an authentication protocol which supports multiple authentication mechanisms. While EAP was originally developed for use with PPP, it is also now in use with IEEE 802. This document updates RFC 2869. Aboba & Calhoun Informational [Page 1] INTERNET-DRAFT RADIUS & EAP 27 May 2002 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 Retransmission .................................. 7 2.3 Fragmentation ................................... 7 2.4 Alternative uses ................................ 7 2.5 Usage guidelines ................................ 8 3. Attributes ............................................ 10 3.1 Password-Retry .................................. 10 3.2 EAP-Message ..................................... 11 3.3 Message-Authenticator ........................... 12 3.4 Table of attributes ............................. 14 4. Security considerations ............................... 14 4.1 Message-Authenticator Security .................. 15 4.2 EAP Security .................................... 15 5. Normative references .................................. 18 6. Informative references ................................ 19 Appendix A - Examples ........................................ 21 ACKNOWLEDGMENTS .............................................. 25 AUTHORS' ADDRESSES ........................................... 25 Full Copyright Statement ..................................... 25 Aboba & Calhoun Informational [Page 2] INTERNET-DRAFT RADIUS & EAP 27 May 2002 1. Introduction [RFC2865] describes the RADIUS Protocol as it is implemented and deployed today, and [RFC2866] describes how Accounting can be performed with RADIUS. The Extensible Authentication Protocol (EAP) is a general protocol for authentication 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 and access points using IEEE 802 [IEEE802]. EAP encapsulation on IEEE 802 media is described in [IEEE8021X]. This memo suggests several additional Attributes that can be added to RADIUS to support the Extensible Authentication Protocol (EAP). These Attributes now have extensive field experience, and so the purpose of this document is to clarify interoperability issues. The Extensible Authentication Protocol (EAP) [RFC2284bis] is an extension that provides support for additional authentication methods. This memo describes how the EAP-Message and Message- Authenticator attributes may be used for providing EAP support within RADIUS. 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]. An implementation is not compliant if it fails to satisfy one or more of the must or must not requirements for the protocols it implements. An implementation that satisfies all the must, must not, should and should not requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the must and must not requirements but not all the should or should not requirements for its protocols is said to be "conditionally compliant." Aboba & Calhoun Informational [Page 3] INTERNET-DRAFT RADIUS & EAP 27 May 2002 A NAS that does not implement a given service MUST NOT implement the RADIUS attributes for that service. For example, a NAS that is unable to offer EAP service MUST NOT implement the RADIUS attributes for EAP. A NAS MUST treat a RADIUS access-request requesting an unavailable service as an access-reject instead. 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 802.11 wireless link, which 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. 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 (802.11) 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 [RFC2044]. Service The NAS provides a service to the user, such as IEEE 802 or PPP. Session Each service provided by the NAS to a user constitutes a session, with the beginning of the session defined as the point where service is first provided and the end of the Aboba & Calhoun Informational [Page 4] INTERNET-DRAFT RADIUS & EAP 27 May 2002 session defined as the point where service is ended. A user 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 [RFC2284bis], provides a standard mechanism for support of additional authentication methods. 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, and others. In order to provide for support of 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. In the proposed scheme, the RADIUS server is used to shuttle RADIUS- encapsulated EAP Packets between the NAS and a backend security server. While the conversation between the RADIUS server and the backend security server will typically occur using a proprietary protocol developed by the backend security server vendor, it is also possible to use RADIUS-encapsulated EAP via the EAP-Message attribute. This has the advantage of allowing the RADIUS server to support EAP without the need for authentication-specific code, which can instead reside on the backend security server. 2.1. Protocol Overview The EAP conversation between the authenticating peer and the NAS begins with the negotiation of EAP. Once EAP has been negotiated, the NAS SHOULD send an EAP-Request/Identity message to the authenticating peer, unless the identity exchange is postponed until later or the identity is determined via some other means such as Called-Station-Id or Calling- Station-Id. The peer will then respond with an EAP-Response/Identity which the the NAS will then forward to the RADIUS server in the EAP- Message attribute of a RADIUS Access-Request packet. The RADIUS Server will typically use the EAP-Response/Identity to determine which EAP type is to be applied to the user. In order to permit non-EAP aware RADIUS proxies to forward the Access- Request packet, if the NAS sends the EAP-Request/Identity, the NAS MUST copy the contents of the Type-Data field of the EAP-Response/Identity 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. NAS-Port or NAS-Port-Id SHOULD be included in the attributes issued by the NAS in the Access-Request packet, and either NAS-Identifier or NAS-IP- Address MUST be included. In order to permit Aboba & Calhoun Informational [Page 5] INTERNET-DRAFT RADIUS & EAP 27 May 2002 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 very difficult to manage. If identity is determined via another means such as Called-Station-Id or Calling-Station-Id, the NAS MUST include these identifying attributes in every Access-Request. While this approach will save a round-trip, it cannot be universally employed. There are circumstances in which the user's identity may not be needed (such as when authentication and accounting is handled based on Called-Station-Id or Calling-Station-Id), and therefore an EAP- Request/Identity packet may not necessarily be issued by the NAS to the authenticating peer. In cases where an EAP-Request/Identity packet will not be sent, the NAS will send to the RADIUS server a RADIUS Access- Request packet containing an EAP-Message attribute signifying EAP-Start. EAP-Start is indicated by sending an EAP- Message attribute with a length of 2 (no data). However, it should be noted that since no User- Name attribute is included in the Access- Request, this approach is not compatible with RADIUS as specified in [RFC2865], nor can it easily be applied in situations where proxies are deployed, such as roaming or shared use networks. If the RADIUS server supports EAP, it MUST respond with an Access- Challenge packet containing an EAP-Message attribute. If the RADIUS server does not support EAP, it MUST respond with an Access-Reject. The EAP-Message attribute includes an encapsulated EAP packet which is then passed on to the authenticating peer. In the case where the NAS does not initially send an EAP-Request/Identity message to the peer, the Access-Challenge typically will contain an EAP-Message attribute encapsulating an EAP-Request/Identity message, requesting the dial-in user to identify themself. The NAS will then respond with a RADIUS Access-Request packet containing an EAP-Message attribute encapsulating an EAP-Response. The conversation continues until either a RADIUS Access-Reject or Access-Accept packet is received. 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 above scenario creates a situation in which the NAS never needs to manipulate an EAP packet. An alternative may be used in situations where an EAP-Request/Identity message will always be sent by the NAS to the authenticating peer. Aboba & Calhoun Informational [Page 6] INTERNET-DRAFT RADIUS & EAP 27 May 2002 For proxied RADIUS requests there are two methods of processing. If the domain is determined based on the Called-Station-Id, the RADIUS Server may proxy the initial RADIUS Access-Request/EAP-Start. If the domain is determined based on the user's identity, the local RADIUS Server MUST respond with a RADIUS Access-Challenge/EAP-Identity packet. The response from the authenticating peer MUST be proxied to the final authentication server. For proxied RADIUS requests, the NAS may receive an Access-Reject packet in response to its Access-Request/EAP-Identity packet. This would occur if the message was proxied to a RADIUS Server which does not support the EAP-Message extension. On receiving an Access-Reject, the NAS MUST deny access to the authenticating peer. 2.2. Retransmission As noted in [RFC2284bis], the EAP authenticator (NAS) is responsible for retransmission of packets between the authenticating peer and the NAS. Thus 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. Note that 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 and Password-Retry attributes 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 provides the NAS with the maximum number of seconds the NAS should wait for an EAP- Response before retransmitting the EAP-Message to the dial-in user. 2.3. 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. Aboba & Calhoun Informational [Page 7] INTERNET-DRAFT RADIUS & EAP 27 May 2002 2.4. Alternative uses Currently the conversation between the backend security server and the RADIUS server is proprietary because of lack of standardization. In order to increase standardization and provide interoperability between Radius vendors and backend 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 backend security server instead. In the case where RADIUS-encapsulated EAP is used in a conversation between a RADIUS server and a backend security server, the security server will typically return an Access-Accept/EAP-Success 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/EAP-Success message to the NAS. 2.5. Usage guidelines 2.5.1. Conflicting messages In some cases, the authentication result implied by the encapsulated EAP packet may not match the result communicated in the RADIUS message. For example, and EAP Failure packet may be encapsulated within an Access- Accept message and an EAP Success packet may be encapsulated within an Access-Reject. Alternatively, no EAP-Message attribute may be included within an Access-Accept or Access-Reject. Such combinations are 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 Success, the Peer will be lead to believe that it authenticated successfully. Similarly, if the NAS receives an Access- Accept with an encapsulated EAP Failure, it will grant access to the Peer. However, on receiving a 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 [RFC2284bis], 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 Aboba & Calhoun Informational [Page 8] INTERNET-DRAFT RADIUS & EAP 27 May 2002 response will be received, and therefore no further Access-Requests will be sent 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 RADIUS server SHOULD check to make sure that the results implied by an encapsulated EAP-Message attribute and the RADIUS message are in agreement. The following combinations SHOULD NOT be sent by a RADIUS server as part of an EAP conversation: Access-Accept/EAP-Message/EAP-Failure Access-Accept/no EAP-Message attribute Access-Reject/EAP-Message/EAP-Success Access-Reject/no EAP-Message attribute Access-Challenge/EAP-Message/EAP-Success Access-Challenge/EAP-Message/EAP-Failure Since the responsibility for avoiding these conflicts lies with the RADIUS server, the NAS MUST NOT "manufacture" EAP packets in order to correct contradictory messages that it receives. 2.5.2. 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, the NAS SHOULD process EAP-Message attributes last. 2.5.3. Displayable messages The Reply-Message attribute, defined in section 5.18 of [RFC2865], indicates text which MAY be displayed to the user. This is similar in concept to the EAP Notification Type, defined in [RFC2284]. When sending a displayable message to a NAS during an EAP conversation, the RADIUS server SHOULD encapsulate displayable messages within EAP- Message/EAP-Request/Notification attribute(s), and SHOULD NOT use Reply- Message attribute(s) for this purpose. A NAS receiving Reply-Message attribute(s) MAY copy the Text field(s) into the Type-Data field of an EAP-Request/Notification packet, fill in the Identifier field, and send this to the Peer. However, several issues may 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. Aboba & Calhoun Informational [Page 9] INTERNET-DRAFT RADIUS & EAP 27 May 2002 For example, consider what happens when a Reply-Message is included within an Access-Accept or Access-Reject packet with no EAP-Message attribute 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. [2] Identifier conflicts. While the EAP-Request/Notification contains an an Identifier, a Reply-Message attribute does not. 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. It is possible that the chosen Identifier will conflict with a value chosen by the RADIUS server for another packet within the EAP conversation. This would violate the requirement in [RFC2284bis] that Identifier values be unique within an EAP conversation. 2.5.4. Multiple EAP-Message attributes An Access-Challenge, Access-Accept, Access-Reject or Access-Request message MAY contain zero or more EAP-Message attributes. However, 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. Since EAP is a "lockstep" protocol, a new EAP-Request cannot be sent until an EAP- Response is received to an outstanding request and only a single Request can be outstanding at a given time. As a result, 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. When used within an EAP conversation, a Reply-Message attribute received by the NAS MAY be translated to an EAP-Request/Notification sent to the peer. As a result, a Reply-Message attribute MUST NOT be included in a RADIUS message containing an EAP-Message attribute. An EAP-Message/EAP- Request/Notification or Reply-Message attribute SHOULD NOT be included within an Access-Accept or Access-Reject packet representing the conclusion of an EAP conversation. 3. Attributes 3.1. Password-Retry Description This attribute MAY be included in an Access-Reject to indicate how Aboba & Calhoun Informational [Page 10] INTERNET-DRAFT RADIUS & EAP 27 May 2002 many authentication attempts a user may be allowed to attempt before being disconnected. A summary of the Password-Retry attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 75 for Password-Retry. Length 6 Value The Value field is four octets, containing an integer specifying the number of password retry attempts to permit the user. 3.2. EAP-Message Description This attribute encapsulates Extended Access Protocol [RFC2284bis] packets so as to allow the NAS to authenticate dial-in users via EAP without having to understand the EAP protocol. The NAS places any EAP messages received from the user into one or more EAP attributes and forwards them to the RADIUS Server as part of the Access-Request, which can return EAP messages in Access- Challenge, Access-Accept and Access-Reject packets. A RADIUS Server receiving EAP messages that it does not understand SHOULD return an Access-Reject. 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- Messages are contained within an Access-Request or Access- Challenge packet, they MUST be in order and they MUST be consecutive attributes Aboba & Calhoun Informational [Page 11] INTERNET-DRAFT RADIUS & EAP 27 May 2002 in the Access-Request or Access-Challenge packet. Access-Accept and Access-Reject packets SHOULD only have ONE EAP-Message attribute in them, containing EAP-Success or EAP- Failure. 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 the EAP-Success or EAP-Failure packets) it is necessary that RADIUS/EAP provide integrity protection at least as strong as those used in the EAP methods themselves. 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 an EAP-Message attribute without a Message-Authenticator attribute SHOULD be silently discarded by the RADIUS server. A RADIUS Server supporting EAP-Message 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 EAP-Message MUST return an Access- Reject if it receives an Access-Request containing an EAP-Message attribute. A RADIUS Server receiving an EAP-Message attribute that it does not understand MUST return an Access-Reject. Access-Challenge, Access-Accept, or Access-Reject packets including an EAP-Message attribute without a Message-Authenticator attribute SHOULD be silently discarded by the NAS. A NAS supporting EAP-Message 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 Aboba & Calhoun Informational [Page 12] INTERNET-DRAFT RADIUS & EAP 27 May 2002 String The String field contains EAP packets, as defined in [3]. 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 passed by RADIUS. 3.3. 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, Aboba & Calhoun Informational [Page 13] INTERNET-DRAFT RADIUS & EAP 27 May 2002 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 hash 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 hash is calculated the signature string should be considered to be sixteen octets of zero. The shared secret is used as the key for the HMAC-MD5 hash. The is calculated and inserted in the packet before the Response Authenticator is calculated. 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. IP Security will eventually make this attribute unnecessary, so it should be considered an interim measure. 3.4. Table of Attributes The following table provides a guide to which attributes may be found in which kind of packets. The attributes added in this document must not be present in an Accounting-Request. Request Accept Reject Challenge # Attribute 0 0 0-1 0 75 Password-Retry 0+ 0+ 0+ 0+ 79 EAP-Message [Note 1] 0-1 0-1 0-1 0-1 80 Message-Authenticator [Note 1] Request Accept Reject Challenge # Attribute [Note 1] An Access-Request that contains either a User-Password or CHAP- Aboba & Calhoun Informational [Page 14] INTERNET-DRAFT RADIUS & EAP 27 May 2002 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. The following table defines 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. 4. Security Considerations The attributes other than Message-Authenticator and EAP-Message in this document have no additional security considerations beyond those already identified in [RFC2865]. 4.1. Message-Authenticator Security Access-Request packets with a User-Password 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 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, in order to establish the identity of the NAS sending the request. Note that the Message-Authenticator attribute may be subjected to an offline dictionary attack in order to recover the RADIUS shared secret. As noted in [RFC2645]: 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. 4.2. EAP Security Since the purpose of EAP is to provide enhanced security for authentication, it is critical that RADIUS support for EAP be secure. In particular, the following issues must be addressed: Separation of EAP server and PPP authenticator Connection hijacking Man in the middle attacks Multiple databases Negotiation attacks Aboba & Calhoun Informational [Page 15] INTERNET-DRAFT RADIUS & EAP 27 May 2002 4.2.1. Separation of EAP server and authenticator It is possible for the EAP endpoints to mutually authenticate, negotiate a ciphersuite, and derive a session key for use in a ciphersuite. 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 pass the session key to the ciphersuite module. The situation is more complex when EAP is used with RADIUS, since the authenticator will typically not reside on the same machine as the EAP server. For example, the EAP server may be a backend security server, or a module residing on the RADIUS server. In the case where the EAP server and authenticator reside on different machines, there are several implications for security. Firstly, 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. As described earlier, when EAP/RADIUS is used to encapsulate EAP packets, the Message-Authenticator attribute is required in EAP/RADIUS Access-Requests sent from the NAS or tunnel server to the RADIUS server. Since the Message-Authenticator attribute involves a HMAC-MD5 hash, 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. Similarly, Access-Challenge packets sent from the RADIUS server to the NAS are also authenticated and integrity protected using an HMAC-MD5 hash, enabling the NAS or tunnel server to determine the integrity of the packet and verify the identity of the RADIUS server. Moreover, EAP packets sent via 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 session key 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 session key from the EAP server to the authenticator or tunnel server that needs to use the key. The specification of this transit mechanism is outside the scope of this document. 4.2.2. Connection hijacking In this form of attack, the attacker attempts to inject packets into the conversation between the NAS and the RADIUS server, or between the RADIUS server and the backend security server. RADIUS does not support encryption, and as described in [RFC2865], only Access-Reply and Access- Aboba & Calhoun Informational [Page 16] INTERNET-DRAFT RADIUS & EAP 27 May 2002 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 EAP/RADIUS packets MUST be authenticated using the Message-Authenticator attribute, as described previously. 4.2.3. Man in the middle attacks Since RADIUS security is based on shared secrets, end-to-end security is not provided in the case where authentication or accounting packets are forwarded along a proxy chain. As a result, attackers gaining control of a RADIUS proxy will be able to modify EAP packets in transit. 4.2.4. Multiple databases In many cases a backend security server will be deployed along with a RADIUS server in order to provide EAP services. Unless the backend 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 backend 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 backend security server store information in the same backend database; by having the backend security server provide a full RADIUS implementation; or by consolidating both the backend security server and the RADIUS server onto the same machine. 4.2.5. Negotiation attacks In a negotiation attack, a rogue NAS, tunnel server, RADIUS proxy or RADIUS server causes the authenticating peer to choose a less secure authentication method so as to make it easier to obtain the user's password. 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 one EAP type occurs via a less secure EAP type, such as MD5. The threat posed by rogue devices, once thought to be remote, has gained currency given compromises of telephone company switching systems, such as those Aboba & Calhoun Informational [Page 17] INTERNET-DRAFT RADIUS & EAP 27 May 2002 described in [Masters]. Protection against negotiation attacks requires the elimination of downward negotiations. This can be achieved 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 EAP when calling one service, while negotiating CHAP for another service, even if both services are accessible via the same phone number. 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 CHAP or PAP. For a NAS, it may not be possible to determine whether a user is required to authenticate with EAP until the user's identity is known. For example, for shared-uses NASes it is possible for one reseller to implement EAP while another does not. In such cases, if any users of the NAS MUST do EAP, then the NAS MUST attempt to negotiate EAP for every call. This avoids forcing an EAP-capable client to do more than one authentication, which weakens 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, the 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 Aboba & Calhoun Informational [Page 18] INTERNET-DRAFT RADIUS & EAP 27 May 2002 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 dialing in from one location (with an EAP-capable proxy) might be able to successfully authenticate via EAP, while the same user dialing into another location (and encountering an EAP- incapable proxy) might be consistently disconnected. 5. Normative references [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996. [RFC2044] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996. [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. [RFC2434] Alvestrand, H. and Narten, T., "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2284bis] Blunk, L., J. Vollbrecht, and Aboba, B., "Extensible Authentication Protocol (EAP)", Internet draft (work in progress), draft-ietf-pppext-rfc2284bis-04.txt, March 2002. [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. Aboba & Calhoun Informational [Page 19] INTERNET-DRAFT RADIUS & EAP 27 May 2002 6. Informative references [Masters] Slatalla, M., and Quittner, J., "Masters of Deception." HarperCollins, New York, 1995. [RFC1510] Kohl, J., Neuman, C., "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, November 1998. [RFC2486] Beadles, M., Aboba, B., "The Network Access Identifier", RFC 2486, January 1999. [RFC2401] Atkinson, R., Kent, S., "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2408] Maughan, D., Schertler, M., Schneider, M., Turner, J., "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [RFC2716] Aboba, B., Simon, D.,"PPP EAP TLS Authentication Protocol", RFC 2716, October 1999. [IEEE80211] Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE Std. 802.11-1997, 1997. Aboba & Calhoun Informational [Page 20] INTERNET-DRAFT RADIUS & EAP 27 May 2002 Appendix A - Examples The example below shows the conversation between the authenticating peer, NAS, and RADIUS server, for the case of a One Time Password (OTP) authentication. OTP is used only for illustrative purposes; other authentication protocols could also have been used, although they might show somewhat different behavior. 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 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 Aboba & Calhoun Informational [Page 21] INTERNET-DRAFT RADIUS & EAP 27 May 2002 Access-Challenge/ EAP-Message/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 In the case where the client fails EAP authentication, the conversation would appear as follows: Authenticating Peer NAS RADIUS Server ------------------- --- ------------- Access-Request/ EAP-Message/Start -> <- RADIUS Access-Challenge/ EAP-Message/Identity <- EAP-Request/ Identity EAP-Response/ Identity (MyID) -> RADIUS Access-Request/ EAP-Message/ Aboba & Calhoun Informational [Page 22] INTERNET-DRAFT RADIUS & EAP 27 May 2002 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-Reject/ EAP-Message/EAP-Failure <- EAP-Failure (client disconnected) In the case that the RADIUS server or proxy does not support EAP- Message, 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/Identity <- EAP-Request/ Identity Aboba & Calhoun Informational [Page 23] INTERNET-DRAFT RADIUS & EAP 27 May 2002 EAP-Response/ Identity (MyID) -> RADIUS Access-Request/ EAP-Message/EAP-Response/ (MyID) -> <- RADIUS Access-Reject (proxied from remote 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 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 -> Aboba & Calhoun Informational [Page 24] INTERNET-DRAFT RADIUS & EAP 27 May 2002 <- PPP CHAP Challenge PPP CHAP Response -> RADIUS Access-Request/ User-Name, CHAP-Password -> <- RADIUS Access-Reject <- PPP LCP Terminate (User Disconnected) Acknowledgments Thanks also to Dave Dawson and Karl Fox of Ascend, Glen Zorn of Cisco Systems and Ashwin Palekar, Tim Moore and Narendra Gidwani of Microsoft for useful discussions of this problem space. Author's Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: +1 425 706 6605 EMail: bernarda@microsoft.com Pat R. Calhoun Black Storm Networks 250 Cambridge Avenue, Suite 200 Palo Alto, California, 94306 USA Phone: +1 650-617-2932 Fax: +1 650-786-6445 E-mail: pcalhoun@bstormnetworks.com Full Copyright Statement Copyright (C) The Internet Society (2002). 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 Aboba & Calhoun Informational [Page 25] INTERNET-DRAFT RADIUS & EAP 27 May 2002 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/AAA/issues.html Expiration Date This memo is filed as , and expires December 24, 2002. Aboba & Calhoun Informational [Page 26]