Attacks On RADIUS Based Authentication

Abstract

There has been a noticeable increase in the development of network technology in the last few years and various types of services are being delivered and offered by these network technologies. But these services are being used by both legitimate and illegitimate users and which makes it a point of concern for security purposes. So, for this AAA (authentication, authorization, and accounting) model is used and this model is being used in RADIUS security models. With a significantly increasing size of remote users using wireless laptops or VOIP phones trying to access the network for services, RADIUS (remote authentication dial-in user service) is currently very popular and in use widely.

Index Terms: RADIUS server, AAA model , Attacks, Protocol

I. INTRODUCTION

RADIUS is a network protocol and is widely used in network services for security purposes. Since embedded systems normally cannot deal with a big number of users with unique authenticating data because it requires more storage, RADIUS protocol is used and this protocol also allows centralized user administration, some level of security against sniffing and its support is nearly omnipresent and uniformly supported. This protocol has three primary functions: 1) It is to authenticate the users before allowing them into the network. 2) It is to authorize those users on the access of the network services. 3) To account for the usage of those services.

RADIUS is the most distinctive network security protocol to use the AAA model. AAA is an abbreviation for authentication, authorization, and accounting and it is used for authenticating and authorizing users and accounts for their activity. When this model is not used, the network is 'open' which means anyone can gain access to network and data without anyone knowing. This type of open network is used in smaller businesses where access can be monitored physically but in bigger businesses, the AAA model is implemented to keep track of users. AAA model can also be partially implemented. For example, if a company does not want to know about the usage of its users for billing purposes, the company can only implement authorization and authentication.

The goal of the RADIUS is to create a central location for user authentication, where users or clients from various locations could request network access and services. The simplicity, efficiency, and usability of the RADIUS system made it popular by network service vendors, to the extent that currently, RADIUS is considered an industry standard and is also positioned to become an Internet Engineering Task Force (IETF) standard. RADIUS system is divided into four components which are user/devices, network access server, RADIUS server, and databases.

II. BACKGROUND

A. FreeRADIUS Server

It is the widely deployed server in the world and has a licensed client library, a pluggable authentication module library, and has 10 million users. This server is popular because of its benefits. Firstly, it is scalable as a single RADIUS server can easily go from serving one request at a time to serve thousands of requests per second. Secondly, these servers' modular interface is easy to use as one can modify the features without affecting other features and can be easily added or removed. And thirdly, more authentication features are supported by this server than by any other servers. For example, it is the only server to support extensible authentication protocol

B. AAA Model

AAA is a security model used in large networks and used in servers like RADIUS and TACACS+ for security purposes. These servers are connected through network devices like switches, routers, other routers, and firewalls. In an ISP or any other network, there are employees such as admin, engineers, managers and more, who need to access such servers and when they want to do this, they needed to be authenticated and authorized.

Authentication: This process involves checking the credentials given by the users to see their credibility and connect as well as grant the services to them. If the credentials match, the client is authenticated and can gain access to the network services else the access is denied.

Authorization: This step refers to the process of deciding what types of permissions and services should be allowed to users. For example, some employees in a company might not have a higher level of clearance for some information so when they try to access it, the user would be denied.

Accounting: It records the usage of resources used by the user when they are accessing the network services such as the amount of the data used, the amount of the data sent and received and more.

C. Network Access Server

It acts as a gateway between the user and the network. In this whenever the user tried to get access to the services, NAS will take the packet containing the credentials from the user to the server where the authentication process will be done.

After the user has been verified, the NAS will enforce the security policies and act as a gateway router or the firewall for that user. NAS will also send a summary of the user (Session identification information, total time on the network, and total traffic to and from the user) to the server. NAS can be a switch, wireless access point, DSLAM or VPN terminator.

III. SUMMARY OF RADIUS PROTOCOL

Between the client and the user, six types of packets are exchanged. Each packet contains field as shown in figure 1.

Code is 1 byte long and will identify the type of the packet. For example, code value 1 means Access-Request type, 2 means Access-Accept, 3 for Access-Reject and so on.

Identifier is also 1 byte long and used to match the responses with requests

Length is 2 bytes long and specifies the length of the packet

The authenticator is 15 bytes long and used by the client to verify the validity of a server's response and for password hiding

Attributes can contain authentication, authorization, and configuration in TLV( type, length, and value) and include username, password, CHAP password, NAS-IP-Address, NAS-Port, Service-Type, EAP-Message and Message-Authenticator.

The operation of the RADIUS protocol has six types of packets as shown in the following points.

Access-Request is sent by the user to the server and it contains the information to determine whether the user is allowed for specific NAS and requested services

Access-Accept is sent by the server to the user added with the information needed to begin the delivery of the requested. In this, the authenticated field is calculated using MD5 hash

Access-Reject is sent by the server to a client if the value of the attribute is not valid.

Access-Challenge is sent by the server to a user through NAS as a challenge that needs a response. It is a request to a client for more data like the MAC address.

Accounting-Request is sent by NAS or user to the server which is also performing the accounting.

Accounting-Response is sent by the server with the code field set to 5 and attributes are not needed for this packet

Another important part of the RADIUS protocol is the authentication protocols, they are used with point-to-point protocol and are also used with EAP in the 802.1x framework. These protocols include PAP, CHAP, and MSCHAP. PAP (Password Authentication Protocol) is only used in the initial phase to establish a link and uses a two-way handshake. CHAP (Challenge-Handshake Authentication Protocol) is more secure than the PAP in a way it uses a three-way handshaking protocol. In this, first, the authenticator sends a challenge packet to the peer then, the peer responds with a value using its one-way hash function. After this, the received value is matched by the authenticator with its own calculated value. If the values match then the authentication is acknowledged otherwise, the process is terminated. MS-CHAP is similar to the CHAP protocol but it is the version of Microsoft and uses MD and DES encryption.

Fig. 1. RADIUS Packet

EAP (Extensible Authentication Protocol) is an internet standard that provides a framework for clients and authentication servers. It supports multiple authentications and only defines how the messages are to be delivered to and from between clients, authenticator, and server. EAP methods such as EAP-TLS, EAP-TTLS, EAP-PEAP maybe used for authentication by the RADIUS server.

IV. ATTACKS ON RADIUS SERVER

During the protocol, the Client creates an Access-Request packet including username and password attributes. In this, the identifier field is created by the user and this process is not usually specified by the protocol but is usually implemented as a counter which increases after every request. This packet also contains a 16 octet Request Authenticator which is generated using PRNGs. Overall this packet is completely unprotected except the username-password attributes. In this, the client and the server shares a secret. This secret is added with the authenticator and put through MD5 hash to generate a value that is XORed with the password entered by the user. The RADIUS protocol has a set of vulnerabilities that are caused by the protocol or by poor client implementation. The vulnerabilities that follow are a few of the vulnerabilities that were observed.

A. Response Authenticator Based Shared Secret Attackr

The Response Authenticator is an ad hoc MD5 based keyed hash and allows an attack on the shared secret. In this, if an attacker notices a valid Access-Request packet and the associated Access-Accept or Access-Reject packet, they can launch an off-line exhaustive attack on the shared secret. The attacker can pre-calculate the MD5 state for (Code+Identifier+Length+Request Authenticator+Attributes) and then continue the hash once for each shared secret guess.

B. User-Password Attribute Cipher Design Comments

The username-password attributes use stream cipher as protection, where an MD5 hash is used as a PRNG (pseudorandom number generator). The first 16 bytes of the stream cipher displays the same features as a synchronous stream cipher. After the first 16 bytes, the stream cipher state is modified by adding the last ciphertext and becomes a self-synchronizing stream cipher. The security of the cipher depends on the strength of MD5. It is though not clear what the requirements for this cipher are, so it is unclear if the MD5 function is appropriate. This function is not made to be a stream cipher primitive, it is created to be a cryptographic hash. This sort of misuse of cryptographic primitives often leads to not noticeble flawed systems.

C. Shared Secret Attack Based On User-Password Attribute

Since the username-password attributes use stream cipher as protection, an attacker can gain information about the Shared Secret if they observe network traffic and can attempt an authentication. In this, the attacker attempts to authenticate to the client with a password known by the client and then he will capture the Access-Request packet and will XOR the secured portion of the User-Password attribute with the password they provided to the user. This results in the value of the MD5. Now, the Request Authenticator is known as it is in the client's Access-Request packet, so the attacker can now launch an offline exhaustive attack on the shared secret.

D. User-Password Based Password Attack

Since the username-password attributes use stream cipher as protection and this results in a vulnerability that allows an attacker to control any authentication rate limits forced by the client. In this, the attacker first attempts to authenticate to the client using a viable username and a known password. The attacker then captures the resulting Access-Request packet and decides the result of the MD5 operation just like the last attack. The attacker can then replay changed Access-Request packet, using the same Request Authenticator and MD5 value, just modifying the password for each replay. If the server does not have user-based rate limits, this will allow the attacker to perform an exhaustive attack for the correct user password.

E. Attack Based On Request Authenticator

The Request Authenticator must be both unique and nonpredictable since the security of RADIUS depends upon its generation. The RADIUS protocol does not show enough importance to the request authenticator, so there are many implementations who use weak PRNGs to create the Request Authenticator. If the client uses a weak PRNG that repeats values, the protocol fails to provide the wanted level of protection. In, the last two attacks in the list followed below requires the attacker to cause the client to create a particular identifier value which is not difficult as identifiers were never meant as a security feature. the identifier field is created by the user and this process is not usually specified by the protocol but is usually implemented as a counter which increases after every. But it often doesn't increase work factors as identifier generation is sometimes deterministic. So, an attacker can insert a series of extra padded requests to the client, making the required identifier to reoccur much more quickly than it would normally. Even if the identifier were not created in such readily and easily attackable way, it would still only increase the work factor by 256 times.

Passive User-Password Compromise By Repeating Request Authenticators: If the attacker can have an inkling and sniff the traffic between the client and the server, they can passively produce a dictionary of Request Authenticators, and the secured User-Password attributes. If the attacker notices a repeated Request Authenticator, they can delete any trace of the Shared Secret from the first 16 bytes of the passwords by XORing the first 16 bytes of the protected passwords together. This results in the first 16 octets of the two less secured user passwords XORed together. The result of this attack varies depends on how efficient the password is. If the users all decided on random passwords of the same length, the attacker can achieve nothing. Unfortunately, this is a somewhat rare occurrence. In reality, users choose passwords of varying lengths (normally less than 16 characters) and of different quality.

The easiest problem for the attacker to exploit in this scenario can happen when two passwords are of different lengths and both less than 16 characters. In this case, one of the passwords has more padding than the other password, so the non-overlapping characters of the longer password are XORed with. This results in the non-overlapping characters of the longer password being leaked to the attacker with no researching. There are more complex attacks available if the attacker thinks that users chose low-entropy credentials. In this case, the attacker can perform a dictionary attack which is guided by statistical analysis of the overlapping part. This attack can also be further used by noticing the length of the two passwords and the trailing part of the longer password and then only trying the passwords with this length and ends. - Active User-Password Compromise By Repeating Request Authenticators: The attacker can try to authenticate numerous times using known credentials and try to intercept the generated access-request packets, gaining the request authenticator and user-password attribute. After this, he can XOR the known password with the user-password attribute and gain MD5 value. After this, he can create dictionaries containing request authenticator and MD5 values of it. So, when the attacker sees a viable Access-Request packet that has a Request Authenticator value that is in the dictionary, the attacker can recover the first 16 bytes from the secured party of the User-Password field by looking up the MD value from the dictionary and XORing it with the Password attribute.

Replay of Server Responses By Repeating Request Authenticators: The attacker can create a dictionary of Request Authenticators, identifiers and server responses. When the attacker notices a request that uses a Request Authenticator and identifier that is in the dictionary, the attacker can acts as the server and replay the previously noticed server response.

Furthermore, if the attacker is able to authenticate and causing the user to create an access-request packet with the same request identifie and authenticator as a lastly known successful authentication, he can replay the viable looking access-accept server response and successfully authenticate to the user without knowing the password.

Creating DOS from the Predicting The Request Authenticator: The attacker can pose as the user and create a dictionary of future request authenticator values and its server responses if the attacker is able to predict future values of request authenticator. The attacker can then masquerade as the server and respond to the client's requests with valid looking Access-Reject packets ending up creating a denial of service.

F. Shared Secret Hygiene

The RADIUS specifically permits the use of the same shared secret by multiple clients. But this is a very bad idea as it provides attackers with more information to work from and allows any flawed user to exploit several machines. All clients who use the same shared secret can be viewed as a single user for the purpose of all these attacks. Now, most implementations only ASCII strings as input for the shared secret and there are only 94 ASCII characters that can be used as input. Also, many implementations restrict the total length of the shared secret to less than or equal to 16 characters. Both of these restrictions are able to lessen the size of the keyspace that an attacker must investigate in order to find the shared secret.

V. CONCLUSION

The RADIUS protocol is effective and acceptable for different applications and utilities. But still some limitations exist in the AAA model. In the near future, the techniques will be developed to overcome the limitations in the protocol. Following are some of the points which can be taken into consideration:

Instead of using stream cipher, block cipher can be used in user-password protection.

While the response authenticator is a good idea, it is poorly implemented as many implementations do not create request authenticator that is effectively random. Plus, Instead of using an ad hoc keyed hash primitive in the Response Authenticator, an allowed MAC(Message Authentication Code) can be used.

Another thing that can be done is that instead of MD5 hash which is a cryptographic hash that could be used in HMAC primitive, SHA-1 can be used to provide better security.

REFERENCES

[1] Daniel Szilagyi, Arti Sood and Tejinder Singh, "RADIUS: A REMOTE AUTHENTICATION DIAL-IN USER SERVICE", InSight: RIVIER ACADEMIC JOURNAL, VOLUME 5, NUMBER 2, FALL 2009.

[2] Joshua Hill "An Analysis of the RADIUS Authentication Protocol "' from http://www.untruth.org/ josh/security/radius/

[3] P. Congdon, B. Aboba, A. Smith, G. Zorn, J. Roese "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580

[4] Arun Pratap Singh Sikarwar,Preeti Saxena,"An Analytical and Experimental Study of AAA Model with Special Reference to RADIUS and TACACS+",International Journal of Computer Applications (0975 – 8887),Volume 169 – No.9, July 2017

[5] Jindrich Jelinek and Pavel Satrapa, Jiri Fiser,"Experimental Issues of the Model of the Enhanced RADIUS Protocol", IEEE International Workshop of Electronics, Control, Measurement, Signals and their Application to Mechatronics (ECMSM), 2015

[6] Hasan, A., Jahnert, J., Zander, S. and Stiller, B.,"Authentication, Authorization, Accounting and Charging for the Mobile Internet" Mobile Summit (September 2001).

[7] FreeRADIUS Documentation from "https://networkradius.com/doc/current/"