H.2 2G GBA bootstrapping procedure

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

A UE and the BSF shall establish a bootstrapped security association between them by running the 2G GBA bootstrapping procedure. The 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.

It shall be possible that the BSF is configured to either allow or disallow the use of 2G GBA bootstrapping. If 2G GBA is disallowed, the BSF shall not start the TLS handshake with the UE as described below.

The 2G GBA Bootstrapping procedure as specified in 3GPP TS 33.220 [1] is further detailed as described below.

– 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 FQDN of the BSF. The UE shall check that the "realm" attribute contains the same FQDN of the BSF that was present in the BSF certificate.

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

c) the "username" parameter shall contain user’s private identity (IMPI) which has been derived from the IMSI of the SIM application as specified in 3GPP TS 23.003 [7].

d) the "nonce" field shall be populated as specified in 3GPP TS 33.220 [1], annex H with

– the "RAND" which is the RAND of the 2G authentication vector, and

– the "AUTN" which is a 128-bit zero number, and

– the "server specific" data is a 128-bit random number "Ks-input" generated by the BSF.

– the "RES" which is used as the password is derived as specified in 3GPP TS 33.220 [1], annex H.

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 the value of the private user identity IMPI derived from the IMSI of the SIM according to 3GPP TS 23.003 [7];

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

– the uri directive, set to either absoluteURL "https://<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 IMSI of the SIM 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) 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 for 2G GBA in 3GPP TS 33.220 [1]. In addition, BSF shall also contain a set of security specific attributes (GUSS) related to the UE.