M.6 Procedures

33.2203GPPGeneric Authentication Architecture (GAA)Generic Bootstrapping Architecture (GBA)TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

M.6.1 General

This chapter specifies in detail the format of the GBA_Digest bootstrapping procedure that is further utilized by various applications. It contains the authentication procedure with BSF, and the key material generation procedure.

M.6.2 Initiation of bootstrapping

Before communication between the UE and the NAF can start, the UE and the NAF first have to agree whether to use GBA. When a UE wants to interact with a NAF, but it does not know if the NAF requires the use of shared keys obtained by means of the GBA, the UE may contact the NAF for further instructions (see figure M.1).

NOTE: The above text implies that a UE may contact either the BSF or the NAF without knowing whether the NAF supports GBA.

Figure M.1: Initiation of bootstrapping

1. The UE may start communication over reference point Ua with the NAF with or without any GBA-related parameters.

2. If the NAF requires the use of shared keys obtained by means of the GBA, but the request from UE does not include GBA-related parameters, the NAF replies with a bootstrapping initiation message. If the use of GBA_Digest is acceptable to the NAF the NAF shall indicate it in this message. The form of this initiation message may depend on the particular reference point Ua.

M.6.3 Bootstrapping procedures

When a UE wants to interact with a NAF, and it knows that the bootstrapping procedure is needed, it shall first perform such a procedure. Otherwise, the UE shall perform a bootstrapping procedure only when it has received a bootstrapping initiation required message or a bootstrapping negotiation indication from the NAF, or when the lifetime of the key in UE has expired (cf. clause M.6.4).

The bootstrapping procedure using SIP Digest credentials is run over the Ub interface (extended for the purposes of GBA_Digest) as described below:

Figure M.2 GBA_Digest bootstrapping procedure

NOTE 1: Figure M.2 only shows an example flow for visualization and not all details are included.

A UE shall always include the product token "3gpp-gba-tmpi" in the user agent request-header field when sending HTTP messages over Ub. A BSF shall always include the product token "3gpp-gba-tmpi" in the server response-header field when sending HTTP messages over Ub.

NOTE 1a: According to the HTTP specification RFC 7230 [63], the product tokens may contain any text. They are ignored when unknown by a UE or a BSF.

Step 0:

The UE and the BSF shall establish a TLS tunnel with server authentication using a server certificate. The use of TLS message integrity is mandatory, while the use of TLS encryption is optional. All further messages between the BSF and UE shall be sent through this tunnel.

NOTE 2: TLS encryption can be useful for protecting the user identity privacy when the TMPI mechanism defined in the present document is not used.

Step 1:

In this HTTP request message from the UE to the BSF, the UE shall include an Authorization header containing a user identity in the "username" parameter and a token indicating the use of GBA_Digest. When a TMPI associated with the IMPI in use is available on the UE, this user identity shall be this TMPI, otherwise it shall be the IMPI. The realm in the Authorization header shall be the realm as defined for SIP Digest in TS 33.203 [16].

Step 2:

The BSF recognises from the structure of the "username" parameter (cf. Annex B.4) whether a TMPI or an IMPI was sent. If a TMPI was sent the BSF shall look up the corresponding IMPI in its local database. If the BSF does not find an IMPI corresponding to the received TMPI it shall return an appropriate error message to the UE. The UE shall then delete the TMPI and retry the request using the IMPI.The BSF shall request a SIP Digest Authentication Vector (SD-AV) from the HSS. The SD-AV is defined in TS 33.203 [16], Annex N. The username field in the Multimedia Auth Request shall contain the IMPI.

Step 3:

The HSS shall retrieve the SD-AV corresponding to the IMPI and send it to the BSF in a Multimedia Auth Answer. The handling of GUSS between BSF and HSS shall be as described in clause 4.5.2, step 2.

The qop value shall be set to "auth-int ".

NOTE 3: The additional protection afforded by qop set to "auth-int" may seem unnecessary considering the fact that the messages exchanged between UE and BSF are protected by a TLS tunnel. However, the use of "auth-int" is consistent with the other modes of GBA (GBA_ME, GBA_U and 2G GBA) and also provides a second layer of integrity protection in case the TLS server authentication is ever compromised (e.g. due to replacement of insecurely stored root certificates on the UE or a Certification Authority being compromised).

Step 4:

In the HTTP 401 Unauthorized response from the BSF to the UE, the BSF shall include a WWW-Authenticate header with parameters as specified in RFC 7235 [61] and RFC 7616 [62].

The parameters realm, qop, and algorithm were provided in the SD-AV in step 3 and the nonce=base64encode (16 byte random value) is generated according to RFC 3548 [60] by the BSF.

Step 5:

When responding to a challenge from the BSF, the UE shall generate a cnonce randomly, and calculate the response RESP. The RESP shall be put into the Authorization header and sent back to the BSF in the GET request.

RESP shall be computed as a Digest-response according to RFC 7235 [61] and RFC 7616 [62] (HTTP Digest) from the most recent GBA_Digest challenge and a password ‘passwd’ that is generated as follows:

passwd = KDF (H(A1), "GBA_Digest_RESP", TLS_MK_Extr)

where H(A1) is the hash of the following three parameters: the user name and password used by the user in IMS for SIP Digest according to TS 33.203 [16], Annex N, and the realm, cf. also RFC 7235 [61] and RFC 7616 [62]. "GBA_Digest_RESP" is a character string. TLS_MK_Extr is extracted from the TLS master key according to RFC5705 [44] or RFC 8446 [59] with the optional context value being omitted, the label set to "EXPORTER_GBA_Digest", and the length set equal to the length of the TLS master secret (48 bytes). KDF is the key derivation function as specified in clause B.2.

NOTE 4: A cautionary note on notation: According to RFC 7235 [61] and RFC 7616 [62], the computation of RESP from the password ‘passwd’ defined above entails again a parameter called H(A1). This parameter will differ from the value of H(A1) that is input to the above formula because the passwords from which these two H(A1) values are derived differ. But no new notation is deemed necessary here as the notation H(A1), when H(A1) is derived from ‘passwd’, is not explicitely used in the text of the present document.

Step 6:

Upon receiving a GET request carrying the authentication response RESP, the BSF shall check that the expected RESP (calculated by the BSF in the same way as by the UE in step 5) matches the received RESP. If the check is successful then the user has been authenticated.

The BSF shall then derive Ks as follows, (see clause B.5 for the formation of the input):

Ks = KDF (H(A1), "GBA_Digest_Ks", TLS_MK_Extr, RESP)

where H(A1), RESP, and TLS_MK_Extr are defined as in step 5, and "GBA_Digest_Ks" is a character string.

The BSF shall generate the bootstrapping transaction identifier (B-TID) for the IMPI and store the tuple
<B-TID, IMPI, Ks, nonce>. The B-TID shall be constructed in the format of a NAI by taking the nonce from step 4, and the BSF server name, i.e. nonce@BSF_server_domain_name.

NOTE 5: The B-TID construction above is almost identical to the one used in clause 4. The difference is that in clause 4 the username part is constructed from the (base64 encoded) RAND value.

The BSF shall compute a new TMPI as specified in Annex B.4 and store it together with the IMPI, overwriting a previous TMPI related to this IMPI, if any.

NOTE 6: The formulations in the preceding paragraph, and the corresponding paragraph below relating to the computation of the TMPI in the UE, differ from the ones in clause 4.5.2 as GBA_Digest-aware UEs and BSFs always include the product tokens as described at the start of this clause. So, the condition in clause 4.5.2 is not needed.

The BSF shall send a 200 OK response to the UE to indicate the success of the authentication.

In this message from the BSF to the UE, the BSF shall include the bootstrapping transaction identifier (B-TID) and the key lifetime.

An Authentication-Info header according to RFC 7235 [61] and RFC 7616 [62] shall be included into the 200 OK response.

The UE shall abort the procedure if the server authentication according to RFC 7235 [61] and RFC 7616 [62] fails. Otherwise, the UE shall derive Ks in the same way as the BSF did above.

The UE shall compute the TMPI as specified in Annex B.4 and store it together with the IMPI, overwriting a previous TMPI related to this IMPI, if any.

After successful bootstrapping procedure the UE and the BSF shall store the key Ks, the nonce, the B-TID, and an indication of the underlying security quality, i.e. GBA_Digest, for further use, until the key Ks is updated or until the deletion conditions in clause M.5.11 are satisfied. The key Ks shall then be used in the BSF and in the UE to derive NAF specific key(s) Ks_NAF to secure Ua reference points in the following way:

Ks_NAF shall be computed as Ks_NAF = KDF (Ks, "gba-digest", nonce, IMPI, NAF_Id), where KDF is the key derivation function as specified in clause B.2, and the input parameters consist of the user’s IMPI, the NAF_Id and ‘nonce’. ‘nonce’ is the nonce that was used for computing the RESP that was input to the derivation of Ks. The NAF_Id shall be constructed as in clause 4.5.2. The "gba-digest" parameter is a static character string.

NOTE 6: The above derivation of Ks_NAF is analagous to the derivation in clause 4.5.2, step 9, and the same KDF can be utilized.

The KDF shall be implemented in the terminal.

M.6.4 Procedures using bootstrapped Security Association

Before communication between the UE and the NAF can start, the UE and the NAF first have to agree whether to use shared keys obtained by means of the GBA. If the UE does not know whether to use GBA with this NAF, it uses the Initiation of Bootstrapping procedure described in clause M.6.2.

Once the UE and the NAF have established that they want to use GBA then every time the UE wants to interact with an NAF the following steps are executed as depicted in figure M.3.

1. UE starts communication over reference point Ua with the NAF:

– in general, UE and NAF will not yet share the key(s) required to protect the reference point Ua. If they already do (i.e. if a key Ks_NAF for the corresponding key derivation parameter NAF_Id is already available), the UE and the NAF can start to securely communicate right away. If the UE and the NAF do not yet share a key, and if the use of a Ks derived from an AKA-based GBA variant according to clauses 4.5.3, 5.5.3, or I.5.3, is not possible, the UE proceeds as follows:

– if the UE knows (through a lack of indication in the Initiation of Bootstrapping procedure or by configuration) that the use of GBA_Digest is not acceptable to the NAF it shall abort the communication with the NAF. Otherwise, a key Ks_NAF shall be derived in the following way:

– if a key Ks derived from SIP Digest credentials is available in the UE, the UE derives the key Ks_NAF from Ks, as specified in clause M.6.3;

– if no key Ks derived from SIP Digest credentials is available in the UE, the UE first agrees on a new key Ks derived from SIP Digest credentials with the BSF over the reference point Ub, and then proceeds to derive Ks_NAF;

NOTE 0: A key Ks derived from an AKA-based GBA variant could still be available from a previous GBA bootstrapping run where the UICC was available, and could then still be used.

If it is not desired by the UE to use the same Ks derived from SIP Digest credentials to derive more than one Ks_NAF then the UE should agree on a new key Ks with the BSF over the reference point Ub, and then proceed to derive Ks_NAF;

– if the NAF shares a key with the UE, but the NAF requires an update of that key, e.g. because the key’s lifetime has expired or will expire soon, or the key can not meet the NAF local validity condition, it shall send a suitable bootstrapping renegotiation request to the UE, see figure M.4. If the key’s lifetime has expired the protocol used over reference point Ua shall be terminated. The form of this indication depends on the particular protocol used over reference point Ua. If the UE receives a bootstrapping renegotiation request, it starts a run of the protocol over reference point Ub, as specified in clause M.6.3, in order to obtain a new key Ks.

To allow for consistent key derivation in BSF and UE, both have to use the same FQDN for derivation (see clause M.6.3). For each protocol used over Ua it shall be specified if only cases (1) and (2) of clause 4.5.2 are allowed for the NAF or if the protocol used over Ua shall transfer also the FQDN used for key derivation by UE to NAF.

NOTE 1: If the shared key between UE and NAF is invalid, the NAF can set deletion conditions to the corresponding security association for subsequent removal.

– the UE supplies the B-TID to the NAF, in the form as specified in clause M.5.8, to allow the NAF to retrieve the corresponding keys from the BSF;

NOTE 2: The UE may adapt the key material Ks_NAF to the specific needs of the reference point Ua. This adaptation is outside the scope of the present document.

– the key management procedures for GBA related keys in the terminal are described in section M.5.11.

– when a new Ks is agreed over the reference point Ub and a key Ks_NAF, derived from one NAF_Id, is updated, the other keys Ks_NAF, derived from different values NAF_Id, stored on the UE shall not be affected;

According to the procedures defined in clauses M.6.3 and M.6.4, in the UE there is at most one Ks_NAF key stored per NAF_Id.

2. NAF starts communication over reference point Zn with BSF:

– The NAF shall request key material corresponding to the B-TID supplied by the UE to the NAF over reference point Ua. The NAF shall indicate to the BSF whether it is willing to accept Ks_NAF based on GBA_Digest;

– The NAF may also request one or more application-specific USSs for the applications, which the request received over Ua from UE may access;

NOTE 3: If the NAF requires service continuity, then the NAF can request a USS that contains a user pseudonym that allows service continuity according to BSF policy.

– With the key material request, the NAF shall supply a NAF_Id (which includes the NAF’s FQDN that the UE has used to access this NAF and the Ua security protocol identifier) to the BSF. (This is to allow for consistent key derivation in the BSF and UE as described above). The BSF shall verify that the NAF is authorized to use that FQDN.

3. The BSF derives the keys required to protect the protocol used over reference point Ua from the key Ks and the key derivation parameters, as specified in clause M.6.3, and supplies to NAF the requested key Ks_NAF, as well as the bootstrapping time and the lifetime of that key, and the requested application-specific and potentially NAF group specific USSs if they are available in subscriber’s GUSS and if the NAF is authorized to receive the requested USSs. For any USSs containing a NAF Group attribute, this attribute shall be removed in the USSs supplied to the NAF. In addition, the BSF shall indicate to the NAF that the subscriber is a subscriber using SIP Digest credentials. If the key identified by the B-TID supplied by the NAF is not available at the BSF, the BSF shall indicate this in the reply to the NAF. The NAF then indicates a bootstrapping renegotiation request to the UE.

NOTE 4: The NAF can further set the local validity condition of the Ks_NAF according to the local policy, for example a limitation of reuse times of a Ks_NAF.

NOTE 5: The NAF will adapt the key material Ks_NAF to the specific needs of the reference point Ua in the same way as the UE did. This adaptation is outside the scope of the present document.

– If the NAF did not indicate that it is willing to accept a Ks_NAF based on GBA_Digest, or if the BSF determines according to its local policy that the NAF shall not serve subscribers using SIP Digest credentials, then the BSF shall not send a Ks_NAF based on GBA_Digest;

– If the NAF indicated that it is willing to accept a Ks_NAF based on GBA_Digest, but the B-TID refers to a key Ks established by using an AKA-based method, then the BSF shall send a key Ks_NAF derived from this Ks unless this Ks was derived from 2G GBA and the NAF does not accept 2G GBA (cf. NOTE 0);

– The BSF may require that one or more application-specific and potentially NAF group specific USSs shall be present in subscriber’s GUSS for the NAF (see clause M.5.7). If one or more of these required settings are missing from the GUSS, the BSF shall indicate this in the reply to the NAF;

– The BSF may also send the private user identity (IMPI) and requested USSs to NAF according to the BSF’s policy;

– If the NAF determines, according to its local policy, that the NAF shall not serve subscribers using SIP Digest credentials, the NAF shall terminate the protocol over the reference point Ua;

– The NAF should accept the Zn response even when the GBA_Digest indication is missing (as this means that the key Ks_NAF was derived from a key Ks established by using an AKA-based method, which is stronger), (cf. NOTE 0);

– When the NAF receives the Zn response, it shall check that the GBA type in the Zn response corresponds with the GBA type negotiated over Ua protocol. If this is not the case, NAF shall terminate the protocol over the reference point Ua.

4. NAF continues with the protocol used over the reference point Ua with the UE.

Once the run of the protocol used over reference point Ua is completed the purpose of bootstrapping is fulfilled as it enabled UE and NAF to use reference point Ua in a secure way.

Figure M.3: The bootstrapping usage procedure

Figure M.4: Bootstrapping renegotiation request

M.6.5 Procedure related to service discovery

The UE shall discover the address of the BSF from the IMPI related to the IMS subscription. When the IMPI was derived from an IMSI as defined in clause 13 of TS 23.003 [11] then the BSF address shall be derived as as specified in clause 16 of TS 23.003 [11] for the case of an IMSI, otherwise the BSF address shall be derived as as specified in clause 16 of TS 23.003 [11] for the case of an IMPI.

NOTE: The reason for this distinction is the NOTE in clause 16 of TS 23.003 [11] warning that BSF addresses of a certain form may be unreachable.