Skip to main content

2.3 Proxy

2.3. Proxy

With proxy RADIUS, one RADIUS server receives an authentication (or accounting) request from a RADIUS client (such as a NAS), forwards the request to a remote RADIUS server, receives the reply from the remote server, and sends that reply to the client, possibly with changes to reflect local administrative policy. A common use for proxy RADIUS is roaming. Roaming permits two or more administrative entities to allow each other's users to dial in to either entity's network for service.

The NAS sends its RADIUS access-request to the "forwarding server" which forwards it to the "remote server". The remote server sends a response (Access-Accept, Access-Reject, or Access-Challenge) back to the forwarding server, which sends it back to the NAS. The User-Name attribute MAY contain a Network Access Identifier [8] for RADIUS Proxy operations. The choice of which server receives the forwarded request SHOULD be based on the authentication "realm". The authentication realm MAY be the realm part of a Network Access Identifier (a "named realm"). Alternatively, the choice of which server receives the forwarded request MAY be based on whatever other criteria the forwarding server is configured to use, such as Called- Station-Id (a "numbered realm").

A RADIUS server can function as both a forwarding server and a remote server, serving as a forwarding server for some realms and a remote server for other realms. One forwarding server can act as a forwarder for any number of remote servers. A remote server can have any number of servers forwarding to it and can provide authentication for any number of realms. One forwarding server can forward to another forwarding server to create a chain of proxies, although care must be taken to avoid introducing loops.

The following scenario illustrates a proxy RADIUS communication between a NAS and the forwarding and remote RADIUS servers:

  1. A NAS sends its access-request to the forwarding server.

  2. The forwarding server forwards the access-request to the remote server.

  3. The remote server sends an access-accept, access-reject or access-challenge back to the forwarding server. For this example, an access-accept is sent.

  4. The forwarding server sends the access-accept to the NAS.

The forwarding server MUST treat any Proxy-State attributes already in the packet as opaque data. Its operation MUST NOT depend on the content of Proxy-State attributes added by previous servers.

If there are any Proxy-State attributes in the request received from the client, the forwarding server MUST include those Proxy-State attributes in its reply to the client. The forwarding server MAY include the Proxy-State attributes in the access-request when it forwards the request, or MAY omit them in the forwarded request. If the forwarding server omits the Proxy-State attributes in the forwarded access-request, it MUST attach them to the response before sending it to the client.

We now examine each step in more detail.

  1. A NAS sends its access-request to the forwarding server. The forwarding server decrypts the User-Password, if present, using the shared secret it knows for the NAS. If a CHAP-Password attribute is present in the packet and no CHAP-Challenge attribute is present, the forwarding server MUST leave the Request- Authenticator untouched or copy it to a CHAP-Challenge attribute.

'' The forwarding server MAY add one Proxy-State attribute to the packet. (It MUST NOT add more than one.) If it adds a Proxy- State, the Proxy-State MUST appear after any other Proxy-States in the packet. The forwarding server MUST NOT modify any other Proxy-States that were in the packet (it may choose not to forward them, but it MUST NOT change their contents). The forwarding server MUST NOT change the order of any attributes of the same type, including Proxy-State.

  1. The forwarding server encrypts the User-Password, if present, using the secret it shares with the remote server, sets the Identifier as needed, and forwards the access-request to the remote server.

  2. The remote server (if the final destination) verifies the user using User-Password, CHAP-Password, or such method as future extensions may dictate, and returns an access-accept, access- reject or access-challenge back to the forwarding server. For this example, an access-accept is sent. The remote server MUST copy all Proxy-State attributes (and only the Proxy-State attributes) in order from the access-request to the response packet, without modifying them.

  3. The forwarding server verifies the Response Authenticator using the secret it shares with the remote server, and silently discards the packet if it fails verification. If the packet passes verification, the forwarding server removes the last Proxy-State (if it attached one), signs the Response Authenticator using the secret it shares with the NAS, restores the Identifier to match the one in the original request by the NAS, and sends the access- accept to the NAS.

A forwarding server MAY need to modify attributes to enforce local policy. Such policy is outside the scope of this document, with the following restrictions. A forwarding server MUST not modify existing Proxy-State, State, or Class attributes present in the packet.

Implementers of forwarding servers should consider carefully which values it is willing to accept for Service-Type. Careful consideration must be given to the effects of passing along Service- Types of NAS-Prompt or Administrative in a proxied Access-Accept, and implementers may wish to provide mechanisms to block those or other service types, or other attributes. Such mechanisms are outside the scope of this document.

Last updated on