 |
» |
|
|
|
The Remote Authentication Dial In User Service (RADIUS) protocol
is widely used and implemented to manage access to network services.
It defines a standard for information exchange between a Network
Access Server (NAS) and an authentication, authorization, and accounting (AAA)
server for performing authentication, authorization, and accounting
operations. A RADIUS AAA server can manage user profiles for authentication
(verifying user name and password), configuration information that
specifies the type of service to deliver, and policies to enforce
that may restrict user access. RADIUS
Topology | |
The RADIUS protocol follows client-server architecture.
The client sends user information to the RADIUS AAA server (in an
Access-Request message) and after receiving a reply from
the server acts according to the returned information. The RADIUS
AAA server receives user requests for access from the client, attempts
to authenticate the user, and returns the configuration information
and polices to the client. The RADIUS AAA server may be configured
to authenticate an Access-Request locally or to act as
a proxy client and forward a request to another AAA server. After
forwarding a request, it handles the message exchanges between the
NAS and the remote server. A single server can be configured to handle
some requests locally and to forward proxy requests to remote servers. In Figure 1-1 “Generic AAA Network Topology” an example
ISP uses four AAA servers to handle user requests. Each user organization
represents a logical grouping of users (defined as a realm). Each
user organization dials in to one of the ISP's servers
through an assigned NAS, some of which are shared by the same groups
or realm. To provide appropriate service to a customer, the server
accesses user and policy information from a repository, which may be
integrated with the server, may be an external application, or a database
that interfaces with the server. For the HP-UX AAA RADIUS and
policy server the repository information may be stored in flat text files
or in an external database, such as an Oracle® database
or LDAP directory server. Establishing
a RADIUS Session | |
The handling of a user request is series of message exchanges
that attempts to provide the user with a network service by establishing
a session for the user. This transaction can be described as a series
of actions that exchange data packets containing information related
to the request. Figure 1-2 “Client-Server RADIUS Transaction” illustrates
the details of the transaction between a RADIUS AAA server and a
client (a NAS in this example). When the user's workstation
connects to the client, the client sends an Access-Request
RADIUS data packet to the AAA server. When the server receives the request, it validates the sending
client. If the client is permitted to send requests to the server,
the server will then take information from the Access-Request
and attempt to match the request to a user profile. The profile
will contain a list of requirements that must be met to successfully
authenticate the user. Authentication usually includes verification
of a password, but can also specify other information, such as the
port number of the client or the service type that has been requested,
that must be verified. If all conditions are met, the server will send an Access-Accept
packet to the client; otherwise, the server will send an Access-Reject.
An Access-Accept data packet often includes authorization
information that specifies what services the user can access and
other session information, such as a timeout value that will indicate
when the user should be disconnected from the system. When the client receives an Access-Accept packet,
it will generate an Accounting-Request to start the session
and send the request to the server. The Accounting-Request
data packet describes the type of service being delivered and the
user that will use the service. The server will respond with an
Accounting-Response to acknowledge that the request was
successfully received and recorded. The user's session
will end when the client generates an Accounting-Request—triggered
by the user, by the client, or an interruption in service—to
stop the session. Again, the server will acknowledge the Accounting-Request
with an Accounting-Response. Supported
Authentication Methods | |
The following list describes the authentication methods the
HP-UX AAA Server supports: Password Authentication Protocol (
PAP) is not a strong authentication
method to establish a connection; passwords are sent in clear text
between the user and client. When used with RADIUS for authentication,
the messages exchanged between the client and server to establish
a PPP connection corresponds to Figure 1-2 “Client-Server RADIUS Transaction”. This authentication method is most appropriately used
where a plaintext password must be available to simulate a login
at a remote host. In such use, this method provides a similar level
of security to the usual user login at the remote host. Challenge-Handshake Authentication
Protocol (CHAP)
is a stronger authentication protocol to establish a connection.
When used with RADIUS for authentication, the messages exchanged between
the client and server to establish a PPP connection is similar to Figure 1-2 “Client-Server RADIUS Transaction”. One difference, however,
is that a challenge occurs between the user and NAS before the NAS
sends an Access-Request. The user must respond by encrypting
the challenge (usually a random number) and returning the result.
Authorized users are equipped with special devices, like smart cards
or software, which can calculate the correct response. The NAS will
then forward the challenge and the response in the Access-Request,
which the AAA server will use to authenticate the user. Microsoft
Challenge-Handshake Authentication Protocol (MS-CHAP)
is an implementation of the CHAP protocol that Microsoft created
to authenticate remote Windows workstations. In most respects, MS-CHAP
is identical to CHAP, but there are some differences. MS-CHAP is
based on the encryption and hashing algorithms used by Windows networks,
and the MS-CHAP response to a challenge is in a format optimized
for compatibility with Windows operating systems.
RADIUS
Data Packets | |
The Access-Request and other RADIUS data packets
contain a header and a set of attribute-value (A-V)
pairs, which are used by the server during the AAA transaction.
The RADIUS RFC 2865 defines how vendors can extend the protocol.
Encapsulation is the RFC defined way of extending RADIUS. Conflicts
can occur when the RFC is not followed. In those cases, the server
can map the attributes to unique internal values for processing.
For a full description of RADIUS attribute-value pairs,
see the Administrator's Guide. Shared
Secret | |
Encrypting the transmission of the User-Password
in a request is accomplished by a shared secret. The shared secret
is used to sign RADIUS data packets to ensure they are coming from
a trusted source. The shared secret is also used to encrypt user
passwords with certain authentication methods such as PAP. The HP-UX
AAA Server uses the clients configuration file to associate a secret to each
client (or server) that is authorized to make use of its services. |
Printable version
