ASSIGNMENT OF AUTHENTICATION PROTOCOL (RADIUS)

MUHAMMAD SHAHRIN BIN RAHILI

A151156

SUBJECT: KESELAMATAN KOMPUTER DAN RANGKAIAN

LECTURE
DR. ZULKARNAIN BIN MD. ALI

FAKULTI TEKNOLOGI SAINS DAN MAKLUMAT

2016/2017

1.1

ATHENTICATION PROTOCOL

Authentication protocol is the communications protocol for transferring authentication

data between two entities. User provides some credentials which identified by users who is
authorized to access the system. First, user must have valid user configured account that can
specify users permission and rights. User must be credentials must be associates with this
account.
If the user wants to gain access of the data, the other users will provide credentials and the
system will checks the database for the comparison with the original entry. If they match, the
user will gain access to the data that has been request.
They are a lot number of authentication protocol that available in these modern technologies. For
example, below are the list of some authentication protocol that:
I.
II.
III.
IV.
V.
VI.
VII.

Kerberos
SSL
Microsoft NTLM
PAP and SPAP
EAP
Certificate Service
RADIUS

Between all these examples, RADIUS Authentication Protocol will be elaborate more for better
understanding in future use.

1.2

RADIUS AUTHENICATION PROTOCOL

RADIUS Authentication Protocol is stand for Remote Authentication Dial-In User

Service. It is used widely for network environments. Most RADIUS is implemented in network
devices such as router, modem servers and switches. RADIUS is often use by Internet service
providers (ISPs) to authenticate and authorize dial-up or VPN users. This authentication protocol
provides security for the networking in preventing the attacks from intruders.

1.3

HISTORY OF RADIUS

Merit was a pioneer in national and international networking and is highly respected for
its Internet expertise. Formed in 1966 to interconnect computers at three Michigan universities,
Merit played a vital role in building today's Internet. Merit developed and deployed its own
network, roughly based on the ARPAnet protocols, initially connecting mainframe computers at
the University of Michigan, Michigan State University and Wayne State University.
By 1990, it had grown to interconnect most colleges and universities in Michigan, and
had added support for distributed dial-in access. With distributed dial-in access, a Michigan State
user could dial into modems at the University of Michigan and log on to the Michigan State host.
In 1987, Merit bid on and was awarded the contract to run the NSFnet by the National Science
Foundation.
The NSFnet was the backbone for the national Internet and from 1987 until the
commercialization of the NSFnet in 1995 Merit was very involved with growing and supporting
the Internet. Internally at Merit there were two operational groups, NSFnet group focusing on
national networking and MichNet group focusing on statewide networking. (Merits MichNet
service is the largest ISP in Michigan; MichNet has over 200 POPs and 10,000 modem ports and
places 95% of Michigan's residents within a local call of the Internet.)
NSFnet started as an IP based network but MichNet had to convert from its proprietary
protocol to IP. One of the requirements for MichNet to transition to IP was to replace the
proprietary dial-in servers with standard dial servers provided by commercial vendors. A major
requirement of any solution was to provide a way to support Merits distributed dial-in service.
In 1991, a process to select a vendor for dial servers started. The requirement to provide
distributed dial-in services was a stumbling block for Interlink Networks, LLC. Only one vendor
that Merit talked with at the time had a remote authentication protocol (Xylogics Access Control
Protocol). Livingstons response to the RFI was a description of RADIUS.
The solution fit the needs and awarded the contract to Livingston. Livingston
implemented the protoRADIUS in their Portmaster dial-in server product and created a simple
RADIUS software server to support it. Livingston Portmasters and RADIUS server software
(which Livingston included for free with the Portmaster hardware) were installed in MichNet.
MichNet extended Livingstons RADIUS server to support additional features such as proxying
for distributed authentication and support for MichNets unique shared dial-in services.
Within a year RADIUS had developed a totally rewritten serverthe Merit RADIUS
Server. The Merit RADIUS Server and its successors (now Interlink Networks RAD-Series

RADIUS Server) has been used in hundreds of thousands of networks across the world, securing
not only dial-up, but wireless and mobile networks as well.

1.4

ADVANTAGES AND DISADVANTAGES OF RADIUS

Nowadays RADIUS has been used widely because it is compatible with the system design
especially in communication network field. RADIUS surely has a lot advantages that can be
beneficial for the user. The advantages of RADIUS are:
i.
ii.
iii.
iv.

The storage provides is larger than the general embedded system.

The use of RADIUS centralized the user administration.
RADIUS provides high protection from sniffing, active attacker and other hacker.
RADIUS support is nearly Omni-present. Other remote authentication protocols do not
have consistent support from hardware vendors, whereas RADIUS is uniformly
supported.

However, RADIUS has limited issues in data protection. This could make RADIUS can be
upgraded to become more security. So, the disadvantages of RADIUS are:
i.
ii.

iii.
iv.

1.5

The User-Password protection technique is flawed in many ways. It should not use a
stream cipher, and it should not use MD5 as a cipher primitive.
Many administrators choose RADIUS shared secrets with insufficient information
entropy. Many client and host implementations artificially limit the shared secret key
space
Many client implementations do not create Request Authenticators that are sufficiently
random.
The Access-Request packet is not authenticated at all.

PROCEDURE OF USING RADIUS

RADIUS is currently the de-facto standard for remote authentication. It is very prevalent in both
new and legacy systems. RADIUS is currently the de-facto standard for remote
authentication. It is very prevalent in both new and legacy systems. The summary
of the RADIUS packet protocol is shown below.

FIGURE 1 THE SUMMARY OF RADIUS AUTHENTICATION AND AUTHORIZATION

FLOW
(Emilhem, 2011)

The client creates an Access-Request RADIUS packet, including at least the User-Name and
User-Password attributes. The Access-Request packets identifier field is generated by the client.
The generation process for the identifier field is not specified by the RADIUS protocol
specification, but it is usually implemented as a simple counter that is incremented for each
request. The Access-Request packet contains a 16 octet Request Authenticator in the
authenticator field. This Request authenticator is a randomly chosen 16 octet string. This packet
is completely unprotected, except for the User-Password attribute, which is protected as follows:
The client and server share a secret. That shared secret followed by the Request Authenticator is
put through an MD5 hash to create a 16 octet value which is XORed with the password entered
by the user. If the user password is greater than 16 octets, additional MD5 calculations are
performed, using the previous ciphertext instead of the Request Authenticator.
The server receives the RADIUS Access-Request packet and verifies that the server possesses a
shared secret for the client. If the server does not possess a shared secret for the client, the
request is silently dropped. Because the server also possesses the shared secret, it can go through
a slightly modified version of the clients protection process on the User-Password attribute and
obtain the unprotected password. It then uses its authentication database to validate the username
and password. If the password is valid, the server creates an Access-Accept packet to send back
to the client. If the password is invalid, the server creates an Access-Reject packet to send back
to the client. Both the Access-Accept packet and the Access-Reject packet use the same identifier

value from the clients Access-Request packet, and put a Response Authenticator in the
Authenticator field. The Response Authenticator is the is the MD5 hash of the response packet
with the associated request packets Request Authenticator in the Authenticator field,
concatenated with the shared secret.
When the client receives a response packet, it attempts to match it with an outstanding request
using the identifier field. If the client does not have an outstanding request using the same
identifier, the response is silently discarded. The client then verifies the Response Authenticator
by performing the same Response Authenticator calculation the server performed, and then
comparing the result with the Authenticator field. If the Response Authenticator does not match,
the packet is silently discarded. If the client received a verified Access-Accept packet, the
username and password are considered to be correct, and the user is authenticated. If the client
received a verified Access-Reject message, the username and password are considered to be
incorrect, and the user is not authenticated.

1.6

SUMMARY OF RADIUS

RADIUS is good authentication protocol for the use of communication network security.
Although RADIUS has some issues that may lead to the harm of the data, but benefits that
provided by RADIUS also can make the user beneficial.

REFERENCES

Joshua Hill, 2001, An Analysis of the RADIUS Authentication Protocol.

John Vollbrecht, 2006, The Beginnings and History of RADIUS.
Deb Shinder, 2000, Understanding and Selecting the Authentications Methods.
http://www.techrepublic.com/article/understanding-and-selecting-authentication-methods/