Copyright [C] The Regents of the University of Michigan and Merit Network, Inc. 1993, 1994, 1995, 1996, 1997 All Rights Reserved. This note describes a NAS/helper protocol implemented by Livingston as their RADIUS protocol and the authentication/authorization system based on it. It also describes changes made to this system by Merit to provide distributed authentication/authorization capabilities. Description of the RADIUS protocol RADIUS is an UDP based protocol. All requests are generated by the NAS and issued to the RADIUS server. The server receives the request and may reply with an accept or a reject, or it may not respond at all. The NAS is expected to retransmit requests, if necessary. There are plans to add additional types of requests, Currently two request types supported - Authentication requests and Accounting requests. The latter is not well defined for the distributed authentication case and will not be described here. RADIUS requests and replies share a common format, depicted in Fig. 1. These messages are issued over UDP. The RADIUS server listens on UDP port 1645 for requests. +------+-----+--------+-----------+---------- -----------+ | | | | | | | Code | id | length | vector | . . . value-pairs . . . | | | | | | | +------+-----+--------+-----------+---------- -----------+ Code: 8 bit request/reply type; (1 = Access-Request, 2 = Access-Accept, 3 = Access-Reject, 4 = Accounting-Request, 5 = Accounting-Response) id: 8 bit message sequence number; Value in reply == Value in Request; length: 16 bit message length, (including this header beginning at Code); vector: 16 octet binary vector; (Value in request is randomly generated, Value in reply is MD5 digest of reply message data appended with "secret", using vector value from request.) value-pairs: Arbitrary numbers of information pairs with format shown in Fig. 2. Fig. 1 - RADIUS Request/Reply message format +-------------+----------+---------+ | | | | | attribute | length | value | | | | | +-------------+----------+---------+ attribute: 8 bit value-pair code: 1 = User-Name string, 2 = User-Password string, 3 = CHAP-Password string 4 = NAS-IP-Address IP address, 5 = NAS-Port integer, 6 = Service-Type integer, 7 = Framed-Protocol integer, 8 = Framed-IP-Address IP address, 9 = Framed-IP-Netmask IP address, 10 = Framed-Routing integer, 11 = Filter-Id string, 12 = Framed-MTU integer, 13 = Framed-Compression integer, 14 = Login-IP-Host IP address, 15 = Login-Service integer, 16 = Login-TCP-Port integer, 18 = Reply-Message string, 19 = Callback-Number string, 20 = Callback-Id string, 22 = Framed-Route string, 23 = Framed-IPX-Network integer, 24 = State string, 25 = Class string, 26 = Vendor-Specific string, 27 = Session-Timeout integer, 28 = Idle-Timeout integer, 29 = Termination-Action integer, 30 = Called-Station-Id string, 31 = Calling-Station-Id string, 32 = NAS-Identifier string, 33 = Proxy-State string, 34 = Login-LAT-Service string, 35 = Login-LAT-Node string, 36 = Login-LAT-Group string, 37 = Framed-AppleTalk-Link integer, 38 = Framed-AppleTalk-Network integer, 39 = Framed-AppleTalk-Zone string, 60 = CHAP-Challenge string, 61 = NAS-Port-Type integer, 62 = Port-Limit integer, 63 = Login-LAT-Port string, length: 8 bit length of this value-pair; value: 1 - 253 octet information item. (The data type of value is determined by the data type associated with this attribute code, as shown in the attribute table above.) Fig. 2 - Value-pair format As shown in Figure 1, the Authentication Request contains a set of "value-pairs". The value-pairs currently placed in these requests are the User-Name and User-Password, along with NAS-IP-Address, NAS-Port, Service-Type, and the Framed-Protocol pair - the latter being present only if the user is using or desires to use PPP or SLIP. Only the User-Password and CHAP-Password values are encrypted. As it is currently defined, CHAP requires that the server have access to an unencrypted copy of a shared secret. Since the unencrypted secret is not, in general, available to the helper, further work is required to support CHAP in the NAS/helper architecture. CHAP is therefore not discussed further in this document. Encryption of the User-Password in a request is accomplished by virtue of the fact that the NAS and server share a common secret. The secret for each helper used by the NAS is configured in the NAS along with the list of helpers that the NAS should try to use. The helper uses a "clients" file to associate a secret with each NAS (or other helper) that is authorized to make use of its services. The same secret is used for messages sent to and received by a NAS/helper pair. For each request, a 16 octet random vector is generated and placed in the "vector" entry of the request header. A copy of the random vector is MD5 encoded using the secret. The password is encrypted by xoring it with the encoded copy of the random vector. This encrypted value is passed in the User-Password value-pair in the request. The unencoded random vector passed in the request header is used along with the secret at the helper end to obtain the unencrypted user password. The same process of MD5 encoding the random vector with the secret and xoring it with the encrypted value received in the User-Password pair yields the unencrypted password. Note that the password may be provided to the NAS by a user dialog or by PAP. Parsing of the requests arriving at the server begins with finding the User-Name value-pair. An attempt is first made to lookup the User-Name string in a local "users" file. The format of this file is shown in Fig. 3. Associated with each id in this file is a set of "check" items and a set of "reply" items. If the id is not found in the file, then a "DEFAULT" entry contained in the file is used. It too has a set of check and reply items associated with it. user1 User-Password="a.p.w" , check-item2, ... , check-itemm reply-item1, reply-item2, ... reply-itemx user2 check-item1, Authentication-Type=UNIX-PW, ... , check-itemn reply-item1, reply-item2, ... reply-itemy ... DEFAULT check-item1, check-item2, ... , Authentication-Type=Realm reply-item1, reply-item2, ... reply-itemz Figure 3 - "Users" file format In general, User-Names will match only the "DEFAULT" entry of the "users" file. Configuring individual user id's in the "users" file runs contrary to the NAS/helper model's goal of providing distributed authentication. Nonetheless, the RADIUS software provides for support of individual id's in the "users" file although it is expected that this capability will be used sparingly. Once the list of check items is obtained from the "users" file, each check item is processed or matched against the request value-pairs. Some check items are considered to be configuration only and indicate special functions to be performed by the helper while others must just be matched by a corresponding value-pair in the request. For example, a check item indicating that the request must be for PPP service must be matched by a corresponding Framed-Protocol=PPP item in the request in order for the request to be satisfied. If a check item is not matched, then the request fails and an Access-Reject is issued. If all the check items associated with the selected entry in the user file are satisfied, then the associated reply items are returned in the Access-Accept. The Reply-Message item may be used in an Access-Reject to return an indication to the cause of the authentication failure or it may provide an advisory message in the Access-Accept. Enhancements Enhancements to the RADIUS server have been made by Merit to perform authentication by accessing a configured set of remote authentication servers. A mechanism was also added to allow one RADIUS server to pass on a request to another RADIUS server. In this manner, a RADIUS server running on one host system can function as one of the remote authentication servers available to other RADIUS servers. Additional enhancements were also made to RADIUS's capabilities for authorization/configuration. It was necessary to break the tie between user id and NAS access protocol that the original RADIUS imposed - the user id no longer implies the access protocol to be used. However, another enhancement was added to restrict the use of certain access protocols on the NAS. For example, RADIUS may be used to disallow non-framed access to the NAS for all but a small set of special users who are configured in a RADIUS's "users" file. The remainder of this section will concentrate on the authentication enhancements only. The ability to allow differing types of authentication was implemented with the addition of an Authentication-Type check item. The presence of this check item in a "users" file entry indicates that the id and password provided in the request are to be treated as being of the type specified by the value of this check item. Example types are UNIX-PW, Kerberos, and Realm. "UNIX-PW" indicates that the id and password are to be validated against the local UNIX password file. The "Kerberos" type indicates the id and password are to be authenticated by the default Kerberos realm of the local system. "Realm" implies more general handling of the user authentication. "Realm" indicates that the User-Name value-pair string should be parsed as an pair. The acceptable syntax for this pair is id@realm or realm/id. An entry matching the realm string is searched for in the file "authfile", of which an example is shown in Fig. 4. If it is not found and a default entry is present in the file, then the default entry is used. The authfile entry is used to map the realm name to an authentication type and authentication host (or realm, for Kerberos) name. Supported authentication types include MIT-Kerberos, AFS-Kerberos, and RADIUS. Other types may easily be added - one such type, MNET, has been added for a unique Merit authentication system. # Authentication Realm Authentication Type Host/Realm merit RADIUS foo.merit.edu umich.edu AFS-KRB UMICH.EDU umich AFS-KRB UMICH.EDU um MNET UM DEFAULT RADIUS bah.merit.edu Figure 4 - Example "Authfile" For example - using the authfile of Fig. 4 - user@merit will be passed to the RADIUS server at foo.merit.edu; while user@umich will be authenticated by the AFS-Kerberos server for the UMICH.EDU realm; user@anycity.usa will be passed on to the RADIUS server at bah.merit.edu. The Kerberos types perform authentication at the specified realm. This authentication is accomplished by asking for a Ticket-Granting-Ticket from the Kerberos server. The RADIUS type relays the original authentication request to the RADIUS server at the host specified in the authfile entry for the realm. Because the password value pair in the authentication request is encrypted using the NAS/RADIUS secret, it needs to be decrypted and reencrypted using the secret shared by the sending RADIUS system and the destination RADIUS server. The authentication request relayed to a RADIUS server appears to the server to be identical to those received from a NAS. It processes the request in the same way as the issuing RADIUS server did. The authfile at the receiving RADIUS server should be configured to specify how to handle the realm name included in the User-Name value pair. If that authfile specifies the realm to be of type RADIUS, a check is made to see if the host name to relay the request to is that of the local system. If so, the id is taken to be a UNIX id on that system. Otherwise, the request will be relayed once again to the specified host. The DEFAULT entry in the authfile allows realm names not configured in a RADIUS server's authfile to be passed along to a more knowledgeable RADIUS server. This allows for a site running its own RADIUS server not to have to worry about adding new domain names at other sites to its local authfile. Replies to relayed authentication requests traverse the reverse route of the request. This is necessitated by the fact that replies contain a digest (or signature) based upon the shared secret between each client/server pair. It is also desirable because it allows each client to modify the authorization/configuration information contained in a relayed authentication reply, although this is not currently performed. A RADIUS server receiving a reply from a relayed request replaces its original set of reply items (obtained from its local "users" file) with those contained in the received reply. In this manner, the authenticating RADIUS system has control over the authorization/configuration items issued to the NAS. If a relayed request is rejected, any user message that accompanies the rejection is also propagated back to the NAS. If a RADIUS server attempts to perform remote authentication (that is, Kerberos, RADIUS, MNET types) but does not receive a reply within a short time interval, it simply aborts the attempt without generating a reply to its client. RADIUS relies on the NAS or client PAP to retransmit the original request until it receives a reply or until a retransmit threshold is exceeded.