11 Usage of RADIUS on Wi interface

29.1613GPPInterworking between the Public Land Mobile Network (PLMN) supporting packet based services with Wireless Local Area Network (WLAN) access and Packet data Networks (PDN)TS

NOTE: The application of procedures in subclause 11.1 is not recommended. The application of procedures in subclause 11.3 is only recommended if user authentication and authorisation is not required. The procedures of those flows are incomplete for the following reason: In order to perform RADIUS Authentication, user ID and password information have to be passed from WLAN UE to PDG. However, this function is missing in the IKEv2 protocol that 3GPP TS 33.234 [16] refers in this release. In addition, user authentication and authorisation with AAA server will be standardised in release 7.

A PDG may, on a per W-APN basis, use RADIUS authentication to authenticate a user and RADIUS accounting to provide information to an External AAA (Authentication, Authorization and Accounting) server.

11.1 RADIUS Authentication and Authorization

RADIUS authentication and authorization shall be used according to RFC 2865 [10] and RFC 3162 [11].

The RADIUS client function may reside in a PDG. When the PDG receives a tunnel establishment request, the RADIUS client function may initiate the authentication and authorization procedure with the External AAA Server after the successful authentication and autorisation with the 3GPP AAA Server.

The following procedure may take place depending on an ability of the External AAA Server. Details on the following procedures are specified in 3GPP TS 33.234 [16].

  • The EAP procedure
    This procedure is the most preferable configuration for the ISP/Intranet access. In this procedure, the External AAA Server shall support EAP extensions specified in the RADIUS (Remote Authentication Dial In User Service) Support for Extensible Authentication Protocol (EAP) [20].
  • The PAP procedure
    This procedure is applied if the External AAA server performs PAP procedure.
  • The CHAP procedure
    This procedure is applied if the External AAA server performs CHAP procedure.

The External AAA Server checks that the user can be accepted. The response (when positive) may contain network information, such as an IPv4 address or IPv6 prefix for the user.

The information delivered during the RADIUS authentication and authorization can be used to automatically correlate the users identity to the IPv4 address or IPv6 prefix, assigned/confirmed by the PDG or the External AAA Server respectively. The same procedure applies, in case of sending the authentication and authorization to a ‘proxy’ authentication server.

11.2 RADIUS Accounting

RADIUS Accounting shall be used according to RFC 2866 [12] and RFC 3162 [11].

The RADIUS accounting client function may reside in a PDG. The RADIUS accounting client may send information to an accounting server, which is identified during the W-APN provisioning. The accounting server may store this information and use it to automatically identify the user. This information can be trusted because the 3GPP network has authenticated the subscriber.

The Accounting-Request STOP and the Accounting ON and Accounting OFF messages may be used to ensure that information stored in the accounting server is synchronized with the PDG information.

11.3 Authentication, Authorization and Accounting message flows

Figure 6 presents the RADIUS message flows between a PDG and an Authentication, Authorization and Accounting (AAA) server. For details of the tunnel establishment and deletion signalling, refer to 3GPP TS 24.234 [3].

NOTE 1: If some external applications require RADIUS Accounting request (Start) information before they can process user packets, then the selected W-APN (PDG) may be configured in such a way that the PDG drops user data until the Accounting Response (START) is received from the External AAA server. The PDG may wait for the Accounting Response (START) before sending the ike-auth response. The PDG may reject the tunnel establishment, if the Accounting Response (START) is not received.

NOTE 2: Separate accounting and authentication servers may be used.

NOTE 3: The Accounting-Request (Start) message may be sent at a later stage, e.g. after IPv6 address has been assigned and PDP Context updated, in case of a stateful address autoconfiguration.

Figure 6: RADIUS message flow

When a PDG receives a tunnel establishment request (IKE-AUTH request) for a given W-APN, the PDG may (depending on the configuration for this W-APN) send a RADIUS Access-Request to an External AAA Server after the successful authentication and autorisation with the 3GPP AAA Server. The External AAA server authenticates and authorizes the user. If RADIUS is also responsible for IPv4 address or IPv6 prefix allocation, the External AAA Server shall return the allocated IPv4 address or IPv6 prefix in the Access-Accept message.

Even if the PDG was not involved in user authentication (e.g. transparent network access mode), it may send a RADIUS Accounting-Request START message to an External AAA Server. This message contains parameters, e.g. the tuple, which includes the user-id and IPv4 address or IPv6 prefix, to be used by application servers (e.g. WAP gateway) in order to identify the user. This message also indicates to the External AAA Server that the user session has started. The session is uniquely identified by the Acct-Session-Id that is composed of the Charging-Id and the PDG-Address.

If some external applications require RADIUS Accounting request (Start) information before they can process user packets, then the selected W-APN (PDG) may be configured in such a way that the PDG drops user data until the Accounting Response (START) is received from the AAA server. The PDG may wait for the Accounting Response (START) before sending the tunnels establishment response (IKE-AUTH response). The PDG may reject the tunnel establishment request, if the Accounting Response (START) is not received. The authentication and accounting servers may be separately configured for each W-APN.

At a stateful address autoconfiguration, no IPv4 address or IPv6 prefix is available at tunnel establishment. In that case the PDG may wait to send the Accounting-Request START message until the WLAN UE receives its IP address in a DHCP-REPLY.

When the PDG receives a delete tunnel request (informational (delete)) and providing a RADIUS Accounting-Request START message was sent previously, the PDG shall send a RADIUS Accounting-Request STOP message to the External AAA Server, which indicates the termination of this particular user session. The PDG shall immediately send a delete tunnel response (informational-resp), without waiting for an Accounting-Response STOP message from the AAA server.

The External AAA Server shall deallocate the IPv4 address or IPv6 prefix (if any) initially allocated to the subscriber, if there is no session for the subscriber.

Accounting-Request ON and Accounting-Request OFF messages may be sent from the PDG to the External AAA Server to ensure the correct synchronization of the session information in the PDG and the External AAA Server.

The PDG may send an Accounting-Request ON message to the External AAA Server to indicate that a restart has occurred. The External AAA Server may then release the associated resources.

Prior to a scheduled restart, the PDG may send Accounting-Request OFF message to the External AAA Server. The External AAA Server may then release the associated resources.

If an Access-Challenge is sent to the PDG when an Access-Request message is pending, the PDG shall silently discard the Access-Challenge message and it shall treat an Access-Challenge as though it had received an Access-Reject instead RFC 2865 [10].

11.4 List of RADIUS attributes

Refer to the 3GPP TS 29.061 [4], subclause "List of Radius attributes".