Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

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 Signalware SIGTRAN protocol stack and configuring the authGateway and GWrelay applications described in the SBR Carrier Installation Guide.

simauth.aut [Bootstrap] Section

simauth.aut [Bootstrap] Section

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

Table 182: simauth.aut [Bootstrap] Fields

Field

Description

LibraryName

Specifies the name of the binary that implements the SIM authentication method.

Default value is simauth.so.

Enable

If set to 1, the simauth authentication method is enabled.

If set to 0, the simauth authentication method is disabled.

Default value is 0.

InitializationString

Specifies the name of a server cookie used by the simauth authentication method. The value must be set to simauth.

simauth.aut [Settings] Section

simauth.aut [Settings] Section

The [Settings] section (Table 183) 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.

Table 183: simauth.aut [Settings] Fields

Field

Description

ConfigLog

Specifies where simauth configuration information is logged. Options are:

  • None= Configuration information is not captured.

  • ConsoleAndLog= Log information is sent to both the console and the log.

  • Console= Log information is sent to the console only.

  • Log= Log information is sent to the log file only.

    Default is ConsoleAndLog.

EnableEAPSIM

If set to 1, EAP-SIM authentication with GSM SIM cards is enabled.

If set to 0, EAP-SIM authentication is disabled.

Default value is 1 (enabled).

This parameter is reloaded every time that SBRC receives a SIGHUP (1) signal.

EnableEAPAKA

If set to 1, EAP-AKA authentication with 3G USIM cards is enabled.

If set to 0, EAP-AKA authentication is disabled.

Default value is 1 (enabled).

This parameter is reloaded every time that SBRC receives a SIGHUP (1) signal.

EnforceEAPHint

If set to 1, and the leading digit of the IMSI is 0 or 1, the server determines the type of authentication (0 for EAP-AKA, 1 for EAP-SIM) and will be enforced.

If set to 0, the type of authentication is determined through negotiation with the client.

Default value is 0.

NumberOfTriplets

 

The number of triplets required for each authentication. The allowable values are 2 or 3. The higher the number of triplets, the more keying material is available and, consequently, the more the authentication is resistant to attacks.

The default value is 3.

This parameter is reloaded every time that SBRC receives a SIGHUP (1) signal.

ReauthenticationRealm

The realm returned with a Reauthentication Identity that indicates where the return responses to reauthentication requests are directed.

The default uses the realm from the Permanent Identity (if any exists) of the client.

This parameter is reloaded every time that SBRC receives a SIGHUP (1) signal.

ReauthenticationCount

Limit

The number of allowed reauthentications before requesting fresh triplets and performing a complete authentication. The range is 0–65535.

The default is 65535.

If you enter 0, Reauthentication Identities are not generated.

This parameter is reloaded every time that SBRC receives a SIGHUP (1) signal.

ReauthenticationLifetimeSec

The duration (in seconds) of an identity that is generated by Steel-Belted Radius Carrier for the purpose of reauthentication.

The default is 3600 (1 hour). The client must reauthenticate within this time or use a Pseudonym or Permanent Identity.

Set to 0 to prevent reauthentication identities from being generated.

This parameter is reloaded every time that SBRC receives a SIGHUP (1) signal.

ProfileIsUser

Specifies whether the authorization policy specifiers listed in the [ProfileMap] section of simauth.aut represent Steel-Belted Radius Carrier native users or profiles.

  • If set to 0 (default) the profiles listed in the ProfileMap section represent profiles configured in SBR Carrier.

  • If set to 1 the profiles in the ProfileMap section represent users.

This parameter is reloaded every time that SBRC receives a SIGHUP (1) signal.

PseudonymSecret

A secret used to encrypt Pseudonyms.

You can use any text string up to 32 characters. There is no default. If you do not specify a secret, pseudonyms are not generated.

When you change this value, all pseudonyms assigned to currently authenticated clients are invalidated, requiring reauthentication.

Note: If running the SIM authentication option in an SBR Carrier cluster, all pseudonym passwords should be the same throughout the cluster.

This parameter is reloaded every time that SBRC receives a SIGHUP (1) signal.

PseudonymLifetimeDays

The lifetime of a Pseudonym in days.

The default is 1 (day).

The actual lifetime varies from the specified time, to twice the specified time.

This parameter is reloaded every time that SBRC receives a SIGHUP (1) signal.

UseEAPResponseIdentity

Set to 1 when the EAP-Response/Identity message is not altered by a proxy RADIUS server. If you set this to 1 and such changes do take place, then authentication fails.

Set to 0 when the client EAP Identity is modified by a proxy RADIUS server.

The default is 0.

EnableFailover

Specifies whether to enable or disable RADIUS failover. The RADIUS failover occurs when the HLR is inaccessible. The authentication requests are silently discarded until the HLR becomes available.

  • If set to 1, enables RADIUS failover.

  • If set to 0, disables RADIUS failover.

Default value is 0.

This parameter is reloaded every time when SBR Carrier receives a SIGHUP (1) signal.

FailoverTimeoutSec

If failover is enabled, the HLR is presumed to be accessible after the specified number of seconds, and the next request is not silently discarded.

Default is 60 seconds.

Setting this value to 0 causes EAP-SIM/EAP-AKA authentication requests to be discarded if the HLR is down.

ChargeableUserIdIn

Response

Specifies which identifier is used as the CUID and returned in the Chargeable-User-Id (CUID) attribute in the RADIUS Access-Accept message.

This field can be set to:

  • None (default)

  • IMSI—The attribute format is 01:imsi, where imsi is the subscriber’s IMSI.

  • NAI—The attribute format is 02:nai, where nai is the subscriber’s NAI.

  • MSISDN—The attribute format is 03:msisdn, where msisdn is the subscriber’s MSISDN.

You can specify more than one CUID identifier. The identifiers must be comma separated. The identifier returned by the NAS is used as the CUID. This identifier is usually the first identifier in the list.

In the following example, the CUID in the CDR is the IMSI.

ChargeableUserIdInResponse=IMSI,NAI

The IMSI and NAI values returned in the Access-Accept are derived from the User-Name attribute in the initial Access-Request. The MSISDN value returned in the Access-Accept is derived from the target module specified in the gsmmap.gen file. See Configuring Each Realm Section and Target Module Section.

This parameter is reloaded every time that SBRC receives a SIGHUP (1) signal.

ChargeableUserId

Attribute

Specifies the attribute that contains the CUID in the Access-Accept.

This field can be set to either of these settings:

  • Chargeable-User-Identity—The CUID is returned in the Chargeable-User-Identity attribute. This setting complies with RFC 4372 available at http://www.ietf.org.

  • TeliaSonera-Chargeable-UserId—The CUID is returned in the TeliaSonera-Chargeable-UserId attribute. This setting complies with GSM Association document IR6.1 available at http://www.gsmworld.com.

    Note: The following call detail record (CDR) fields carry CUID information. See CDR Fields for a list of all CDR types.

  • Charging ID

  • Domain Index

  • Charging Identifier

This parameter is reloaded every time that SBRC receives a SIGHUP (1) signal.

SendCUIDOnlyIf

Received

Used only if ChargeableUserIdAttribute is set to Chargeable-User-Identity.

This field may be set to:

  • 0—The CUID attribute is attached to the Access-Accept regardless of whether the CUID attribute was received in the Access-Request.

  • 1—The CUID attribute is attached to the Access-Accept only if the CUID was received in the Access-Request.

This parameter is reloaded every time that SBRC receives a SIGHUP (1) signal.

simauth.aut [ProfileMap] Section

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.