AAA Working Group Lidong Chen Internet Draft Robert Patzer Expires: April 24, 2001 Motorola Inc. October 24, 2000 Authenticate the Network Access Server in RADIUS Status of this Memo This document is a submission to the AAA Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the aaa-wg@merit.edu mailing list. Distribution of this memo is unlimited. 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 obsolete 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. Abstract This document describes a method that allows for a RADIUS server to authenticate the network access server (NAS) in RADIUS [1, 2] protocol such that the RADIUS server can distinguish a false NAS or message interruption from a user authentication failure. Table Of Contents 1.0 Introduction 1.1 Requirements Language 2.0 Operation 2.1 Detecting a false NAS 2.2 Discovering transmission errors 3.0 RADIUS attributes 3.1 User-Password attribute 3.2 CHAP-Password attribute 4.0 IANA considerations 5.0 Security Considerations 6.0 Authors' Addresses 7.0 References 1. Introduction This document describes a method that allows for a RADIUS server to authenticate the network access server (NAS) in the RADIUS [1, 2] protocol. In the RADIUS protocol, in order to authenticate a user, the network access server (NAS) sends user authentication information to the RADIUS server. The RADIUS server then verifies the information and tells the NAS whether the user authentication succeeds or not. The user authentication information is sent to the RADIUS server via the Access-Request message. The RADIUS server tells the user authentication results to the NAS by the Access-Accept message, Access-Reject message, or Access-Challenge message in case the RADIUS server chooses to challenge the user. The user authentication information could be either a password or a response computed by the user based on a challenge, like CHAP challenge [3]. If the user authentication information is a password, then NAS includes the user password in User-Password attribute. The password is encrypted by a secret key shared between the NAS and the RADIUS server. If the user authentication is a CHAP response, then the response will be included in CHAP-Password attribute. In this case, the response may not be encrypted but sent in cleartext. In either case, if the password or response is different from what RADIUS server expected, then the authentication fails. However, there are two possibilities in case that the password or response is not correct. The first possibility is that the user is not a legal user and fails to authenticate itself. The second possibility includes that the NAS is a false NAS or the Access-Request message is interrupted when transmitted. It is possible that neither the user nor the NAS is a legal part in the protocol. But we only distinguish these two situations in this draft. Before roaming networks existed, since a service provider owned both the NAS and the RADIUS server, the false NAS was not considered a problem. Therefore, in the RADIUS protocol [1, 2], the NAS is completely trusted. That is, NAS authentication was considered unnecessary. The Roaming Operations Working Group (ROAMOPS) has published a set of specifications [4, 5, 6] that define how a user can gain access to the internet by dialing into a point of presence (POP). Therefore, the trust model assumed for the RADIUS protocol has changed. Furthermore, when proxy servers are used, the current RADIUS protocol cannot provide a sound authentication. Tremendous efforts have been made in the related working groups of IETF to provide a sound authentication solution for roaming networks. The DIAMETER protocol [7, 8] defines a strong security extension to accommodate end-to-end authentication by using public key cryptography. Since the RADIUS protocol has been used for many years, an evolution in RADIUS will be more suitable to provide NAS authentication in order to support the case that the NAS and the RADIUS server belong to different service providers. This draft provides a method to authenticate the NAS with minimum changes to the current RADIUS protocol. 1.1 Requirement Language 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 BCP 14. 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." 2. Operations When a client may work as a network access server (NAS), and is configured to use RADIUS, any user of the client presents authentication information to the client. This might be with a customizable login prompt, where the user is expected to enter their username and password. Alternatively, the user might use a link framing protocol such as the Point-to-Point Protocol (PPP), which has authentication packets that carry this information. In this case, the user authentication information might be a response to a random challenge based on a secret key shared among the user and the server. Once the client has obtained such information, it may choose to authenticate using RADIUS. To do so, the client creates an "Access-Request" containing such Attributes as the user's name, the user's password, the ID of the client and the Port ID that the user is accessing. When a password is present, it is encrypted using a method based on the Message Digest Algorithm MD5 [9]. The encryption key is a pre-shared secret between the client and the server. With the same piece of pre-shared secret key, the client computes a message authentication code (MAC) of ciphertext of the user password, or a message authentication code (MAC) of the user response. In both cases, the MAC is included in the same attributes as the password or the response contained in an Access-Request message. The client is validated by the MAC in the Access-Request message. Once the RADIUS server receives the request, it validates the sending client. A request from a client for which the RADIUS server does not have a shared secret MUST be silently discarded. If the client is valid, the RADIUS server consults a database of users to find the user whose name matches the request. The user entry in the database contains a list of requirements that must be met to allow access for the user. This always includes verification of the password, but can also specify the client(s) or port(s) to which the user is allowed access. The RADIUS server MAY make requests of other servers in order to satisfy the request, in which case it acts as a client. If any Proxy-State attributes were present in the Access-Request, they MUST be copied unmodified and in order into the response packet. Other Attributes can be placed before, after, or even between the Proxy-State attributes. If any condition is not met, the RADIUS server sends an "Access-Reject" response indicating that this user request is invalid. If desired, the server MAY include a text message in the Access-Reject that MAY be displayed by the client to the user. If all conditions are met and the RADIUS server wishes to issue a challenge to which the user must respond, the RADIUS server sends an "Access-Challenge" response. It MAY include a text message to be displayed by the client to the user prompting for a response to the challenge, and MAY include a State attribute. If the client receives an Access-Challenge and supports challenge/response it MAY display the text message, if any, to the user, and then prompt the user for a response. The client then re-submits its original Access-Request with a new request ID, with the User-Password Attribute replaced by the response (encrypted), and including the State Attribute from the Access-Challenge, if any. Only 0 or 1 instances of the State Attribute SHOULD be present in a request. The server can respond to this new Access-Request with either an Access-Accept, an Access-Reject, or another Access-Challenge. If all conditions are met, the list of configuration values for the user is placed into an "Access-Accept" response. These values include the type of service (for example: SLIP, PPP, Login User) and all necessary values to deliver the desired service. For SLIP and PPP, this may include values such as IP address, subnet mask, MTU, desired compression, and desired packet filter identifiers. For character mode users, this may include values such as desired protocol and host. 2.1 Detecting a false client With the new applications of RADIUS protocol in mind, if a user has been successfully authenticated, the further information about the user, for example, billing information or service profile, may be sent from the server to the client for usage in the service. The method of detecting a false client is based on such an assumption that the purpose of a false client is to make the user authentication succeed so that the protocol can continue. If either of them, the user authentication information and the message authentication code, is not valid, then the server will reject the access of the user. As a result, there is no further disclosure of any user sensitive information to the client besides authentication information. This method cannot prevent a malicious client from intently invalidating a legal user, since there are many ways to do so for a network access server. 2.2 Discovering transmission errors The message may be interrupted in the process of transmission from the client to the server. By a message authentication code, such a kind of error can be detected as well. 3.0 RADIUS attributes changes This section defines some changes to two existing RADIUS attributes. They are User-Password attribute and CHAP-Password attribute. Some new attributes may be defined for Access-Reject message to distinguish transmission error from user authentication failure in the future. 3.1 User-Password with MAC attribute Description This Attribute indicates the password of the user to be authenticated, or the user's input following an Access-Challenge. It is only used in Access-Request packets. On transmission, the password is hidden. The password is first padded at the end with nulls to a multiple of 16 octets. A one-way MD5 hash is calculated over a stream of octets consisting of the shared secret followed by the Request Authenticator. This value is XORed with the first 16-octet segment of the password and placed in the first 16 octets of the String field of the User-Password Attribute. If the password is longer than 16 characters, a second one-way MD5 hash is calculated over a stream of octets consisting of the shared secret followed by the result of the first xor. That hash is XORed with the second 16 octet segment of the password and placed in the second 16 octets of the String field of the User-Password Attribute. If necessary, this operation is repeated, with each xor result being used along with the shared secret to generate the next hash to xor the next segment of the password, to no more than 128 characters. Whenever the above operation is finished, a message authentication code of the ciphertext is computed with the same one-way hash function MD5 and the same shared secret key. Call the shared secret S and the pseudo-random 128-bit Request Authenticator RA. Break the password into 16-octet chunks p1, p2, etc. with the last one padded at the end with nulls to a 16-octet boundary. Call the ciphertext blocks c(1), c(2), etc. We'll need intermediate values b1, b2, etc. After encryption is completed for password p1, p2, ..., pi, a message authentication code (MAC) is computed on ciphertext c(1), c(2), ..., c(i ) with shared secret key S. Call the MAC c(i+1). b1 = MD5(S + RA) c(1) = p1 xor b1 b2 = MD5(S + c(1)) c(2) = p2 xor b2 . . . . . . bi = MD5(S + c(i-1)) c(i) = pi xor bi c(i+1) = MD5(S+c(1)+c(2)+...+c(i)) The String will contain c(1)+c(2)+...+c(i) + c(i+1) where + denotes concatenation. On receipt, the c(i+1) will be first verified. If it is a valid MAC of c(1)+c(2)+...+c(i) respect to the secret key S, the process is reversed to yield the original password. A summary of the User-Password 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 2 for User-Password. Length At least 34 and no larger than 130. String The String field is between 32 and 128 octets long, inclusive. 3.2 CHAP-Password with MAC attribute Description This Attribute indicates the response value called RV provided by a PPP Challenge-Handshake Authentication Protocol (CHAP) user in response to the challenge. It is only used in Access-Request packets. The response value MAY not be encrypted. But a message authentication code (MAC) MAY be computed for the response by pre-shared secret key S. C(1) = MD5(S+RV). The CHAP challenge value is found in the CHAP-Challenge Attribute (60) if present in the packet, otherwise in the Request Authenticator field. A summary of the CHAP-Password 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 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | CHAP Ident | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 3 for CHAP-Password. Length 33 CHAP Ident This field is one octet, and contains the CHAP Identifier from the user's CHAP Response. String The String field is 32 octets, and contains the CHAP Response value RV from the user and its MAC c(1). 4. IANA considerations The document allocates two new values for two new attributes defined in section 3. As IANA would be allocating them, they should be listed as TBD1 and TBD2. 5. Security considerations The proposed method in this document is intended to provide the appropriate level of security for roaming network with the minimum changes to RADIUS. The NAS authentication resulting from use of this method does not offer any higher level of security than already implicit in use of the RADIUS server. 6. Authors' Addresses Lidong Chen Network Solutions Sector Motorola Inc. 1501 W. Shure Dr. Arlington Heights, IL 60004 U.S.A. Phone : +1-(847) 632 -3033 E-mail : LCHEN1@email.mot.com Robert Patzer Personal Communications Sector Motorola Inc. 600 N. US Highway 45 Libertyville, IL 60048 U.S.A. Phone : +1-(847)-523-5228 E-mail : RPATZER1@email.mot.com 7. References [1] C Rigney, A Rubens, W A Simpson, S Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997. [2] C Rigney, A Rubens, W A Simpson, S Willens, "Remote Authentication Dial In User Service (RADIUS)", draft-ietf-radius-radius-v2-06.txt, Work in progress [3] W. Simpson, "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC1994, August 1996. [4] B. Aboda, G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999. [5] B. Aboda, J. Lu, J. Alsop, J. Ding, W. Wang, "Review of Roaming Implementations", RFC 2194, September 1997. [6] B. Aboda, J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999. [7] B. Calhoun, G. Zorn, P. Pan, H. Akhtar, "DIAMETER Framework Document", draft-calhoun-diameter-framework-05.txt, Work in progress. [8] B. Calhoun, W. Bulley, S. Farrell, "DIAMETER Strong Security Extension", draft-calhoun-diameter-strong-crypto-01.txt, Work in progress. [9] R. Rivest, S. Dusse, "The MD5 Message Digest Algorithm", RFC 1321, April 1992. 8. Intellectual Property This is to advise the IETF that Motorola may have patents or patents pending which may be applicable to this draft which has been submitted to the AAA WG. draft-ietf-radius-nas-auth-00.txt Expire date: April 24, 2001 Chen, et. Al. Expires April 24, 2001 [Page 7]