K.2 Shared key-based UE authentication with certificate-based AF authentication
24.1093GPPBootstrapping interface (Ub) and network application function interface (Ua)Protocol detailsRelease 17TS
The TLS profile for GBA in clause 5.3.2.1 is modified with the AKMA AF taking the role of the NAF from GBA (see 3GPP TS 33.220 [1]) to support AKMA keys as follows:
– the UE and the AF 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 AF, it shall establish a TLS tunnel with the AF. The AF 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 AF with which it established the tunnel. No client authentication is performed as part of TLS (no client certificate necessary).
b) the UE sends an HTTP request to the AF inside the TLS tunnel (HTTPS, i.e. HTTP over TLS) as described in clause 5.2 with the following changes:
1) the UE shall indicate to an AF that it supports AKMA based HTTP Digest authentication by including a "product" token, that is a constant string "3gpp-akma", in the "User-Agent" header (see RFC 7231 [31]) in outgoing HTTP requests; and
2) the AF may decide to authenticate the UE using AKMA-based shared secret by executing the authentication procedure. This is indicated in the "realm" parameter of the WWW-Authenticate header field. The realm attribute shall contain the constant string "3GPP-bootstrapping-akma". If the AF has a choice between GBA_Digest (see 3GPP TS 33.220 [1]) and AKMA keying, then the AF shall select AKMA over GBA_Digest.
NOTE 1: The choice between AKMA and AKA-based GBA at the UE and the AF, if both are supported, is application dependent.
c) the UE shall generate the HTTP request and the AF shall authenticate the HTTP request using HTTP Digest. HTTP Digest authentication (see RFC 3310 [6]) shall be used with previously bootstrapped security association as follows:
1) the "username" parameter shall be the A-KID;
2) the password used in the digest calculations shall be KAF (AKMA Application Key) with the KAF Base64 encoded as specified in RFC 4648 [37]; and
3) the "realm" parameter shall contain two parts delimited by "@" sign where the first part is the constant string "3gpp-akma" and the latter part shall be the FQDN of the AF (e.g. "3gpp‑akma@af1.operator.com"); and
d) both the UE and the AF 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 AF.
The authentication failures are supported as described in clause 5.3.2.2.
Clauses 5.3.2.3 and 5.3.2.4 are not supported as AKMA does not support deriving a fresh key in the same way as GBA.
NOTE 2: How a fresh key is derived for AKMA is up to Ua* protocol implementation.