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.
For HLR and HSS definitions used in this chapter refer to TS 23.002.
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.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.
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 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.