RADIUS ensures that remote users are who they say they are, keeps track of their network usage, and secures your network infrastructure from intrusion. Learn how deploying RADIUS in-house or as a managed service can benefit you and your company's network.
Isn’t it wonderful that we can connect to ISPs or office networks from anywhere, using any access technology? Have you ever wondered how ISPs and office networks know whether or not a user has a legitimate account? And how does a provider keep track of a user's access time anyway? The answer is very likely RADIUS, the most widely deployed example of an Authentication, Authorization, and Accounting system (sometimes called AAA systems).
RADIUS is a set of AAA standards that has been implemented by many vendors. It has been around for ages, quietly providing services that keep networks secure from unauthorized use. Let's delve in and learn more about this useful capability and how it can benefit you and your company's network.
Thirty years ago, ARPANET, the predecessor to the Internet, was built to permit dumb terminals to access remote computing resources. In the days before PCs and LANs, the hardwired connection between the terminal and computer was managed by a Terminal Interface Processor, or TIP. But even then, managers, developers, and users wanted to be able to work from home or on the road (dial-up via an acoustically-coupled modem). Bandwidth was scarce and expensive, and people wanted to protect the network, and the mainframes and minicomputers on it, from unauthorized access and possible disruption.
It quickly became apparent that the use of unlisted dial-in numbers was not a secure answer. Was there something that could be done to further protect the network from unauthorized access? TACACS, the original AAA system, was developed for the ARPANET to solve that problem. Later, commercial companies adopted and extended the technology in open and proprietary ways. With experience and the expanding use of data networks, the limitations of the original TACACS architecture became apparent.
RADIUS was originally developed by Steve Wilens of Livingston Enterprises and then later acquired by Lucent Technologies in 1992, and is now an IETF standard. The most recent version is RFC 2865 (June 2000), which covers both authentication and authorization. A companion IETF document, RFC 2866, describes how to extend RADIUS to implement accounting services.
What Is It Used For?
The need for AAA systems has grown tremendously over the years. Corporations (and carriers) still support dial-up lines of course, but now remote users also access networks via VPNs and broadband, while employees and guests connect to internal wireless networks simply by powering up their laptops and PCs. Today's AAA systems must be highly robust, scaleable, secure, and easily manageable to meet the needs of a modern IT environment.
Basic RADIUS implementations provide access control by authenticating end users and authorizing their requests, while extended implementations include user accounting. Depending on the RADIUS product, you can:
- Centrally administer access to your network resources, perhaps with fine control over access based on time of day or by regulating the number of simultaneous log-ins by a single user
- Utilize the function and information from your other access control systems, such as the Netware NDS and Windows Active Directory
- Allow your dial-in or VPN service vendors to query your access control database, so any changes you make are automatically available to them
- Create central summary or real-time reports that can audit usage for tracking and billing
If you have not already implemented RADIUS in your network, new technologies like wireless Ethernet should prompt you to consider it for the future.
Page 2: How RADIUS Works
How RADIUS Works
Fundamentally, “RADIUS is a highly extensible UDP client/server application protocol. A full server implementation of RADIUS consists of two servers: the RADIUS server itself (for Authentication and Authorization) and the RADIUS accounting server that binds to UDP ports 1812 and 1813, respectively,” says Bruce Morrison of Pegasus Networks. There are actually three types of applications that participate in RADIUS: the end user, the RADIUS client, and the RADIUS server.
- The end-user application, such as a dial-up utility, is in the end user’s PC or laptop. It talks with the RADIUS client as part of establishing a connection.
- Typically, the RADIUS client software is installed in a device at the network edge, where external traffic first enters a company’s or ISP’s infrastructure. For example, it could be located in a remote access server or firewall. The RADIUS client communicates with the end user and with the RADIUS server.
- The RADIUS server can be anywhere. The only requirement is for reliable and sufficient network connectivity between it and its clients. The RADIUS server checks the configuration database and processes the request using one or more authentication mechanisms. The database contains client service configuration data as well as specific rules for granting access. The database can be implemented separately from the server.
Because each of the three software packages is typically developed and marketed by different vendors, adherence to standards is very important.
Here are the step by step details of what happens when an end user account accesses a network using RADIUS authentication:
- The RADIUS client receives the account username and password from the end user.
- The client sends an Access-Request to the RADIUS server with information such as the end user’s username, password, and the port-id on which the end user’s traffic is arriving over the network. The client is configured to wait for a response for a specified time. It may try again by retransmitting the request to the same server or to a different one.
- When a server receives the Access-Request, it first validates the sending client. It then authenticates the end user data by consulting the end user database entry to verify the password and any additional requirements, such as which clients or client ports the end user is permitted to use.
- If a server does not have direct access to the required database entry, and if it has been configured appropriately, the RADIUS server can act as a proxy and query another RADIUS server to get the information it needs. This facilitates implementation of capabilities such as roaming, in which one administrative entity “owns” the user and another administrative entity owns the network where access is managed.
- Finally, if and when the server is satisfied that the end user is authenticated and authorized to access the network, the RADIUS server sends a list of service configuration values back to the client. For example, a SLIP or PPP connection might be specified with values for the IP address and subnet mask. The client implements these values and the end user is given access to the network.
Additional steps might be needed if accounting options are enabled. The client might notify the server at the start and end of a session, and proxies can be used for accounting, just as they are in establishing authentication and access authorization.
Page 3: A Relationship Based on Security and Trust
A Relationship Based on Security and Trust
Security and trust are at the heart of the RADIUS client and server interaction. Their transactions are authenticated using a shared secret. To be certain that an outsider can never spoof either party, the shared secret is never transmitted over the network. Instead, it is configured directly into the client and server. The protocol also allows RADIUS servers to issue cryptographically-based challenges (ultimately responded to by the end user) as an extra security measure.
What makes RADIUS so versatile is that it does not dictate the end user connection or communication with the client, so it could be dial-up, hardwired to a switch port, wireless, or some new technology that hasn’t been invented yet. The connection password can and should be protected using a mechanism appropriate to the link technology. It also does not dictate the method used by the server to authenticate a password, once it knows the end user’s username and password.
The basis of RADIUS operations is the exchange of attributes between the client and server. The use of standard attributes, such as user name, password, service, addressing, and timeout information, is determined by your requirements and configuration.
RADIUS also supports the use of vendor-specific attributes — vendor-defined extensions that are implemented in only certain products, such as one vendor’s firewalls or remote access servers. When purchasing a RADIUS server, make sure that it has support for the vendor-specific attributes that are important to your network and the equipment (associated with clients) that you have or are planning to buy.
Deployment Architecture Choices
Since RADIUS supports distributed operations, the first important decision in your RADIUS deployment design is whether to outsource the management of the servers or to keep it in-house. If you neither have nor want to acquire in-house RADIUS expertise, the cost of outsourcing may compare favorably with in-house RADIUS server acquisition and operation.
If you do decide to keep it in-house, there are some important considerations for the RADIUS implementation. The RADIUS server software runs on either a dedicated or shared server platform. Like any popular client-server protocol, RADIUS server implementations are available for a variety of operating system environments, including network appliances.
Since the goal of RADIUS is to secure and control access to your network, proper RADIUS database configuration is paramount. It all comes down to good policy design first, and then implementation in the RADIUS server. Your access policy covers the rules for granting access to the network and specifying when and how RADIUS security mechanisms are used to safeguard its operation. It may be as simple as table look-ups, or it may use more sophisticated logic to look at history, behavior, or current conditions.
The configuration also includes the distribution and storage of the shared client and server secrets, and if and when challenges are used. Good security design is based on experience and an understanding of your particular needs, as well as the specifics of your network technology. If you don’t have in-house expertise, consider some outside help.
Page 4: Performance Issues
This article was originally published on Tuesday Jul 29th 2003
RADIUS performance can be sensitive to client retransmission or retry strategies. There is no explicit way for a RADIUS server to tell a client it is busy. Instead, RADIUS relies on the client to be well-behaved, waiting a reasonable amount of time before retransmitting the request to the same server, or contacting a different RADIUS server.
A badly configured client can quickly overload the servers with repeated requests. When planning a RADIUS deployment, you should remember that this is a client-side issue, not a problem in the server. Your goal should be to configure clients with a reasonable retransmission/retry strategy. That will depend on what is supported.
You should also aim to have sufficient server capacity so that the lack of a response is most likely due to a server’s being off the network rather than being overloaded. In addition, clients should be configured not to send test requests to RADIUS servers just to see if they are available.
Use of proxies is another consideration for RADIUS deployment design. Many small and medium-sized enterprises do not need proxies. However, using RADIUS proxies can help distribute administration in large or geographically dispersed organizations, or it can be a good means to gain quick response time for user database changes. Beware, however, that using proxies may represent a potential security concern, especially if they are not under your direct control.
RADIUS performance, availability, and scalability rely on good management of load and congestion. You need to look at total server capacity (based on hardware and software), the number and location of servers, balancing load across servers, and network connectivity/bandwidth between clients and servers. These design issues are common to many client-server architectures, not just RADIUS.
Just as TACACS was superceded by RADIUS, RADIUS itself may be replaced at some point in the future. Work on DIAMETER, a potential successor to RADIUS, has been going on for a number of years in the IETF’s AAA Working Group. DIAMETER’s improvements include a fail-over strategy, use of TCP for reliable transport (instead of UDP, as RADIUS uses), and more general support for transmission-level security (via IPSEC).
DIAMETER also adds required support for server-initiated messages (to handle unsolicited disconnects, for example) and includes optional capabilities for data object security, which is particularly important when proxies are involved. It also is more explicit about the behavior of agents, such as proxies. While many of these added capabilities are of interest to companies, they are of greater and more immediate value to ISPs.
Unfortunately, the DIAMETER protocol is not directly compatible with RADIUS. However, it has been designed to coexist with RADIUS in the same network, cooperating via a gateway or a server that implements both.
RADIUS can be very useful for ensuring that remote users are who they say they are, keeping track of their network usage, and securing your network infrastructure from intrusion. If you are not already using RADIUS, what are you waiting for? If you do not have the expertise in-house to deploy it, consider using a managed service or an appliance.
Is it time to start considering DIAMETER products for your future deployments? Not just yet — while it is something to keep on your radar screen, DIAMETER is not far enough along in terms of standard vendor support or market acceptance to merit consideration for near-term implementation.
IETF specification for the RADIUS protocol: RFC 2865
IETF specification for RADIUS protocol accounting support: RFC 2866
IETF extension to RFC 2866 to include tunnel protocol support: RFC 2867
IETF extension to RFC 2865 to include tunnel protocol support: RFC 2868
IETF additional attributes that may be used with RFCs 2865 and 2866: RFC 2869
IETF specification for operation of RADIUS over IPv6: RFC 3162
IETF draft of DIAMETER base protocol (December 2002): draft-ietf-aaa-diameter-17.txt
Beth Cohen is president of Luth Computer Specialists, Inc., a consulting practice specializing in IT infrastructure for smaller companies. She has been in the trenches supporting company IT infrastructure for over 20 years in a number of different fields, including architecture, construction, engineering, software, telecommunications, and research. She is currently consulting, teaching college IT courses, and writing a book about IT for the small enterprise.
Debbie Deutsch is a principal of Beech Tree Associates, a data networking and information assurance consultancy. She is a data networking industry veteran with 25 years experience as a technologist, product manager, and consultant, including contributing to the development of the X.500 series of standards and managing certificate-signing and certificate management system products. Her expertise spans wired and wireless technologies for Enterprise, Carrier, and DoD markets.
See All Articles by Columnist Beth Cohen