For the purposes of the present document, the following terms and definitions apply. Subscriber certificate:

For the purposes of the present document, the following abbreviations apply: AKA AP AS BSF GAA GBA HSS NAF NE PKI SSC UE

There are generally speaking two types of authentication mechanisms. One is based on a secret shared between the communicating entities, the other one is based on (public, private) key pairs and digital certificates. Also in GAA these are the two options that are a priori available for mobile applications as is illustrated in Figure 3.

There are several authentication protocols that rely on a pre-shared secret between the two communicating entities. Popular examples include HTTP Digest, Pre-Shared Key TLS, IKE with pre-shared secret and a priori any mechanism based on username and password. The main problem with these mechanisms is how to agree on this pre-shared secret. Clause 5.2 and GBA TS 33.220 describe how in a mobile context an AKA based mechanism can be used to provide both communicating entities with a pre-shared secret.

An alternative to using shared secrets for authentication is to rely on asymmetric cryptography. This assumes that the entity that needs to be authenticated (one or both partners in the communication) possesses a (public, private) key pair and a corresponding digital certificate. The latter validates the key pair and binds the key pair to its legitimate owner. Well-known protocols whose authentication is based on (public, private) key pairs include PGP and HTTP over TLS, RFC 2818 (the later is commonly called by its protocol identifier, "HTTPS"). The main disadvantage of this type of authentication is that a PKI is needed and that asymmetric key cryptographic operations often require substantially more computational effort than symmetric key operations. Clause 5.3 and Support for Subscriber Certificates (SSC) TS 33.221 describe how a mobile operator can issue digital certificates to its subscribers (hence providing a basic PKI).

Figure 4 illustrates the relation between this TR and TS 33.220 and TS 33.221. There are on the one hand authentication methods that are based on shared secrets and GBA, described in TS 33.220, specifies a mechanism to provide communicating parties with such a shared secret. On the other hand there are authentication methods that rely on (public, private) key pairs and digital certificates and SSC, described in TS 33.221, specifies how to issue certificates to mobile subscribers.

TS 33.220 specifies an application independent mechanism based on the 3GPP AKA mechanism to provide a client and an application server with a common shared secret. This shared secret can subsequently be used to authenticate the communication between the client and an application server.

TS 33.221, specifies a mechanism to issue a digital certificate to a mobile subscriber. Once a mobile subscriber has a (public, private) key pair and has obtained a certificate for it, he can use the certificate together with the corresponding key pair to produce digital signatures in e.g. m-commerce applications but also to authenticate to a server (e.g. in TLS).

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 [1] 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.

GAA provides different alternatives to an AS or an AP to perform user authentication (i.e. force the UE to run AKA with the BSF as specified in TS 33.220 or use a mechanism based on subscriber certificates). Also under GAA, an AS may understand that the user request is already authenticated by an Authentication Proxy. GAA as described in this TR has not the intention to impose any one authentication mechanism onto applications . It is rather aimed to be a tool at developers disposal which they can use to their benefit. Application developers may save development time by using GAA instead of designing and implementing application-specific authentication mechanisms. An additional advantage of the mechanisms of GAA is that they can provide global coverage, inherited from the GSM/UMTS coverage. Depending on network configuration and policies of the operator, an AS or an AP will be able to use any of the alternatives provided by GAA or even any other user authentication mechanisms specified outside of 3GPP if such mechanisms are at their disposal. It is therefore assumed that an AS and an AP should be able to take the decision what parts of GAA shall be used if any. This section tries to give an overview of arguments that can play a role in the choice of authentication mechanism. The authentication mechanism selected will be dependent on:

1. Requirements/policies relating to the user/server/application/device that needs authentication. This may be in both directions (mutual authentication), but the usual emphasis is user to server authentication.
2. Device and service characteristics, user capabilities and preferences as defined in the user profile.
3. Policies of the network or networks providing the transport service and the service providers of the applications.

Requirements/policies relating to authentication will depend on whether there is a need for:

1. Device authentication: The device is genuine and not a clone i.e. Authentication of a (U)SIM by challenge response.
2. Integrity protection: An example is signalling protection in UTRAN access A weakness in GSM is that it is very easy for a man in the middle to manipulate signalling message e.g. cipher mode command and a way to prevent it being compromised is to use device authentication and integrity protection via a keyed MAC (Message Authentication Code) on the specific signalling messages.
3. Application authentication: It will often be necessary to check the authenticity of the application software. Application authentication is however out of the scope of GAA.
4. User authentication:. This refers to authentication of the end user, the person who is using the end user device. One way of doing this is to make the USIM availability to devices/protocols/applications dependent, logically, by user PIN input or physically, by a policy of removal and insertion. The entry of a PIN may also be required before access is allowed to a specific application.
5. Transaction authentication and non-repudiation: For some business transactions that are carried out using the mobile device it is necessary to digitally sign the transaction with a users private key, specifically where there is a need for non repudiation i.e. to prevent:
   • the False Denial of the: SENDING of the Message, e.g. "I never sent it!"
   • the CONTENT of the Message, e.g. "I said you should sell, not buy!"
   • the TIME of the Message, e.g. "I sent it a different time!"

Figure 6 shows how device and service characteristics can impact the choice of a particular technique from the Spectrum of Authentication Mechanisms.

Some examples of where shared secrets from the innovation of GBA can be used are:

• distribution of symmetric ciphering and integrity keys for securing applications running between the UE and a server in the network. Example protocols that can be used to secure an application and that require a shared secret include HTTP Digest, shared secret TLS and IPsec;
• distribution of passwords and PIN for third party applications;
• for protecting the distribution of certificates between the UE and the certificate authority.

Some examples of where certificates can be used for authentication are:

• when it is necessary to check the identity of the end user;
• when the application security protocol works smoothly with (public, private) key pair authentication and subscriber certificates are available (e.g. normal TLS);
• where there is a need for non-repudiation and where the user is required to digitally sign the transaction with a user's private key as many authentication techniques such as 3GPP AKA are based on a single key, which is shared between the network and the user. Non-repudiation provable to a third party may require the use of public key technique where the private key is only held by the sender.

Monitoring of GAA usage requires the logging of certain events. The following list of events, grouped by interfaces on which they occur, may serve as a baseline for implementing monitoring in the network nodes.

1. Ub interface: Bootstrapping between UE and BSF over Ub interface,
2. Ua interface:
   1. Authentication of UE and NAF based on bootstrapped NAF specific key.
   2. Enrollment of subscriber's public key.
   3. Delivery of operator's root CA certificate.
3. Zn interface:
   1. Delivery of NAF specific key material to the NAF,
   2. Delivery of USS to NAF
4. Zh interface: Delivery of AV and GUSS.

TR 33.905 outlines the GAA related functionalities and their interworking in the terminal. It describes the relationship of the GAA server in the terminal that communicates with the BSF server over Ub reference point, and with the UICC through the relevant device drivers, the GAA client that is part of a terminal application and communicates over the network with a NAF server and the GAA server in the terminal to obtain the NAF specific GAA credentials.

TR 33.920 outlines needed changes to provision an ME and a NAF with a shared secret based on the SIM card. TS 33.220 focuses on the usage of 3G USIM / ISIM for GBA and the SIM card specific details can be found in the Annex I. 2G GBA provides allows building services where authentication is performed and managed in an analogous way as using USIM. The protocol wherein the SIM card is used, decides the strength of the security of the whole system. Therefore, the solution described for an early implementation feature in this specifications targets to enhance GSM security to address the known GSM vulnerabilities when using 2G GBA. 2G GBA does not require any change to the existing SIM specifications, in particular GBA_U as in 3G GBA is not part of 2G GBA.

TS 33.110 describes a GBA based key establishment between a UICC and a terminal. The UICC is rarely a stand-alone device; it usually interacts with a terminal. For sensitive applications that are split between a smart card and a terminal with sensitive data exchanged between those two. TS 33.110 provide means to establish keys, that then can be used to establish a secure channel between a UICC and a terminal.

TR 33.980 defines the Interworking between GBA and Liberty Alliance protocols. GBA and the Liberty Alliance Identity Federation and Web Service Framework were developed and can be deployed indepently of each other. The Liberty Alliance Identity Federation and Web Service Framework offers simplified single sign-on and session management for complex web service business interaction protocols. The GBA offers a mechanism to provide a shared secret and certificates to two communicating entities for mobile applications, based on GSM and UMTS authentication and key agreement protocols. TR 33.980 provides guidelines on the interworking of the Generic Authentication Architecture (GAA) and the Liberty Alliance architecture. It studies the details of possible interworking methods between the Liberty Alliance Identity Federation Framework (ID-FF), the Identity Web Services Framework (ID-WSF) and GBA for various Single Sign On scenarios.

TS 33.246 specifies the usage of GBA TS 33.220. GBA is used to provision the keys that are needed to run an MBMS User Service. If protection for the MBMS User Service is required, then the UE needs to share GBA-keys with the BM-SC that is acting as a Network Application Function (NAF) according ot TS 33.220. The MMBS Serivice Keys for an MBMS User Service shall be stored on either the UICC if the UICC is capable of MBMS key management or the ME if the UICC is not capable of MBMS key management.