Network Working Group C. Rigney Request for Comments: 2138 Livingston Obsoletes: 2058 A. Rubens Category: Standards Track Merit W. Simpson Daydreamer S. Willens Livingston April 1997 Remote Authentication Dial In User Service (RADIUS) Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. Implementation Note This memo documents the RADIUS protocol. There has been some confusion in the assignment of port numbers for this protocol. The early deployment of RADIUS was done using the erroneously chosen port number 1645, which conflicts with the "datametrics" service. The officially assigned port number for RADIUS is 1812. Table of Contents 1. Introduction .......................................... 3 1.1 Specification of Requirements ................... 4 1.2 Terminology ..................................... 5 2. Operation ............................................. 5 2.1 Challenge/Response .............................. 7 2.2 Interoperation with PAP and CHAP ................ 7 2.3 Why UDP? ........................................ 8 3. Packet Format ......................................... 10 4. Packet Types .......................................... 13 4.1 Access-Request .................................. 13 Rigney, et. al. Standards Track [Page 1] RFC 2138 RADIUS April 1997 4.2 Access-Accept ................................... 14 4.3 Access-Reject ................................... 15 4.4 Access-Challenge ................................ 17 5. Attributes ............................................ 18 5.1 User-Name ....................................... 21 5.2 User-Password ................................... 22 5.3 CHAP-Password ................................... 23 5.4 NAS-IP-Address .................................. 24 5.5 NAS-Port ........................................ 25 5.6 Service-Type .................................... 26 5.7 Framed-Protocol ................................. 28 5.8 Framed-IP-Address ............................... 29 5.9 Framed-IP-Netmask ............................... 29 5.10 Framed-Routing .................................. 30 5.11 Filter-Id ....................................... 31 5.12 Framed-MTU ...................................... 32 5.13 Framed-Compression .............................. 33 5.14 Login-IP-Host ................................... 33 5.15 Login-Service ................................... 34 5.16 Login-TCP-Port .................................. 35 5.17 (unassigned) .................................... 36 5.18 Reply-Message ................................... 36 5.19 Callback-Number ................................. 37 5.20 Callback-Id ..................................... 38 5.21 (unassigned) .................................... 38 5.22 Framed-Route .................................... 39 5.23 Framed-IPX-Network .............................. 40 5.24 State ........................................... 40 5.25 Class ........................................... 41 5.26 Vendor-Specific ................................. 42 5.27 Session-Timeout ................................. 44 5.28 Idle-Timeout .................................... 44 5.29 Termination-Action .............................. 45 5.30 Called-Station-Id ............................... 46 5.31 Calling-Station-Id .............................. 47 5.32 NAS-Identifier .................................. 48 5.33 Proxy-State ..................................... 48 5.34 Login-LAT-Service ............................... 49 5.35 Login-LAT-Node .................................. 50 5.36 Login-LAT-Group ................................. 51 5.37 Framed-AppleTalk-Link ........................... 52 5.38 Framed-AppleTalk-Network ........................ 53 5.39 Framed-AppleTalk-Zone ........................... 54 5.40 CHAP-Challenge .................................. 55 5.41 NAS-Port-Type ................................... 55 5.42 Port-Limit ...................................... 56 5.43 Login-LAT-Port .................................. 57 5.44 Table of Attributes ............................. 58 Rigney, et. al. Standards Track [Page 2] RFC 2138 RADIUS April 1997 6. Examples .............................................. 59 6.1 User Telnet to Specified Host ................... 60 6.2 Framed User Authenticating with CHAP ............ 60 6.3 User with Challenge-Response card ............... 61 Security Considerations ...................................... 63 References ................................................... 64 Acknowledgements ............................................. 64 Chair's Address .............................................. 65 Author's Addresses ........................................... 65 1. Introduction Managing dispersed serial line and modem pools for large numbers of users can create the need for significant administrative support. Since modem pools are by definition a link to the outside world, they require careful attention to security, authorization and accounting. This can be best achieved by managing a single "database" of users, which allows for authentication (verifying user name and password) as well as configuration information detailing the type of service to deliver to the user (for example, SLIP, PPP, telnet, rlogin). Key features of RADIUS are: Client/Server Model A Network Access Server (NAS) operates as a client of RADIUS. The client is responsible for passing user information to designated RADIUS servers, and then acting on the response which is returned. RADIUS servers are responsible for receiving user connection requests, authenticating the user, and then returning all configuration information necessary for the client to deliver service to the user. A RADIUS server can act as a proxy client to other RADIUS servers or other kinds of authentication servers. Network Security Transactions between the client and RADIUS server are authenticated through the use of a shared secret, which is never sent over the network. In addition, any user passwords are sent encrypted between the client and RADIUS server, to eliminate the possibility that someone snooping on an unsecure network could determine a user's password. Rigney, et. al. Standards Track [Page 3] RFC 2138 RADIUS April 1997 Flexible Authentication Mechanisms The RADIUS server can support a variety of methods to authenticate a user. When it is provided with the user name and original password given by the user, it can support PPP PAP or CHAP, UNIX login, and other authentication mechanisms. Extensible Protocol All transactions are comprised of variable length Attribute- 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. MUST This word, or the adjective "required", means that the definition is an absolute requirement of the specification. MUST NOT This phrase means that the definition is an absolute prohibition of the specification. SHOULD This word, or the adjective "recommended", means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications must be understood and carefully weighed before choosing a different course. MAY This word, or the adjective "optional", means that this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementation which does include the option. Rigney, et. al. Standards Track [Page 4] RFC 2138 RADIUS April 1997 1.2. Terminology This document frequently uses the following terms: service The NAS provides a service to the dial-in user, such as PPP or Telnet. session Each service provided by the NAS to a dial-in user 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 user may have multiple sessions in parallel or series if the NAS supports that. 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. 2. Operation When a client 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 which carry this information. 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 which the user is accessing. When a password is present, it is hidden using a method based on the RSA Message Digest Algorithm MD5 [1]. The Access-Request is submitted to the RADIUS server via the network. If no response is returned within a length of time, the request is re-sent a number of times. The client can also forward requests to an alternate server or servers in the event that the primary server is down or unreachable. An alternate server can be used either after a number of tries to the primary server fail, or in a round-robin fashion. Retry and fallback algorithms are the topic of current research and are not specified in detail in this document. Rigney, et. al. Standards Track [Page 5] RFC 2138 RADIUS April 1997 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 should 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 which 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 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 which MAY be displayed by the client to the user. No other Attributes are permitted in an Access-Reject. 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 Attributes 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 are 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. Rigney, et. al. Standards Track [Page 6] RFC 2138 RADIUS April 1997 2.1. Challenge/Response In challenge/response authentication, the user is given an unpredictable number and challenged to encrypt it and give back the result. Authorized users are equipped with special devices such as smart cards or software that facilitate calculation of the correct response with ease. Unauthorized users, lacking the appropriate device or software and lacking knowledge of the secret key necessary to emulate such a device or software, can only guess at the response. The Access-Challenge packet typically contains a Reply-Message including a challenge to be displayed to the user, such as a numeric value unlikely ever to be repeated. Typically this is obtained from an external server that knows what type of authenticator should be in the possession of the authorized user and can therefore choose a random or non-repeating pseudorandom number of an appropriate radix and length. The user then enters the challenge into his