RADIUS

Remote Authentication Dial-In User Service (RADIUS) is commonly used to provide centralized authentication, authorization, and accounting for dial-up, virtual private network, and, more recently, wireless network access. We can see some security issues of radius and we will discuss Extensible Authentication Protocol (EAP).

Remote Authentication Dial-In User Service (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 virtual private network (VPN) servers, wireless access points, authenticating Ethernet switches, Digital Subscriber Line (DSL) access, and other network access types. RADIUS is described in RFC 2865, "Remote Authentication Dial-in User Service (RADIUS)," (IETF Draft Standard) and RFC2866, "RADIUS Accounting" (Informational).

A RADIUS client (typically an access server such as a dial-up server, VPN server, or wireless access point) sends user credentials and connection parameter information in the form of a RADIUS message to a RADIUS server. The RADIUS server authenticates and authorizes the RADIUS client request, and sends back a RADIUS message response. RADIUS clients also send RADIUS accounting messages to RADIUS servers. Additionally, the RADIUS standards support the use of RADIUS proxies. A RADIUS proxy is a computer that forwards RADIUS messages between RADIUS clients, RADIUS servers, and other RADIUS proxies. RADIUS messages are never sent between the access client and the access server.

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 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.

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 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.

·        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.

A RADIUS message consists of a RADIUS header and RADIUS attributes. Each RADIUS attribute specifies a piece of information about the connection attempt. For example, there are RADIUS attributes for the user name, 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).

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

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-CHAP v2), the results of the authentication negotiation between the access server and the access client are forwarded to the RADIUS server for verification.

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 secure RADIUS traffic and is commonly configured as a text string on both the RADIUS client and server.

Extensible Authentication Protocol (EAP) Overview

The Extensible Authentication Protocol (EAP) was originally developed as an extension to PPP allowing for deployment of arbitrary network access authentication mechanisms. With PPP authentication protocols such as CHAP, MS-CHAP, and MS-CHAP v2, a specific authentication mechanism is chosen during the link establishment phase. During the connection authentication phase, the negotiated authentication protocol is used to validate the connection. The authentication protocol itself is a fixed series of messages sent in a specific order. With EAP, the specific authentication mechanism is not chosen during the link establishment phase of the PPP connection. Instead, each PPP peer negotiates to perform EAP during the connection authentication phase. When the connection authentication phase is reached, the peers negotiate the use of a specific EAP authentication scheme known as an EAP type.

Once the EAP type is agreed upon, EAP allows for an open-ended exchange of messages between the access client and the authenticating server (the RADIUS server) that can vary based on the parameters of the connection. The conversation consists of requests for authentication information and the responses. The length and detail of the authentication conversation is dependent upon the EAP type.

Architecturally, EAP is designed to allow authentication plug-in modules at both the access client and authenticating server ends of a connection. By installing an EAP type library file on both the access client and the authenticating server, a new EAP type can be supported. This presents vendors with the opportunity to supply a new authentication scheme at any time. EAP provides the highest flexibility to allow for more secure authentication methods.

You can use EAP to support authentication schemes such as Generic Token Card, One Time Password (OTP), MD5-Challenge, and Transport Level Security (TLS) for smart card and certificate support, as well as any future authentication technologies. EAP is a critical technology component for secure connections.

In addition to support within PPP, EAP is also supported within the IEEE 802 link layer. IEEE 802.1X, an IEEE standard for network port authentication, defines how EAP is used for authentication by IEEE 802 devices, including IEEE 802.11b (WiFi) wireless access points and Ethernet switches. IEEE 802.1X differs from PPP in that only EAP authentication methods are supported. As a result, it is not possible to negotiate the use of PAP with IEEE 802.1X.

EAP over RADIUS

EAP over RADIUS is not an EAP type, but the passing of EAP messages of any EAP type by the remote access server to a RADIUS server for authentication. An EAP message sent between the access client and access server is formatted as the EAP-Message RADIUS attribute (RFC 2869), and sent in a RADIUS message between the access server and the RADIUS server. The access server becomes a pass-through device passing EAP messages between the access client and the RADIUS server. Processing of EAP messages occurs at the access client and the RADIUS server, not at the access server.

EAP over RADIUS is used in environments where RADIUS is used as the authentication provider. An advantage of using EAP over RADIUS is that EAP types do not need to be installed at each access server, only at the RADIUS server. However, the access server must support the negotiation of EAP as an authentication protocol and the passing of EAP messages to a RADIUS server.

In a typical use of EAP over RADIUS, the access server is configured to use EAP and to use RADIUS as its authentication provider. When a connection attempt is made, the access client negotiates the use of EAP with the access server. When the client sends an EAP message to the access server, the access server encapsulates the EAP message as a RADIUS message and sends it to its configured RADIUS server. The RADIUS server processes the EAP message and sends a RADIUS-formatted EAP message back to the access server. The access server then forwards the EAP message to the access client.