5 Network application function; Ua interface

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

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

5.1 Introduction

The usage of bootstrapped security association i.e. B-TID and Ks_NAF (or Ks_ext_NAF or Ks_int_NAF) over Ua interface depends on the application protocol used between UE and NAF.

The Ua interface is used to supply the B-TID, generated during the bootstrapping procedure, to the network application function (NAF), and Zn interface is used by the NAF to retrieve the Ks_NAF or Ks_ext_NAF or Ks_int_NAF from BSF. The default is the use of Ks_(ext)_NAF, but the usage of Ks_int_NAF in Ua interface is possible. The Ua interface depends on type of NAF. The Zn interface is defined in 3GPP TS 29.109 [3]. This clause describes how B‑TID and Ks_NAF or Ks_ext_NAF or Ks_int_NAF can be utilized, as specified in 3GPP TS 33.220 [1], and in the context of more specific Ua usage, as specified for deployment of HTTPS in 3GPP TS 33.222 [5], or for a PKI portal in 3GPP TS 33.221 [4]).

5.2 HTTP Digest authentication

5.2.1 General

The HTTP Digest authentication model as described in RFC 7616 [36] can be used with bootstrapped security association as the authentication and integrity protection method, if the application protocol used over Ua interface between UE and NAF is based on HTTP (see RFC 7230 [30], RFC 7231 [31], RFC 7232 [32], RFC 7233 [33], RFC 7234 [34] and RFC 7235 [35]). The HTTP Digest authentication may be used for all protocols that have adopted the HTTP authentication framework to mutually authenticate the UE and the NAF, and also optionally integrity protect any payload being transferred between them.

The UE shall indicate to an application server (i.e. a NAF) that it supports 3GPP-bootstrapping based HTTP Digest authentication by including a "product" token to the "User-Agent" header (cf. RFC 7231 [31]) in outgoing HTTP requests. If the UE supports

a) AKA-based authentication, then the "product" token is a static string "3gpp-gba" if the HTTP client application resides in the ME, or "3gpp-gba-uicc" if the HTTP client application resides in the UICC; or

b) GBA_Digest, then the "product" token is "3gpp-gba-digest".

The UE may indicate multiple GBA modes by inserting multiple "product" tokens in the User-Agent header field. The User-Agent header field with GBA related "product" tokens shall be added to each outgoing HTTP request if the UE supports GBA-based authentication using HTTP Digest.

Upon receiving GBA related "product" tokens, the application server if it supports NAF functionality may decide to authenticate the UE using GBA-based shared secret by executing the authentication procedure. If multiple GBA modes have been indicated in the User-Agent header field, then the NAF selects one GBA mode and indicates the selected mode in responses to the UE in the "realm" parameter of the WWW-Authenticate header field. In the selection of the GBA mode by the UE, AKA-based modes shall take priority over GBA_Digest.

The protocol stack of the Ua interface when HTTP Digest authentication is used is presented in figure 5.2-1. The details are defined in the following clauses.

NOTE: HTTP is not the only protocol that can be used. Other protocols can also be used as long as the protocol has adopted the HTTP authentication framework.

Figure 5.2-1: Protocol stack of Ua interface with HTTP Digest authentication

5.2.2 Authentication procedure

5.2.2.1 General

HTTP Digest authentication as specified in RFC 7616 [36] shall be used with previously bootstrapped security association as follows:

1) the "username" parameter shall be the bootstrapping transaction identifier (B-TID);

2) the password used in the digest calculations shall be

a) in case of GBA_ME the NAF specific key material (Ks_NAF);

b) in case of GBA_U the NAF specific ME based key material (Ks_ext_NAF) or the NAF specific UICC-based key material (Ks_int_NAF);and

c) in case of GBA_Digest the NAF specific key material (Ks_NAF);

NOTE: The NAF specific key material (Ks_NAF or Ks_ext_NAF or Ks_int_NAF) is derived from the key material (Ks) using key derivation function as specified in 3GPP TS 33.220 [1].

The NAF specific key material (Ks_NAF or Ks_ext_NAF or Ks_int_NAF) is Base64 encoded as specified in RFC 4648 [37].

3 the "realm" parameter shall contain two parts delimited by "@" sign. The first part is the constant string "3GPP-bootstrapping" (in case of a ME-based application) , "3GPP-bootstrapping-uicc" (in case of a UICC-based application) or "3GPP-bootstrapping-digest " (in case of GBA_Digest), and the latter part shall be the FQDN of the NAF (e.g. "3GPP-bootstrapping@naf1.operator.com" or "3GPP-bootstrapping-uicc@naf1.operator.com" or "3GPP-bootstrapping-digest@naf1.operator.com").

In the case of GBA_U, the NAF shall indicate to the UE which NAF specific key was selected to be used by setting the first part of the realm to "3GPP-bootstrapping" (for the ME-based key i.e. Ks_ext_NAF), or to "3GPP-bootstrapping-uicc" (for the UICC-based key i.e. Ks_int_NAF).

Both the UE and the NAF shall verify upon receiving each of the HTTP responses and HTTP requests that the second part of the realm attribute is equal to the FQDN of the NAF.

In the case of GBA_U, if the HTTPS client application resides in the ME, then the application shall use only the ME-based key i.e. Ks_ext_NAF (the UICC-based key Ks_int_NAF is not available in the ME). If the NAF indicates to the ME-based HTTPS client application that only UICC-based key shall be used, the application must terminate the communication with the NAF. If the HTTP client application resides in the UICC, then the application shall use only the UICC-based key. If the NAF indicates to the UICC-based application that only ME-based key shall be used, the application must terminate the communication with the NAF.

In the case of GBA_U, the operator may indicate the type of the key to be used in the Ua reference point in the NAF specific USS as specified in 3GPP TS 29.109 [3]. If the NAF has requested an application specific USS, and the indication is present in the USS, the NAF shall use the indicated key type. If the type of the negotiated key is different from the type indicated in the USS, the NAF shall terminate the communication with the UE.

An example flow of a successful HTTP Digest authentication procedure can be found in clause B.3.

5.2.3 Authentication failures

Authentication failures are handled as they are described in RFC 7616 [36] and RFC 7235 [35].

5.2.4 Bootstrapping required indication

NAF shall indicate to the UE that bootstrapped security association is required by sending an HTTP response with code 401 "Unauthorized" and include the WWW-Authenticate header into the response. In particular, the "realm" attribute shall contain a prefix "3GPP-bootstrapping@" or "3GPP-bootstrapping-uicc@" or "3GPP-bootstrapping-digest", and this shall trigger UE to run bootstrapping procedure over Ub interface.

5.2.5 Bootstrapping renegotiation indication

The NAF shall indicate to the UE that the existing bootstrapped security association used in the last HTTP request sent by the UE has expired and that a new bootstrapped security association is required by sending an HTTP response described in clause 5.2.3. When the UE receives the 401 "Unauthorized" HTTP response to the HTTP request that was protected using the existing bootstrapped security association, this shall trigger the UE to run bootstrapping procedure over Ub interface.

5.2.6 Integrity protection

Integrity protection may be provided by using HTTP Digest integrity protection, i.e. quality of protection (qop) parameter is set to "auth-int".

5.3 UE and NAF authentication using HTTPS

5.3.1 General

Prior to establishing HTTP, the UE and the NAF may perform authentication. Three different authentication mechanisms may be used for UE and NAF authentication:

a) Shared key-based UE authentication (HTTP Digest) with certificate-based NAF authentication (TLS);

b) Shared key-based mutual authentication between UE and NAF (PSK TLS), and;

c) Certificate based mutual authentication between UE and AS;

The protocol stack of the Ua interface when TLS is used is presented in figure 5.3.1-1. and described in clause 5.3.2. The HTTP Digest authentication is described in clause 5.2.

Figure 5.3.1-1: Protocol stack of Ua interface with TLS

The protocol stack of the Ua interface when PSK TLS is used is presented in figure 5.3.1-2 and described in clause 5.3.3. The HTTP Digest authentication is described in clause 5.2.

Figure 5.3.1-2: Protocol stack of Ua interface with PSK TLS

5.3.2 Shared key-based UE authentication with certificate-based NAF authentication

5.3.2.1 Authentication procedure

The authentication mechanism described in this section for ME-based application is mandatory to implement in the ME and optional to implement in the NAF.

The authentication mechanism described in this section for UICC-based application is optional to implement in the UICC and the NAF.

The UE and the NAF shall support the TLS version as specified in annex E of 3GPP TS 33.310 [25]. See clause 5.3.1 in 3GPP TS 33.222 [5] for the detailed profiling of TLS.

a) When the UE starts communication via Ua reference point with the NAF, it shall establish a TLS tunnel with the NAF. The NAF is authenticated to the UE by means of a public key certificate. The UE shall verify that the server certificate corresponds to the FQDN of the NAF it established the tunnel with. No client authentication is performed as part of TLS (no client certificate necessary).

b) The UE sends an HTTP request to the NAF inside the TLS tunnel (HTTPS, i.e. HTTP over TLS) as described in clause 5.2.

c) The NAF shall authenticate the HTTP request using HTTP Digest as specified in clause 5.2.

5.3.2.2 Authentication failures

Server authentication failures are handled in TLS as they are described in the RFC for TLS which is defined in annex E of 3GPP TS 33.310 [25]. Client authentication failures are handled in HTTP Digest as they are described in RFC 7616 [36] and RFC 7235 [35].

5.3.2.3 Bootstrapping required indication

Bootstrapping required indication is done on HTTP Digest and therefore described in clause 5.2.4.

5.3.2.4 Bootstrapping renegotiation indication

Bootstrapping renegotiation indication is done on HTTP Digest and therefore described in clause 5.2.5.

5.3.3 Shared key-based mutual authentication between UE and NAF

5.3.3.1 Authentication procedure

5.3.3.1.1 General

The authentication mechanism described in this section for ME-based application is optional to implement in the ME and the NAF.

The authentication mechanism described in this section for UICC-based application is optional to implement in the UICC and the NAF.

The PSK-based authentication for TLS (PSK TLS) may be used with bootstrapped security association as the authentication, confidentiality, and integrity protection method. The profile for TLS and TLS Extensions to be used together with PSK TLS is defined in annex E of 3GPP TS 33.310 [25].

5.3.3.1.2 Authentication procedure using TLS 1.2

The PSK TLS handshake shall be used with bootstrapped security association as follows:

– the ClientHello message shall contain one or more PSK-based ciphersuites;

– the ClientHello message shall contain the server_name TLS extension and it shall contain the hostname of the NAF;

– the ServerHello message shall contain a PSK-based ciphersuite selected by the NAF;

– the ServerKeyExchange shall be sent by the server and it shall contain the psk_identity_hint field and it shall contain the static string "3GPP‑bootstrapping" or "3GPP-bootstrapping-uicc" or "3GPP-bootstrapping-digest". If several authentication methods are supported then the ServerKeyExchange message shall include the PSK-identity hints for all allowed authentication methods, separated by semi-colon ";" (e.g., "3GPP-bootstrapping;3GPP-bootstrapping-uicc").

In the case of GBA_U, the NAF shall indicate to the UE which NAF specific key can be used by setting the psk_identity_hint to "3GPP-bootstrapping" (for the ME-based key i.e. Ks_ext_NAF), or to "3GPP-bootstrapping-uicc" (for the UICC-based key i.e. Ks_int_NAF). If the NAF allows both types of keys to be used then the psk_identity_hint field shall contain both hints separated by semi-colon ";".

In addition, the NAF may include an indication to use a BSF address different from the one specified in 3GPP TS 23.003 [7] in the psk_identity_hint field of the ServerKeyExchange message. The indication to use the different BSF address shall contain a prefix "3GPP bootstrapping-BSF-address", a separator character ":" and the FQDN of the BSF. The NAF may only include this indication for an application specified to support this functionality (e.g. Proximity-based Services, see 3GPP TS 33.303 [29]) and if it is included then the static strings "3GPP bootstrapping" shall be included.

The psk_identity_hint field may contain a list of psk_identity_hints and are separated by a semi-colon character (";") (see NOTE 1);

NOTE 1: Other psk identity name spaces than "3GPP‑bootstrapping" or "3GPP‑bootstrapping-uicc" can be supported, however, they are out of the scope of this specification.

– the ClientKeyExchange shall contain the psk_identity field and it shall contain a prefix "3GPP‑bootstrapping" or "3GPP‑bootstrapping-uicc" or "3GPP-bootstrapping-digest" indicating the selected psk identity name space, a separator character ";" and the B-TID. In the selection of the GBA mode by the UE, AKA-based modes shall take priority over GBA_Digest.;

– if the PSK TLS client resides in the ME, the UE shall derive the TLS premaster secret from the NAF specific key material i.e. Ks_NAF in the case of GBA_ME. For GBA_U the UE shall derive the TLS premaster secret from the ME-based key material i.e. Ks_ext_NAF;

– if the PSK TLS client resides in the UICC, the UE shall derive the TLS premaster secret from the NAF specific UICC-based key material i.e. Ks_int_NAF;

– if the indication to use a different BSF address was included in the psk_identity_hint field of the ServerKeyExchange message, the ME shall derive the TLS premaster secret from a Ks_NAF resulting from a GBA_ME bootstrapping with the indicated BSF and shall use the prefix "3GPP bootstrapping" in the psk_identity field of the ClientKeyExchange message.

NOTE 2: A GBA_U capable NAF indicates to the UE the type of the authorized NAF specific key (i.e. (Ks_ext_NAF or Ks_int_NAF or both). The details of the key decision mechanism in the NAF are specified in 3GPP TS 29.109 [3].

In the case of GBA_U, if the HTTPS client application resides in the ME then the application shall use only the ME-based key i.e. Ks_ext_NAF (the UICC-based key Ks_int_NAF is not available in the ME). If a NAF indicates to a ME-based HTTPS client application that the UICC-based key shall be used then the application must terminate the communication with this NAF. If a HTTPS client application resides in the UICC, then the application shall only use the UICC-based key. If the NAF indicates to the UICC-based application that only the ME-based key can be used then the application must terminate the communication with the NAF.

An example flow of the PSK TLS procedure can be found in clause F.3.

5.3.3.1.3 Authentication procedure using TLS 1.3

The PSK TLS handshake shall be used with bootstrapped security association as follows:

1) The UE shall include in the ClientHello message:

a) an indication that it supports the TLS with PSK authentication using the "psk_key_exchange_modes" extension;

b) the hostname of the NAF using the "server_name" TLS extension;

c) authentication methods other than PSK the UE supports;

d) PSK identities within the psk_identities field. Each included psk_identity parameter within the psk_identities field shall contain a prefix indicating the PSK identity name space, a separator character ";" and the B-TID. The psk_identity parameters within the psk_identities field are separated by a comma character (","); and

e) an additional psk_identity parameter in the psk_identities field for each of psk_identity parameter included in step 1)d) to allow the NAF to signal that a bootstrapping is required for that bootstrapping method. The format of this additional psk_identity parameter is the original one without the semi-colon character and B-TID but with "_bootstrappingrequired" appended, e.g. "3GPP-bootstrapping-uicc-bootstrappingrequired" parameter is included if the psk_identity parameter with the "3GPP-bootstrapping-uicc" PSK identity name space is included in the psk_identities field and similarly for the other methods.

The prefix "3GPP-bootstrapping" is used in the psk_identity parameter to indicate that the UE accepts that AKA-based Ks(_ext)_NAF is used establish the TLS session keys.

The prefix "3GPP-bootstrapping-uicc" is used in the psk_identity parameter to indicate that the UE accepts that Ks_int_NAF is used to establish the TLS sessions keys.

The prefix "3GPP-bootstrapping-digest" is used in the psk_identity parameter to indicate that the UE accepts that GBA_Digest-based Ks_NAF is used to establish the TLS sessions keys.

NOTE: Other PSK identity name spaces can be supported, however, they are out of the scope of the present document.

If the UE has a choice in the selection of the GBA mode, AKA-based modes shall take priority over GBA_Digest.

The UE shall derive the TLS external PSK from the NAF specific key Ks(_ext)_NAF if the initiating HTTPS client resides on the ME or Ks_int_NAF if the initiating HTTP client resides on the UICC).

2) If the NAF wants the UE to perform a new bootstrapping for a particular method:

a) the NAF shall indicate the index of the bootstrapping required of the selected psk_identity parameter in the ServerHello message;

b) the UE shall treat the ServerHello message the NAF sent in step 2)a) as a HelloRetryRequest message and shall perform a new bootstrapping run for the indicated bootstrapping method; and

c) once the bootstrapping is completed, the UE shall send a new ClientHello message with the psk_identities field including only the psk_identity parameter containing the psk_identity_namespace of the chosen bootstrapping method and the new B-TID.

3) If the NAF is willing to establish a TLS tunnel using PSK authentication the NAF shall select one of the psk_identity parameters from the psk_identities field received within the ClientHello message.

4) The NAF shall reply with the ServerHello message and indicate the index of the psk_identity parameter. The NAF concludes the TLS handshake by sending Finished message to the UE.

If the NAF received within the ClientHello messages the psk_identities field with the psk_identity parameter containing:

a) "3GPP-bootstrapping" prefix and the B-TID the NAF shall fetch the NAF specific shared secret (Ks(_ext)_NAF) from the BSF using the B-TID;

b) "3GPP-bootstrapping-uicc" prefix and the B-TID the NAF shall fetch the NAF specific shared secret (Ks_int_NAF) from the BSF using the B-TID; or

c) "3GPP-bootstrapping-digest" prefix and the B-TID the NAF shall indicate to the BSF that GBA_Digest is acceptable.

If the NAF has requested an application specific USS, and the indication is present in the USS, the NAF shall use the indicated key type. If the type of the negotiated key is different from the type indicated in the USS, the NAF shall terminate the communication with the UE.

The NAF shall derive the TLS external PSK from the NAF specific key (Ks(_ext)_NAF or Ks_int_NAF).

5) The UE concludes the TLS handshake by sending Finished message to the NAF.

The UE and the NAF have established a TLS tunnel using GBA-based shared secret, and they may start to use the application level communication through this tunnel.

5.3.3.2 Authentication failures

Authentication failures are handled as they are described in the profile for TLS specified in annex E of 3GPP TS 33.310 [25].

5.3.3.3 Bootstrapping required indication

In TLS 1.2, during TLS handshake, the NAF shall indicate to the UE that bootstrapped security association is required by sending a ServerHello message containing a PSK-based ciphersuite, and a ServerKeyExchange message containing the psk_identity_hint field, which contains a static string "3GPP-bootstrapping" or "3GPP-bootstrapping-uicc" or "3GPP-bootstrapping-digest". This shall trigger the UE to run the bootstrapping procedure over Ub interface.

NOTE: The NAF shall select a PSK-based ciphersuite only if the UE has offered one or more PSK-based ciphersuites in the corresponding ClientHello message.

In TLS 1.3, during TLS handshake, the UE shall include the psk_identities field in the ClientHello message to enable the request of a fresh bootstrapping. If the NAF wants the UE to perform a new bootstrapping for a particular method, the NAF shall indicate the index of the bootstrapping required of the selected psk_identity parameter in the ServerHello message. This shall trigger the UE to run the new bootstrapping procedure over Ub interface.

5.3.3.4 Bootstrapping renegotiation indication

During usage of TLS session, the NAF shall indicate to the UE that bootstrapped security association has expired by sending close_notify alert message to the UE.

In TLS 1.2, the UE may attempt resume the old TLS session by sending a ClientHello message containing the old session ID. The NAF shall refuse to use the old session ID by sending a ServerHello message with a new session ID. This will indicate to the UE that the bootstrapped security association it used has expired.

During TLS handshake, the NAF shall indicate to the UE that the bootstrapped security association has expired by sending handshake_failure message as a response to the Finished message sent by the UE. This will indicate to the UE that the bootstrapped security association it used has expired.

5.3.4 Certificate based mutual authentication between UE and application server

The authentication mechanism described in this clause is optional to implement in the UE and in the application server.

The certificate based mutual authentication between an UE and an application server shall be based on TLS and TLS Extensions. The profile for TLS and TLS Extensions is defined in annex E of 3GPP TS 33.310 [25].

Annex B in 3GPP TS 33.222 [5] provides guidance on certificate mutual authentication between UE and application server.

5.3.5 Integrity protection

Integrity protection is provided by using authenticated TLS tunnel as described in RFC 2818 [12].