Authentication
& Authorization
How does it work?
The RADIUS protocol is used to authenticate and authorize users on the
client side, through a series of network communications, on the server.
Any user of a RADIUS configured client, should present authentication
information (This might be a customizable login prompt, with username and
password).
Once the client has the user's information, it may choose to
authenticate using RADIUS. to do so, the client creates an
"Access-Request" frame containing such Attributes as the user's name,
the user's password, the ID of the client and the Port ID which the user is
accessing. This frame is submitted to the RADIUS server via the network. To make sure the request gets to
the server, the RADIUS protocol manages an error control so that if there is no
response from the server in a length of time, the request is re-sent a number
of times. Also, t he client can forward
requests to an alternate server or servers in the event that the primary server
is down or unreachable.
Once the RADIUS server receives the request, it validates the sending
client. If the server recognizes
the client as a valid one, it consults a database of users to find the user
whose name matches the request, if the client is not recognized, the request is
ignored. The user entry in the
database contains a list of requirements which must be met to allow access for
the user, which always includes verification of the password, but can also specify
the client or port to which the user is allowed access.
The RADIUS server may make requests of other servers in order to satisfy
the request, in which case it acts as a client.
There could be three kinds of answers the RADIUS server might send back
to the client:
1.
If any condition is
not met, the RADIUS server sends an "Access-Reject " response
indicating that this user request is invalid. If desired, the server may include a text message in the
Access-Reject which may be displayed by the client to the user.
2.
If all conditions are met and the RADIUS
server wishes to issue a challenge to which the user must respond, the RADIUS
server sends an "Access-Challenge" response (see below). It may include a text message to be displayed
by the client to the user prompting for a response to the challenge. If the
client receives an Access-Challenge and supports challenge/response it may
display the text message, if any, to the user, and then prompt the user for a
response. The client then
re-submits its original Access-Request with a new request ID, with the
User-password Attribute replaced by the response (encrypted).
3. If all conditions are met, the list of
configuration values for the user are placed into an "Access-Accept
" response. These values
include the type of service and all necessary values to deliver the desired
service.
Challenge/Response
The RADIUS server holds a sophisticated mechanism with which he can
check exclusively authorized users, using the challenge/response
authentication. In this method, the user is given an unpredictable number and
challenged to encrypt it and give back the result. Authorized users are
equipped with special devices such as smart cards or software that facilitate
calculation of the correct response with ease. Unauthorized users, lacking the
appropriate device or software and lacking knowledge of the secret key
necessary to emulate such a device or software, can only guess at the response.
The Access-Challenge packet typically contains a Reply-Message including
a challenge to be displayed to the user, such as a random numeric value
unlikely ever to be repeated. Typically this is obtained from an external
server that knows what type of authenticator should be in the possession of the
authorized user and can therefore choose a random or non-repeating pseudorandom
number of an appropriate radix and length.
The user then enters the
challenge into his device (or software) and it calculates a response, which the
user enters into the client which forwards it to the RADIUS server via a second
Access-Request. If the response
matches the expected response the RADIUS server replies with an Access-Accept,
otherwise an Access-Reject.
Why UDP?
The UDP is the most appropriate protocol to support all the technical demands of RADIUS, Since RADIUS is a transaction based protocol:
1.
If the request to a primary Authentication
server fails, a secondary server must be queried. To meet this requirement, a copy of the request
must be kept above the transport layer to allow for alternate transmission.
This means that retransmission timers are still required.
2.
The timing requirements of this particular
protocol are significantly different than TCP provides. RADIUS does not require a
"responsive" detection of lost data. The user is willing to wait several seconds for the
authentication to complete. The
generally aggressive TCP retransmission (based on average round trip time) is
not required, nor is the acknowledgement overhead of TCP. Also, the user is not
willing to wait several minutes for authentication. Therefore the reliable delivery of TCP data two minutes
later is not useful. The faster
use of an alternate server allows the user to gain access before giving up.
3.
The stateless nature of this protocol simplifies
the use of UDP. UDP completely eliminates any need for special handling of lost
connections/messages. Each client and server can open their UDP transport just
once and leave it open through all types of failure events on the network.
4. UDP simplifies the server implementation. In the earliest
implementations of RADIUS, the server was single threaded. This means that a single request was
received, processed, and returned.
This was found to be unmanageable in environments where the back-end
security mechanism took real time (1 or more seconds). The server request queue would fill and
in environments where hundreds of people were being authenticated every minute,
the request turn-around time increased to longer that users were willing to
wait (this was especially severe when a specific lookup in a database or over
DNS took 30 or more seconds). The
obvious solution was to make the
server multi-threaded. Achieving
this was simple with UDP. Separate
processes were spawned to serve each request and these processes could respond
directly to the client NAS with a simple UDP packet to the original transport
of the client.
As mentioned, there is one problem: using UDP requires one thing which is
built into TCP: with UDP we must artificially manage retransmission timers to
the same server, although they don't require the same attention to timing
provided by TCP. Thus, t his one
penalty is a small price to pay for the advantages of UDP in this protocol.
Packet Format
The general RADIUS
packet structure was explained before.
The field's contents to provide the authentication and authorization processes
are described below:
Code:
The RADIUS Codes
relevant for authorization and authentication are as follows:
1
Access-Request
2
Access-Accept
3
Access-Reject
11
Access-Challenge
Authenticator
Two forms of that
field are being used for authentication and authorization:
1. Request Authenticator
In order to maintain on the
distributed security the authenticator should be a random number which demonstrates
not only unpredictability, but also both temporal and global uniqueness.
The shared secret (the
password shared between the client and the RADIUS server) held by both the
RADIUS server and client is fed into a one-way hash followed by this Authenticator
to create a sixteen octet value which is xored with the password entered by the
user, and the xored result placed in the generation of unique unpredictable
requests can protect against a wide range of active attacks against
authentication.
2. Response Authenticator
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 hash to obtain the response sixteen octet Authenticator.
Packet Types
The RADIUS Packet type is determined by the Code field in the first
octet of the Packet. The packet types used for authentication and authorization
are described below:
Access-Request
This packet is sent to the server from the client to determine whether a
user is allowed access to a specific NAS, and any special services requested
for that user.
Upon receipt of an Access-Request from a valid client, an appropriate
reply must be
transmitted.
Code
1
for Access-Request.
Identifier
The Identifier field must be changed
whenever the content of the Attributes field changes, and whenever a valid reply
has been received for a previous request.
For retransmissions, the
Identifier must remain unchanged.
Request Authenticator
The Request Authenticator value must be changed each time a new
Identifier is used.
Attributes
For the list of Attributes, see the RADIUS
packet structure.
Access-Accept
After the Access-Request is received
and acceptable by the server the Access-Accept packets are sent by the RADIUS
server, and provide specific configuration information necessary to begin
delivery of service to the user.
Code
2
for Access-Accept.
Identifier
The Identifier field is a copy of
the Identifier field of the Access-Request which caused this Access-Accept.
Response
Authenticator
The Response Authenticator value is
calculated from the Access-Request value, as described earlier.
Attributes
For the list of Attributes, see the RADIUS
packet structure.
Access-Reject
In case the server doesn't accept the Access-Request
it transmits an Access-Reject packet It may include one or more Reply-Message
Attributes with a text message which the NAS may display to the user.
Code
3
for Access-Reject.
Identifier
The Identifier field is a copy of
the Identifier field of the Access-Request which caused this Access-Reject.
Response
Authenticator
The Response Authenticator value is calculated from the Access-Request
value, as described earlier.
Attributes
The Attribute field is variable in length, and contains a list of zero
or more Attributes. For the list of Attributes, see the RADIUS
packet structure.
Access-Challenge
When the RADIUS server wants to send the user a challenge requiring a
response, it
uses this kind of packet as a response to the Access-Request packet. If
the NAS does not support challenge/response, it must treat an Access-Challenge
as though it had received an Access-Reject instead.
If the NAS supports challenge/response, receipt of a valid
Access-Challenge indicates that a new Access-Request should be sent. The NAS may display the text message,
if any, to the user, and then prompt the user for a response. It then sends its
original Access-Request with a new request ID and Request Authenticator,
with the User-Password Attribute replaced by the user's response (encrypted),
and including the State Attribute from the Access-Challenge, if any. Only 0 or 1 instances of the State
Attribute can be present in an Access-Request
Code
11
for Access-Challenge.
Identifier
The Identifier field is a copy of the
Identifier field of the Access-Request which caused this Access-Challenge.
Response
Authenticator
The Response Authenticator value is
calculated from the Access-Request value, as described earlier.
Attributes
The Attributes field is variable in
length, and contains a list of zero or more Attributes. For the list of
Attributes, see the RADIUS
packet structure.
Attributes
RADIUS Attributes carry the specific authentication, authorization,
information and configuration details for the request and reply.
Some Attributes may be included more than once. The effect of this is Attribute
specific, and is specified in each Attribute description.
For the list of Attributes, see the full attributes list.
