Copyright [C] The Regents of the University of Michigan and Merit Network,
Inc. 1993, 1994, 1995, 1996, 1997, 1998 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
<id, authentication realm> 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.
