


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.  

The work described here is relevant to the NAS-helper
model under study by the nasreq working group.  This initial work may
help to guide the NAS-helper protocol definition and may also help to
point out or clarify some of the unresolved issues in this area.  

Description of the RADIUS protocol

RADIUS is an RPC 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 ack 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 Password-Change 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 = Authentication Request,
              2 = Authentication ACK,
              3 = Authentication Reject)

  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 = Client-Id                   ip address,
               5 = Client-Port                 integer,
               6 = User-Service                1 = Login,
                                               2 = Framed,
                                               3 = Dialback-Login
                                               4 = Dialback-Framed,
                                               5 = Authentication-Only,
               7 = Framed-Protocol             1 = PPP,
                                               2 = SLIP,
               8 = Framed-Address              ip address,
               9 = Framed-Netmask              ip address,
              10 = Framed-Routing              0 = None,
                                               1 = Broadcast,
                                               2 = Listen,
                                               3 = Broadcast - Listen,
              11 = Framed-Filter-id            string,
              12 = Framed-MTU                  integer,
              13 = Framed-Compression          1 = V-J TCP/IP,
              14 = Login-Host                  ip address,
              15 = Login-Service               0 = Telnet,
                                               1 = Rlogin,
                                               2 = TCP-Clear,
                                               3 = PortMaster,
              16 = Login-TCP-Port              integer,
              
              18 = Port-Message                string,
              19 = Dialback-Number             string,
              20 = Dialback-Name               string,
             *21 = Password-Expiration         time,
             *22 = Authentication_Type         0 = Domain  
                                               1 = Kerberos
                                               2 = Unix 
             *23 = Prohibit_Protocol           0 = Dumb,
                                               1 = PPP,
                                               2 = SLIP,

              
 length:    8 bit length of this value-pair;

 value:     0 - 128 octet information item.
            (The data type of value is determined by the data type
             associated with this attribute code, as shown in attribute 
             table above.)

* indicates value-pairs that are used only as check-items in the "users" file.
  Such items are not present in Authentication Requests, Acks or Rejects.
        
	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 Client-Id, Client-Port, User-Service,
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 but will be addressed by the nasreq and
ppp-extensions working groups.  

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, ... , check-itemn
	        reply-item1
	        reply-item2
	        ...
	        reply-itemy

	...

	DEFAULT check-item1, check-item2, ... , Authentication-Type=Domain
		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, such as the "Password-Expiration" item, 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 authentication 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 Authentication Ack. The
Port-Message item can be used in a reject to return an indication as the
cause of the authentication failure or it can provide an advisory message in
Authentication Ack.

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 can be used to disallow non-framed access to the NAS for all
but a small set of special users that are configured in 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.  Possible types are Unix, Kerberos, or Domain.  "Unix"
indicates that the id and pw are to be validated against the local unix
password file.  "Kerberos" indicates the id and pw are to be authenticated by
the default Kerberos domain of the local system.  "Domain" implies more
general handling of the user authentication.

"Domain" indicates that the User-Name value-pair string should be parsed as an
<id, authentication domain> pair.  The acceptable syntax for this pair is
id@domain or domain/id.  An entry matching the domain 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 domain name to an authentication
type and authentication host (or realm, for Kerberos) name.  Supported
authentication types are MIT-Kerberos, AFS-Kerberos, and RADIUS.  Other types
can easily be added - one such type, MNET, has been added for a unique Merit
authentication system.


	# Authent. domain name	Authent. Type	Host/Realm
	
	merit			RADIUS		merit.edu

	umich.edu               AFS-KRB         UMICH.EDU
	umich                   AFS-KRB         UMICH.EDU

	um			MNET		UM
	
	DEFAULT			RADIUS		radmaster.merit.edu


	Figure 4 - Example "Authfile"


For example - using the authfile of Fig. 4 - acr@merit will be passed to the
RADIUS server at merit.edu; acr@umich will be authenticated by the
AFS-Kerberos server for the UMICH.EDU realm; acr@anycity.usa will be passed on
to the RADIUS server at radmaster.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
domain.  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 WRADIUS server.  The random vector and sequence number of the
received authentication request are relayed as is to 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 domain name included in the id value pair. 
If the authfile specifies the domain 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 domain 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 to not 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 reject is also propagated back to the NAS.

If a RADIUS server attempts to perform remote authentication (e.g.,
Kerberos, RADIUS, MNET types) but does not receive a reply within a short
time interval (currently 3 seconds) 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.

Issues

This document describes the way RADIUS currently works.  Its functions and
protocols will be changed to adhere to evolving nasreq standards and
recommendations.  There is still a long way to go before RADIUS provides all
the functionality that will be required of a full functioning nasreq helper.
A few issues relevant to the current level of functionality of RADIUS are
discussed next.

One such issue is that of the treatment of the id by the NAS.  The
question is should the NAS attempt to parse the id string into id and
domain name or should the helper do this?  It's also been suggested
that the id be encrypted just as the password in the authentication
request.

Is the password encryption mechanism used secure enough?  It appears to be
susceptible to "playback" attack but maybe this doesn't matter for the
environment in which it will be used.  Maybe the source ip address should be
used in the MD5 encoding?

Another issue is whether RADIUS should, in addition to handling relayed
authentication requests, provide a way to tell the sender of a relayed
request the information required to make subsequent requests to the same
authentication directly.

There are still, of course, many issues related to authorization that need to
be addressed.  In the context presented here, check item processing and
generation of the user-reply value-pairs are all performed by the helper. 
This processing needs to be split between the helper and remote
authorization agents.  The mechanism for doing this needs to be defined.

The value-pair definitions thus far are very ad-hoc.  Does a more general
and expandable mechanism need to be defined for passing information between
NAS and helper?  

There are any number of other issues that need to be addressed.  It is hoped
that this document will help to raise, clarify, or resolve many of them.


