Configuring the simauth.aut File

The SIM authentication module handles EAP-SIM authentication for clients using SIM cards and EAP-AKA authentication for clients using USIM cards. The settings for EAP-SIM and EAP-AKA authentication are stored in the simauth.aut file in the Steel-Belted Radius Carrier installation directory.

Note: Authenticating subscribers requires communication with the HLR. To establish connection with the HLR, follow the directions for installing and configuring the SIGTRAN protocol stack and configuring the authGateway and GWrelay applications described in the SBR Carrier Installation Guide.

simauth.aut [Bootstrap] Section

The [Bootstrap] section (Table 188) of the simauth.aut file specifies information that Steel-Belted Radius Carrier uses to load and start the SIMauth module.

simauth.aut [Settings] Section

The [Settings] section (Table 189) of the simauth.aut file contains these settings:

Note: For an overview of EAP-SIM and EAP-AKA pseudonyms and reauthentication identities, see the information about the SIM Authentication Module in the SBR Carrier Administration and Configuration Guide. SBRC always tries protocols in a fixed order (EAP-SIM, EAP-AKA), skipping any protocols that are not enabled. It is possible for the NAS client to select whether a particular protocol is preferred. If the NAS client prefers to use a particular protocol, then SBRC accepts the protocol in its fixed order list. If the preferred protocol does not work for some reason (for example, the protocol is disabled), then SBRC continues with the next protocol in its fixed order list. This is a known limitation in the NAS client that it prefers a particular protocol but sends a NAK when SBRC accepts it. For example, it is not possible for SBRC to try EAP-SIM after a NAS client prefers EAP-AKA, but it is possible for SBRC to try EAP-AKA after the NAS client uses EAP-SIM.

simauth.aut [ProfileMap] Section

Your HLR includes a database of subscribers. The database maps subscribers to one or more classes of service to which they are subscribed. You can configure the MAP Gateway to return strings that indicate a subscriber’s service authorization. The service authorization strings returned by the MAP Gateway correspond to selected TS, BS, or ODB settings in the subscriber’s profile on the HLR. For information about defining service authorization strings, see the Authorization Options section of the authGateway.conf file in the SBR Carrier Installation Guide.

Alternatively, you can configure Steel-Belted Radius Carrier to request service authorization strings from an external SQL or LDAP database instead of from an HLR. For information about requesting authorization information from an SQL database, see SQL Database Data Retrieval Methods. For information about requesting authorization information from an LDAP directory, see the [Response] Section of the ldapaccessor.gen file.

You can create two types of Steel-Belted Radius Carrier entities that are used for specifying authorization policies:

• Profiles
• Native user

You can use Steel-Belted Radius Carrier profiles or native users to define classes of subscribers who are authorized for service. Refer to the SBR Carrier Administration and Configuration Guide for information about creating profiles and native users.

Note: If you configure native users for use with EAP-SIM or EAP-AKA authentication, then you must modify ProfileIsUser in simauth.aut.

You can use the [ProfileMap] section of the simauth.aut file to assign one or more service authorization strings to these Steel-Belted Radius Carrier profiles (or native users). By doing so, each time that a subscriber requests an account, the service that is specified by the HLR is checked against the strings that you assign to a profile or native user in the [ProfileMap] section of the simauth.aut:

• If the set of service authorization strings do not match those of any profile or native user who you list, the provisioning request is denied.
• The profile map entries are checked in order. When the set of service strings match those of a profile or native user who you list, the subscriber is assigned that Steel-Belted Radius Carrier profile or native user.
• Although the authorization string values must match those in authGateway.conf, you can include authorization strings that are valid for multiple HLRs in a given line corresponding to a profile or native user in the [ProfileMap] section of simauth.aut.

You can use each line in the [ProfileMap] section of simauth.aut to provide a set of HLR authorization strings (from authGateway.conf) that specify an authorization policy defined by a Steel-Belted Radius Carrier profile or native user.

The format for each line is:

where ProfileName1 is the name of a Steel-Belted Radius Carrier profile or native user, and auth1, auth2, and auth3 are the HLR authorization strings configured in the MAP Gateway authGateway.conf file. The sequence and capitalization of the authorization strings are ignored. You can specify up to 128 authorization strings.

To use a particular profile or native user to define an authorization policy, make sure all the listed authorization strings exactly match the authorization strings returned from the MAP Gateway. You can also use a wildcard * to match any otherwise unmatched strings. For example, you can have the following:

This matches any set of authorization strings as long as they include auth1 and auth2.

You can specify combinations of authorization strings for which authorization is denied by entering one or more DENY lines. A DENY line is of the form:

where the profile name is not specified and where auth1, auth2, and auth3 are the HLR authorization strings configured in the MAP Gateway authGateway.conf file. The same matching and wildcard rules apply as with PROFILE lines. For example, the following statement denies authorization if the authorization strings returned are auth1, auth2, and auth3.

The following statement denies authorization if the authorization strings returned include both auth1 and auth2 and any other strings.

Similarly, the following statements deny authorization if the authorization strings returned include auth1 or auth2.

Finally, the following statement denies authorization if no authorization strings are returned:

We recommend you place DENY statements at the top of the list because a subscriber is assigned the policy associated with the first match in the list of profiles (or native users) that you include in the profile map. Place PROFILE statements with specific criteria in the middle of the list and PROFILE statements with wildcards at the bottom of the list.

Note: If the set of service authorization strings do not match those of any profile or native user who you list, the provisioning request is denied. All settings are reloaded every time when SBRC receives a SIGHUP (1) signal.