F.3 Signalling flow demonstrating a successful PSK TLS authentication procedure

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

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

The signalling flow in figure F.3-1 describes the generic message exchange between UE and NAF using PSK TLS. In this example, the PSK TLS client application resides in the ME, i.e., either Ks_NAF or Ks_ext_NAF is used as the key.

Figure F.3-1: PSK TLS handshake with bootstrapped security association.

1. TLS handshake message: ClientHello (UE to NAF)

The UE sends ClientHello message to the NAF. In order to indicate that the UE is capable of PSK-based authentication it includes the PSK-based ciphersuites to the list of acceptable ciphersuites list. The UE also includes to the ClientHello message the server_name TLS extension containing the hostname of the NAF.

TLS.ClientHello.client_version: the version of the TLS protocol in the UE is 3.1.

TLS.ClientHello.random: a UE generated random structure.

TLS.ClientHello.session_id: the ID of the TLS session is empty, i.e. no previous TLS session is used.

TLS.ClientHello.cipher_suites: the list of ciphersuites includes one or more PSK-based ciphersuites.

TLS.ClientHello.compression_methods: a list of the compression methods is null.

TLS.ClientHello.client_hello_extension_list: list of extensions includes server_name extension that contains the hostname of the NAF.

2. TLS handshake messages: ServerHello, ServerKeyExchange, ServerHelloDone (NAF to UE)

If the NAF wants to use PSK-based authentication, it selects one of the acceptable PSK-based ciphersuites, places the selected ciphersuite in the ServerHello message, and includes an appropriate ServerKeyExchange message. The NAF can help the UE in selecting the correct PSK identity by providing a list of hints in ServerKeyExchange message. That list includes a static string "3GPP‑bootstrapping ".

TLS.ServerHello.server_version: the version of the TLS protocol in the NAF is 3.1.

TLS.ServerHello.random: a NAF generated random (must be different from ClientHello.random).

TLS.ServerHello.session_id: the identity of the TLS session generated by the NAF.

TLS.ServerHello.cipher_suite: the ciphersuite selected by the NAF is one of the PSK-based ciphersuites listed in ClientHello.cipher_suites.

TLS.ServerHello.compression_method: the compression method selected by the NAF is null.

TLS.ServerHello.server_hello_extension_list: list of extensions is empty.

TLS.ServerKeyExchange.psk_identity_hint: the PSK identity hint contains the constant string "3GPP-bootstrapping".

TLS.ServerHelloDone: this message does not have data fields.

3. Bootstrapping and generation of NAF specific key material at UE

The UE performs the bootstrapping procedure to produce B-TID and Ks_(ext)_NAF as described in clause A.3. If bootstrapping procedure has been done recently, the UE can use the B-TID and Ks_(ext)_NAF produced from that procedure.

4. TLS handshake messages: ClientKeyExchange, ChangeCipherSpec, Finished (UE to NAF)

The UE sets concatenated "3GPP-bootstrapping" string, separator character ";" and the B-TID as the PSK identity, and Ks_(ext)_NAF as the pre-shared key. The UE then sends ClientKeyExchange containing the B-TID, ChangeCipherSpec, and Finished messages to the NAF. The TLS premaster secret is derived from Ks_(ext)_NAF.

TLS.ClientKeyExchange.psk_identity: the PSK identity contains concatenated "3GPP-bootstrapping" string, separator character ";" and the B-TID.

TLS.ChangeCipherSpec.type: contains value 1 (change_cipher_spec).

TLS.Finished.verify_data: the verify data contains the hash of the handshake messages. For details, see the RFC for TLS defined in annex E of 3GPP TS 33.310 [25].

5. Zn: NAF specific key procedure

The NAF extracts the B-TID from the ClientKeyExchange message and requests the NAF specific key (Ks_NAF or Ks_ext_NAF) from BSF. The BSF returns the NAF specific key that corresponds to the B-TID.

If the NAF retrieved an application-specific USS and it contained a keyChoice indication, the NAF must enforce this indication. Hence, if the UICC-based key was indicated the NAF must terminate the communication with the UE in this phase.

NOTE: If the local configuration in the NAF restricts the access to this NAF service to UICC-based applications, then the NAF will terminate the communication with the UE in this phase.

For detailed signalling flows see 3GPP TS 29.109 [3].

Table F.3-1: Bootstrapping authentication information procedure (NAF to BSF)

Message source and destination	Zn Information element name	Information Source in TLS	Description
NAF to BSF	B-TID	ClientKeyExchange.psk_identity	The bootstrapping transaction identifier (B-TID) is encoded in the ClientKeyExchange.psk_identity field according to PSK TLS.

6. Authentication at NAF

The NAF validates the Finished message sent by the UE.

7. TLS handshake messages: ChangeCipherSpec, Finished (NAF to UE)

The NAF sends ChangeCipherSpec, and Finished messages to the UE.

TLS.ChangeCipherSpec.type: contains value 1 (change_cipher_spec).

TLS.Finished.verify_data: the verify data contains the hash of the handshake messages. For details, see the RFC for TLS defined in annex E of 3GPP TS 33.310 [25].

8. Authentication at UE

The UE validates the Finished message sent by the NAF.

9. Application data transfer

The UE and the NAF initiate application data transfer in the TLS session.

Annex G (normative):
3GPP specific extension-headers for HTTP entity-header fields