Network Working Group Bernard Aboba INTERNET-DRAFT Microsoft Corporation Glen Zorn 17 January 1997 Microsoft Corporation Extensible Authentication Protocol Support in RADIUS 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing 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 mate- rial or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). The distribution of this memo is unlimited. It is filed as , and expires July 1, 1997. Please send com- ments to the authors. 2. Abstract The Enhanced Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP. Currently, the RADIUS protocol only supports conventional PPP authen- tication methods such as PAP and CHAP. This document describes two new attributes, EAP-Authentication-Type and EAP-Authentication-Server-End- point, and how they may be used for providing EAP support within RADIUS. 3. Introduction The Extensible Authentication Protocol (EAP), described in [1], pro- vides a standard mechanism for support of additional authentication methods within PPP. Through the use of EAP, support for a number of authentication schemes may be added, including token cards, Kerberos, Public Key, S/Key, and others. However, the RADIUS protocol, described in [4], currently only supports CHAP and PAP authentication. This doc- ument describes two new attributes, EAP-Authentication-Type, and EAP- Authentication-Server-Endpoint, and how they may be used for providing EAP support within RADIUS. Aboba & Zorn [Page 1] INTERNET-DRAFT 17 January 1997 The scheme described here differs from that proposed in [2], in that rather than shuttling RADIUS-encapsulated EAP Packets between the NAS and a backend security server, the RADIUS server instead returns the type of EAP authentication desired, and the address and port of the backend authentication server to be contacted. The NAS device then uses this information to contact the backend security server directly. Due to the 253 octet limitation in the size of a RADIUS attribute, the scheme described in [2] could not be easily implemented on existing RADIUS servers, and was dependent on deployment of an expanded version of the RADIUS protocol. Since the scheme described here does not encapsulate EAP packets in RADIUS, it may be implemented within RADIUS as described in [3] and [4]. While the conversation between the NAS and backend security server will typically occur using a proprietary protocol developed by the backend security server vendor, it is also possible to encapsulate EAP in UDP or TCP. This has the advantage of allowing the NAS to support EAP without the need for authentication-specific code, which can instead reside on a backend security server. 4. Protocol overview The EAP conversation between the authenticating peer and the NAS begins with the negotiation of EAP within LCP. Once EAP has been nego- tiated, if the NAS is set up for RADIUS authentication, it will initi- ate an EAP-identity request. While use of the identity request is not required by EAP, without knowledge of the identity, RADIUS would not be capable of returning user-specific connection setup attributes, or accounting for resource usage. Since these are the main benefits of the RADIUS protocol, if an identity request were not required, the NAS should be set up to operate with a local profile rather than using RADIUS. Since the purpose of EAP is to authenticate the user, prior to sending the Access-Request the RADIUS client has obtained the user's identity, but no authentication can be assumed to have taken place. Therefore with EAP it is typically not possible to include a conventional User- Password or CHAP-Password attribute within the Access-Request. Instead, after obtaining the user's identity, the RADIUS client gener- ates an Access-request containing the following attributes: User-Name (filled in with the identity), EAP-Authentication-Server-Endpoint (with an address of 0.0.0.0, and port of 0x0000), EAP-Authentication- Type (with type 0) and a User-Password attribute which contains an MD5 hash of the Access-Request concatenated with the shared secret (i.e. User-Password=MD5(Code+ID+Length+RequestAuth+Attributes+Secret)). This amounts to a null password, but authenticates that the request came from a known NAS. The user's connection is only set up by the NAS should the EAP authentication succeed. It is also possible for the NAS to carry out an MD5 authentication prior to sending the Access-Request. In this case, the NAS will Aboba & Zorn [Page 2] INTERNET-DRAFT 17 January 1997 include a CHAP-Password attribute in the Access-Request, along with the null EAP-Authentication-Server-Endpoint and EAP-Authentication- Type attributes, and as a result, the RADIUS server is able to verify the user password. However, use of multiple authentications may not be desirable in many applications. On receiving the Access-Request, the RADIUS server checks the validity of the User-Password or CHAP-Password attributes, and if this check is successful, the RADIUS server returns connection-related attributes in the Access-Reply, along with the EAP-Authentication-Type and EAP- Authentication-Server-Endpoint attributes. Although use of multiple EAP authentications is typically not desirable, it is possible for the RADIUS server to return more than one set of EAP-Authentication-Type and EAP-Authentication-Server-Endpoint attributes; in this case the NAS will carry out the authentications in the indicated order. If the authenticating peer is successful in completing the EAP authen- tication, then the NAS grants access to the network, and sends a RADIUS Accounting-Request/START packet to the RADIUS server, including the EAP-Authentication-Type and EAP-Authentication-Server-Endpoint attributes. The RADIUS server replies with an Accounting-Reply packet. Similarly, when the connection is terminated, the NAS sends a RADIUS Accounting-Request/STOP packet to the RADIUS server, including the EAP-Authentication-Type and EAP-Authentication-Server-Endpoint attributes, and the RADIUS server replies with an Accounting-Reply packet. The conversation between the authenticating peer, NAS, and RADIUS server is summarized below: Authenticating Peer NAS RADIUS Server ------------------- --- ------------- <- LCP EAP-Request LCP EAP ACK -> <- PPP EAP-Request/Identity PPP EAP-Response/Identity (MyID) -> RADIUS Access-Request Username (MyID), User-Password, EAP-Authentication-Type(0) EAP-Authentication-Server- Endpoint (0) -> <-RADIUS Access-Accept (Referral) EAP-Authentication-Type:S-Key, EAP-Authentication-Server-Endpoint, (Other attributes) <- PPP EAP-Request/S-Key S-Key Challenge PPP EAP-Response/S-Key, S-Keypw -> EAP-Request/S-Key S-Keypw (to security server) Aboba & Zorn [Page 3] INTERNET-DRAFT 17 January 1997 EAP-Success (from security server) <- PPP EAP-Success IPCP phase starts IPCP phase completes RADIUS Accounting-Request with Acct-Status-Type=Start, EAP-Authentication-Server-Endpoint EAP-Authentication-Type -> <- RADIUS Accounting-Reply RADIUS Accounting-Request with Acct-Status-Type=Stop, EAP-Authentication-Server-Endpoint EAP-Authentication-Type -> <- RADIUS Accounting-Reply 4.1. Backward compatibility It is conceivable that the RADIUS server to which the initial Access- Reqest is directed will not support EAP. In this case, the User-Pass- word attribute will not match, and the RADIUS server will respond with a RADIUS Access-Reject. The NAS will then NAK the Authenticating Peer, and will request CHAP or PAP authentication. 5. Attributes 5.1. EAP-Authentication-Type Description When included in an Access-Request message, this attribute MUST contain a value of 0, used to indicate a request for an EAP authen- tication type. When returned in an Access-Accept message, this attribute indicates the authentication protocol to be used. A NAS is not required to implement all of these authentication types, and MUST treat unknown or unsupported EAP-Authentication-Types as though an Access-Reject had been received instead. A summary of the EAP-Authentication-Type 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 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value | Aboba & Zorn [Page 4] INTERNET-DRAFT 17 January 1997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 69 for EAP-Authentication-Type Length 3 Value The Value field is a single octet. 0 Request for EAP redirection (Access-Request only) 1 Identity 2 Notification 3 Nak (Response only) 4 MD5-Challenge 5 S/Key (RFC 1760) 6 Generic Token Card 5.2. EAP-Authentication-Server-Endpoint Description When included in an Access-Request message, this attribute MUST contain a value of 0, used to indicate a request for an EAP authen- tication server endpoint address and port. If this attribute is not included in the Access-Request, it When returned in an Access- Reply/Accept message, this Attribute indicates the address of the backend security server. A summary of the Authentication-Server-Endpoint 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 70 for EAP-Authentication-Server-Endpoint. Length =8 for IPv4, 20 for IPv6 String Aboba & Zorn [Page 5] INTERNET-DRAFT 17 January 1997 The structure of the string field is as follows: 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 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port | Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The string field consists of a two-octet port field, as well as an address field. The length of the address depends on whether we are using IPv4 or IPv6. In IPv4, the attribute is 8 octets in length, and in IPv6, it is 20 octets in length. length. 6. Security Issues This specification raises two major security issues: the use of a mod- ified User-Password attribute in the Access-Request, and the use of an EAP encapsulation over the Internet. In a conventional RADIUS conversation, user attributes are sent by the RADIUS server to the NAS only after the user password has been veri- fied. In the protocol specified in this document, the attributes are sent on verification of the secret shared between the NAS and the RADIUS server. While the User-Password scheme described here protects against modification of the Access-Request message, which standard RADIUS does not, it makes it more likely that an attacker obtaining the shared secret would then also be able to obtain user attribute information. The most important such information is the knowledge that an account exists for a given userID, although other attributes (such as the user's IP address or framing) may also be of interest. While this risk can be mitigated by requiring an MD5 authentication prior to release of the connection setup information, and including the CHAP-Password attribute in the Access-Request, use of multiple authentications may not be desirable in many applications. The scheme described in this document results in the NAS entering to a direct conversation with a backend security server, while in the scheme described in [2], the RADIUS server shuttles EAP packets back and forth between the NAS and the backend security server. In the sit- uation where the RADIUS server is located close to the backend secu- rity server, the conversation between the NAS and RADIUS server or backend security server will typically occur over the Internet, while a conversation between a RADIUS server and backend security server will typically occur over a local LAN or other private network. Since the security of an EAP authentication is only as good as the weakest link, it is worthwhile to examine the security aspects of these conversations. In the conversation between the NAS and the back- end security server or RADIUS server, it is desirable for mutual Aboba & Zorn [Page 6] INTERNET-DRAFT 17 January 1997 authentication to be provided. However, typically encryption of the EAP conversation is not required, since EAP authentication protocols have already taken the possibility of snooping into account. In the scheme described here, the conversation between the NAS and backend security server can either occur via a proprietary protocol, or via an EAP encapsulation. Assuming that the EAP encapsulation is secured (via SSL or IP Sec), then mutual authentication can be pro- vided, as well as encryption. As described earlier, the use of a modi- fied User-Password attribute provides assurance to the RADIUS server that the Access-Request comes from a legitimate NAS device, and the Authenticator provided in the Access-Reply provides assurance to the RADIUS client that the reply comes from a legitimate RADIUS server. The scheme described in [2] provides for mutual authentication between the NAS and RADIUS server. This is handled via a message integrity check (MIC) included within the Access-Request. As a result, expanded RADIUS provides assurance of the authenticity and integrity of both EAP requests and responses. While [2] does not describe the communication mechanisms between the RADIUS server and backend security server, it can be assumed that this also occurs either via a proprietary protocol, or via an EAP encapsu- lation. However, since the conversation between the RADIUS server and backend security server is likely to occur over a LAN or private net- work, security concerns are typically not as severe. 7. Acknowledgements Thanks to Gurdeep Singh Pall, Peter Ford, and Narendra Gidwani of Microsoft for useful discussions of this problem space. 8. References [1] L. J. Blunk, J. R. Vollbrecht. "PPP Extensible Authentication Protocol (EAP)." draft-ietf-pppext-eap-auth-02.txt, Merit Network, Inc., June, 1996. [2] A. Rubens, P.R. Calhoun. "Enhanced Remote Authentication Dial In User Service (RADIUS) Extensible Authentication Protocol Support." draft-calhoun-enh-radius-eap-00.txt, Merit Network, Inc., US Robotics Access Crop., June, 1996. [3] C. Rigney, A. Rubens, W. A. Simpson, S. Willens. "Remote Authen- tication Dial In User Service (RADIUS)." draft-ietf-radius- radius-05.txt, Livingston, Merit, Daydreamer, July 1996. [4] C. Rigney. "RADIUS Accounting." draft-ietf-radius-account- ing-05.txt, Livingston, July 1996. Aboba & Zorn [Page 7] INTERNET-DRAFT 17 January 1997 9. Authors' Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 206-936-6605 EMail: bernarda@microsoft.com Glen Zorn Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 206-703-1559 EMail: glennz@microsoft.com Aboba & Zorn [Page 8]