Steel-Belted Radius Carrier 7.2.x Reference Guide > Configuring EAP-SIM and EAP-AKA for the SIM Authentication Module > Configuring the simauth.aut File

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 SS7 and SIGTRAN protocol stacks and configuring the authGateway application described in the Steel-Belted Radius Carrier 7.2 Installation Guide.

simauth.aut [Bootstrap] Section

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

[Bootstrap]

LibraryName=simauth.so

Enable=1

InitializationString=EAP/SIM

Table 147: simauth.aut [Bootstrap] Fields 

Field	Description
LibraryName	Specifies the name of the SIMauth module. Default value is simauth.so. Do not change this unless you are advised to do so by Juniper Networks Technical Support.
Enable	If set to 1 (default), the SIMauth module is enabled. If set to 0, the SIMauth module is disabled. Default value is 1.
InitializationString	This entry is used to specify the name of the simauth authentication method. Default value is SIMAUTH.

simauth.aut [Settings] Section

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

[Settings]

ConfigLog=ConsoleAndLog

EnableSIM=1

EnableAKA=1

NumberOfTriplets=3

ReauthenticationRealm=

ReauthenticationCountLimit=65535

ReauthenticationLifetimeSec=3600

PseudonymSecret=

PseudonymLifetimeDays=1

UseEAPResponseIdentity=0

EnableFailover=yes

FailoverTimeoutSec=60

ChargeableUserIdInResponse=IMSI

ChargeableUserIdAttribute=Chargeable-User-Identity

SendCUIDOnlyIfReceived=0

ProfileisUser=0

NOTE: For an overview of EAP-SIM and EAP-AKA pseudonyms and reauthentication identities, see EAP-SIM/EAP-AKA Identities in Chapter 25, SIM Authentication Module of the Steel-Belted Radius Carrier 7.2 Administration and Configuration Guide.

Table 148: 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.
EnableSIM	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).
EnableAKA	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).
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.
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.
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.
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.
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.
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.
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.
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	Set to 1 to enable RADIUS failover by silent discard. Failover occurs when the HLR is inaccessible; further requests are silently discarded until the HLR becomes available.
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. If you set this value to 0, HLR availability is not presumed and EAP-SIM/EAP-AKA authentication requests are discarded until the HLR responds.
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.
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
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-Accept.

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 Steel-Belted Radius Carrier 7.2 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 Steel-Belted Radius Carrier 7.2 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:

ProfileName1=auth1:auth2:auth3

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:

ProfileName1=auth1:auth2:*

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:

<DENY>=auth1:auth2:auth3

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.

<DENY>=auth1:auth2:auth3

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

<DENY>=auth1:auth2:*

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

<DENY>=auth1:*

<DENY>=auth2:*

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

<DENY>=

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.