4 Generic Bootstrapping Architecture

33.2203GPPGeneric Authentication Architecture (GAA)Generic Bootstrapping Architecture (GBA)TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

The 3GPP authentication infrastructure, including the 3GPP Authentication Centre (AuC), the USIM or the ISIM, and the 3GPP AKA protocol run between them, is a very valuable asset of 3GPP operators. It has been recognised that this infrastructure could be leveraged to enable application functions in the network and on the user side to establish shared keys. Therefore, 3GPP can provide the "bootstrapping of application security" to authenticate the subscriber by defining a Generic Bootstrapping Architecture (GBA) based on AKA protocol.

4.1 Reference model

For HLR and HSS definitions used in this chapter refer to [34].

When HSS is mentioned in this specification without an indication of supported reference point towards the BSF, then the support of the Zh reference point is meant.

Figure 4.1 shows a simple network model of the entities involved in the bootstrapping approach when an HSS with Zh reference point is deployed, and the reference points used between them.

Figure 4.1: Simple network model for bootstrapping involving HSS with Zh reference point

Figure 4.1a shows a simple network model of the entities involved when the network application function is located in the visited network.

NOTE: The Zn’ reference point is distinguished from the Zn reference point in that it is used between operators.

Figure 4.1a: Simple network model for bootstrapping in visited network involving HSS with Zh reference point

Figure 4.1b shows a simple network model of the entities involved in the bootstrapping approach when either an HLR or an HSS without Zh reference point support is deployed, and the reference points used between them. The reference point Zh’ is optional for the BSF to support.

Figure 4.1b: Simple network model for bootstrapping involving either an HLR or an HSS without Zh reference point support

4.2 Network elements

4.2.1 Bootstrapping server function (BSF)

A generic Bootstrapping Server Function (BSF) and the UE shall mutually authenticate using the AKA protocol, and agree on session keys that are afterwards applied between UE and a Network Application Function (NAF). The BSF shall restrict the applicability of the key material to a specific NAF by using the key derivation procedure as specified in Annex B. The key derivation procedure may be used with multiple NAFs during the lifetime of the key material. The lifetime of the key material is set according to the local policy of the BSF. The generation of key material is specified in clause 4.5.2.

The BSF shall be able to acquire the GBA user security settings (GUSS) from the HSS.

The BSF shall be able to keep a list, which assigns NAFs to NAF Groups. This list is used to select if any and which application-specific USS within GUSS is valid for a certain NAF.

NOTE 1: The operator does the assignment of NAFs to NAF Groups. NAF Group definitions in HSS and all connected BSFs belonging to the same operator’s network shall be equal (cf., clause 4.2.3). As these network elements belong to the same operator’s network, standardisation of the NAF Group definitions themselves is not necessary in 3GPP.

NOTE 2: The NAF grouping may be e.g. "home" and "visited". It allows the BSF to send USSs for the same application with e.g. different authorization flags to different NAFs, e.g., in home network and visited networks. The NAF e.g. in visited network indicates only the requested application, but it is unaware of the grouping in home network of the subscriber.

NOTE 3: If support of GBA User Security Settings (GUSS) for service differentiation or GBA_U is desired in combination with HLR or HSS without Zh reference point support, then this can be achieved, for instance by storing the GUSS information in a BSF database (external and/or external to the node itself), or in any other network database which is deemed as appropriate for a specific deployment. GUSS information is not sent over Zh’ reference point.

If an HLR or an HSS without Zh reference point support is used within the GBA architecture, then the BSF needs to be configured to use the Zh’ reference point with that HLR or HSS. If the Zh reference point is available in the HSS and the full migration has happened, then it shall be used between the BSF and the HSS.

NOTE 4: If an operator wants to upgrade from a GBA architecture using HLR or HSS without Zh reference point support, to one using HSS with Zh reference point support, then the BSF needs to be configured accordingly to use then the Zh reference point. This can also involve a configuration, where gradual replacement is needed. If GBA is deployed from the beginning with an HSS with Zh reference point support then this kind of configuration is not needed.

NOTE 5: During migration from HLR to HSS, the BSF will need to select for a subscriber between HSS and HLR’s. Such a mechanism (e.g. configuration based) will not be standardized.

4.2.2 Network application function (NAF)

After the bootstrapping has been completed, the UE and a NAF can run some application specific protocol where the authentication of messages will be based on those session keys generated during the mutual authentication between UE and BSF.

General assumptions for the functionality of a NAF are:

– there is no previous security association between the UE and the NAF;

– NAF shall be able to locate and communicate securely with the subscriber’s BSF;

– NAF shall be able to acquire a shared key material established between UE and the BSF during the run of the application-specific protocol;

– NAF shall be able to acquire zero or more application-specific USSs from the HSS via the BSF;

– NAF shall be able to set the local validity condition of the shared key material according to the local policy;

– in the case of GBA_U, the NAF shall be able to determine which key (i.e., Ks_ext_NAF or Ks_int_NAF or both) should be used by using a local policy in the NAF or a key selection indication in the application-specific USS. If the NAF has received an application-specific USS, which contains the key selection indication, this shall override the local policy in the NAF;

– NAF shall be able to check lifetime and local validity condition of the shared key material.

NOTE: Without additional measures, GBA does not guarantee the freshness of the key, Ks(_int/ext)_NAF in the sense that it does not guarantee that the key was not used in a previous run of the Ua protocol. The additional measures which may be taken by the UE and the NAF to ensure key freshness in GBA are:

1) enforce a new run of the Ub protocol (thus generating a new Ks) before deriving a new Ks_NAF.

2) store previously used keys Ks(_int/ext)_NAF, or the corresponding key identifiers B-TID, until the end of their lifetime.

A UE and a NAF that support a Ua protocol that does not provide replay protection over unconnected runs of the protocol, will need to take corresponding action to avoid replay attacks if desired.

4.2.2a Zn-Proxy

In the case where UE has contacted a NAF that is operated in another network than home network, this visited NAF shall use a Zn-Proxy of the NAFs network to communicate with subscriber’s BSF (i.e. home BSF).

NOTE: Zn-Proxy functionality may be implemented as a separate network element, or be part of any NE in the visited network that implements Diameter/HTTP proxy functionality (examples of such NE’s are the BSF of the network that the visited NAF belongs to, or an AAA-server, or an HTTP server).

General requirements for the functionality of Zn-Proxy are:

– Zn-Proxy shall be able to function as a proxy between the visited NAF, and the subscriber’s home BSF;

– Zn-Proxy shall be able to locate subscriber’s home BSF and communicate with it over secure channel;

– Zn-Proxy shall be able to validate that the visited NAF is authorized to participate in GBA and shall be able to assert to subscriber’s home BSF the visited NAFs DNS name. The Zn-Proxy shall also be able to assert to the BSF that the visited NAF is authorized to request the GBA specific user profiles contained in the NAF request;

– the physical security level of the Zn-proxy shall not be lower than the highest level of the NAFs which it interfaces with.

4.2.3 HSS

The set of all user security settings (USSs), i.e. GUSS, is stored in the HSS. In the case where the subscriber has multiple subscriptions, i.e. multiple ISIM or USIM applications on the UICC, the HSS may contain one or more GUSSs that can be mapped to one or more private identities, i.e. IMPIs and IMSIs. Each of the existing GUSSs shall be mapped to one or more private identities, but each private identity shall only have zero or one GUSS mapped to it.

The requirements on the HSS are:

– HSS shall provide the only persistent storage for GUSSs;

– GUSS shall be defined in such a way that interworking of different operators for standardised application profiles is possible;

– GUSS shall be defined in such a way that profiles for operator specific applications and extensions to existing application profiles are supported without need for standardisation of these elements.

– GUSS shall be able to contain application-specific USSs that contain parameters that are related to key selection indication in the case of GBA_U (i.e., whether the NAF shall use Ks_ext_NAF or Ks_int_NAF), identification or authorization information of one or more applications hosted by one ore more NAFs. Any other types of parameters are not allowed in the application-specific USS.

NOTE 1: The necessary subscriber profile data may be fetched by the NAF from its local database without involvement with the HSS.

NOTE 2: One possibility to revoke temporarily an application specific USS from the GUSS is that the HSS may temporarily remove an application-specific USS from the GUSS if the service is temporarily revoked from the subscriber. The GUSS in the BSF is not changed by this operation and only updated when the existing bootstrapping session times out, or is overwritten by a new bootstrapping session during which the new modified GUSS is fetched from HSS along with the AV.

– GUSS shall be able to contain parameters intended for the BSF usage:

– the type of the UICC the subscriber is issued (i.e. is it GBA_U aware or not, cf. subclause 5);

– subscriber specific key lifetime:

– optionally the timestamp indicating the time when the GUSS has been last modified by the HSS.

NOTE 3: These parameters are optional and if they are missing from subscriber’s GUSS or subscriber does not have GUSS then the BSF will use the default values in the BSF local policy defined by the particular MNO.

– HSS shall be able to assign application-specific USSs to a NAF Group. This shall be defined in such a way that different USSs for the same application, but for different groups of NAFs, are possible. The restrictions on the number of USSs per GUSS are dependent on the usage of NAF Groups by the operator:

– if no NAF Groups are defined for this application then at most one USS per application is stored in GUSS;

– if NAF Groups are defined for this application then at most one USS per application and NAF Group is stored in GUSS.

– NAF Group definitions in the HSS and all connected BSFs belonging to the same operator’s network shall be equal.

4.2.4 UE

The required functionalities from the UE are:

– the support of HTTP Digest AKA protocol;

– the capability to use both a USIM and an ISIM in bootstrapping;

– the capability to select either a USIM or an ISIM to be used in bootstrapping, when both of them are present;

– the capability for a Ua application on the ME to indicate to the GBA Function on the ME the type or the name of UICC application to use in bootstrapping (see clause 4.4.8);

– the capability to derive new key material to be used with the protocol over Ua interface from CK and IK;

– support of NAF-specific application protocol (For an example see TS 33.221 [5]).

A GBA-aware ME shall support both GBA_U, as specified in clause 5.2.1 and GBA_ME procedures, as specified in clause 4.5.

4.2.5 SLF

The SLF:

– is queried by the BSF in conjunction with the Zh interface operation to get the name of the HSS containing the required subscriber specific data.

– is accessed via the Dz interface by the BSF.

The SLF is not required in a single HSS environment. Use of SLF is not required when BSF are configured/managed to use pre-defined HSS.

4.2.6 HLR

If a HLR is used, then the requirement on the HLR is:

– The HLR shall support the request from the BSF for the required authentication vector.

4.3 Bootstrapping architecture and reference points

4.3.1 Reference point Ub

The reference point Ub is between the UE and the BSF. Reference point Ub provides mutual authentication between the UE and the BSF. It allows the UE to bootstrap the session keys based on 3GPP AKA infrastructure.

The HTTP Digest AKA protocol, which is specified in RFC 3310 [4], is used on the reference point Ub. It is based on the 3GPP AKA TS 33.102 [2] protocol. The interface to the USIM is as specified in TS 31.102 [1] and to the ISIM is as specified in TS 31.103 [10].

4.3.2 Reference point Ua

The reference point Ua carries the application protocol, which is secured using the keys material agreed between UE and BSF as a result of the run of HTTP Digest AKA over reference point Ub. For instance, in the case of support for subscriber certificates TS 33.221 [5], it is a protocol, which allows the user to request certificates from the NAF. In this case the NAF would be the PKI portal.

4.3.3 Reference point Zh

The reference point Zh used between the BSF and the HSS allows the BSF to fetch the required authentication information and all GBA user security settings from the HSS. The reference point Zh is an intra-operator domain interface. The interface to the 3G Authentication Centre is HSS-internal, and it need not be standardised as part of this architecture.

4.3.4 Reference point Zn

The reference point Zn is used by the NAF to fetch the key material agreed during a previous HTTP Digest AKA protocol run over the reference point Ub from the UE to the BSF. It is also used to fetch application-specific user security settings from the BSF, if requested by the NAF.

4.3.5 Reference point Dz

The reference point Dz used between the BSF and the SLF allows the BSF to get the name of the HSS containing the required subscriber specific data.

4.3.6 Reference point Zh’

The reference point Zh’ used between the BSF and the HLR allows the BSF to fetch the required authentication information. The reference point Zh’ is an intra-operator domain interface.

4.4 Requirements and principles for bootstrapping

The following requirements and principles are applicable to bootstrapping procedure:

– the bootstrapping function shall not depend on the particular NAF;

– the server implementing the bootstrapping function needs to be trusted by the home operator to handle authentication vectors;

– the server implementing the NAF needs only to be trusted by the home operator to handle derived key material;

– it shall be possible to support NAF in the operator’s home network and in the visited network;

– the architecture shall not preclude the support of network application function in a third network;

– to the extent possible, existing protocols and infrastructure should be reused;

– in order to ensure wide applicability, all involved protocols are preferred to run over IP;

– it shall be prevented that a security breach in one NAF who is using the GBA, can be used by an attacker to mount successful attacks to the other NAFs using the GBA.

– an attacker shall not be able to exploit a security breach in one security protocol over Ua in order to mount a successful attack against a different security protocol over Ua.

4.4.1 Access Independence

Bootstrapping procedure is access independent. Bootstrapping procedure requires IP connectivity from UE.

4.4.2 Authentication methods

Authentication between the UE and the BSF shall not be possible without a valid cellular subscription. Authentication shall be based on the 3GPP AKA protocol.

4.4.3 Roaming

The requirements on roaming are:

– The roaming subscriber shall be able to utilize the bootstrapping function in the home network. The subscriber shall be able to utilize network application function that is in a visited network.

– The home network shall be able to control whether its subscriber is authorized to use the service in the visited network.

4.4.4 Requirements on reference point Ub

The requirements for reference point Ub are:

– the BSF shall be able to identify the UE;

– the BSF and the UE shall be able to authenticate each other based on AKA;

– the BSF shall be able to send a bootstrapping transaction identifier to the UE;

– the UE and the BSF shall establish shared keys;

– the BSF shall be able to indicate to the UE the lifetime of the key material. The key lifetime sent by the BSF over Ub shall indicate the expiry time of the key.

NOTE 1: This does not preclude a UE to refresh the key before the expiry time according to the UE’s local policy.

– the BSF and the UE shall protect the permanent user identity IMPI against passive eavesdropping attacks by using a temporary identity. The support of the temporary identity by UE or BSF shall not preclude a successful bootstrapping procedure if the other entity conforms to an earlier release of this specification and does not support the use of a temporary identity.

NOTE 2: User identity privacy can be achieved only when both, UE and BSF, support the use of a temporary identity.

NOTE 3: The use of a temporary identity is not required for 2G GBA (cf. Annex I) as the IMPI is already protected by the mandatory TLS tunnel.

4.4.5 Requirements on reference point Zh

The requirements for reference point Zh are:

– mutual authentication, confidentiality and integrity shall be provided;

NOTE 1: This requirement may be fulfilled by physical or proprietary security measures since BSF and HSS are located within the same operator’s network.

– the BSF shall be able to send bootstrapping information request concerning a subscriber;

– optionally the BSF may have the capability able to send the timestamp of subscriber’s GBA user security settings to the HSS (timestamp option);

– the HSS shall be able to send one 3GPP AKA vector at a time to the BSF;

– the HSS shall be able to send the complete set of subscriber’s GBA user security settings needed for security purposes to the BSF. Optionally the HSS may have the capability to indicate to the BSF whether the BSF already has the latest copy of the GUSS based on the GUSS timestamp (timestamp option);

NOTE 2: If subscriber’s GUSS is updated in HSS, this is not propagated to the BSF. The GUSS in the BSF is updated when the BSF next time fetches the authentication vectors and GUSS from the HSS over Zh reference point as part of the bootstrapping procedure.

– no state information concerning bootstrapping shall be required in the HSS;

– all procedures over reference point Zh shall be initiated by the BSF;

– the number of different interfaces to HSS should be minimized.

4.4.6 Requirements on reference point Zn

The requirements for reference point Zn are:

– mutual authentication, confidentiality and integrity shall be provided;

– If the BSF and the NAF are located within the same operator’s network, the DIAMETER based Zn reference point shall be secured according to NDS/IP [13] or may be secured using TLS as specified in Annex E of the present document;

– If the BSF and the NAF are located in different operators’ networks, the DIAMETER based Zn’ reference point between the Zn-Proxy and the BSF shall be secured using TLS as specified in Annex E of the present document;

– An HTTP based Zn/Zn’ reference point shall be secured using TLS as specified in Annex E of the present document;

– The BSF shall verify that the requesting NAF is authorised to obtain the key material or the key material and the requested USS;

– The NAF shall be able to send a key material request to the BSF, containing NAF’s public hostname used by the UE’s corresponding request. The BSF shall be able to verify that a NAF is authorized to use this hostname, i.e. the FQDN used by UE when it contacts the NAF;

– The BSF shall be able to send the requested key material to the NAF;

– The NAF shall be able to get a selected set of application-specific USSs from the BSF, depending on the policy of the BSF and the application indicated in the request from the NAF over Zn;

– The NAF shall be able to indicate to the BSF the single application or several applications it requires USSs for;

NOTE 2: If some application needs only a subset of an application-specific USS, e.g. only one IMPU or MSISDN, the NAF selects this subset from the complete set of USS sent from BSF.

– The BSF shall be able to be configured on a per NAF or per application basis

– whether private subscriber identity, i.e. IMPI, may be sent to the NAF;

– whether a particular USS may be sent to a NAF;

NOTE 3: Privacy issues need be considered when determining which user identifier is sent to the NAF. If service continuity is desired, then the BSF can be configured to send the IMPI. If HLR is utilized instead of HSS, BSF can be configured to send MSISDN over Zn (but then there is no user anonymity). If the BSF does not send the IMPI, MSISDN or IMPU / pseudonym in the USS, then the user remains anonymous towards the NAF; or more precisely, the B-TID functions as a temporary user identifier. This can cause that the NAF cannot provide a continuous service, since a user identity is needed in the NAF to ensure that the NAF is able to update keys for a Ua session when the UE has bootstrapped and contacts the NAF with a new B-TID. If user privacy is desired, the NAF can requests a USS and the BSF is configured to send a user pseudonym in the USS, but not the IMPI.

– If a NAF requests USSs from the BSF and they are not present in subscriber’s GUSS, it shall not cause an error, provided the conditions of the local policy of the BSF are fulfilled. The BSF shall then send only the requested and found USSs to the NAF;

– It shall be possible to configure a local policy as follows: BSF may require one or more application-specific USS to be present in a particular subscriber’s GUSS for a particular requesting NAF, and to reject the request from the NAF in case the conditions are not fulfilled. In order to satisfy this local policy, it is not required that the NAF requests the USSs over the Zn reference point, which the BSF requires to be present in the GUSS, rather it is sufficient that the BSF checks the presence of the USSs locally. It shall also be possible to configure the BSF in such a way that no USS is required for the requesting NAF;

NOTE 4: For more information on the local policy usage, see Annex J.

– The BSF shall be able to indicate to the NAF the bootstrapping time and the lifetime of the key material. The key lifetime sent by the BSF over Zn shall indicate the expiry time of the key, and shall be identical to the key lifetime sent by the BSF to the UE over Ub.

NOTE 5: This does not preclude a NAF to refresh the key before the expiry time according to the NAF’s local policy.

NOTE 6: If one or more of the USSs that have been delivered to the NAF has been updated in subscriber’s GUSS in the HSS, this change is propagated to the NAF the next time it fetches the USS from the BSF over Zn reference point (provided that the BSF has updated subscriber’s GUSS from the HSS over Zh reference point).

– The BSF shall remove any existing attribute indicating NAF Grouping from the USSs sent to NAFs.

– NAF shall be able to indicate to BSF the protocol identifier of Ua security protocol it requires the key material by sending NAF-Id to BSF (cf. Annex H).

4.4.7 Requirements on Bootstrapping Transaction Identifier

Bootstrapping transaction identifier (B-TID) shall be used to bind the subscriber identity to the keying material in reference points Ua, Ub and Zn.

Requirements for B-TID are:

– B-TID shall be globally unique;

– B-TID shall be usable as a key identifier in protocols used in the reference point Ua;

– NAF shall be able to detect the home network and the BSF of the UE from the B-TID.

NOTE 1: NAF can remove the security association based on deletion conditions after the key has become invalid.

NOTE 2: Care has to be taken that the parallel use of GBA and non-GBA authentication between UE and NAF does not lead to conflicts, e.g. in the name space. This potential conflict cannot be resolved in a generic way as it is dependent on specific protocol and authentication mechanism used between UE and application server. It is therefore out of scope of this specification.
For the example of HTTP Digest authentication used between UE and NAF, parallel use is possible as the following applies: <username,password>-pairs must be unique to one realm only. As the NAF controls the realm names, it has to ensure that only the GBA based realm is named with the reserved 3GPP realm name. In the special case that the NAF wants to allow non GBA based authentication in the GBA realm also, it has to ensure that no usernames in the format of a B-TID are used outside GBA based authentication.

4.4.8 Requirements on selection of UICC application and related keys

When several applications are present on the UICC, which are capable of running AKA, then the ME shall choose one of these UICC applications for performing the GBA procedures specified in this document in the following order of preference:

1. The UE determines which UICC application is to be involved:

a. the application on the ME that needs Ks_NAF (Ua application) may indicate to the GBA support function (GBA function) the type or the name of the UICC application: no preference, USIM, ISIM, or the "Label" (see definition in TS 31.101 [15]) of the UICC application.

NOTE 1: A Ua application specification may require the use of only a USIM (e.g. in MBMS) or only an ISIM.

NOTE 2: A user or operator may want to use a Ua application with a specific UICC application indicated by the “Label”. This could be configured in the Ua application in the ME by the user or the operator.

A Ua application may require to use the same UICC application in the first and all consecutive runs of Ub protocol for a Ua application instance to ensure that IMPI is not changed during a Ua application session which lasts over several runs of Ub protocol. In this case the Ua application shall request the GBA function to run the Ub protocol with the UICC application that is indicated by the corresponding "Label" or IMPI, depending on which one is available. If both are available, then IMPI shall be used to indicate which UICC application is to be used by the GBA function.

If the application on the ME indicated a "Label" of the UICC application, step b below shall be executed.

If the application on the ME indicated that the UICC application type should be:

– the USIM; step b below is skipped and in steps c and d only USIM applications are considered.

– the ISIM; step b below is skipped and in steps c and d only ISIM applications are considered.

if the application on the ME did not indicate a preference, step b below is skipped and the selection process is executed as described below, starting with step c;

b. if a "Label" was indicated in step a:

At most, there can be only one USIM active at one time. Therefore, if the USIM indicated in the "Label" by the Ua application is different to the currently active USIM application, then the ME shall reject this request.

If a different ISIM to the currently active ISIM application(s) is indicated to the GBA support function by the Ua application, then the ME shall not terminate the currently active ISIM application(s) but the ME shall follow the procedure in chapter 4.4.8.1 when activating the ISIM application indicated by the "Label", as the UE is allowed to have several ISIM’s active simultaneously.

c. if no "Label" was indicated in step a and there are UICC applications active:

If a preferred UICC application type was indicated but no UICC application of this type is active then step d shall be followed.

If a preferred UICC application type was indicated and there are active UICC applications of this preferred type, then the GBA function shall choose:

– if the preferred UICC application type is USIM then the active USIM is selected

– if the preferred UICC application type is ISIM and only one ISIM is active then this is selected

– if the preferred UICC application type is ISIM and more than one ISIM is active then the GBA function may show a UICC application choosing dialogue to the end user (the list contains the "Labels" from the application list of all active ISIM applications on the UICC), from which the end user chooses the UICC application to be selected; if no dialogue is shown the GBA function shall select an active ISIM.

If no preference was given and there is more than one active UICC application, the GBA function may show a UICC application choosing dialogue to the end user (the list contains the "Labels" from the application list of all active UICC applications), from which the end user chooses the UICC application to be selected; if no dialogue is shown the GBA function shall select the active USIM application, if an active USIM application exists, otherwise any active ISIM application.

If no preference was given and there is only one active UICC application, then the GBA function selects this active UICC application;

d. if no "Label" was indicated in step a and if there are no UICC applications active active or if there is no UICC application of the preferred UICC application type active:

– if there is only one UICC application on the UICC, the GBA function selects it, if possible;

– if there is more than one UICC application on the UICC, the GBA function may show a UICC application choosing dialogue to the end user (the list contains the "Labels" from the application list of the UICC), from which the end user chooses the UICC application to be selected. If a preferred UICC application type was indicated and there are UICC applications of this type on the UICC, then the list shown contains only UICC applications of this type, otherwise the list contains all UICC applications on the UICC. If no dialogue is shown the GBA function shall select the "last selected" UICC application of the preferred type (i.e. either the "last selected" USIM or the "last selected" ISIM depending on the given preference), if possible. In case the Ua application indicated "no preference" and both USIM and ISIM are present on the UICC, then the "last selected" USIM is selected.

The procedure in clause 4.4.8.1 shall be followed.

e. if the UICC application type indicated in step a and used in step c and/or d was ISIM, but there was no ISIM to select, then step c and/or d is repeated with UICC application type USIM; otherwise the selection process fails.

NOTE 3: Step e is required for the case that an ISIM as defined in TS 33.203 [16] may be realised using a USIM application on the UICC.

2. If there already is a key Ks derived from the chosen UICC application, the UE takes this key to derive Ks_NAF.

3. If there is no such key Ks, the UE first runs the Ub protocol involving the selected UICC application and then goes to step 2.

If a USIM is chosen, the IMPI obtained from the IMSI stored on the USIM as specified in TS 23.003 [11] clause 13.3, is used in the protocol run over Ub.

NOTE 4: Strictly speaking, an IMPI, and the derivation of an IMPI from an IMSI as in TS 23.003 [11], clause 13 are only defined in the context of the IMS. For the purposes of this specification, however, an identifier obtained from an IMSI as specified in TS 23.003 [11], clause 13.3 is also called an IMPI, even if the user has no IMS subscription.

If an ISIM is selected, the IMPI stored on the ISIM is used in the protocol run over Ub.

Whenever a UICC application is successfully selected or terminated, the rules in this clause for choosing the UICC application are re-applied and, consequently, the UICC application chosen for GBA may change.

NOTE 5: At any one time, there is at most one UICC application chosen for performing the GBA procedures.

4.4.8.1 UICC application activation procedure in GBA

UICC application activation is defined in TS 31.101 [15].

NOTE: As part of the UICC application (USIM or ISIM) activation procedure, the UICC may require user verification e.g. PIN entry.

If activation of a new UICC application fails then the GBA function shall indicate this to the Ua application.

4.4.9 Requirements on reference point Ua

The generic requirements for reference point Ua are:

– the UE and the NAF shall be able to secure the reference point Ua using the GBA-based shared secret;

NOTE: The exact method of securing the reference point Ua depends on the application protocol used over reference point Ua.

– in the case of GBA_U, the UE and the NAF shall be able to agree which key (i.e, Ks_ext_NAF or Ks_int_NAF or both) is used as the GBA-based shared secret if both keys may be used;

There are two ways to have an agreement between the UE and the NAF which key shall be used Ks_(ext)_NAF or Ks_int_NAF or both:

a) In a generic case, where the protocol used over reference point Ua can be used for different applications (e.g., HTTPS), the protocol should be able to indicate which key should be used.

b) In a specific case, where the protocol is application specific (e.g., MIKEY in MBMS), the agreement can be based on implicit knowledge.

– any security protocol over Ua shall be associated with a Ua security protocol identifier. This identifier shall be specified in Annex H of this specification.

– the NAF shall be able to indicate to the UE that GBA-based shared secret should be used;

– the NAF shall be able to indicate to the UE that the current shared secret has expired and the UE should use newer shared secret with the NAF.

– The default lifetime of the NAF specific key material Ks_(ext/int)_NAF shall be equal to the lifetime of Ks when not specified within the Ua-application specification. The lifetime of the Ks_(ext/int)_NAF shall not exceed the lifetime of corresponding Ks. If a lifetime for the Ks_(ext/int)_NAF (or further adapted key material) is available in the NAF, due to a Ua application specification having its own lifetime value or due to NAF having it’s own policy for the adapted key material, then if this lifetime is different from the Ks lifetime received from the BSF, then the NAF shall always select the minimum value for the lifetime out of these two.

– The UE and NAF may adapt the key material Ks_(ext/int)_NAF to the specific needs of the reference point Ua. This adaptation is outside the scope of this specification. The default lifetime of the adapted key material shall be equal to the lifetime of Ks_(ext/int)_NAF when not specified within the Ua-application specification. The lifetime of the adapted key material shall not exceed the lifetime of corresponding Ks_(ext/int)_NAF. If a lifetime for the Ks_(ext/int)_NAF (or further adapted key material) is available in the NAF, due to a Ua application specification having its own lifetime value or due to NAF having it’s own policy for the adapted key material, then if this lifetime is different from the Ks lifetime received from the BSF, then the NAF shall always select the minimum value for the lifetime out of these two.

4.4.10 Requirements on reference point Dz

This interface between BSF and SLF is used to retrieve the address of the HSS which holds the subscription for a given user. This interface is not required in a single HSS environment.

4.4.11 Requirements on GBA keys and parameters handling

When referring to GBA keys, the following keys are intended: Ks and NAF specific keys derived from the Ks. When referring to NAF specific keys, the following keys are intended: Ks_ext/int_NAF (in GBA_U context) and Ks_NAF (in GBA_ME context), and any keys derived from these keys. The notation Ks_(ext/int)_NAF refers to Ks_ext/int_NAF in GBA_U context and Ks_NAF in GBA_ME context. The notation Ks_(ext)_NAF refers to Ks_ext_NAF in GBA_U context, and Ks_NAF in GBA_ME context.

The ME shall delete all GBA keys (i.e., Ks, and NAF specific keys) and the corresponding NAF_IDs, B-TID, Ks_(int/ext)_NAF lifetimes, Ks lifetime, and lifetime (of the keys derived from Ks_(ext)_NAF) when at least one of the conditions below is met:

1 the UICC is removed from the ME when the ME is in power on state;

2 the ME is powered up and the ME discovers that another UICC has been inserted to the ME. For this, the ME needs to store in non-volatile memory the last inserted UICC-identity to be able to compare that with the used UICC-identity at UICC insertion and power up; or

3 the ME is powered up and the ME discovers that no UICC has been inserted to the ME.

NOTE 1: One possible way, how this requirement can be fulfilled by an application in an open platform is, if the keys are deleted at shut-down and at start-up of the application. When the ME operating system detects one of the conditions above, it can shut down the application to force key deletion. The deletion at start-up ensures that keys are also deleted, when an irregular power-down or UICC removal during power down has occurred.

The ME shall delete all GBA keys related to a certain Ks (i.e., Ks itself, and NAF specific keys derived from this specific Ks) and the corresponding NAF_IDs, B-TID, Ks_(ext/int)_NAF lifetimes, Ks lifetime, and lifetime (of the keys derived from Ks_(ext)_NAF) when the key lifetime of this specific Ks expires.

In the case of GBA_ME, the key Ks shall be deleted from the ME when the ME is powered down. The NAF specific keys (i.e. Ks_(ext)_NAF and keys derived therefrom, if any) may be deleted from the ME when the ME is powered down. If the ME does not delete these NAF specific keys at power down then the NAF specific keys (i.e. Ks_(ext)_NAF and keys derived therefrom, if any) together with the NAF_IDs, B-TID, Ks_(ext)_NAF lifetime and lifetimes (of the keys derived from Ks_(ext)_NAF) shall be stored in non-volatile memory.

If the NAF specific keys are stored in non-volatile memory, then when the ME is powered up again, the ME may need to ensure that the same UICC application is selected for the Ua application, in order to allow the re-use of the NAF specific keys (i.e. Ks_(ext)_NAF and keys derived therefrom, if any), cf. clause 4.4.8. For this, the ME shall store also the IMPI in non-volatile memory. If the same UICC application can not be selected for a Ua application at UE power up, then the ME shall delete the NAF specific keys related to that IMPI stored in non-volatile memory.

Whenever a UICC application is terminated (see section 4.4.8) the shared key Ks established from it in the protocol over the Ub reference point (according to clauses 4.5.2 and 5.3.2) shall be deleted.

NOTE 2: In case the key Ks has been deleted, but the same UICC is still present (i.e. none of conditions 1, 2 or 3 is met), the Ua applications can continue using the NAF specific keys (Ks_(ext/int)_NAF) until the Ks lifetime expires.

4.4.12 Requirements on reference point Zh’

This reference point is optional for the BSF to support. The requirements for reference point Zh’ are:

– mutual authentication, confidentiality and integrity shall be provided;

NOTE 1: This requirement may be fulfilled by physical or proprietary security measures, since BSF and HLR are located within the same operator’s network.

– the BSF shall be able to send an authentication vector request concerning a subscriber;

– the HLR shall be able to send one authentication vector, as described in TS 29.109 [32] at a time to the BSF;

– no other GBA functionality than conveying authentication vectors shall be required on Zh’;

– no state information concerning bootstrapping shall be required in the HLR;

– all procedures over reference point Zh’ shall be initiated by the BSF;

– the number of different interfaces to HLR should be minimized.

NOTE 2: If support of GBA User Security Settings (GUSS) is desired in combination with HLR or HSS with Zh’ reference point support, then this can be achieved, for instance by storing the GUSS information in a BSF database (external and/or external to the node itself), or in any other network database which is deemed as appropriate for a specific deployment. GUSS information is not sent over Zh’ reference point.

4.4.13 Requirements on TMPI handling

The BSF shall store a TMPI together with the IMPI, from which it was derived (cf. Annex B.4), until the next bootstrapping procedure is executed using this TMPI.

The BSF may have a local policy for deleting stored (TMPI, IMPI)-pairs before the next bootstrapping procedure is executed using this TMPI, e.g. for storage or performance reasons.

The ME shall store a TMPI together with the IMPI, from which it was derived (cf. Annex B.4), in non-volatile memory.

The ME shall delete all stored (TMPI, IMPI)-pairs when at least one of the conditions below is met:

1. the UICC is removed from the ME when the ME is in power on state; or

2. the ME is powered up and the ME discovers that another UICC has been inserted to the ME. For this, the ME needs to store in non-volatile memory the last inserted UICC-identity to be able to compare that with the used UICC-identity at UICC insertion and power up; or

3. the ME is powered up and the ME discovers that no UICC has been inserted to the ME.

4.5 Procedures

This chapter specifies in detail the format of the bootstrapping procedure that is further utilized by various applications. It contains the AKA authentication procedure with BSF, and the key material generation procedure.

4.5.1 Initiation of bootstrapping

Before communication between the UE and the NAF can start, the UE and the NAF first have to agree whether to use the GBA. When a UE wants to interact with a NAF, but it does not know if the NAF requires the use of shared keys obtained by means of the GBA, the UE may contact the NAF for further instructions (see figure 4.2).

NOTE: The above text implies that a UE may contact either the BSF or the NAF without knowing whether the NAF supports GBA

Figure 4.2: Initiation of bootstrapping

1. The UE may start communication over reference point Ua with the NAF with or without any GBA-related parameters.

2. If the NAF requires the use of shared keys obtained by means of the GBA, but the request from UE does not include GBA-related parameters, the NAF replies with a bootstrapping initiation message. The form of this initiation message may depend on the particular reference point Ua.

4.5.2 Bootstrapping procedures

When a UE wants to interact with a NAF, and it knows that the bootstrapping procedure is needed, it shall first perform a bootstrapping authentication (see figure 4.3). Otherwise, the UE shall perform a bootstrapping authentication only when it has received bootstrapping initiation required message or a bootstrapping negotiation indication from the NAF, or when the lifetime of the key in UE has expired (cf. subclause 4.5.3).

NOTE 1: The main steps from the specifications of the AKA protocol in TS 33.102 [2] and the HTTP digest AKA protocol in RFC 3310 [4] are repeated in figure 3 for the convenience of the reader. In case of any potential conflict, the specifications in TS 33.102 [2] and RFC 3310 [4] take precedence.

Figure 4.3: The bootstrapping procedure

A UE shall always include the product token "3gpp-gba-tmpi" in the user agent request-header field when communicating over Ub. A BSF shall always include the product token "3gpp-gba-tmpi" in the server response-header field when communicating over Ub.

NOTE 1a: According to the HTTP specification RFC 7230 [63], the product tokens may contain any text. They are ignored when unknown by a UE or a BSF.

1. The UE sends an HTTP request towards the BSF. When a TMPI associated with the IMPI in use is available on the UE, the UE includes this TMPI in the "username" parameter, otherwise the UE includes the IMPI.

2. The BSF recognises from the structure of the "username" parameter (cf. Annex B.4) whether a TMPI or an IMPI was sent. If a TMPI was sent the BSF looks up the corresponding IMPI in its local database. If the BSF does not find an IMPI corresponding to the received TMPI it returns an appropriate error message to the UE. The UE then deletes the TMPI and retries the request using the IMPI.

The BSF retrieves the complete set of GBA user security settings and one Authentication Vector (AV, AV = RAND||AUTN||XRES||CK||IK) over the reference point Zh from the HSS.

In the case that no HSS with Zh reference point is deployed, the BSF retrieves the Authentication Vector over the reference point Zh’ from either an HLR or an HSS with Zh’ reference point support.

If the BSF implements the timestamp option and has a local copy of the GUSS for the subscriber that has been fetched from the HSS during a previous bootstrapping procedure, and this GUSS includes a timestamp, the BSF may include the GUSS timestamp in the request message. Upon receiving that timestamp, if the HSS implements the timestamp option, the HSS may compare it with the timestamp of the GUSS stored in the HSS. In this case, if and only if the HSS has done the comparison and the timestamps are equal, then the HSS shall send "GUSS TIMESTAMP EQUAL" indication to the BSF. In any other case, the HSS shall send the GUSS (if available) to the BSF. If the BSF receives "GUSS TIMESTAMP EQUAL" indication, it shall keep the local copy of the GUSS. In any other case, the BSF shall delete the local copy of the GUSS, and store the received GUSS (if sent).

NOTE 2: In a multiple HSS environment, the BSF may have to obtain the address of the HSS where the subscription of the user is stored by querying the SLF, prior to step 2.

3. Then BSF forwards the RAND and AUTN to the UE in the 401 message (without the CK, IK and XRES). This is to demand the UE to authenticate itself.

4. The UE checks AUTN to verify that the challenge is from an authorised network; the UE also calculates CK, IK and RES. This will result in session keys IK and CK in both BSF and UE.

5. The UE sends another HTTP request, containing the Digest AKA response (calculated using RES), to the BSF.

6. The BSF authenticates the UE by verifying the Digest AKA response.

NOTE 3: The password in "AKAv1" HTTP Digest AKA is in binary format.

7. The BSF generates key material Ks by concatenating CK and IK. The B-TID value shall be also generated in format of NAI by taking the base64 encoded (cf. RFC 4648 [60]) RAND value from step 3, and the BSF server name, i.e. base64encode(RAND)@BSF_servers_domain_name.

NOTE 3a: If the HSS/AuC uses a good random number generator, then the chance of a B-TID collision is practically zero. If such a collision occurs, then the key retrieved by the NAF can have a mismatch with the UE generated NAF key. This will result in a Ua authentication failure which will cause the NAF to once again request the UE to bootstrap which will create a new Ks and a new B-TID.

If the request included the product token "3gpp-gba-tmpi" in the user agent request-header field the BSF shall compute a new TMPI as specified in Annex B.4 and store it together with the IMPI, overwriting a previous TMPI related to this IMPI, if any.

8. The BSF shall send a 200 OK message, including a B-TID, to the UE to indicate the success of the authentication. In addition, in the 200 OK message, the BSF shall supply the lifetime of the key Ks. The key material Ks is generated in UE by concatenating CK and IK.

9. Both the UE and the BSF shall use the Ks to derive the key material Ks_NAF during the procedures as specified in clause 4.5.3. Ks_NAF shall be used for securing the reference point Ua.

Ks_NAF is computed as Ks_NAF = KDF (Ks, "gba-me", RAND, IMPI, NAF_Id), where KDF is the key derivation function as specified in Annex B, and the key derivation parameters consist of the user’s IMPI, the NAF_Id and RAND. The NAF_Id is constructed as follows: NAF_Id = FQDN of the NAF || Ua security protocol identifier. The Ua security protocol identifier is specified in Annex H. KDF shall be implemented in the ME.

NOTE 4: If a NAF hosts two or more applications which use the same FQDN and Ua security protocol identifier, they will share the same NAF specific keys. This causes a risk of so called two-time pad which may lead to the situation that the security of these applications is compromised. This can be avoided by running bootstrapping separately to each application or by application specific means, which are however out of the scope of the current specification.

To allow consistent key derivation based on NAF name in UE and BSF, at least one of the three following prerequisites shall be fulfilled:

(1) The NAF is known in DNS under one domain name (FQDN) only, i.e. no two different domain names point to the IP address of the NAF. This has to be achieved by administrative means.
This prerequisite is not specific to 3GPP, as it is necessary also under other circumstances, e.g. for TLS without use of wildcard or multiple-name certificates.

(2) Each DNS entry of the NAF points to a different IP address. The NAF responds to all these IP addresses. Each IP address is tied to the corresponding FQDN by NAF configuration. The NAF can see from the IP address, which FQDN to use for key derivation.

(3) Ua uses a protocol which transfers the host name (FQDN of NAF as used by UE) to NAF (e.g. HTTP/1.1 with mandatory Host request header field). This requires the NAF to check the validity of the host name, to use this name in all communication with UE where appropriate, and to transfer this name to BSF to allow for correct derivation of Ks_NAF.
In case of a TLS tunnel this requires either multiple-identities certificates or the deployment of TLS Extensions as specified in Annex E of TS 33.310 [19] or other protocol means with similar purpose.

The UE and the BSF shall store the key Ks with the associated B-TID for further use, until the lifetime of Ks has expired, or until the key Ks is updated or until the deletion conditions are satisfied (see 4.4.11).

NOTE 5: The following case can occur. The UE contacts the NAF1 and generates keys for NAF1. Then the UE contacts NAF2 and generates NAF2 keys. Then NAF1 requests then keys from the BSF, but the old key keys could have been overwritten due to NAF2 having initiated a new GBA run. The UE initiates a new GBA-run (B-TID2) after handling NAF1 (B-TID1) and starting the request to the NAF1 over Ua. One possible reason is that B-TID1 lifetime was about to expire. It is very likely that the GBA-run takes much more time (HSS involvement) then the Zn/Ua request such that the B-TID1 request at the BSF should arrive in most cases earlier at the BSF. So this out-of-order case should be very rare. This error situation will be signalled back to the UE, such that the most recent B-TID2 will also be used for NAF1. This out-of order case is self-correcting, since if the B-TID1 is unknown in the BSF, then the Ua request will fail and the UE can send a new request using B-TID2.

If the response included the product token "3gpp-gba-tmpi" in the server response-header field the UE shall compute the TMPI as specified in Annex B.4 and store it together with the IMPI, overwriting a previous TMPI related to this IMPI, if any.

4.5.3 Procedures using bootstrapped Security Association

Before communication between the UE and the NAF can start, the UE and the NAF first have to agree whether to use shared keys obtained by means of the GBA. If the UE does not know whether to use GBA with this NAF, it uses the Initiation of Bootstrapping procedure described in clause 4.5.1.

Once the UE and the NAF have established that they want to use GBA then every time the UE wants to interact with an NAF the following steps are executed as depicted in figure 4.4.

1. UE starts communication over reference point Ua with the NAF:

– in general, UE and NAF will not yet share the key(s) required to protect the reference point Ua. If they already do (i.e. if a key Ks_NAF for the corresponding key derivation parameter NAF_Id is already available), the UE and the NAF can start to securely communicate right away. If the UE and the NAF do not yet share a key, the UE proceeds as follows:

– if a key Ks for the selected UICC application is available in the UE, the UE derives the key Ks_NAF from Ks, as specified in clause 4.5.2;

– if no key Ks for the selected UICC application is available in the UE, the UE first agrees on a new key Ks with the BSF over the reference point Ub, and then proceeds to derive Ks_NAF

If it is not desired by the UE to use the same Ks for the selected UICC application to derive more than one Ks_NAF then the UE should agree on a new key Ks with the BSF over the reference point Ub, and then proceed to derive Ks_NAF.

– if the NAF shares a key with the UE, but the NAF requires an update of that key, e.g. because the key’s lifetime has expired or will expire soon, or the key can not meet the NAF local validity condition, it shall send a suitable bootstrapping renegotiation request to the UE, see figure 4.5. If the key’s lifetime has expired the protocol used over reference point Ua shall be terminated. The form of this indication depends on the particular protocol used over reference point Ua. If the UE receives a bootstrapping renegotiation request, it starts a run of the protocol over reference point Ub, as specified in clause 4.5.2, in order to obtain a new key Ks.

To allow for consistent key derivation in BSF and UE, both have to use the same FQDN for derivation (see clause 4.5.2). For each protocol used over Ua it shall be specified if only cases (1) and (2) of clause 4.5.2 are allowed for the NAF or if the protocol used over Ua shall transfer also the FQDN used for key derivation by UE to NAF.

NOTE 1: If the shared key between UE and NAF is invalid, the NAF can set deletion conditions to the corresponding security association for subsequent removal.

– the UE supplies the B-TID to the NAF, in the form as specified in clause 4.5.2, to allow the NAF to retrieve the corresponding keys from the BSF;

NOTE 2: The UE may adapt the key material Ks_NAF to the specific needs of the reference point Ua. This adaptation is outside the scope of this specification.

– the key management procedures for GBA related keys in the ME (i.e. Ks and Ks_NAF keys) are described in section 4.4.11.

– when a new Ks is agreed over the reference point Ub and a key Ks_NAF, derived from one NAF_Id, is updated, the other keys Ks_NAF, derived from different values NAF_Id, stored on the UE shall not be affected;

According to the procedures defined in clauses 4.5.2 and 4.5.3, in the UE there is at most one Ks_NAF key stored per NAF-Id.

2. NAF starts communication over reference point Zn with BSF

– The NAF requests key material corresponding to the B-TID supplied by the UE to the NAF over reference point Ua.;

– The NAF may also request one or more application-specific USSs for the applications, which the request received over Ua from UE may access;

NOTE 3: If the NAF requires service continuity, then the NAF can request a USS that contains a user pseudonym that allows service continuity according to BSF policy.

– With the key material request, the NAF shall supply a NAF-Id (which includes the NAF’s FQDN that the UE has used to access this NAF and the Ua security protocol identifier) to the BSF. (This is to allow for consistent key derivation in the BSF and UE as described above). The BSF shall verify that the NAF is authorized to use that FQDN.

3. The BSF derives the keys required to protect the protocol used over reference point Ua from the key Ks and the key derivation parameters, as specified in clause 4.5.2, and supplies to NAF the requested key Ks_NAF, as well as the bootstrapping time and the lifetime of that key, and the requested application-specific and potentially NAF group specific USSs if they are available in subscriber’s GUSS and if the NAF is authorized to receive the requested USSs. For any USSs containing a NAF Group attribute, this attribute shall be removed in the USSs supplied to the NAF. If the key identified by the B-TID supplied by the NAF is not available at the BSF, the BSF shall indicate this in the reply to the NAF. The NAF then indicates a bootstrapping renegotiation request to the UE.

NOTE 4: The NAF can further set the local validity condition of the Ks_NAF according to the local policy, for example a limitation of reuse times of a Ks_NAF.

NOTE 5: The NAF will adapt the key material Ks_NAF to the specific needs of the reference point Ua in the same way as the UE did. This adaptation is outside the scope of this specification.

– The BSF may require that one or more application-specific and potentially NAF group specific USSs shall be present in subscriber’s GUSS for the NAF (see clause 4.4.6). If one or more of these required settings are missing from the GUSS, the BSF shall indicate this in the reply to the NAF.

– The BSF may also send the private user identity (IMPI) and requested USSs to NAF according to the BSF’s policy;

4. NAF continues with the protocol used over the reference point Ua with the UE.

Once the run of the protocol used over reference point Ua is completed the purpose of bootstrapping is fulfilled as it enabled UE and NAF to use reference point Ua in a secure way.

Figure 4.4: The bootstrapping usage procedure

Figure 4.5: Bootstrapping renegotiation request

4.5.4 Procedure related to service discovery

The UE shall discover the address of the BSF the from the identity information related to the UICC application that is used during bootstrapping procedure, i.e., IMSI for USIM, or IMPI for ISIM. The address of the BSF is derived as specified in TS 23.003 [11].