This clause gives a high level overview of the content of the different GAA and GBA related documents and describes how these documents fit together.
GAA refers to this TR that describes the general framework of the Generic Authentication Architecture.
As briefly indicated in clause 5.2
, GBA provides a general mechanism based on 3GPP AKA 
to install a shared secret between a UE and a server.
AKA is a very powerful mechanism that mobile networks make use of. GBA takes benefit of this mechanism and re-uses AKA to bootstrap application security. GBA introduces a new network element (NE) called the Bootstrapping Server Function (BSF). This BSF has an interface with the HSS. The UE runs AKA with the HSS via the BSF. From the resulting (CK, IK), a session key is derived in BSF and UE. An application server (called Network Application Function (NAF) in TS 33.220
) can fetch this session key from the BSF together with subscriber profile information. In this way the application server (NAF) and the UE share a secret key that can subsequently be used for application security, in particular to authenticate UE and NAF at the start of the application session (possibly also for integrity and/or confidentiality protection although that might not be strictly in the scope of GAA). The communication between the UE and the BSF as well as that between NAF and BSF and between BSF and HSS are application independent and are described in TS 33.220
If only SIM cards or SIMs on UICC is available, and 2G_GBA is allowed, the BSF and UE mutually authenticates using the 2G AKA and TLS protocol.
The following argument leads to the introduction of this new NE (BSF):
keep the number of different types of NEs as well as the total number of NEs that retrieve AVs from the HSS to a minimum.
One generic mechanism for different applications avoids a large diversity of mechanisms and allows to address security issues once and in a consistent way.
If a client wants to make use of asymmetric encryption technology, he needs a digital certificate that is created by a certification authority (CA). Such a certificate binds a public key to the identity of its legitimate owner and certifies the validity of the public key. If a mobile subscriber wants to have and make use of a (public, private) key pair, the key pair and a certificate should either be preloaded or the subscriber must have the means to either generate or obtain a key pair and dynamically obtain a corresponding digital certificate. As briefly indicated in clause 5.3
, SSC specifies a mechanism to dynamically issue a digital certificate to a mobile subscriber.
To dynamically obtain a digital certificate a UE must send an appropriate certificate request to a PKI portal of his home operator, and the PKI portal must authenticate the certificate request. The certificate enrolment process i.e. the issuing of a certificate to a subscriber and the corresponding communication session between a UE and a PKI portal is in fact an example of a mobile application. As with many mobile applications it requires authentication of the communicating entities, in this case the UE and the PKI portal (the latter plays the role of the application server). As for any other application there are 2 options for this authentication: pre-shared secret based or based on asymmetric cryptography and certificates. The latter is only an option when a new certificate is requested from the PKI portal while another still valid certificate is already loaded in the UE. The former method requires a shared secret between the PKI portal and the UE. If the shared secret is not pre-configured, GBA can be used to obtain such a shared secret.
As indicated in Figure 5, the result of the process of issuing a certificate to a mobile subscriber which is described in the SSC TS 33.221
is that the UE is loaded with a certificate corresponding to its (public, private) key pair. This is indicated by the green upward arrow.
Once the certificate is in place it can be used (together with the corresponding (public, private) key pair) to authenticate the UE. This is indicated by the black dotted lines that connect "certificates"
to the underlying applications (HTTPS and SSC in Figure 5). The (public, private) key pair and the corresponding digital certificate can also be used for integrity protection (or less likely confidentiality) but these are not part of the scope of GAA.
It is envisaged that HTTPS (or HTTP/TLS) may be used in a number of services to secure the application session between the UE and the application server (Ua interface in TS 33.220
, see TS 33.222
). TS 33.222
describes the details of the possible authentication options when HTTPS is used between a UE and an application server. Any existing or future application based on HTTPS or Pre-Shared Key TLS can refer to TS 33.222
for details on authentication and the set up of a secure HTTP session.
describes a mechanism where a reverse proxy (called authentication proxy (AP)) is used between the UE and the AS.
The AP is the TLS end point and the UE shall be able to simultaneously connect to different ASs behind one AP. The AP shall be able to authenticate the UE using the means of GAA, and shall send the authenticated UE identity to the AS. If UE authentication is based on a shared secret then the AP acts as the NAF in the GAA architecture and terminology.
Possible advantages of the use of such an AP may include reduced consumption of authentication vectors, minimization of SQN synchronization failures and reduction of number of TLS sessions that a UE needs to set up and maintain.
HTTP based application servers can also be deployed without the use of an authentication proxy. In this case the HTTPS (or TLS) session is between the UE and the AS. In this case the AS shall be able to authenticate the UE using the means of GAA. If UE authentication is based on a shared secret then the AS acts as the NAF in the GAA architecture and terminology.
The HTTP client and server can authenticate each other based on the GBA-based shared key between the UE and the BSF generated during the bootstrapping procedure created by the procedures in TS 33.220
. The shared key shall be used as a master key to generate further TLS session keys, and also be used as the proof of secret key possession as part of the authentication function. The exact procedure can be found in Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)