4 Generic Bootstrapping Architecture; Ub interface

24.1093GPPBootstrapping interface (Ub) and network application function interface (Ua)Protocol detailsRelease 17TS

4.1 Introduction

Generic Authentication Architecture (GAA) is based on shared secrets provided by generic bootstrapping architecture (GBA). The stage 2 description of GAA framework is described in 3GPP TR 33.919 [2] and the GBA procedures in 3GPP TS 33.220 [1].

The GBA related to the Ub interface is between the UE and bootstrapping server function (BSF). During the bootstrapping procedure BSF also uses the Zh interface to request authentication vectors from HSS. The Zh interface is defined in 3GPP TS 29.109 [3]. The end result of the bootstrapping procedure is that both BSF and an UE have a security association in a form of a bootstrapping transaction identifier (B-TID) and key material (Ks).

According to 3GPP TS 33.220 [1] the bootstrapping procedure shall be based on HTTP Digest AKA as described in RFC 3310 [6]. The protocol stack of the Ub interface in bootstrapping procedure is presented in figure 4.1-1. The details are defined in the following clauses.

Figure 4.1-1: Protocol stack of Ub interface

The bootstrapping procedure described in the present document can result to different key materials depending on whether ME-based or UICC-based GBA is used. However, the bootstrapping procedure itself is the same for both ME-based GBA (GBA_ME), and UICC-based GBA (GBA_U).

The bootstrapping procedure can also be based on SIM, i.e., 2G GBA. The 2G GBA bootstrapping procedure is specified in annex H.

The bootstrapping procedures can also be based on GBA_Digest. The GBA_Digest bootstrapping procedures is specified in annex I.

4.2 Bootstrapping procedure

The UE shall initiate the bootstrapping procedure when:

a) the UE wants to interact with a NAF and bootstrapping is required;

b) a NAF has requested bootstrapping required indication as described in clause 5.2.4 or bootstrapping renegotiation indication as described in clause 5.2.5; or

c) the lifetime of the key has expired in the UE if one or more applications are using that key.

A UE and the BSF shall establish bootstrapped security association between them by running bootstrapping procedure. Bootstrapping security association consists of a bootstrapping transaction identifier (B-TID) and key material Ks. Bootstrapping session on the BSF also includes security related information about subscriber (e.g. user’s private identity). Bootstrapping session is valid for a certain time period, and shall be deleted in the BSF when the session becomes invalid.

Bootstrapping procedure shall be based on HTTP Digest AKA as described in 3GPP TS 33.220 [1] and in RFC 3310 [6] with the modifications described below.

The BSF address is derived from the IMPI or IMSI according to 3GPP TS 23.003 [7].

A UE shall indicate to the BSF that it supports the use of TMPI as defined in 3GPP 33.220 [1] by including a "product" token in the "User-Agent" header field (cf. RFC 7231 [31]) that is set to a static string "3gpp-gba-tmpi" in HTTP requests sent to the BSF.

A BSF shall indicate to the UE that it supports the use of TMPI as defined in 3GPP 33.220 [1] by including a "product" token in the "Server" header field (cf. RFC 7231 [31]) that is set to a static string "3gpp-gba-tmpi" in HTTP responses sent to the UE.

In the bootstrapping procedure, Authorization, WWW-Authenticate, and Authentication-Info HTTP headers shall be used as described in RFC 3310 [6] with following exceptions:

a) the "realm" parameter shall contain the network name where the username is authenticated;

b) the quality of protection ("qop") parameter shall be "auth-int"; and

c) the "username" parameter shall contain user’s private identity (IMPI).

NOTE: If the UE does not have an ISIM application with an IMPI, the IMPI will be constructed from IMSI, according to 3GPP TS 23.003 [7].

In addition to RFC 3310 [6], the following apply:

a) In the initial request from the UE to the BSF, the UE shall include Authorization header with following parameters:

– the username directive, set to

1) the value of the TMPI if one has been associated with the private user identity as described in 3GPP 33.220 [1]; or

2) the value of the private user identity;

– the realm directive, set to the BSF address derived from the IMPI or IMSI according to 3GPP TS 23.003 [7];

– the uri directive, set to either absoluteURL "http://<BSF address>/" or abs_path "/", and which one is used is specified in RFC 7616 [36];

– the nonce directive, set to an empty value; and

– the response directive, set to an empty value;

b) In the challenge response from the BSF to the UE, the BSF shall include parameters to WWW-Authenticate header as specified in RFC 3310 [6] with following clarifications:

– the realm directive, set to the BSF address derived from the IMPI or IMSI according to 3GPP TS 23.003 [7];

c) In the message from the BSF to the UE, the BSF shall include bootstrapping transaction identifier (B-TID) and the key lifetime to an XML document in the HTTP response payload. The BSF may also include additional server specific data to the XML document. The XML schema definition of this XML document is given in annex C.

d) When responding to a challenge from the BSF, the UE shall include an Authorization header containing a realm directive set to the value as received in the realm directive in the WWW-Authenticate header.

e) Authentication-Info header shall be included into the subsequent HTTP response after the BSF concluded that the UE has been authenticated. Authentication-Info header shall include the "rspauth" parameter.

After successful bootstrapping procedure the UE and the BSF shall contain the key material (Ks) and the B-TID. The key material shall be derived from AKA parameters as specified in 3GPP TS 33.220 [1]. In addition, BSF shall also contain a set of security specific attributes related to the UE.

An example flow of successful bootstrapping procedure can be found in clause A.3.

4.3 User authentication failure

If the response returned by the UE is different than expected, the BSF may challenge the UE again with a new AKA challenge. After N consecutive incorrect responses from the UE, the BSF shall indicate a failure to the UE. The exact value of N is defined by local policy.

4.4 Network authentication failure

In case the UE fails at authenticating the network, the UE shall abort the bootstrapping procedure.

4.5 Synchronization failure

If the UE considers the sequence number in the challenge not to be in the correct, the UE shall send a synchronization failure indication back to the BSF as specified RFC 3310 [6].

An example flow can be found in clause A.4.