CNS - 13 - RADIUS I


Lecture Info

  • Date: [2020-10-19 lun 14:00]

  • Lecturer: Giuseppe Bianchi

  • Slides:

  • Introduction: In this lecture we introduce the RADIUS protocol and discuss one of its historical vulnerability found in the authentication process.

1 Intro to RADIUS

When you connect to uniroma you use the radius protocol. Radius stands for Remote Authentication Dial In User Service, and was developed in the 1990s where the main way to connect to the internet was using a phone call.

Today RADIUS should be obsoleted for various reasons:

  • There is a more functional protocol, named DIAMETER.

  • In terms of security in RADIOUS they did mostly everything wrong.


1.1 Motivation

Networks are large, and you can use heterogeneous and distributed access technologies to connects to such networks. This means that managing large scale networks is a nightmare. What happens for example if you need to change the password of the user? If you change the password from a node, then you need to communicate it with all the other nodes in the network.

The idea is to centralize everything in a single huge database, situated in a single RADIUS server. Like this we're able to centralize the authentication of the users. If now a user changes his password, the only place we have to update is the single radius server.

With RADIUS the typical authentication process is extended as follows.

Its important to not focus the radius client with the actual client.


1.2 AAA Protocol Services

Radius is an AAA protocol, which provides the following three security services:

  • Authentication: you need to prove that you are really the one you claim to be.

  • Authorization: you need to prove that you have the permissions to access a particular service.

  • Accounting: recording what you are doing. This service is crucial when you are dealing with money.

Note that there is a big difference between authorization and authentication. In general authentication and authorization should be clearly divided. Sometimes you need only one and not the other.

Observation: The scientific literature is rich of techniques which allow one to offer only authorization and not authentication, providing services more oriented towards privacy.


1.3 Protocol

RADIUS was originally developed as a client-server protocol in which only the radius client can start the connection. It is based on UDP/IP and the server listens in a well known port \(1812\).

It is (logically) centralized, meaning that you have \(1\) primary server. In practice however you don't have a single server, but typically you have a complex infrastructure in which you might have many secondary replicated servers.

Many radius servers also offer the possibility of acting as proxies, which is very important because radious allows you to run in roaming mode.


1.4 Architecture

In RADIUS we have several blocks such as:

  • RADIUS Server application.

  • Registered User Database.

  • Client database: clients whcih are entitled to communicate with the server. These are not the final clients but rather the RADIUS clients.

  • Accounting database.


1.5 Security Features

Let us now discuss how RADIUS implements security. For this RADIUS did only two things:

  1. Per-packet authenticated reply. This was done so as to make impossible for an attacker to spoof a YES-reply message, telling that a user was authenticated. To do this they used a CHAP-like approach based on a shared-secreet. There are, however, few problems, such as:

    • Only reply is authenticated.

    • Hash-based, not HMAC-based.

    • Usage of specific hash function, MD5.

    • Often low-entropy shared key.

  2. Encrypted user password transmission. They invented a custom encryption technique for the transmission of the user passwords. Even in this case, a few blunders were made:

    • They decided to invent a new mechanism rather than using an existing one. When dealing with crypto, it is always better to reuse.

    • They used the same shared key used for authentication. This is not actually exploitable, but technically speaking it is still a vulnerability.

Its crucial to understand the difference between a protocol and an algorithm. If you put inside a protocol a specific algorithm, you get mozzarella chees, i.e. your potocol has a deadline and at some point in time it will be broken.

2 RADIUS Authenticated Reply

Suppose a user wants to connect to the RADIUS network. Then he will talk to a radius client (NAS, Network Access Server), which can be thought of as "Giano Bifronte", the god with two faces, because he can talk to the end user with a specific protocol such as PPP, Ethernet, etc, and to the radius server with the particular radius protocol. The radius client and the radius server have a shared secret \(S\).

When the radius client receivs an auth request from an end client, the radius client parsers the contents of the request and creates a radius packet with the user credentails and two other important fields: the ID field and the AUTH field. The ID field is a technical value that lets me match requests with responses. What matters to us it the AUTH value, which is the nonce that is used by the radius server to authenticate the reply message.

Notice the authentication code, which is

\[H(\text{ID}, \text{AUTH}, \text{replymsg}, S)\]

which is checked by the client by using the ID to retrieve the associated AUTH value and by computing once again the auth code, to check if its the valid one, i.e. to check if the sender of the authentication code has the actual secret \(S\).

Notice that \(\text{AUTH}\) is choosen randomly for every new connection. This allows to protect against reply attacks.

Observation: This protocol is a sort of hybrid between a message integrity protocol and a challenge authentication protocol, because we are proving the authenticity of a message by using a challenge provided by the client.


2.1 Packet Format

Radius is an application layer protocol that is wrapped by a UDP packet.

The packet itself is divided in the following fields

where,

  • code: tells you what kind of radius packet type. Some of the possible codes are the following

    \[\begin{split} 1 &\longleftrightarrow \text{Access-Request} \\ 2 &\longleftrightarrow \text{Access-Accept} \\ 3 &\longleftrightarrow \text{Access-Reject} \\ 4 &\longleftrightarrow \text{Accounting-Request} \\ 5 &\longleftrightarrow \text{Accounting-Response} \\ 11 &\longleftrightarrow \text{Access-Challenge} \\ \end{split}\]

    Notice here the terminology challenge is used to keep the connection going until the server decides to accept the client.

  • identifier: used to match requests with responses.

  • length: length of the packet

  • authenticator: In the Access-Request it is used to put the random AUTH value generated by the client, in the Access-Response it is used as a tag to validate the integrity of the message. Finally, it is also used as a nonce for password encryption.

  • attributes: triples of the form \((\text{type}, \text{len}, \text{value})\). By using these attributes you can specify the particular service the user is asking for. Examples of attributes are the following

Most implementation of the radius protocol are vulnerabile because the authenticator value was not generated as a truly random variable.


2.1.1 Authentication Field

The most important field in terms of security is the authentication field. This fields contains different values depending on the nature of the packet:

  • In Access-Requests sent by the client to the server \((C \to S)\) this field should contain 16 randomly generated bytes to prevent replay attacks. Note however that, in general, unpredicatability has nothing to do with replay attacks. But if the specification asks you to have unpredicatability, just use a truly random number generator or a cryptographic pseudorandom number generator.

  • In esponse packets sent by the server to the client \((S \to C)\), which can can be of type accept, reject and challenge, this field should contain the MD5() hash of

    • The request ID

    • The request authenticator

    • The shared secret

    • The packet response information

    More specifically,

    \[\text{MD5}(\text{Code} \,\,|\,\, \text{ID} \,\,|\,\, \text{Length} \,\,|\,\, \text{RequestAuth} \,\,|\,\, \text{Attributes} \,\,|\,\, \text{Secret})\]



2.2 Possible Messages

The possible message sent by the protocols are the following.


2.2.1 Access-Request

The access-request message typically contains the following informations:

  • Who is the user (User-Name)

  • Password of the user

  • An identifier of the radius client (nas-IP or nas-identifier)

  • An identifier of the port the user is accessing (nas-port)



2.2.2 Access-Reject

This message is sent either because the authentication field or because the authorization failed.



2.2.3 Access-Challenge

Sometimes more than a single message is needed to validate/invalidate a request. In order to support this we need a sort of "neutral message". This mesage is called the Access-Challenge message.



2.3 PPP CHAP support

The PPP CHAP protocol is supported by RADIUS.

The basic idea is that instead of having the challenge, which is a random number, generated by the server, we'll the nas do it.

Now, is this protocol secure? We want to make sure that an attacker cannot forge a fake accept message. As it happens, this protocol is not secure, and this is for the following reasons:

  1. The reply message sent by the server contains no information about the specific username, CHAP password and CHAP challenge data of the request message.

  2. For the previous reason, even if the challenge is randomly generated everytime from the NAS, since there no message authentication is done on the first message sent by the NAS to the server, we can simply modify the spoof the message and modify the User Name, CHAP password and CHAP challenge fields.

The attack works as follows:

  • First the attack sniffs a complete connection in which:

    • The nas (trusted) sends a challenge \(1234\) to the user, which replies back to the nas with \(\alpha \beta \gamma\).

    • The nas then sends to the server a message containing various info including the auth code \(9876\), the username \((\text{GB})\), the challenge \(1234\) and the previous response of the user \(\alpha \beta \gamma\).

    • Finally the server replies back with an accept-request containing auth code \(9876\).

  • Now its the turn of the attacker (the devil) to initiate a new connection:

    • The nas sends him a different challenge \(5678\), and the attacker replies back with whather he wants \(\delta \epsilon \phi\).

    • The nas prepares a new radius packet with a new AUTH code \(1998\), followed by the username \(\text{GB}\) (the devil claims to be giuseppe bianchi), the challenge \(5678\) and the previous response of the user \(\delta \epsilon \phi\).

    • The attack starts here: at this point the attacker can take the message and can change the challenge and the CHAP-password fields to whather he likes. In particular he overwrites them in the following way

      \[\begin{split} 5678 &\to 9876 \\ \delta \epsilon \phi &\to \alpha \beta \gamma \\ \end{split}\]

    • If the server does not check whether or not challengs are used multiple times we can get inside and impersonificate giuseppe bianchi.

The attack just described is a subtle replay attack in which I replace the payload of the request message.

Some final remarks:

  • Since 1998 even requests were authenticated, so this type of attack does not work anymore. There might still exist some implementations in which this is not done.

  • If we could only authenticate one of the two messages, one idea could've been to bind the two messages by including an hash of the request within the authenticated reply.