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. 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.

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.

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). 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.

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.
• 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.
• 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.

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).

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.

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.

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.

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, is used on the reference point Ub. It is based on the 3GPP AKA TS 33.102 protocol. The interface to the USIM is as specified in TS 31.102 and to the ISIM is as specified in TS 31.103.

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, it is a protocol, which allows the user to request certificates from the NAF. In this case the NAF would be the PKI portal.

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.

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.

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.

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.