I.2 GBA_Digest 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 GBA_Digest bootstrapping procedure. The bootstrapping security association consists of a bootstrapping transaction identifier (B-TID) and key material Ks. A Bootstrapping session on the BSF also includes security related information about the subscriber (in particular the user’s private identity). A Bootstrapping session is valid for a certain time period, and shall be deleted in the BSF when the session becomes invalid.
The UE shall establish a TLS connection with the BSF prior to sending any HTTP request to the BSF.
A UE shall indicate to the BSF that it intends to run GBA_Digest as defined in 3GPP TS 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 "GBA_Digest" in HTTP requests sent to the BSF. The BSF is configured to either allow or disallow the use of GBA_Digest bootstrapping. If GBA_Digest is disallowed, the BSF shall reject the HTTP request by the UE.
The GBA_Digest Bootstrapping procedure as specified in 3GPP TS 33.220 [1] is further detailed as described below.
– Authorization, WWW-Authenticate, and Authentication-Info HTTP header fields shall be used as described in RFC 7616 [36] with following exceptions:
a) the "realm" parameter shall be set to the domain name of the home network;
b) the quality of protection ("qop") parameter shall be "auth-int";
c) the "username" parameter shall contain user’s private identity;
d) the "nonce" field shall be populated as specified in 3GPP TS 33.220 [1], annex M with a random number generated by the BSF according to RFC 7616 [36]; and
– a password, which is called "passwd" and is derived as specified in 3GPP TS 33.220 [1], annex M.
In addition to RFC 7616 [36], the following apply:
a) in the initial request from the UE to the BSF, the UE shall include an Authorization header field with following parameters:
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;
– the response directive, set to an empty value;
b) in the HTTP response containing the Digest challenge from the BSF to the UE, the BSF shall include parameters to WWW-Authenticate header field as specified in RFC 7616 [36];
c) in the HTTP request sent as an answer to the HTTP response in bullet b) the UE shall include an Authorization header field that contains a digest-response, "algorithm", "qop", "cnonce", and "nc" header field parameters as specified in RFC 7616 [36], and
– 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
d) n the message from the BSF to the UE, which the BSF shall only send after the BSF concluded that the UE has been authenticated, the BSF shall include an Authentication-Info header with the "rspauth" parameter. Furthermore, the BSF shall include the 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.
After a 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 SIP Digest parameters as specified for GBA_Digest in 3GPP TS 33.220 [1]. In addition, the BSF may also contain a set of security specific attributes (GUSS) related to the UE, depending on the conditions in clause 4.5.2 of 3GPP TS 33.220 [1].