Configuring RADIUS Proxy Service   9

  This chapter includes the following topics:

•  "How Proxy Service Works" on page 9-2
•  "Servers Running Proxy Service" on page 9-5
•  "Proxy Confederations" on page 9-6
•  "Configuring Proxy Information on the Server" on page 9-7

  RADIUS for UNIX supports proxy  service. Proxy service enables a RADIUS for UNIX server--the proxy server--to forward an authentication request from a network access server (NAS) to a remote RADIUS server and return the remote server's reply to the NAS. A common use for proxy service is roaming . Roaming permits two or more Internet service providers (ISPs) to allow each other's users to dial in to either ISP's network for service. Users traveling outside the area of one ISP's coverage can access their services through another ISP.

  Proxy service also enables an ISP to share its modem pool with that of neighboring ISPs. Suppose that during peak usage hours the modems of an ISP are so busy that some users cannot get through. It can establish a business arrangement with a neighboring ISP--if both are using RADIUS for UNIX, Lucent's Port Authority RADIUS server, or any other proxy-compatible RADIUS server--so that its users can dial in to the neighbor's modem pool.

  For example, suppose you run an ISP that has such a modem sharing arrangement. When the users of the other ISP dial in to your modems, your server contacts the ISP's remote server for authentication and authorization information. The remote server authenticates the user and sends, through your server, all the information needed to configure the user's session on your client.

  Because you are in a reciprocal arrangement with the other ISP, your users can dial in to it and be forwarded to your server. You and the other ISP can accumulate accounting records for each other's users and determine how the services are billed.

  Each ISP with which you have a business relationship can specify a server to act as a remote server for proxy service. In some geographic areas, ISPs are establishing consortia to pool modems throughout the region by using remote servers.

       How Proxy Service Works

  Suppose the user of another ISP dials in to your ISP. Your network access server--such as a PortMaster--sends its RADIUS access request to the forwarding server --your RADIUS server, also known as the proxy server. The RADIUS server parses the remote server's realm  from the user's request. Your RADIUS server acts as a client to the remote server and shares a secret with it. RADIUS forwards the request to the remote server  identified by the realm. The remote server sends a response (either access-accept, access-reject, or access-challenge) back to the forwarding server, which sends it back to the NAS. This process is illustrated in Figure 9-1.

  Figure 9-1 How Proxy Service Works

  If the access-request is accepted, the NAS and the forwarding and remote servers process an accounting-request as follows:

  1. The NAS sends an accounting-request to the forwarding server.

  2. The forwarding server writes the request to its accounting log.

  3. The forwarding server forwards the request to the remote server.

  4. The remote server logs the accounting-request and sends an accounting-response to the forwarding server.

  5. The forwarding server sends the accounting response to the NAS.

  Both your forwarding server, which receives the access request directly from the NAS, and the remote accounting server store the accounting information in the directories /usr/adm/radacct/ name_or_address/detail . The RADIUS daemon on each server creates the name_or_address directory. The forwarding server substitutes the name of the NAS for name_or_address. If the IP address of the NAS cannot be resolved to a hostname, then the IP address of the NAS is used rather than its name. On the remote server, the name is based on the hostname (or IP address) of the forwarding server the request was received from.

  Note ¯ If the request is forwarded across a chain of forwarding servers, the accounting records are stored on all servers in the chain.

  Realms.  The forwarding server sends the request to the remote server specified by the authentication realm . There are two kinds of realms:

•  A named realm  is the part of a user login following the at  sign (@). For example:

    ¯ If isolde@cornwall.net  is the user login, cornwall.net  is the realm.

    ¯ If sequoyah@cheroke e is the user login, cherokee  is the realm.

    A domain name is frequently used as the named realm to provide uniqueness.

•  A numbered realm  is a Called-Station-Id. You can establish a number for users to call if they need proxy service, and forward proxy requests based on the number called.

  RADIUS searches for numbered realms first. If you are using numbered realms and the RADIUS server must respond to points of presence (POPs) from multiple area codes, you must specify the area code for each PortMaster in the proxy  file on the RADIUS server.

  Here is an example of a proxy file for POPs in two different area codes:

  tracy.dog.net frtp67w3g3$1 2095559288

  sanramon.dog.net xst1ru83vm7s3yhp 9255554613

  With the following example profile, user bridget can be authenticated when she calls in to either of the POPs whose numbers are listed in her profile as Called-Station-Ids:

  bridget Password = "knppog8"

  Service-Type = Framed-User,

  Framed-Protocol = PPP,

  Framed-IP-Address = 255.255.255.254,

  Framed-Routing = None

  Note ¯ Usernames with embedded @ s--such as tristram@cornwall.net --are treated as proxy realms.

  Note ¯ RADIUS 2.1 currently supports the old username style, realm/ user. Lucent InterNetworking Systems might not support this style in future releases and recommends that you avoid such usernames. The at sign (@ ) always takes precedence over the slash sign (/ ). As a consequence, the radiusd  daemon interprets a/b@c as user a/b in the named realm c. Lucent InterNetworking Systems strongly recommends avoiding such mixed usage.

  Proxy-State Attribute.  When a forwarding server passes along an access request to another server, the server can add a Proxy-State attribute. The attribute must be returned unmodified in the reply packet, whether that response is an access-accept, an access-reject, or an access-challenge. The forwarding server removes the Proxy-State attribute before sending the response back to the requesting client. Because access-accept and access-reject replies are authenticated on the entire packet contents, the forwarding server must re-sign the packet. See "Request-Authenticator" on page 8-10 for information about packet signatures.

  Each forwarding server in a proxy chain can add a Proxy-State attribute after those added by previous servers in the chain. No server can modify or remove any Proxy-State attribute except its own. The reply from the remote server maintains the order of the Proxy-State attributes. Each server in turn then removes the last Proxy-State added--which must be its own--and passes the remaining Proxy-State attributes along when it sends the reply back down the proxy chain to the NAS.

  You can include the old  keyword in the proxy file entry for a remote server to communicate with RADIUS servers that do not support proxy. Using this keyword prevents the server from adding a Proxy-State attribute when it forwards a request and from removing a Proxy-State attribute when it receives the reply.

  A summary of the Proxy-State Attribute format is shown below.

  Table 9-1 Proxy-State Attribute as Currently Implemented in Lucent RADIUS 2.1 

 

Octet	Contents
0	Numeric code for attribute name. For Proxy-State, the code is 33 .
1	Length of attribute in bytes. This value is currently 30.
2-5	Timestamp--in seconds since epoch--that packet reached forwarding server.
6-9	Client IP Address from which packet was received.
10-11	Client source port from which packet was received.
12	ID of packet received from client.
13	Pad byte. This value is currently 0 .
14-29	Client request authenticator.

  Note ¯ The Lucent RADIUS Proxy-State attribute consists of an opaque sequence of octets and is subject to change without notice. The attribute value is only meaningful to the server that sent the attribute.

       Servers Running Proxy Service

  Both the forwarding server and the remote server must be running RADIUS for UNIX version 2.1 or later, or Lucent's Port Authority RADIUS server. Any third-party RADIUS-conforming proxy server can probably work as either the forwarding server or remote server, but Lucent InterNetworking Systems has not tested proxy service with other RADIUS servers to determine if they correctly implement proxy. Lucent InterNetworking Systems RADIUS versions 2.0.1 and earlier do not support proxy RADIUS. However, a remote server can use the earlier versions of Lucent RADIUS if the proxy file on the forwarding server has the old  keyword set in its proxy file entry for the remote server.

  The RADIUS server uses the following UDP ports by default:

•  1645 for RADIUS authentication
•  1646 for RADIUS accounting
•  1650 for proxy requests and responses
•  1651 for proxy requests and responses

  The forwarding and remote servers can run on different operating systems. A RADIUS server can function both as a forwarding server and remote server, acting as a forwarding server for some realms and as a remote server for other realms. A remote server can in turn forward a request to another remote server.

  One forwarding server can forward to any number of other forwarding or remote servers, but only one per realm. A remote server can have any number of servers forwarding to it and can provide authentication for any number of realms.

       Proxy Confederations

  Proxy service requires planning and cooperation between different business entities. The typical implementation involves a confederation of businesses designating a single proxy forwarding server to serve as a clearinghouse  server. Within each organization's system, the forwarding server knows only the address of the clearinghouse server. The clearinghouse server knows the addresses of all remote servers in the confederation. Figure 9-2 shows how this typical proxy confederation works.

  Figure 9-2 One Practical Implementation of Proxy Service

  Suppose a NAS sends a proxy request to the RADIUS forwarding server. If the realm is not found in the proxy  file, the request is forwarded to the clearinghouse server. The clearinghouse server performs the lookup for the request and forwards the request to the desired remote server. The remote server sends the appropriate information back to the clearinghouse server, which in turn passes the information to the original forwarding server.

  Each RADIUS server also acts as a remote server to the clearinghouse server. The clearinghouse server functions as both a forwarding server and a remote server to the servers at the ends of the confederation.

  If you are using a clearinghouse remote server, you can define it as your default by specifying the realm name DEFAULT  (all uppercase letters). Proxy requests are forwarded to the DEFAULT server if the named realm has no other entry in the proxy  file.

  Note ¯ You must ensure that the servers in a proxy system do not forward to each other, which creates a forwarding loop that passes packets back and forth between them. For example, this situation occurs if a proxy file has an incorrect entry that associates the realm of the next server in the proxy chain with the IP address of the previous server in the chain.

       Configuring Proxy Information on the Server

  To use the proxy service, you must configure RADIUS as you would normally, with the following additions:

•  You must create a proxy  file on each forwarding server.
•  If you are using any named realms, the remote server must also have a proxy  file so that it can authenticate them. If you are using only numbered realms, the remote server needs no proxy file.

    Caution ¯ Because the proxy  file contains the shared secrets for the proxy servers, verify that only root users have read and write access to the file.

       Components of the proxy File

  You create a proxy  file in the /etc/raddb  directory on the forwarding server and, if necessary, on the remote server. Each entry or line in the proxy  file describes one realm.

  Here is a sample proxy  file:

  #remote server

  #hostname or optional ports

  #IP address shared secret realm or keywords

  #-------------- ----------------- ------- -----------------

  radius.edu.net vdlk4%#p67w3g&g1 edu.net

  s134.net.com ru83vm7xst1shm!p 5551234 1812 1813

  net54.edu.net 2hbtr5$w*3m7xstt 5555624

  s134.net.com x56jy76mgpkst 5551134

  rad.edu.com ch5#5eb716erth edu.com 1645

  rad7.com.net lx4zDFapa3ep com.net 1645 1646 old

  eg.edu.net e997asepdflj edu.net old secure

  An entry contains the following information, all separated by spaces or tabs:

•  Hostname or IP address of the remote server for the realm--a server acting as a remote server to this server, but which might in turn forward the request.
•   Secret shared between this same server and the remote server.
•   Realm handled by the remote server.

  You can optionally include the following additional information in a proxy  file entry:

•  UDP port number for RADIUS authentication
•  UDP port number for RADIUS accounting
•  One or more keywords to affect the server behavior

    ¯ old --This keyword causes the server to strip the realm from the login name and not attach Proxy-State when forwarding access-requests. Use this keyword when you are forwarding requests to servers with RADIUS versions older than 2.1.

    Caution ¯ Use the secure  keyword with only if you want certain users to be granted administrative privileges.

    ¯ secure --This keyword enables the remote server to authorize someone to log in to your NAS with administrative privileges. If this keyword is not present, an access-accept message from the forwarding server to the client that grants administrative access (either Service-Type = Administrative-User or Service-Type = NAS-Prompt-User) is sent to the client as an access-reject.

    The RADIUS server generates a syslog  message similar to the following (shown on three lines for clarity):

    Jul 10 21:10:00 ra radius[14870]: remote server 192.168.96.6/1645.4 returned insecure service for client 172.16.3.24/1039.17, sending reject instead

    ¯ ipass --This keyword instructs the server to use the iPass protocol rather than the RADIUS protocol to communicate with the remote server. See Appendix E, "Contact Information for Third-Party Products," for information on how to contact iPass, Inc. for more information.

  You can include the optional information in any order in the proxy  entry, after  the first three mandatory fields. If you specify only a single UDP port number, the server interprets this as the RADIUS authentication port number. If you specify two UDP port numbers, the first number is interpreted as the RADIUS authentication port and the second number as the RADIUS accounting port. If you do not specify any ports in the proxy entry, the server uses its own port numbers for communication with the remote server.

  If a remote server--the final server in the proxy chain--has a proxy  file, the file must have an entry configured for each of the server's own realms. This entry must include the following information:

•  Server's own hostname or IP address
•  Unique shared secret--this secret is not configured on any other device
•  Realm for which this server is authoritative

       Special Realms: DEFAULT and NOREALM

  You can include entries in your proxy  file for the special realms DEFAULT and NOREALM. The following example shows sample DEFAULT and NOREALM entries:

  center.com.net e199aespfdx4 DEFAULT

  others.com.net e19aepsfd9x4 NOREALM

  Requests are forwarded to the DEFAULT server if their named realm has no other entry in the proxy  file. You might use the DEFAULT realm to define the entry for a clearinghouse server.

  When you want users that have no realm to be forwarded to a specific server, you can create a NOREALM entry for that server. Consider the situation where for performance reasons you have configured your network access servers to communicate with many forwarding servers that each have proxy  files but no local users  files. You can use the NOREALM entry in each of these proxy files to forward all the local users--those who log in without specifying a realm--to your full RADIUS server for authentication.

  The last DEFAULT and NOREALM entries in the proxy file are the ones used. Whenever you update the proxy file, the RADIUS server reads it into memory in its entirety. The RADIUS server uses the copy in memory rather than reading the file each time it needs to access a proxy entry.

       On the Forwarding Server

  The RADIUS clients  file must have an entry for the name or IP address and the shared secret of the NAS. If the forwarding server is in a chain of multiple servers, the clients  file must contain the name or IP address and the shared secret of any servers for which it forwards requests.

  The proxy  file must have an entry for the name or IP address, shared secret, and realm of all remote RADIUS servers. The shared secret in the forwarding server's proxy  file must match the shared secret in the remote server's clients  file.

  Remote in this instance means a server to which the forwarding server sends a request for authentication. That server might be the ultimate server in the proxy chain and process the request, or it might in turn forward the request on, until the request reaches the ultimate server in the proxy chain and is processed for authentication.

       On the Remote Server

  The clients  file must contain the name or IP address and the shared secret of all forwarding servers. The shared secret must match the shared secret in each forwarding server's proxy  file.

  If any named realms are used, the proxy  file must contain the name or IP address of the remote server, an unused dummy secret, and the realm for which this remote server is authoritative. If only numbered realms are used, then no proxy  file needs to be defined on the remote server.

       Example Proxy Server Relationships and Configuration Steps

  Figure 9-3 illustrates the client/server relationships in a system that includes two forwarding servers and a remote server.

  Figure 9-3 Proxy Server Relationships

  The NAS is a client to server #1. Server #1 is a client to server #2. Server #2 is a remote server to server #1, and a client to server #3. You must include each client's name or IP address and shared secret in the clients  file of its associated server. Each client/server pair must share a secret. You must configure each server's proxy  file to point to the next server in the chain, including the name or IP address, shared secret, and realm of the next server. The secret you configure in the proxy  file must match the secret configured in the clients  file of the next server in the chain.

  Figure 9-4 shows how secrets are shared between devices in a proxy chain. In this example, shared secrets #2 and #6 can be identical, but need not be. Shared secrets #3 and #5 can be identical, but need not be.

  Figure 9-4 Shared Secrets

  Figure 9-5 provides a detailed example of the proxy relationships shown in Figure 9-3. In this example, the server xroad.net acts as a clearinghouse server for ISPs in Argentina (estancia.net) and New York (redsauce.net). The clearinghouse server proxies requests in both directions.

  To properly configure the components of the proxy service shown in Figure 9-5, where each NAS is a PortMaster, the administrators must perform the steps described below. This example considers the case of a user with a home account in New York who travels to Argentina.

  1. On PortMaster pm1.estancia.net, enter the following commands to set the RADIUS authentication and accounting servers:

  set authentic 192.168.190.21 1645

  set secret ujm49fud3$$

  set accounting 192.168.190.21 1646

  2. Determine the IP address or fully qualified domain name of each NAS and server.

  In this example, you have the following from the viewpoint of someone dialing in to the ISP in Argentina:

  ¯ PortMaster named pm1.estancia.net with IP address 192.168.190.20

  ¯ Forwarding server named jorge.estancia.net with an IP address of 192.168.190.21 in the realm estancia.net

  ¯ Clearinghouse server xroad.net with an IP address of 172.30.140.2

  ¯ Remote server named vinnie.redsauce.net with an IP address of 172.16.240.111 in the realm redsauce.net

  ¯ PortMaster named pm22.redsauce.net with IP address 172.16.240.110

  3. On forwarding server jorge.estancia.net, configure the following:

  ¯ Contents of /etc/raddb/clients 

  pm1.estancia.net ujm49fud3$$

  xroad.net thx1984

  ¯ Contents of /etc/raddb/proxy 

  xroad.net m72hbtr5$w3xst redsauce.net

  jorge.estancia.net dummysecret estancia.net

  DEFAULT can be substituted for the realm redsauce.net.

  Figure 9-5 Proxy Server Relationships

  4. On clearinghouse server xroad.net, configure the following:

  ¯ Contents of /etc/raddb/clients 

  jorge.estancia.net m72hbtr5$w3xst

  vinnie.redsauce.net kntbr352bfd

  ¯ Contents of /etc/raddb/proxy 

  vinnie.redsauce.net qbfja97-8 redsauce.net

  jorge.estancia.net thx1984 estancia.net

  5. On remote server vinnie.redsauce.net, configure the following:

  ¯ Contents of /etc/raddb/clients 

  xroad.net qbfja97-8

  pm22.redsauce.net bws5629s$r53

  ¯ Contents of /etc/raddb/proxy 

  xroad.net kntbr352bfd estancia.net

  vinnie.redsauce.net dummysecret2 redsauce.net

  DEFAULT can be substituted for the realm estancia.net.

  6. On PortMaster pm22.redsauce.net, enter the following commands to set the RADIUS authentication and accounting servers:

  set authentic 172.16.240.111

  set secret bws5629s$r53

  set accounting 172.16.240.111

  7. Define the user profiles.

  You must define a user profile in the users  file of the remote server for each user that is to be authenticated via the remote server.

  If the user's password is stored in the users  file, an example user profile for marciano on vinnie.redsauce.net is the following:

  marciano Password = "jmp$f87"

  Service-Type = Framed-User,

  Framed-Protocol = PPP,

  Framed-IP-Address = 255.255.255.254,

  Framed-Routing = None

  However, if marciano's password is stored in the /etc/passwd  file, an example user profile is the following:

  marciano Auth-Type = System

  Service-Type = Framed-User,

  Framed-Protocol = PPP,

  Framed-IP-Address = 255.255.255.254,

  Framed-Routing = None

  If marciano goes to Argentina on a business trip and dials in to the network at estancia.net, he must enter marciano@redsauce.net  at the password login prompt.

  8. Run the radiusd daemon on servers jorge.estancia.net, xroad.net, and vinnie.redsauce.net.

  The RADIUS accounting records for proxy users are logged into the detail file of all the servers.