RADIUS

written by: Hazrul Aaron; article published: year 2007, month 03;


In: Categories » Electronics and communication » Network security » RADIUS

This section takes a few steps to describe the basic principles of the AAA methodology, which is considered to be the fundamental structure behind the Remote Authentication Dial-In User Service (RADIUS). Additionally we briefly identify the functionality and principles of the RADIUS protocol. In the middle of the section we go through the steps required to install, configure, maintain, and monitor your RADIUS services. We conclude with practical implementations of the RADIUS protocol in relation to user authentication on wireless networks, as well as suggest useful software that will assist with your day-to-day use and administration of RADIUS servers for wireless user authentication.

Basics of AAA Framework

Authentication, authorization, and accounting (AAA) can be interpreted as a structure for controlling access to computer resources, enforcing policies, analyzing usage of resources, and providing the information necessary to charge for this service. These processes are considered vital for efficient and effective network management and security enforcement.

Even though the RADIUS protocol was developed before the existence of the AAA framework, it gives a good example of its implementation in practice. The AAA model outlines the three basic aspects of user access control, namely authentication, authorization, and accounting. These specifications are described next.

Authentication

Authentication is the process that provides a method of identifying users by requesting and comparing a valid set of credentials. The authentication is based on each user having a unique criteria for gaining access. The AAA-compliant server compares the user's authentication references with the database-stored information. If the credentials match, the user is granted access to the requested network resources; otherwise, the authentication process fails and network access is denied.

Authorization

Authorization follows authentication and is the process of determining whether the user is approved to request or use certain tasks, network resources, or operations. Usually, authorization occurs within the context of authentication and once the client is approved, he or she can use the requested resources. Therefore, authorization is a vital aspect of a healthy policy administration.

Accounting

The final aspect of the AAA structure is accounting, and it is best described as the process of measuring and recording the consumption of network resources. This allows the monitoring and reporting of events and usage for various purposes, including billing, trend analysis, resource utilization, capacity planning, and ongoing policy maintenance.

An Overview of the RADIUS Protocol

RADIUS is a widely used protocol implemented in many network environments. RADIUS can be defined as a security protocol that uses a client/server approach to authenticate remote users. This is carried out through a series of challenges and responses that the client relays between the Network Access Server (NAS) and the enduser. The RADIUS protocol has been composed because of the emerging demand for a method of authenticating, authorizing, and accounting for users who needed access to heterogeneous computing environments.

In this article, we intend to cover enough aspects of RADIUS to enable the reader to understand the practical implications of RADIUS in relation to wireless network authentication. If required, the complete description of the protocol and accounting procedures can be found in RFCs 2138 and 2139, which can be downloaded from http://www.ietf.org/rfc/rfc2138.txt and http://www.ietf.org/rfc/rfc2139.txt, respectively.

RADIUS Features

The RFC 2138 identifies the following key features of the RADIUS protocol:

  • Client/server model. A NAS operates as a client of RADIUS. The client is responsible for transferring user information to designated RADIUS servers and then acting on the received response. RADIUS servers are responsible for receiving user connection requests, authenticating the user, and then returning all the configuration details necessary for the client to deliver services to the user. Additionally the RADIUS server can act as a proxy client to other RADIUS servers or similar authentication servers.

  • Network security. Communication between the client and the RADIUS server is authenticated through the use of a shared secret that is never sent over the network in clear text. Also, the user passwords are sent encrypted between the client and the RADIUS server to eliminate the possibility of a sniffing attack.

  • Flexible authentication mechanisms. The RADIUS server allows for a variety of methods of authenticating a user. When it is provided with the username and original password given by the user, it can support PAP or CHAP, UNIX login, and other authentication methods such as PAM, LDAP, SQL, and so on.

  • Extensible protocol. All transactions are comprised of variable length Attribute–Length–Value (ALV) 3-tuples. New attribute values can be added without disturbing existing implementations of the protocol, thus making the protocol more flexible and dynamic to support new implementations.

Packet Formats

The RADIUS packet is encapsulated in a stateless UDP data stream that is addressed with the destination ports 1812, 1813, and 1814, representing access, accounting, and proxying, respectively. For compatibility and historical values, some servers are still erroneously running over ports 1645 and 1646. This dates from the early stages of the development of RADIUS and now actually conflicts with the "datametrics" service.

The elements of the RADIUS packet are described next.

  • Code. The Code field is one octet in length and identifies the type of RADIUS packet. When a server receives a packet with an invalid Code field, it ignores it without further notification. The packet types are examined in the next section.

  • Identifier. The identifier is a one-octet value that allows the RADIUS client to match a RADIUS response with the correct outstanding request.

  • Length. The Length field is two octets. It indicates the length of the RADIUS message and represents the corresponding sum of the Code, Identifier, Length, Authenticator, and Attribute fields.

  • Authenticator. This value is 16 octets long and is used to authenticate and verify the reply from the RADIUS server, and it is also used as the password hiding mechanism. The two types of values are the Request and Response authenticators. The former type should be a random and unique value used with Access and Accounting Request packets. The latter type is used in Access-Accept, Access-Reject, and Access-Challenge packets and contains a one-way MD5 hash calculated from a stream of values consisting of the Code, Identifier, Length, and Request Authenticator fields and the response Attributes, followed by the shared secret.

  • Attributes. The Attributes section of the packet classifies various characteristics and behavior patterns of the service, which usually announces a particular feature of the offered or requested service type. The six attribute types and their possible values are shown below:

RADIUS Attribute Types
Attribute Value Length in Octets Size (Bits) Examples
INT (Integer) 4 32 256

65536

ENUM (Enumerated) 4 32 1 = user name

2 = user password

13 = framed compression

26 = vendor-specific

STRING (String) 1–253 Varies "Any-string"

"192.168.111.111"

"www.arhont.com"

IPADDR (IP address) 4 32 0xFFFFFF

0x00000A

DATE (Date) 4 32 0xFFFFFF

0x00000A

BINARY (Binary) 1 1 0


Packet Types

The RADIUS server identifies the message types by the Code field in the RADIUS packet. The description of the codes can be found below. This section does not go into details of each of the RADIUS codes, as we consider them to be self-explanatory. However, if you require more details, please look at the Packet Types section of RFC 2138.

RADIUS Packet Codes
RADIUS Code Description
1 Access-Request
2 Access-Accept
3 Access-Reject
4 Accounting-Request
5 Accounting-Response
11 Access-Challenge
12 Status-Server (experimental)
13 Status-Client (experimental)
255 Reserved

legal disclaimer

1) Our website is not responsible for the information contained by this article as well for any and all copyright infringements by authors and writers. E-articles is a free information resource. If you suspect this article for any copyright infringements, please read the Terms of service and contact us to investigate the problem.
2) The E-articles directory team is not responsible for inaccuracies, falsehoods, or any other types of misinformation this tutorial may contain and will not be liable for any loss or damage suffered by a user through the user's reliance on the information gained here. Please read the Terms of service

Useful tools and features

Translate this article to...    Send this article to you or to a friend

Link to this article from your page   
If you like this article (tutorial), please link to it from your web page using the information above. Linking to this page, this is the only way to help us improve our service, the same time providing your visitors with a way to improve their online experience.

related articles

1. PDAs Versus Laptops
The first question that beginners ask before assembling their kit is whether a laptop or a PDA should be used for wireless penetration testing of any kind. Our answer is to use both if you can. The main advantage of PDAs (apart from size) is decreased power consumption, letting you cover a significant territory while surveying the site. The main disadvantage is the limited resources, primarily nonvolatile memory. The CPU horsepower is not that important here as we are not cracking AES. Other disadvantages are the limited amount...

2. Cryptographic Hash Functions
Can symmetric cryptography meet the requirements of the Biba model, based on the data integrity checks and proper authentication? The answer is "yes," but in a very inefficient way. Recall the practical authentication example with the UNIX (well, Linux in our case) password encryption flaw when DES in ECB is used. Of course, any of the feedback modes or 128-bit block ciphers can be used instead of DES, with the obvious performance penalties. However, in our example, MD5 scales very well. A cryptographic hash function i...

3. 802.11i Wireless Security Standard and WPA
Thus, the main hope of the international 802.11 community and network administrators lies with the 802.11i standard development. Sometimes 802.11i is referred to as the Robust Security Network (RSN) as compared to traditional security network (TSN). The "i" IEEE task group was supposed to produce a new wireless security standard that should have completely replaced legacy WEP by the end of 2003. In the meantime, some bits and pieces of the incoming 802.11i standard have been implemented by wireless equipment and software vendor...

4. Proprietary Improvements to WEP and WEP Usage
The article devoted to the proprietary and standards-based improvements for currently vulnerable 802.11 safeguards. The most publicized 802.11 vulnerability is the insecurity of WEP. We have already reviewed the cryptographic weaknesses of WEP linked to the key IV space reuse and insecure key-from-string generation algorithm. There are also well-known WEP key management issues: All symmetric cipher implementations suffer secure key distribution problems. WEP is no exception. In the original design,...

5. Penetration Testing as Your First Line of Defense
It is hard to overemphasize the importance of penetration testing in the overall information security structure and the value of viewing your network through the cracker's eyes prior to further hardening procedures. There are a variety of issues specific to penetration testing on wireless networks. First of all, the penetration tester should be very familiar with RF theory and specific RF security problems (i.e., signal leak and detectability, legal regulations pertaining to the transmitter power output, and characteris...

6. Asymmetric Cryptography
Message authentication using HMACs works just fine, but how do we distribute symmetric cipher keys among the users? We can pass them around on floppies or fancy USB pen-drives with encrypted partitions on them, but what if many users live all over the world? What if the physical key distribution method takes time and the keys must be frequently changed? This is the case with the traditional WEP, which should be rotated every few minutes. Key-encrypting keys (KEKs) were offered as symmetric cipher keys used only to encrypt...

7. Examples and Analysis of Common Wireless Attack Signatures
The best way of knowing these signatures is trying out the tools in question and sniffing out their output: "Attack through defending, defend through attacking" (Dr. Mudge). The best source on wireless network intrusion tool detection and attack signatures we are aware of is Joshua Wright's "Layer 2 Analysis of WLAN Discovery Applications for Intrusion Detection" and "Detecting Wireless LAN MAC Address Spoofing" papers. A large part of this tutorial is inspired by these brilliant articles and our experience of analyzing WLAN tr...

8. Deploying a Wireless IDS Solution for Your WLAN
How many IDS solutions that implement the recommendations and follow the guidelines we have already discussed are present on the modern wireless market? The answer is none. There are many wireless IDS solutions that look for illicit MAC addresses and ESSIDs on the monitored WLAN. Some of these solutions are even implemented as specialized hardware devices. Although something is better than nothing, in our opinion such "solutions" are a waste of both money and time. They might also give you a false sense of security. Let's...