, Wi-Fi access points, and VPN servers all offer network access.
When these devices are used to control access to a network, for example a Wi-Fi access point with WPA2 Enterprise security implemented or an Ethernet switch with 802.1x (EAP) port-based authentication enabled, they are referred to as a Network Access Server (NAS).
All these devices need to exercise some form of control to ensure proper security and usage. This requirement is commonly described as Authentication, Authorization, and Accounting (AAA). AAA is also sometimes referred to as the Triple A Framework. AAA is a high-level architecture model, which can be used for specific implementations.
AAA is specified through various RFCs. Generic AAA Architecture is specified in RFC 2903. There are also RFCs that cover different AAA aspects.
Authentication is usually the first step taken in order to gain access to a network and the services it offers. This is a process to confirm whether the credentials which Alice provided are valid. The most common way to provide credentials is by a username and password. Other ways such as one-time tokens, certificates, PIN numbers, or even biometric scanning can also be used.
After successful authentication a session is initialized. This session lasts until the connection to the network is terminated.
The following image illustrates an authentication process by using the common activity of drawing money from an ATM as an example. This in essence lets you gain access to the bank's network (although it is limited in the extreme).
Authorization is a means by which Isaac controls the usage of the resources. After Alice has authenticated herself, Isaac can impose certain restrictions or grant certain privileges. Isaac can, for instance, check from which device Alice accesses the network and based on this make a decision. He can limit the number of open sessions that Alice can have, give her a pre-determined IP Address, only allow certain traffic through, or even enforce Quality of Service (QoS) based on an SLA.
If we take the previous ATM example we can see that if Alice does not have an overdraft facility she will be limited on the amount of money she can withdraw.
Accounting is a means of measuring the usage of resources. After Isaac has established who Alice is and imposed proper control on the established session, he can also measure her usage. Accounting is the ongoing process of measuring usage.
This allows Isaac to track how much time or resources Alice spends during an established session. Obtaining accounting data allows Isaac to bill Alice for the usage of his resources. Accounting data is not only useful to recover costs but it allows for capacity planning, trend analysis, and activity monitoring.
When Alice wants to check her usage and availability of money the ATM offers this functionality. The Bank of Isaac can also monitor her account and discover if she is usually broke before the end of the month. They can then offer her an overdraft facility.
RADIUS is a protocol which is used to provide AAA on TCP/IP networks. The next section will continue with more on the RADIUS protocol.
RADIUS is an acronym for Remote Access Dial In User Service. RADIUS was part of an AAA solution delivered by Livingston Enterprises to Merit Network in 1991. Merit Network is a non-profit Internet provider, which required a creative way to manage dial-in access to various Points-Of-Presence (POPs) across it's network.
The solution supplied by Livingston Enterprises had a central user store used for authentication. This could be used by numerous RAS (dial-in) servers. Authorization and accounting could also be done whereby AAA was satisfied. Another key aspect of the Livingston solution included proxying to allow scaling.
The RADIUS protocol was then subsequently published in 1997 as RFCs, some changes applied, and today we have RFC2865, which covers the RADIUS protocol, and RFC2866, which covers RADIUS accounting. There are also additional RFCs which cover enhancements on certain RADIUS aspects. Having RFCs to work from allows any person or vendor to implement the RADIUS protocol on their equipment or software. This resulted in widespread adoption of the RADIUS protocol to handle AAA on TCP/IP networks. You will find the word RADIUS is used loosely to either mean the RADIUS protocol or the entire RADIUS client/server system. The meaning should be clear from the context in which it is used.
Supporting the RADIUS protocol and standards became the de facto requirement for NAS vendors. RADIUS is used in a wide variety of places, from cellular network providers having millions of users to a small WISP start-up providing the local neighborhood with Internet connectivity to enterprise networks that implement Network Access Control (NAC) using 802.1x to ring fence their network. RADIUS is found in all these places and more!
ISPs and network administrators should be familiar with RADIUS since it is used by various devices that control access to TCP/IP networks. Here are a couple of examples:
- A firewall with VPN service can use RADIUS.
- Wi-Fi access points with WPA-2-Enterprise encryption involve RADIUS.
- When Alice connects through an existing Telco's infrastructure using DSL; the Telco's equipment will use RADIUS to contact Isaac's RADIUS servers in order to determine if she can gain Internet access through DSL (proxying).
The next section will summarize the RADIUS protocol as specified in RFC2865.
This section explores the RADIUS protocol on a technical level as published in RFC2865. RADIUS accounting is excluded. This is published as RFC2866 and explored in its own section.
The RADIUS protocol is a client/server protocol, which makes use of UDP to communicate. Using UDP instead of TCP indicates that communication is not strict on state. A typical flow of data between the client and server consists of a single request from the client followed by a single reply from the server. This makes RADIUS a very lightweight protocol and helps with its efficiency across slow network links.
Before successful communication between the client and server can be established, each has to define a shared secret. This is used to authenticate clients.
Let's investigate the composition of a RADIUS datagram.
Knowing the format of a RADIUS packet will greatly assist in understanding the RADIUS protocol. Let us look more closely at the RADIUS packet. We will look at a simple authentication request. A client sends an Access-Request packet to the server. The server answers with an Access-Accept packet to indicate success.
The RADIUS packets shown here are only the payload of a UDP packet. A discussion of the UDP and IP protocols is beyond the scope of this book.
Note
We used a program called Wireshark to capture and look at the content of the data packets. Wireshark is an open source tool that should be part of any serious network guru's arsenal. It can be found here:
The screenshots here are the result of a simple Authentication request send to a RADIUS server. The obtaining of this data is commonly known as packet sniffing among IT geeks.
The following screenshot shows the Access-Request packet send from the RADIUS client:
The following screenshot shows the RADIUS server responding to this request with an Access-Accept packet:
Let's discuss the packets.
Each packet is identified by a code. This field is one octet in size. The value of this code determines certain characteristics and requirements of the packet. The following table can be used as a reference to list some of the current defined codes for RADIUS packets:
|
RADIUS code (decimal) |
Packet type |
Sent by |
|---|---|---|
|
1 |
Access-Request |
NAS |
|
2 |
Access-Accept |
RADIUS server |
|
3 |
Access-Reject |
RADIUS server |
|
4 |
Accounting-Request |
NAS |
|
5 |
Accounting-Response |
RADIUS server |
|
11 |
Access-Challenge |
RADIUS server |
|
12 |
Status-Server (Experimental) | |
|
13 |
Status-Client (Experimental) | |
|
255 |
Reserved |
Knowing these codes is beneficial when working with RADIUS.
The second octet of each packet contains a unique identifier. It is generated by the client and used as an aid to match requests and replies. RADIUS packets are transported using connectionless UDP. This requires RADIUS to implement its own algorithm to submit retry requests from the client. When a client resends a request to the server the packet's identifier will remain unchanged. The server will respond to requests by matching the identifier in the response packet.
This is the third and fourth octets in the datagram. It indicates up to where the useful data inside the packet is located. Octets outside the boundary indicated by this field are considered to be padding and silently ignored.
The manner in which this field, which consists of 16 octets, is formed differs depending on whether the packet is a request from the client or a response from the server. It also depends on the packet type, for example Access-Request or Accounting-Request. If it is a request, the field is referred to as a Request Authenticator. If it is a response, the field is referred to as a Response Authenticator.
The value of a Request Authenticator is a random number not to be repeated again. The value of a Response Authenticator is the MD5 hash of various fields in the reply packet along with the shared secret between the client and server.
The rest of the RADIUS packet will contain zero or more attributes, which are referred to as Attribute Value Pairs (AVP). The end of these AVPs is indicated by the packet's length field, as mentioned before.
AVPs are the workhorse of the RADIUS protocol. AVPs can be categorized as either check or reply attributes. Check attributes are sent from the client to the server. Reply attributes are sent from the server to the client.
Attributes serve as carriers of information between the client and server. They are used by the client to supply information about itself as well as the user connecting through it. They are also used when the server responds to the client. The client can then use this response to control the user's connection based on the AVPs received in the server's response.
The following sections will describe the format of an AVP.
The first octet of the AVP is the type field. The numeric value of this octet is associated with an attribute name so that we humans can also understand. Assignment of these attribute names to numbers is controlled by IANA (http://www.iana.org/). The attribute names are usually descriptive enough to deduce their function, for example User-Name(1), User-Password(2), or NAS-IP-Address(4).
RADIUS also allows extending the protocol; attribute Type 26 (called Vendor-Specific) allows for this. The value of the Vendor-Specific attribute can in turn contain Vendor Specific Attributes (VSAs) which are managed by a vendor.
VSAs allows vendors to define their own attributes. The format of the attribute definitions is basically the same as for normal AVPs with the addition of a vendor field. VSAs are sent as the value of AVP Type 26. This means that VSAs are an extension of AVPs and carried inside AVPs.
This makes RADIUS very flexible and allows a vendor to create extensions to customize their RADIUS implementation. CoovaChilli for instance has a VSA attribute called 'ChilliSpot-Max-Total-Octets'. When the CoovaChilli client receives this attribute in a reply from the RADIUS server it uses this value to restrict data through the captive portal.
The RADIUS protocol allows for scaling. Proxying allows one RADIUS server to act as a client to another RADIUS server. This can eventually form a chain.
A discussion on proxying also includes realms. Realms are names used to group users and form part of the username. A username is separated from the realm name with a specified delimiter character. The realm name can be prefixed or postfixed to the username. Today's popular standard uses domain names as a postfix and delimits it with the @ character, for example <alice@freeradius.org>. This is, however, just a convention. The realm can be any name and the delimiter can be any character. Windows users typically use a prefix notation specifying the domain first with a \ character as delimiter, for example my_domain\alice.
When the RADIUS server receives a request with a username containing a realm it can decide whether to process the request or to forward the request to another RADIUS server designated to handle requests for the specified realm. This would require that the second RADIUS server should have the forwarding RADIUS server defined as a client and that they also have a shared secret in common.
The RADIUS protocol is client/server based. The RADIUS server will listen on UDP port 1812 and 1813. Port 1812 is used for authentication. This will involve Access-Request, Access-Accept, Access-Reject, and Access-Challenge packets. Port 1813 is used for accounting. This will involve Accounting-Request and Accounting-Response packets.
This section explores the accounting functionality of the RADIUS protocol. Accounting is a means of tracking usage of resources and typically used for billing.
The RADIUS accounting server runs on port 1813. When a user's session begins the NAS sends an Accounting-Request packet to the RADIUS server. This packet must contain certain AVPs. It is the first packet sent after successful authentication. The server will confirm reception by sending a matching Accounting-Response packet.
Throughout the session the NAS can send optional update reports on the time and data usage of a particular user. When the user's session ends the NAS informs the server about it. This puts closure to the accounting details recorded during the user's session.
The RADIUS client's functionality makes provision for instances when the server is down. The NAS will then, depending how it is configured, retry or contact another RADIUS server.
When a RADIUS server functions as a forwarding proxy to another RADIUS server, it will serve as a relay for the accounting data. It may also record the accounting data locally before forwarding it.
Accounting involves RADIUS code 4 (Accounting-Request) and code 5 (Accounting-Response) packets. Accounting packets like authentication packets use the same RADIUS protocol. One unique feature of accounting packets is that the User-Password attribute is not sent in the request.
See the following output from Wireshark that shows a typical accounting transaction. It starts with an Accounting-Request from the client:
The server then replies to the client with an Accounting-Response:
Accounting-Request packets are also required to include certain AVPs. Let us take a look at important AVPs used in accounting.
This packet indicates the status of the user or the NAS. An NAS may send interim updates on the usage of a certain session. in order to do this the NAS sets the type to Interim-Update. This allows us to follow usage trends in approximately real time.
The RADIUS server does not check up on an NAS. If an NAS has informed the RADIUS server about a newly connected user (status type Start) and thereafter the NAS breaks down completely, the records on the RADIUS server will still indicate that the user is connected to the NAS when in fact the user is not. These records are referred to as rogue entries. To reduce rogue entries, it is good practice for an NAS to send an Accounting-Off followed by an Accounting-On packet just after boot-up and also an Accounting-Off packet before shutting down. This action will cause RADIUS to close all open records for any user connected to the particular NAS allowing a clean start.
Rogue entries are particularly problematic when you limit the number of sessions a user can have. If the component limiting the sessions of a user makes use of data containing rogue entries the calculations will not be accurate.
The following decimal to type table can be used as reference for the possible status values:
|
Decimal value |
Status type |
|---|---|
|
1 |
Start |
|
2 |
Stop |
|
3 |
Interim-Update |
|
7 |
Accounting-On |
|
8 |
Accounting-Off |
|
9-14 |
Reserved for tunnel accounting |
|
15 |
Reserved for failed |
Although the Acct-Status-Type AVP is not compulsory it is almost always included.
This indicates the octets received during the session and is used with Acct-Status-Type having a value of Interim-Update or Stop.
Take note of the value's limitation. Four octets limit it to 4,29,49,67,296. Most modern RADIUS implementations already cater for this.
This indicates the octets sent during the session and is used with Acct-Status-Type having a value of Interim-Update or Stop.
Take note of the value's limitation. Four octets limit it to 4,29,49,67,296. Most modern RADIUS implementations already cater for this.
Compulsory for all Accounting-Request packets, this is a unique value that is used to match Start, Interim, and Stop records. All Start, Interim, and Stop records of a session should have the same value for Acct-Session-Id.
The name is self explanatory. The time in seconds indicating the session's duration and is used with Acct-Status-Type having a value of Interim-Update or Stop.
After the initial RFCs defining RADIUS in general and RADIUS accounting, various extensions were proposed to expand RADIUS usage or improve some weaknesses.
There is also an improved RADIUS protocol called Diameter (A word play—twice as good as RADIUS). The uptake of Diameter has been very slow though, and RADIUS still remains the de facto standard for the foreseeable future. A major reason for this is probably the fact that the many enhancements that Diameter was supposed to bring are already covered by the various RADIUS extensions. There is, for instance, the RadSec protocol that transports RADIUS over TCP and TLS. This makes RADIUS scale better in roaming environments.
Although there are more, we will only look at two important extensions likely to be used.
This extension helps to create a feedback loop from the RADIUS server to the NAS. This in effect swaps the roles of the client and server. The RADIUS server becomes a client to the NAS.
Dynamic authorization allows for the RADIUS server to inform the NAS about changes that have to be made to a user's existing session on the NAS. There are two popular applications of this extension.
Also known as a Packet of Disconnect (POD), this is used to disconnect an existing user's session. The RADIUS server sends the disconnect request and the NAS has to reply whether the disconnection was successful or not.
This message supplies data to change the authorization of an existing user's session. We can now dynamically change the bandwidth limit per session for instance. This allows us to increase the per session bandwidth when load on our Internet link decreases. When load on our Internet link increases we can again decrease the per session bandwidth.
MikroTik RouterOS includes this functionality on some of the services that use RADIUS.
The following table lists the codes and names of the RADIUS packets involved:
|
Radius code (decimal) |
Packet type |
Send by |
|---|---|---|
|
40 |
Disconnect-Request |
RADIUS server |
|
41 |
Disconnect-ACK |
NAS |
|
42 |
Disconnect-NAK |
NAS |
|
43 |
CoA-Request |
RADIUS server |
|
44 |
CoA-ACK |
NAS |
|
45 |
CoA-NAK |
NAS |
FreeRADIUS is an open source project supplying a very feature-rich implementation of the RADIUS protocol with its various enhancements (http://www.freeradius.org). When people refer to FreeRADIUS, they usually talk about the server software. This is the main component of the software suite included in a FreeRADIUS download.
FreeRADIUS development started in 1999 after the future of the original Livingston RADIUS server became uncertain. This allowed for the creation of a new RADIUS server that was open source and could include active community involvement.
FreeRADIUS managed to gain a solid reputation and was able to compete with and even beat most commercial equivalents. Their motto of "The world's most popular RADIUS Server" has been unchallenged for some time now, making it a very valid statement.
FreeRADIUS has many strengths, which contributed to its popularity. Let us look at some of them:
- Open source: This is not just free as in beer; you are free to adapt, change, expand, and fix whatever is required. FreeRADIUS is released under the GNU General Public License (GPL).
- Modular: FreeRADIUS comes with lots of modules included. You can also create your own modules to be used by FreeRADIUS. Modules are included for LDAP integration or SQL back-ends. There are also Perl and Python modules, which allow you to unleash these two powerful scripting languages in FreeRADIUS.
- Used by the masses: Someone does not get fired for choosing FreeRADIUS. It is easy to get references from ISPs and large companies who have very large user counts in their FreeRADIUS deployments. FreeRADIUS conducted a survey to determine the usage and deployment size of FreeRADIUS. The detailed results of this survey are available on request from them.
- Active community: Because FreeRADIUS has such a large user base, chances are someone else has experienced the same hurdles as you. FreeRADIUS has active mailing lists with searchable archives.
- Available info: The information may not be in one locality, but it is available, and just has to be found. There are lots of Wiki pages full of detail. There are also man pages and configuration files, which are well written and easy to follow.
- Active development: FreeRADIUS follows the "release early, release often" motto. New developments around the RADIUS protocol are most likely to be supported first in FreeRADIUS. You can look forward to one or more new FreeRADIUS releases annually.
- Commercial support: The core developers of FreeRADIUS offer commercial support. There are also various people knowledgeable in FreeRADIUS who should be able to supply paid support. Network RADIUS SARL has a nice website with more details on paid support: http://networkradius.com/.
- Availability: FreeRADIUS is available for various operating systems. All of the popular Linux distributions include it as part of their available packages. It is even available for Windows! Under the downloads page of the FreeRADIUS website there are links to binary packages for various operating systems
There is no such thing as a perfect piece of software; FreeRADIUS is no exception. Here are some of its weaknesses:
- Complexity: This is the only real weakness. FreeRADIUS offers an all-inclusive piece of software with many configuration options. If you are not careful you can end up with a broken system.
- Vulnerabilities: A few vulnerabilities were reported in the past but they have been fixed since then. You can read more about those vulnerabilities and what version of FreeRADIUS contained them at the following: http://freeradius.org/security.html.
When FreeRADIUS states that it is the most popular server, who it is competing with? There are competing RADIUS servers but also competing technologies. The competing RADIUS servers include Cisco's ACS, Microsoft's IAS, and Radiator. Competing AAA technologies include Diameter (mentioned earlier), TACACS+ (which is proprietary to CISCO, although also supported by other enterprise network equipment manufacturers), and LDAP (LDAP only supports authentication).
|
Name |
Stands for |
Short description |
|---|---|---|
|
AAA |
Authentication, Authorization, and Accounting |
The three components required for proper control of access and usage. |
|
NAS |
Network Access Server |
A device controlling access to the network for example, a VPN server. Acts as the RADIUS client. |
|
AVP |
Attribute Value Pair |
A three-field component inside a RADIUS packet used to contain a specified field and its data. |
|
VSA |
Vendor-Specific Attributes |
An extension of the AVP managed by a specific vendor. |
- AAA is a security architecture model.
- RADIUS is a specific implementation of AAA.
- FreeRADIUS is a practical application of RADIUS.
- Thus we have AAA → RADIUS → FreeRADIUS.
- RADIUS is all about central control and is the de facto standard supported by NAS vendors.
- RADIUS is a client/server protocol. It uses UDP and listens on port 1812 for authentication and port 1813 for accounting requests.
- RADIUS data packets have a code field, which specifies the type of RADIUS packet.
- RADIUS data packets have zero or more AVPs, which contain the data used in RADIUS.
- FreeRADIUS implements the RADIUS protocol along with its various extensions as specified in RFCs.
- FreeRADIUS is a very popular, widely used, and very flexible RADIUS server.
- Explain the term NAS device.
- What are the start and end points of a session?
- Which protocol and ports does RADIUS use?
- What do the RADIUS client and server require for successful communication?
- What packet does the RADIUS client send when authenticating a user?
- Who initiates a Disconnect Request packet and who receives it?
- Name three components of an Attribute Value Pair (AVP).
- Alice connects with username
alice@freeradius.orgto a network. What is the name of the realm to which Alice belongs?
