RADIUS

RADIUS

RADIUS is a widely deployed protocol enabling centralized authentication, authorization, and accounting for network access.

Originally developed for dial-up remote access, RADIUS is now supported by wireless access points (APs), authenticating Ethernet switches, virtual private network (VPN) servers, Digital Subscriber Line (DSL) access servers, and other types of network access servers.

More Info
RADIUS is described in RFC 2865, Remote Authentication Dial-In User Service (RADIUS), and RFC 2866, RADIUS Accounting.

Components of a RADIUS Infrastructure

A RADIUS authentication, authorization, and accounting infrastructure consists of the following components:

  • Access clients

  • Access servers (RADIUS clients)

  • RADIUS servers

  • User account databases

  • RADIUS proxies

These components are shown in Figure 4-1.

figure 4-1 the components of a radius infrastructure.

Figure 4-1. The components of a RADIUS infrastructure.

These components are described in detail in the following sections.

Access Clients

An access client requires access to a network or another part of the network. Examples of access clients are dial-up or VPN remote access clients, wireless clients, or LAN clients connected to a switch.

Access Servers

An access server provides access to a network. An access server using a RADIUS infrastructure is also a RADIUS client, sending connection requests and accounting messages to a RADIUS server. Examples of access servers are the following:

  • Wireless APs that provide physical layer access to an organization s network by using wireless-based transmission and reception technologies.

  • Switches that provide physical layer access to an organization s network by using traditional LAN technologies such as Ethernet.

  • Network access servers (NASs) that provide remote access connectivity to an organization s network or the Internet. An example is a computer running Windows Server 2003 or Windows 2000 Server and the Routing and Remote Access service and providing either traditional dial-up or VPN-based remote access to an organization s intranet.

RADIUS Servers

A RADIUS server receives and processes connection requests or accounting messages sent by RADIUS clients or RADIUS proxies. During a connection request, the RADIUS server processes the list of RADIUS attributes in the connection request. Based on a set of rules and the information in the user account database, the RADIUS server either authenticates and authorizes the connection and sends back an Access-Accept message or sends back an Access-Reject message. The Access-Accept message can contain connection restrictions that are enforced by the access server for the duration of the connection.

NOTE
The IAS component of Windows 2000 Server and Windows Server 2003 is an industry standard compliant RADIUS server.

User Account Databases

A user account database is a list of user accounts and their properties that can be checked by a RADIUS server to verify authentication credentials and obtain user account properties containing authorization and connection parameter information.

The user account databases that IAS can use are the local Security Accounts Manager (SAM), a Microsoft Windows NT 4.0 domain, or Active Directory. For Active Directory, IAS can provide authentication and authorization for user or computer accounts in the domain in which the IAS server is a member; two-way trusted domains; and trusted forests with domain controllers running a member of the Windows 2000 Server or Windows Server 2003 families.

If the user accounts for authentication reside in a different type of database, you can use a RADIUS proxy to forward the authentication request to a RADIUS server that does have access to the user account database.

RADIUS Proxies

A RADIUS proxy routes RADIUS connection requests and accounting messages between RADIUS clients (and RADIUS proxies) and RADIUS servers (and RADIUS proxies). The RADIUS proxy uses information within the RADIUS message to route the RADIUS message to the appropriate RADIUS client or server.

A RADIUS proxy can be used as a forwarding point for RADIUS messages when the authentication, authorization, and accounting must occur at multiple RADIUS servers in different organizations.

With the RADIUS proxy, the definition of RADIUS client and RADIUS server becomes blurred. A RADIUS client to a RADIUS proxy can be an access server (that originates connection requests or accounting messages) or another RADIUS proxy (in a chained proxy configuration). There can be multiple RADIUS proxies between the originating RADIUS client and the final RADIUS server using chained RADIUS proxies. In a similar way, a RADIUS server to a RADIUS proxy can be the final RADIUS server (to which the RADIUS message is ultimately destined) or another RADIUS proxy. Therefore, when referring to RADIUS clients and servers from a RADIUS proxy perspective, a RADIUS client is the RADIUS entity from which it receives RADIUS request messages, and a RADIUS server is the RADIUS entity to which it forwards RADIUS request messages.

NOTE
The IAS component of Windows Server 2003 is an industry standard compliant RADIUS proxy.

RADIUS Messages

RADIUS messages are sent as User Datagram Protocol (UDP) messages. UDP port 1812 is used for RADIUS authentication messages, and UDP port 1813 is used for RADIUS accounting messages. Some older access servers might use UDP port 1645 for RADIUS authentication messages and UDP port 1646 for RADIUS accounting messages. Only one RADIUS message is included in the UDP payload of a RADIUS packet.

A RADIUS message consists of a RADIUS header and RADIUS attributes. Each RADIUS attribute contains a specific item of information about the connection. For example, there are RADIUS attributes for the username, the user password, the type of service requested by the user, and the IP address of the access server.

RADIUS attributes are used to convey information between RADIUS clients, RADIUS proxies, and RADIUS servers. For example, the list of attributes in the Access-Request message includes information about the user credentials and the parameters of the connection attempt. In contrast, the list of attributes in the Access-Accept message includes information about the type of connection that can be made, connection constraints, and any vendor-specific attributes (VSAs).

More Info
RADIUS attributes are described in RFCs 2865, 2866, 2867, 2868, 2869, and 3162. RFCs and Internet drafts for VSAs define additional RADIUS attributes.

RFCs 2865 and 2866 define the following RADIUS message types:

  • Access-Request

    Sent by a RADIUS client to request authentication and authorization for a network access connection attempt.

  • Access-Accept

    Sent by a RADIUS server in response to an Access-Request message. This message informs the RADIUS client that the connection attempt is authenticated and authorized.

  • Access-Reject

    Sent by a RADIUS server in response to an Access-Request message. This message informs the RADIUS client that the connection attempt is rejected. A RADIUS server sends this message if either the credentials are not authentic or the connection attempt is not authorized.

  • Access-Challenge

    Sent by a RADIUS server in response to an Access-Request message. This message is a challenge to the RADIUS client that requires a response. This challenge helps to verify the identity of the client.

  • Accounting-Request

    Sent by a RADIUS client to specify accounting information for a connection that was accepted.

  • Accounting-Response

    Sent by the RADIUS server in response to the Accounting-Request message. This message acknowledges the successful receipt and processing of the Accounting-Request message.

For Point-to-Point Protocol (PPP) authentication protocols such as Password Authentication Protocol (PAP), Challenge Handshake Authentication Protocol (CHAP), Microsoft Challenge Handshake Authentication Protocol (MS-CHAP), and MS-CHAP version 2 (MS-CHAPv2), the results of the authentication negotiation between the access server and the access client are forwarded to the RADIUS server for verification in the Access-Request message.

For Extensible Authentication Protocol (EAP) authentication, the negotiation occurs between the RADIUS server and the access client. The RADIUS server uses Access-Challenge messages to send EAP messages to the access client. The access server forwards EAP messages sent by the access client to the RADIUS server as Access-Request messages. For more information, see Chapter 5, EAP

RADIUS Authentication, Authorization, and Accounting Processes

Authentication, authorization, and accounting of network access connections use RADIUS messages in the following way:

  1. Access servers, such as dial-up network access servers, VPN servers, and wireless APs, receive connection requests from access clients.

  2. The access server, configured to use RADIUS as the authentication, authorization, and accounting protocol, creates an Access-Request message and sends it to the RADIUS server.

  3. The RADIUS server evaluates the Access-Request message.

  4. If required (for example, when the authentication protocol is EAP), the RADIUS server sends an Access-Challenge message to the access server. The response to the challenge is sent as a new Access-Request to the RADIUS server.

  5. The user credentials and the authorization of the connection attempt are verified.

  6. If the connection attempt is both authenticated and authorized, the RADIUS server sends an Access-Accept message to the access server.

    If the connection attempt is either not authenticated or not authorized, the RADIUS server sends an Access-Reject message to the access server.

  7. Upon receipt of the Access-Accept message, the access server completes the connection process with the access client and sends an Accounting-Request message to the RADIUS server.

  8. After the Accounting-Request message is processed, the RADIUS server sends an Accounting-Response message.

More Info
For a detailed description of the RADIUS authentication process for wireless access, see Chapter 5.

Securing RADIUS Traffic

RADIUS traffic, like any other network traffic, is susceptible to interception and analysis. To provide the best security for your RADIUS traffic, you should use the following:

  • Strong shared secrets

  • Message-Authenticator attribute

  • Internet Protocol security (IPSec)

Using Strong Shared Secrets

To provide security for RADIUS messages, the RADIUS client and the RADIUS server are configured with a common shared secret. The shared secret is used to authenticate RADIUS messages (by using the Authenticator field in the RADIUS header of RADIUS response messages) and to encrypt sensitive RADIUS attributes. The shared secret is commonly configured as a text string on both the RADIUS client and server.

In many RADIUS installations, the same shared secret is used to protect many RADIUS client-server pairs, and the RADIUS shared secret does not have sufficient randomness (or information entropy) to prevent a successful offline dictionary attack. For a guess of the RADIUS shared secret, the value of the Authenticator field in the RADIUS response message is easily computed. These results are compared to the values contained within a captured Access-Accept, Access-Reject, or Access-Challenge message.

Creating a Strong Shared Secret

A simple RADIUS shared secret can be easily compromised, so it is important to create strong shared secrets. If the shared secret must be a sequence of keyboard characters, it should be at least 22 characters long and consist of a random sequence of upper- and lowercase letters, numbers, and punctuation. If the shared secret can be configured as a sequence of hexadecimal digits, use at least 32 random hexadecimal digits.

RFC 2865 recommends shared secrets be at least 16 characters long, but for a total of 128 bits of information entropy, each character must contain a full 8 bits of information entropy. If the shared secret is limited to keyboard characters (as opposed to hexadecimal digits), each character has only 5.8 bits of information entropy. To provide 128 bits of information entropy, the RADIUS client, server, or proxy should allow the configuration of shared secrets at least 22 keyboard characters long. For example, shared secrets for Windows 2000 Server IAS and Windows Server 2003 IAS can be up to 128 keyboard characters long.

To ensure a random shared secret, use a computer program to generate a random sequence at least 22 characters long and use as many different shared secrets as you can.

Using the Message-Authenticator Attribute

By default, there is no cryptographic verification of the incoming Access-Request message by the RADIUS server. The RADIUS server verifies that the message originated from an Internet Protocol (IP) address for a configured RADIUS client, but source IP addresses for RADIUS messages can be easily spoofed and therefore provide little assurance that the incoming request is genuine or has not been altered.

The solution is for the RADIUS server to require the Message-Authenticator attribute in all Access-Request messages. The Message-Authenticator attribute is the keyed Message Digest 5 (MD5) hash of the entire Access-Request message using the shared secret as the key. The access server must send Access-Request messages with the Message-Authenticator attribute, and the RADIUS server must silently discard the message if the Message-Authenticator attribute is either not present or fails verification. Normally, the Message-Authenticator attribute is required only for EAP over RADIUS messages. Requiring the Message-Authenticator attribute for IAS is configured from the properties of a RADIUS client in the Internet Authentication Service snap-in.

Fortunately, for wireless access, EAP is always used and the Message Authenticator attribute is always present in Access-Request messages.

Using IPSec

To provide data confidentiality for the entire RADIUS message, implement IPSec using Encapsulating Security Payload (ESP) and an encryption algorithm such as Triple Data Encryption Standard (3DES). (This technique is described more fully in RFC 3162.) By encrypting the entire RADIUS message with IPSec, sensitive RADIUS fields (such as the Request Authenticator field in the Access-Request message) and attributes (such as User-Password, Tunnel-Password, and the MPPE-Key attributes) are further protected from compromise while traveling over the network.

An attacker must first decrypt the IPSec-protected RADIUS message before they can analyze the RADIUS message contents. Support for certificate-based IPSec authentication is recommended to prevent an attacker from launching online attacks against a RADIUS server.



Deploying Secure 802.11 Wireless Networks with Microsoft Windows
Deploying Secure 802.11 Wireless Networks with Microsoft Windows
ISBN: 0735619395
EAN: 2147483647
Year: 2000
Pages: 123
Authors: Joseph Davies

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net