The family of AAA protocols, which stands for Authentication, Authorization and Accounting, were originally designed as remote access control mechanisms and network service providers through modem and dial-in services, but they continue to be presently implemented in multiple architectures.
RADIUS, which stands for Remote Authentication Dial-In User Service, is the paradigm of AAA protocol. Created in 1991 and originally developed by Livingston Enterprises for the PortMaster series of its Network Access Servers (NAS), it later converted into RFC standards through the Internet Engineering Task Force IETF:
- 1991-1993: Merit Network and Livingston Enterprise (access to NSFnetwork)
- 1997 - January: RFC 2058 (Authentication and Authorization) and RFC 2059 (Accounting)
- 1997 - April: RFC 2138 (Authentication and Authorization) and RFC 2139 (Accounting)
- 2000 - June: RFC 2865 (Authentication and Authorization) and RFC 2866 (Accounting)
Description of a basic AAA platform with RADIUS
Without going into too much detail, we will use RADIUS as an example to describe a typical AAA architecture such as those used by an internet provider or ISP. An intermediate element exists in these types of architectures, the Network Access Server, which operates like a RADIUS client. The client is responsible for sending the user’s information to the RADIUS servers and then acting upon the response that is returned.
The RADIUS servers receive the client’s request and execute the authentication of the user based on the received data (generally against directory servers), returning the configuration with the necessary information so that the client can access the authenticated user service. During this Authentication and Authorization process the user’s validity and the resources it has authorized access to are verified. This procedure is complemented by the Accounting process which registers the session’s relevant data and which is normally used to generate rate-setting registrations.
Authentication and Authorization
The user requesting access makes the request by sending his user information and password to a NAS, who he established a link level point to point communication (PPP). The NAS, which acts as a RADIUS client resends the request to the RADIUS server. This request includes the end user’s information along with his password, which is encrypted with a password that is shared with the server (Authenticator). The server validates the Authentication through any of the supported mechanisms: PAP, CHAP, EAP (challenge-response based mechanisms), Unix login, LDAP, etc. and obtains the relevant information related to the client. If the RADIUS server authorizes the access, it sends a message (Access Accept) with a series of parameters attached that characterize the connection such as the IP address and bandwidth. If the access is rejected, the Authentication/Authorization will be denied, informing the user with an Access Reject message which indicates the reasons behind the rejection.
-Message flow in a RADIUS Authentication/Authorization process -
In addition, once he has been authenticated and authorized, the client can send an Accounting request to start a session which the RADIUS server responds to, initiating a connection registration with data about the start/end of the session, volume of transferred data, etc. The session ends with a request from the server or client (Accounting Stop).
RADIUS’s most common messages
RADIUS has the following messages at its disposal to control all of the phases in the AAA process:
- Access-Request. Sent by a RADIUS client to request access Authentication and Authorization to a network.
- Access-Accept. Sent by the RADIUS server in response to an Access-Request message. This message notifies the client of his Authentication and Authorization which he corresponds to by contributing the necessary attributes.
- Access-Reject. Sent by the RADIUS server in response to an Access-Request message. This message informs the client that his request has been rejected, explaining the reason why.
- Access-Challenge. Sent by the RADIUS server in response to the Access-Request message. This message is sent to the client with a challenge that the client must respond to.
- Accounting-Request. Sent by a RADIUS client to specify information about the connection that has been accepted. It can be start or stop type to start or stop the accounting.
- Accounting-Response. Sent by the RADIUS server in response to an Accounting-Request message. This message notifies about the correct reception of the request and starts the session’s process.
Security in RADIUS.
RADIUS suffers from a number of weaknesses, which are:
- RADIUS messages are not encrypted, except for especially sensitive data such as passwords.
- RADIUS uses MD5 as a cryptographic hash algorithm which means it is vulnerable to collision attacks.
- Communications are performed through the UDP protocol, which means that the IP addresses can be easily falsified and are susceptible to identity theft.
- The specifications for the shared password are not sufficiently robust and are re-used by the server with clients. Therefore, it is vulnerable to brute force attacks. Once the password is obtained, the "Authenticator" field used in Authentication messages (Access-Request) is easily generated.
Some counter-measures which could be used to strengthen RADIUS’s security include contemplating the implementation of IPSec to cipher the communications between client and server. In addition or alternatively, the Authentication can be strengthened by using robust challenge-response protocols such as CHAP.
Evolution of RADIUS.
To solve many of the weaknesses that RADIUS presents as a AAA protocol, DIAMETER, which is an evolution of RADIUS (people said it was "twice as good" and that is how it got its name), appears on the scene and includes the following upgrades:
- It uses reliable transport protocols (TCP o SCTP)
- It uses transport level security (IPSEC o TLS)
- It has a larger address space for attributes (Attribute Value Pairs) and identifiers (32 bits instead of 8)
- It is a peer to peer protocol instead of client-server. Therefore any node can start an exchange of messages.