Radius

This article can be found at: http://www.squashduck.com/~roundman/radius/

Radius is a distributed security system developed by Livingston Enterprises which uses an authentication server to solve the security problems associated with remote computing. Distributed security separates user authentication and authorization from the communications process and creates a single, central location for user authentication data. Livingston originally built the server around a model of distributed security previously defined by the IETF. Recently, Merit* has improved the Radius system and it is now a fully open protocol with a scalable client/server security system. Radius is prov ided free of charge to customers and it supports the Radius client protocols in the PortMaster family of communication servers. Early systems were built and tested on the PDP-11 around 1989. Obviously, the entire security system has come a long way since then. Now new security technologies can be added to the network without Livingston or Merit supporting them. The customer can ad d new features to the server, or have an outside resource add them. This is one of the aspects which Radius' extensible architecture will support. One Radius server can support up to tens of thousands of users, making it a very practical service for rapi dly growing networks.

Distributed security is a client/server approach which allows a number of communication servers, or clients, to authenticatea dial-in user's identity through a single, central database, or Authentication Server, which stores all information about users, t heir passwords, and access privileges. Distributed Security is better than other types of security because of the central location for authentication data which makes it more secure than scattering information on different devices throughout a network. It is also scalable, which makes it conform to customers' client needs, and it is easier to manage with all the data in one, secure place.

Network Security has always been an issue in the field of computing. However, it is relatively new to personal computing. Accessing a network with a pc is a wonderful new opportunity but it also creates a huge security risk with the sheer volume of users that are doing so. Every remote login brings with it a new chance of a security breach. In the past, large mainframes used very high-level security measures to protect sensitive data, and most office computers were stand-alone CPU's which posed no securit y threat. Today, stand-alones are basically extinct and the entire system has been replaced with LAN's or WAN's. Now everyone can communicate over the Network, but hackers see this as an opportunity to wreak havoc with the system and bring it down. A more serious concern is the possibility of confidential information being stolen and misused or destroyed.

Radius authenticates users through a series of communications between the client and the server. Once a user is authenticated, the client provides theuser with access to the appropriate network services. Following this section is a detailed flow chart tra cing the path of the client/server interaction of Radius. The user dials in via modem to a modem connected to a PortMaster Communications Server. Once the modem connection is completed, the PortMaster prompts the user for a name and password. Now the PortMaster creates a data packet from this information called the authentication request. This packet includes information identifying the specific PortMaster sending the authentication request, the port that is being used for the modem connection, and the user name and password. For protection from eavesdropping hackers, the PortMaster, actin g as the Radius client, encrypts the password before it is sent on its journey to the Radius server. The Authentication Request is sent over the network from the Radius client to the Radius server. This communication can be done over a LAN or WAN, allowing network managers to locate Radius clients remotely from the Radius server. If the Radius server can't be reached, the Radius client can route the request to an alternate server. When an Authentication Request is received, the Authentication Server validates the request and then decrypts the data packet to access the user name and password information. This information is passed on to the appropriate security system being supported. This could be UNIX password files, Kerberos, a commercially available securit y system or even a custom developed security system. If the user name and password are correct, the server sends an Authentication Acknowledgement that includes information on the user's network system and service requirements. For example, the Radius server will tell the PortMaster that a user needs TCP/IP and/or NetWare using PPP (Point-to-Point Protocol) or that the user needs SLIP (Serial Line InterNet Protocol) to connect to the network. the acknowledgement can even contain filtering information to limit a user's access to specific resourced on the net work. If at any point in this log-in process conditions are not met, the Radius server send an Authentication Reject to the PortMaster and the useris denied access to the network. To ensure that requests are not responded to by unauthorized hackers on the network, the Radius server send an authentication key, or signature, identifying itself to the Radius client. Once this information is received by the PortMaster, it enable sthe n ecessary configuration to deliver the right network services to the user. Flow Chart Functional Details of the Radius Server

When a authentication request to a primary server fails, a request can be made to a secondary server. To do this, there needs to be a copy of the request kept above the transport layer. This need lends itself to UDP.

The user of a radius product will wait a few seconds for retransmission, however most users will not be willing to wait much longer like TCP would expect them to wait under non-prime conditions.

UDP implementation of RADIUS is simplified by it's stateless nature.

The use of UDP makes the implementation of the RADIUS server much simplier; using a multi-threaded implementaion.

"Without TCP we would still probably be using tin cans connected by string. But for this particular protocol, UDP is a better choice." Quote from draft RFC version 04.

PORT 1645: Used for authentication requests, replies, and challenges.

PORT 1646: Used for accounting purposes.

Client/Server Model: The NAS(ie: a Livingston Portmaster acts as the client in this protocol. Also there ususally is a authentication server running some form of a RADIUS server(either the Livingston version or the newest Merit AAA Server version). Usually the RADIUS server is run on a UNIX machine. A good example of a practicle in-use version of this system is the internet service provider : TerraWorld.

Also, RADIUS servers can act as clients to other kinds of authentication servers.

RADIUS is a open protocol, so the server can be modified to meet each site's individual needs.

All transactions between the client and the RADIUS server are encrypted with a shared secret, which should NEVER be sent over the network.

RADIUS supports several authentication techniques including PPP, PAP or CHAP, UNIX login, and other authentication mechanisms.

RADIUS's use of the variable length Attrib-Length-Value 3-tuples allows new attribute values can be added without disturbing the existing implementation.

The availibility of RADIUS's source code allows the RADIUS protocol to be enhanced faster because each person does not have to re-invent the wheel.

Where the following key holds:

C = Code octet of packet.

I = Identifier octet of packet.

L = Length octet pair of packet.

A = Authenticator group of 16 octets of packet.

t = Attributes or parameters of the code.

The code is a single octet which identifies the type of RADIUS packet. If a RADIUS server recieves a packet with an invalid code, the server will silently discard or simply read and forget about the packet.

Valid RADIUS codes are:

1 Access-Request 2 Access-Accept 3 Access-Reject 4 Accounting-Request 5 Accounting-Response 11 Access-Challenge 12 Status-Server 13 Status-Client 255 Reserved

The Identifier is a single octet used to match requests and replies.

The Length is two octets that determine the overall length of the packet; ie: the sum of the length of the Code, Identifier, Length, Authenticator, and the Attribute fields.

The Authenticator field a sixteen octet field transmitted most significant octet first which is used by the RADIUS client to determine the validity of the RADIUS server response; and used by the RADIUS server for password hiding.

The authenticator should be a sixteen octet random number which demonstrates not only unpredictability, but also both temporal and global uniqueness. The shared secret (or key) held by both the RADIUS server and RADI S US client is fed into a one-way MD5 hash followed by this Authenticator to create a sixteen octet value which is xored with the User-Password in the Access-Request packet.

The authenticator of a response packet is obtained by pumping the Code, Identifier, the Length, and the Authenticator fields from the Access-Request packet with the response attributes and finally the shared secret through a one-way MD5 hash to obtain the response sixteen octet Authenticator.

Where the following key holds:

T Attribute type

L Length

V Value

The length field of the attributes is a single octet which specifies the length of the attribute including the type, length, and value.

The value field is a number of octets between zero and two hundred fifty-three. The Type and Length fields can be used to determine the length, because the length is type dependent, and some types stil have variable lengths. The four types of value are:

Benefits of Using Radius Radius is a versatile, inexpensive, and effective security system for networks which are growing rapidly. The distributed security system makes it a practical option for companies who need to protect their networks while allowing their employees easy acce ss to areas in which they have approved access. Centralizing all the security information makes it easier to modify the system and also makes security breaches easier to find. The architecture of the server supports increasing the number of users without disturbing the effciency of the system, decreasing the amount of "down" time on the network. Because of it's network-friendly features Radius is rapidly becoming the standard for Network security systems. The RFC Draft which has been presented to the IETF will no doubt soon be approved and confirm the status of Radius as the best security system for networks in the computing industry. .

Merit AAA Server FAQ http://www.merit.edu/aaa/documentation.html

Livingston Whitepaper http://www.livingston.com/Marketing/Whitepapers/radius_paper.shtml

Livingston http://www.livingston.com/

Merit AAA Server http://www.merit.edu/aaa/