This chapter describes how to use Oracle Communications Billing and Revenue Management Elastic Charging Engine (ECE) RADIUS Gateway for authenticating access requests and processing accounting requests from RADIUS clients, such as terminal servers or network access servers (NAS).
Before reading this chapter, you should be familiar with ECE concepts and architecture. See the following chapters in BRM Elastic Charging Engine Concepts:
ECE Overview
ECE System Architecture
Before using RADIUS Gateway for authentication and accounting, you should be familiar with RFC-2865, RFC-2869, and RFC-2866. See BRM Elastic Charge Engine RADIUS Gateway Protocol Implementation Conformance Statement for information about the supported attribute-value pairs (AVPs) and messages.
Important:
Before using RADIUS Gateway for authentication or accounting, you must first implement ECE with Pricing Design Center (PDC) and Oracle Communications Billing and Revenue Management (BRM) to load event definitions from PDC into ECE and to load customer data and data keys from BRM into ECE. See "Integrating ECE with PDC" and "Integrating ECE with BRM" for instructions.You use RADIUS Gateway for authenticating access requests and processing accounting requests for online charging when your customers use your terminal server or NAS to connect to ECE. RADIUS Gateway does the following when it receives a request from the RADIUS client:
Translates the request into an ECE request.
Submits the ECE request to the ECE server.
Receives the ECE response from the ECE server and translates it into a RADIUS message response.
Sends the RADIUS message response to the RADIUS client.
The following steps summarize how to set up ECE for authentication and accounting using RADIUS Gateway:
Add additional RADIUS Gateway nodes required for your topology and configure each instance.
See the discussion about configuring the ECE system in BRM Elastic Charging Engine System Administrator's Guide for instructions on how to add RADIUS Gateway nodes and specifying RADIUS Gateway node properties.
(Optional) Customize the RADIUS data dictionary to include custom vendor-specific attributes.
See the discussion about configuring the ECE system in BRM Elastic Charging Engine System Administrator's Guide for instructions on how to customize the RADIUS data dictionary.
Load your event definitions (which include request specification data) from PDC into ECE. See "Loading Pricing Data into ECE" for more information.
Load customer data and data keys from BRM into ECE. See "Loading Data from BRM into ECE" for more information.
Load the RADIUS mediation specification data.
See the discussion about configuring the ECE system in BRM Elastic Charging Engine System Administrator's Guide for instructions on how to load the RADIUS mediation specification data.
Map RADIUS network attributes to event attributes.
See the discussion about configuring the ECE system in BRM Elastic Charging Engine System Administrator's Guide for instructions on how to map the RADIUS network attributes to event attributes.
Start the RADIUS Gateway nodes.
When the RADIUS Gateway nodes start, they automatically join the Coherence cluster gaining access to ECE caches and invocation services that it uses to send requests to ECE.
See the discussion about starting and stopping ECE in BRM Elastic Charging Engine System Administrator's Guide for instructions on how to start RADIUS Gateway nodes.
RADIUS Gateway queries the ECE server for the AVPs received in the access requests from RADIUS clients and authenticates the user based on the information retrieved from the ECE server.
RADIUS Gateway supports the following authentication mechanisms for querying the ECE server and authenticating access requests:
Password Authentication Protocol (PAP). An authentication protocol that uses the user name and password to validate users. See "Authenticating Access Requests by Using PAP" for more information on how RADIUS Gateway performs the PAP authentication.
Challenge Handshake Authentication Protocol (CHAP). An authentication protocol that authenticates a user to a network entity; for example, the Web. This protocol ensures that the server sends a challenge to the RADIUS client after the RADIUS client establishes a network connection to access the Web server. See "Authenticating Access Requests by Using CHAP" for more information on how RADIUS Gateway performs the CHAP authentication.
Extensible Authentication Protocol (EAP). An authentication protocol that supports multiple authentication mechanisms for authenticating network access; for example, EAP-Message Digest 5 (MD5). See "Authenticating Access Requests by Using EAP" for more information on how RADIUS Gateway performs the EAP authentication.
You use PAP to authenticate access requests based on the clear-text user name and user password. Only Access-Request requests are considered for PAP authentication: other messages are ignored. The PAP authentication is performed based on the User-Name and User-Password AVP values in the Access-Request request.
The PAP authentication process is as follows:
RADIUS Gateway receives the Access-Request request from the RADIUS client.
RADIUS Gateway authenticates the RADIUS client using the sharedsecret password that you provided during installation.
Note:
If RADIUS clients are represented by using an IP address range, ensure that all the RADIUS clients within the IP address range use the same sharedsecret password.RADIUS Gateway translates the Access-Request request into an ECE query.
RADIUS Gateway sends the query with the User-Name AVP value to the ECE server to validate the user name.
If the user name is not found in the ECE server, the ECE server returns a failed response. RADIUS Gateway translates the failed response into the Access-Reject message and returns it to the RADIUS client.
If a match for the user name is found, RADIUS Gateway sends a query with the User-Password AVP value in the request to the ECE server to validate the user password.
The ECE server returns a password. If the password is encrypted, RADIUS Gateway decrypts the password using a data key loaded from BRM before validating the user password. The data key to be used is identified using the key ID in the password returned by the ECE server.
If the user password in the ECE server matches the User-Password AVP value in the query, the ECE server returns a success response. RADIUS Gateway translates the success response into the Access-Accept message and returns it to the RADIUS client.
If the user password does not match, the ECE server returns a failed response. RADIUS Gateway translates the failed response into the Access-Reject message and returns it to the RADIUS client.
Sample Access-Request Request for PAP Authentication
Code: Access-Request(1) Identifier: 0 Length: 120 Authenticator: 0x7D564C041FD183A4DBA037E03E3244F3 User-Name: alias#1006 User-Password: 0x41FD183A4335037E03E3244F3123123 NAS-IP-Address: 128.1.2.3 NAS-Port-Type: 1034 Service-Type: 2
You use CHAP to authenticate access requests by validating the identity of the RADIUS client using Access-Challenge messages. The CHAP authentication is performed based on the CHAP-Password and CHAP-Challenge AVP values in the Access-Request request. RADIUS Gateway uses the State AVP value in the Access-Request request or the noOfChallenges value that you configured in ECE to carry out the number of Access-Challenge messages for a given authentication session.
At any time in a given authentication session, RADIUS Gateway can also request the RADIUS client to send an Access-Challenge message. The CHAP authentication uses encrypted passwords for authentication and the Access-Challenge message can be requested for authentication by RADIUS Gateway at any time. Therefore, the CHAP authentication process is considered more secure than the PAP authentication process.
The CHAP authentication process is as follows:
The RADIUS client encrypts a clear-text user password by using the CHAP identifier and CHAP-Challenge AVP value and sends it in the CHAP-Password AVP in an Access-Request request.
RADIUS Gateway authenticates the RADIUS client using the sharedsecret password that you provided during installation.
Note:
If RADIUS clients are represented by using an IP address range, ensure that all the RADIUS clients within the IP address range use the same sharedsecret password.RADIUS Gateway translates the Access-Request request into an ECE query.
RADIUS Gateway sends the query with the User-Name AVP value to the ECE server to validate the user name.
If the user name is not found in the ECE server, the ECE server returns a failed response. RADIUS Gateway translates the failed response into the Access-Reject message and returns it to the RADIUS client.
If a match for the user name is found, the ECE server returns the password associated with the user name. If the password is encrypted, RADIUS Gateway decrypts the password into a clear-text password using the data key loaded from BRM before validating the password. The data key to be used is identified using the key ID in the password returned by the ECE server.
RADIUS Gateway generates an MD5 hash value using the password, CHAP-Challenge AVP, and CHAP identifier (which is the first byte of the CHAP-Password AVP), and compares it with the CHAP-Password AVP value in the Access-Request request.
If the values do not match, RADIUS Gateway returns a failed response. RADIUS Gateway returns an Access-Reject message to the RADIUS client.
If the MD5 hash value and the CHAP-Password AVP value match, RADIUS Gateway returns a success response.
RADIUS Gateway sends an Access-Challenge message to the RADIUS client.
RADIUS Gateway uses the State AVP value in the Access-Request request to determine the number of Access-Challenge messages to be sent to the RADIUS client. For example, if the State AVP value is 0, RADIUS Gateway directly returns the Access-Accept message. If the State AVP value is 1, RADIUS Gateway sends only one Access-Challenge message to the RADIUS client.
If the State AVP value is null or if the value is not set, RADIUS Gateway calculates a random number between one and the maximum number of challenges configured in ECE and sends the Access-Challenge messages to the RADIUS client.
The RADIUS client responds with a value calculated through the MD5 hash function.
RADIUS Gateway checks the response against its calculation of the expected hash value.
If the values match, RADIUS Gateway repeats the Access-Challenge messages based on the State AVP value or the number calculated by RADIUS Gateway.
If the values do not match, RADIUS Gateway returns an Access-Reject message to the RADIUS client.
Sample Access-Request Request for CHAP Authentication
Code: Access-Request(1) Identifier: 0 Length: 144 Authenticator: 0x7D564C041FD183A4DBA037E03E3244F3 CHAP-Password: 0x423423432412ADA123CC1123124123 Chap-Challenge="0xFBFCE5676F94433682718EF97F8AB24900" NAS-IP-Address: 127.0.0.8 State: 0 NAS-Port-Type: 1816 Service-Type: 2
You use EAP to authenticate users using different authentication mechanisms. EAP includes password-based authentication methods and secure certificate-based authentication methods. The EAP authentication is performed based on the EAP-Message AVP value in the Access-Request request. RADIUS Gateway supports the following EAP authentication methods:
EAP-Tunneled Transport Layer Security (TTLS). Authentication between RADIUS Gateway and the RADIUS client uses a secured connection in two phases. In the first phase, RADIUS Gateway and the RADIUS client exchange authentication certificates for establishing the secured connection. In the second phase, RADIUS Gateway authenticates the RADIUS client by using different authentication mechanisms, such as EAP-PAP, EAP-CHAP, and EAP-MD5. These authentication mechanisms use the attributes in the Access-Request request to perform the authentication. You can also configure a custom EAP authentication mechanism by using the RADIUS Gateway extension points. For information about RADIUS-Request processing extension points, see BRM Elastic Charge Engine Extensions.
EAP-Non-TTLS. Authentication between RADIUS Gateway and the RADIUS client uses a configured list of EAP authentication mechanisms. The EAP-Non-TTLS authentication process is as follows:
RADIUS Gateway performs a standard check on the Access-Request request received from the RADIUS client.
RADIUS Gateway sends the EAP-Type AVP in the Access-Challenge message that contains the value corresponding to the first EAP type configured.
If the RADIUS client returns NAK, RADIUS Gateway sends the next EAP type in the configured list in the Access-Challenge message. RADIUS Gateway continues this process until the RADIUS client responds with an Access-Accept message or until the end of the configured list is reached. In that case, RADIUS Gateway sends an Access-Reject message.
RADIUS Gateway, by default, supports only the EAP-MD5 authentication mechanism in the EAP-Non-TTLS method. To use a different authentication method, use the CustomAuth and CustomEAPChallenge extension points. The CustomEAPChallenge extension point sends the initial EAP challenge to the RADIUS client. The CustomAuth extension point performs the authentication and returns the authentication result. Based on the result received, RADIUS Gateway sends the appropriate RADIUS response to the RADIUS client. For information about the CustomAuth and CustomEAPChallenge extension points, see BRM Elastic Charge Engine Extensions.
Sample Access-Request Request for EAP-MD5 Authentication
Code: Access-Request(1) Identifier: 0 Length: 120 Authenticator: 0x7D564C041FD183A4DBA037E03E3244F3 User-Name: BOB NAS-IP-Address: 127.0.0.1 Calling-Station-Id: 02-00-00-00-00-01 Framed-MTU: 1400 NAS-Port-Type: 19 Connect-Info: CONNECT 11Mbps 802.11b Service-Type: 2 EAP-Message: 0x0200000801424F42 Message-Authenticator: 0x4FB1186DDA9643CED0CD13D59ECD9D4E
RADIUS Gateway processes the accounting requests to track information about customer usage. For example, RADIUS Gateway tracks when customers log in to a network for using the services and when customers log out of the network. The information tracked by RADIUS Gateway is used for statistical purposes, network monitoring, and billing the customers based on the duration of the sessions or the type of services used.
To track customer usage information, RADIUS Gateway uses the network mapping definitions in ECE and maps the accounting requests received from the RADIUS clients to the usage requests with the corresponding operation types configured in ECE.
See the following topics for information on the different types of accounting requests received from the RADIUS clients:
The RADIUS Gateway accounting process is as follows:
At the start of accounting or the start of a user session, the RADIUS client sends an accounting request to RADIUS Gateway. The Acct-Status-Type AVP value in the request indicates the start of accounting or start of a session for the user.
RADIUS Gateway processes the request and records the information as either an accounting-on record or an accounting-start record in ECE, based on the accounting request received.
RADIUS Gateway returns an Accounting-Response message to the RADIUS client to acknowledge the accounting-start or accounting-on request.
While the session is active, the RADIUS client sends periodic updates on the data usage to RADIUS Gateway through accounting requests with the Acct-Status-Type AVP set to Interim-Update.
RADIUS Gateway processes the requests and records the information as accounting-interim-update records in ECE.
RADIUS Gateway returns Accounting-Response messages to the RADIUS client to acknowledge the interim-update requests.
At the end of accounting or the end of the user session, the RADIUS client sends an accounting request that contains the Acct-Status-Type AVP value indicating the end of accounting or the end of the user session.
RADIUS Gateway processes the request and records the information as either an accounting-off record or an accounting-stop record in ECE, based on the accounting request received.
RADIUS Gateway returns an Accounting-Response message to the RADIUS client to acknowledge the accounting-off or accounting-stop request. At any time, if the RADIUS client does not receive an Accounting-Response message, it continues to send accounting requests until it receives a response.
When a client is configured to use RADIUS accounting, the RADIUS client sends an Accounting-Start request, which specifies the start of a session for delivering a service, and an Accounting-Stop request, which specifies the end of the session that was started for delivering a service, to RADIUS Gateway. The Accounting-Start request describes the type of service being delivered and the user who is using that service. The Accounting-Stop request describes the type of service that was delivered. The Accounting-Stop request might also contain statistics, such as elapsed time, input and output octets, or input and output messages. The RADIUS client uses the Acct-Status-Type AVP to specify the start of a session and to specify the end of a session.
The following AVPs must be present in an Accounting-Start or Accounting-Stop request:
Acct-Session-Id
Note:
The Accounting-Start and Accounting-Stop requests for a given session must have the same Acct-Session-Id AVP.Acct-Status-Type
NAS-IP-Address or NAS-Identifier
User-Name
The AVP that you configured to derive the product type in ECE. For more information on the avpName and vendorId parameters, see the discussion about configuring RADIUS Gateway nodes in BRM Elastic Charging Engine System Administrator's Guide.
For an Accounting-Start request, the Acct-Status-Type AVP must be set to 1. When a RADIUS client sends the Accounting-Start request, the RADIUS client indicates that the user service session has started. When RADIUS Gateway receives the Accounting-Start request, RADIUS Gateway records the information contained in the request for billing purpose and returns the Accounting-Response message to the RADIUS client.
For an Accounting-Stop request, the Acct-Status-Type AVP must be set to 2. When a RADIUS client sends the Accounting-Stop request, the RADIUS client indicates that the user service session has ended. When RADIUS Gateway receives the Accounting-Stop request, RADIUS Gateway records the information contained in the request for billing purposes and returns the Accounting-Response message to the RADIUS client.
The RADIUS client continues to send the Accounting-Start or Accounting-Stop requests until it receives the Accounting-Response message.
Sample Accounting-Start Request for Accounting
[Code: Accounting-Request(4) Identifier: 0 Length: 94 Authenticator: 0x30303030303030303030303030303030 Acct-Session-Id: 123456 Acct-Status-Type: 1 NAS-Identifier: telco.org User-Name: alias#5000 Service-Type: 1] Radius Response Packet [Code: Accounting-Response(5) Identifier: 0 Length: 20 Authenticator: 0x00000000000000000000000000000000]
Sample Accounting-Stop Request for Accounting
[Code: Accounting-Request(4) Identifier: 1 Length: 87 Authenticator: 0x30303030303030303030303030303030 Acct-Session-Id: 123456 Acct-Status-Type: 2 Acct-Input-Octets: 10 Acct-Output-Octets: 18 Acct-Session-Time: 200 NAS-Identifier: telco.org User-Name: alias#5000 Service-Type: 1] Radius Response Packet [Code: Accounting-Response(5) Identifier: 1 Length: 20 Authenticator: 0x00000000000000000000000000000000]
When a client is configured to use RADIUS accounting, the RADIUS client sends an Accounting-On request, which specifies the start of accounting, and an Accounting-Off request, which specifies the end of accounting, to RADIUS Gateway. The RADIUS client uses the Acct-Status-Type AVP to specify the start of accounting and to specify the end of accounting.
The following AVPs must be present in an Accounting-On or Accounting-Off request:
Acct-Status-Type
NAS-IP-Address or NAS-Identifier
The AVP that you configured to derive the product type in ECE. For more information on the avpName and vendorId parameters, see the discussion about configuring RADIUS Gateway nodes in BRM Elastic Charging Engine System Administrator's Guide.
For an Accounting-On request, the Acct-Status-Type AVP must be set to 7. When a RADIUS client sends the Accounting-On request, the RADIUS client indicates that it is ready for service. When RADIUS Gateway receives the Accounting-On request, RADIUS Gateway closes or terminates any open accounting session associated with that RADIUS client before the RADIUS client indicated it was ready for service.
For an Accounting-Off request, the Acct-Status-Type AVP must be set to 8. When a RADIUS client sends the Accounting-Off request, the RADIUS client indicates that it is going out of service. When RADIUS Gateway receives the Accounting-Off request, RADIUS Gateway closes or terminates all the open accounting sessions associated with that RADIUS client.
Sample Accounting-On Request for Accounting
[Code: Accounting-Request(4) Identifier: 4 Length: 68 Authenticator: 0x30303030303030303030303030303030 Acct-Session-Id: 131 Acct-Status-Type: 7 NAS-Identifier: telco.org User-Name: alias#5000 Service-Type: 1 [Code: Accounting-Response(5) Identifier: 4 Length: 20 Authenticator: 0x00000000000000000000000000000000]
Sample Accounting-Off Request for Accounting
[Code: Accounting-Request(4) Identifier: 5 Length: 68 Authenticator: 0x30303030303030303030303030303030 Acct-Session-Id: 131 Acct-Status-Type: 8 NAS-Identifier: telco.org User-Name: alias#5000 Service-Type: 1 Radius Response Packet [Code: Accounting-Response(5) Identifier: 5 Length: 20 Authenticator: 0x00000000000000000000000000000000]
During a session, the RADIUS client periodically sends Accounting-Interim-Update requests, which specify the current session duration and current data usage, to RADIUS Gateway. The RADIUS client uses the Acct-Status-Type AVP to specify the interim update.
The following AVPs must be present in an Accounting-Interim-Update request:
Acct-Session-Id
Note:
The Accounting-Interim-Update requests for a given session must have the same Acct-Session-Id AVP.Acct-Status-Type
NAS-IP-Address or NAS-Identifier
User-Name
The AVP that you configured to derive the product type in ECE. For more information on the avpName and vendorId parameters, see the discussion about configuring RADIUS Gateway nodes in BRM Elastic Charging Engine System Administrator's Guide.
When periodic Accounting-Interim-Update requests are sent for the same active session, the identifier in each Accounting-Interim-Update request must be unique. If the identifier is the same, RADIUS Gateway considers only the first request received with that identifier and ignores other requests.
For an Accounting-Interim-Update request, the Acct-Status-Type AVP must be set to 3. When a RADIUS client sends the Accounting-Interim-Update request, the RADIUS client indicates that the session is active. When RADIUS Gateway receives the Accounting-Interim-Update request, RADIUS Gateway records the information contained in the request for billing purposes and returns the Accounting-Response message to the RADIUS client.
The RADIUS client continues to send Accounting-Interim-Update requests until it receives the Accounting-Response message.
Sample Accounting-Interim-Update Request for Accounting
[Code: Accounting-Request(4) Identifier: 0 Length: 95 Authenticator: 0x30303030303030303030303030303030 Acct-Session-Id: 123456 Acct-Status-Type: 3 Acct-Input-Octets: 6 Acct-Output-Octets: 10 NAS-Identifier: telco.org User-Name: alias#5000 Service-Type: 1] Radius Response Packet [Code: Accounting-Response(5) Identifier: 0 Length: 20 Authenticator:0x00000000000000000000000000000000]