RADIUS: Secure Authentication Services at Your Service - Page 2

By Debbie Deutsch | Posted Jul 29, 2003
Page 2 of 4   |  Back to Page 1
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

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:

  1. The RADIUS client receives the account username and password from the end user.

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

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

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

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

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter