RADIUS Proxy Service : ROAMING

New version of RADIUS supports proxy service. Proxy service enables a RADIUS 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 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-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 Figure1.

Figure 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:

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.

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:

isolde@cornwall.net

cornwall.net

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:

T2dialup.afnogws.afnog.org xst1ru83vm7s3yhp 9255554613

Servers Running Proxy Service

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 2 shows how this typical proxy confederation works.

Figure 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.

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.

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.afnog.org vdlk4%#p67w3g&g1 afnog.org

s134.cedeao.org ru83vm7xst1shm!p 5551234 1812 1813

cisco.cybercom.tg ch5#5eb716erth cybercom.tg 1645

rad7.softnet.tg lx4zDFapa3ep softnet.tg 1645 1646 old

NAS1.cafe.tg e997asepdflj cafe.tg 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

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

secure

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

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.

Figure 3 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 3 Shared Secrets

Figure 4 provides a detailed example of the proxy relationships .

In this example, the server xroad.net acts as a clearinghouse server for ISPs in Cape Town (radius.co.za) and Lome (radius.tg). The clearinghouse server proxies requests in both directions.

To properly configure the components of the proxy service shown in Figure 4, where each NAS, the administrators must perform the steps described below. This example considers the case of a user with a home account in Lome (TOGO) who travels to Cape Town (South Africa).

1. On NAS nas.radius.co.za, enter the following commands to set the RADIUS authentication and accounting servers:

radius-server host 192.168.190.21 1812

radius-server key ujm49fud3$$

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 Cape Town:

NAS named nas.radius.co.za with IP address 192.168.190.20

Forwarding server named capetown.radius.co.za with an IP address of 192.168.190.21 in the realm radius.co.za

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

Remote server named lome.radius.tg with an IP address of 172.16.240.111 in the realm radius.tg

NAS named nas.radius.tg with IP address 172.16.240.110

3. On forwarding server capetown.radius.co.za, configure the following:

Contents of /etc/raddb/clients

nas.radius.co.za ujm49fud3$$

serveur.router.net thx1984

¯ Contents of /etc/raddb/proxy

serveur.router.net m72hbtr5$w3xst radius.tg

capetown.radius.co.za secret radius.co.za

DEFAULT can be substituted for the realm radius.tg.

Figure 4 Proxy Server Relationships

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

Contents of /etc/raddb/clients

capetown.radius.co.za m72hbtr5$w3xst

lome.radius.tg kntbr352bfd

Contents of /etc/raddb/proxy

lome.radius.tg qbfja97-8 radius.tg

capetown.radius.co.za thx1984 radius.co.za

5. On remote server lome.radius.tg, configure the following:

Contents of /etc/raddb/clients

serveur.router.net qbfja97-8

nas.radius.tg bws5629s$r53

Contents of /etc/raddb/proxy

serveur.router.net kntbr352bfd radius.co.za

lome.radius.tg confidential radius.tg

DEFAULT can be substituted for the realm radius.co.za.

6. On NAS NAS.radius.tg, enter the following commands to set the RADIUS authentication and accounting servers:

radius-server host 172.16.240.111

radius-server key bws5629s$r53

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 kodjo a togolese user goes to Cape Town on a business trip and dials in to the network at radius.co.za, he must enter kodjo@radius.tg at the password login prompt.

8. Run the radiusd daemon on servers capetown.radius.co.za,serveur.router.net, and lome..radius.tg.

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