Introduction to Radius
The Remote Authentication Dial-In User Service (RADIUS) is a client/server
security protocol created by Livingston Enterprises, Inc . RADIUS is an Internet
draft standard protocol.
See RFCs 2865 and 2866
User profiles are stored in a central location, known as the RADIUS server.
RADIUS clients (Network Access Server ) communicate with the RADIUS server
to authenticate users. The server specifies back to the client what the authenticated
user is authorized to do. RADIUS server is usually a daemon process running
on a UNIX or Windows NT machine. A RADIUS server can act as a proxy client
to other RADIUS servers or other kinds of authentication servers. Although
the term RADIUS refers to the network protocol that the client
and server use to communicate, it is often used to refer to the entire client/server
Communication between a network access server (NAS) and a RADIUS server is
based on the User Datagram Protocol (UDP). Generally, the RADIUS protocol
is considered a connectionless service. Issues related to server availability,
retransmission, and timeouts are handled by the RADIUS-enabled devices rather
than the transmission protocol.
- The RADIUS server uses the User Datagram Protocol (UDP) and the following
If different ports are assigned to these services in the /etc/services
file, RADIUS uses those ports in preference to the default ports listed above.
You can also specify different UDP ports by using the radiusd -p
portnumber command on UNIX hosts. Port 1812 is reserved
for RADIUS authentication and port 1813 is reserved for RADIUS accounting
- Port 1645 for authentication
- Port 1646 for accounting
How it works
This figure shows the interaction between a dial-in user and the RADIUS client
1- User initiates PPP authentication to the NAS.
- 2- NAS prompts for
username and password (if PAP) or challenge (if CHAP).
- 3- User replies.
- 4- RADIUS client sends username and encrypted password to
the RADIUS server.
- 5- RADIUS server responds with Accept, Reject, or Challenge.
- The RADIUS client acts upon services and services
parameters bundled with Accept or Reject.
Authentication and Authorization
The RADIUS server can support a variety of methods to authenticate a user.
When it is provided with the username and original password given by the user,
it can support PPP, PAP or CHAP, UNIX login, and other authentication mechanisms.
Typically, a user login consists of a query (Access-Request) from the NAS
to the RADIUS server and a corresponding response (Access-Accept or Access-Reject)
from the server. The Access-Request packet contains the username, encrypted
password, NAS IP address, and port. The format of the request also
provides information about the type of session that the user wants to initiate.
For example, if the query is presented in character mode, the inference is
"Service-Type = Exec-User," but if the request is presented in PPP packet
mode, the inference is "Service Type = Framed User" and "Framed Type = PPP."
When the RADIUS server receives the Access-Request from the
NAS, it searches a database for the username listed. If the username does
not exist in the database, either a default profile is loaded or the RADIUS
server immediately sends an Access-Reject message. This Access-Reject message
can be accompanied by a text message indicating the reason for the refusal.
In RADIUS, authentication and authorization are coupled together.
If the username is found and the password is correct, the RADIUS server returns
an Access-Accept response, including a list of attribute-value pairs that
describe the parameters to be used for this session. Typical parameters include
service type (shell or framed), protocol type, IP address to assign the user
(static or dynamic), access list to apply, or a static route to install in
the NAS routing table. The configuration information in the RADIUS server
defines what will be installed on the NAS. The figure below illustrates the
RADIUS authentication and authorization sequence.
The accounting features of the RADIUS protocol can be used independently of
RADIUS authentication or authorization. The RADIUS accounting functions allow
data to be sent at the start and end of sessions, indicating the amount of
resources (such as time, packets, bytes, and so on) used during the session.
An Internet service provider (ISP) might use RADIUS access control and accounting
software to meet special security and billing needs.
Transactions between the client and RADIUS server are authenticated
through the use of a shared secret, which is never sent over the network.
In addition, user passwords are sent encrypted between the client and RADIUS
server to eliminate the possibility that someone snooping on an insecure network
could determine a user's password.
- RADIUS offers the following features:
In large networks, security information can be scattered throughout
the network on different devices. RADIUS allows user information to be stored
on one host, minimizing the risk of security loopholes. All authentication
and access to network services is managed by the host functioning as the RADIUS
Using modifiable "stubs," RADIUS can be adapted to work with existing security
systems and protocols. You adapt the RADIUS server to your network, rather
than adjusting your network to work with RADIUS.
The RADIUS server stores security information in text files at a central location;
you add new users to the database or modify existing user information by
editing these text files.
Extensive auditing capabilities
RADIUS provides extensive accounting trail capabilities, referred to as
RADIUS accounting . Information collected in a log file can be analyzed
for security purposes or used for billing.
- RADIUS 2.1 provides the following enhancements
to improve RADIUS functionality:
Proxy RADIUS enables your RADIUS server to forward
authentication requests from a network access server (NAS) to a remote RADIUS
server and to pass the reply back to the NAS. This feature enables cooperating
Internet service providers (ISPs) to handle dial-in service requests from
each other's users. Corporate users can easily forward packets from local
to remote networks.
RADIUS now supports ActivCard authentication on the
following platforms supported by ActivCard 2.1: AIX, HP-UX, Solaris, and
Sun-OS. ActivCard authenticates users by means of dynamic passwords generated
by a handheld token using the public Digital Encryption Standard (DES) algorithm.
The RADIUS server can forward all requests specified by the user profiles
to the ActivCard server.
You can restrict the number of logins permitted to specified telephone
The syslog message for many kinds of rejected access-requests
now includes the Calling-Station-Id--if known--enabling you to track down
where the failed login attempts are dialing from.
You can turn on RADIUS debugging by sending
a SIGUSR1 signal to radiusd . Sending a SIGUSR2 signal to radiusd
turns debugging off. The RADIUS server logs a short summary message of
radiusd activity when either signal is sent and when radiusd
Table1 provides a quick overview of the tasks required to install and
Table1 Overview of RADIUS Installation and Configuration
|1. Select a host to use as the RADIUS server.
|2. Install the RADIUS server software on the host.
|3. Configure client information on the RADIUS server.
|4. Configure the NAS as a RADIUS client.
|5. Configure user profiles.
|6. You can optionally define menus to enable authenticated users to select
different login options.
|7. You can optionally install and configure RADIUS accounting.
|8. You can optionally configure RADIUS proxy service.
Current Users of RADIUS
Any company with a centralized MIS department managing a large corporate
network is concerned with security issues.
1- RADIUS is being used to secure several university networks that provide
dial-in IP connectivity to students and faculty.
2- Several Internet service providers use RADIUS
to provide security to users accessing their networks from multiple POPs
(Points Of Presence). UNIX security systems are typically used in these environments.
3- Radius is now used to authenticate users for services ftp, pop etc....