Content for TS 33.535 Word version: 17.7.0
A Key derivation functions
A.1 KDF interface and input parameter construction
A.2 KAKMA derivation function
A.3 A-TID derivation function
A.4 KAF derivation function
B AKMA profiles for Ua* protocols
B.1 TLS based protocols
$ Change history
A (Normative) Key derivation functions p. 21
A.1 KDF interface and input parameter construction p. 21
A.1.1 General p. 21
All key derivations for AKMA shall be performed using the key derivation function (KDF) specified in Annex B.2.2 of TS 33.220.
This clause specifies how to construct the input string, S, and the input key, KEY, for each distinct use of the KDF. Note that "KEY" is denoted "Key" in TS 33.220.
A.1.2 FC value allocations p. 21
The FC number space used is controlled by TS 33.220, FC values allocated for the present document are in the range of 0x80 - 0x82.
A.2 KAKMA derivation function p. 21
When deriving a KAKMA from KAUSF, the following parameters shall be used to form the input S to the KDF:
- FC = 0x80;
- P0 = "AKMA";
- L0 = length of "AKMA"; (i.e. 0x00 0x04)
- P1 = SUPI;
- L1 = length of SUPI.
A.3 A-TID derivation function p. 21
When deriving the A-TID from KAUSF, the following parameters shall be used to form the input S to the KDF:
- FC = 0x81;
- P0 = "A-TID";
- L0 = length of "A-TID"; (i.e. 0x00 0x05)
- P1 = SUPI;
- L1 = length of SUPI.
A.4 KAF derivation function p. 22
When deriving a KAF from KAKMA, the following parameters shall be used to form the input S to the KDF:
- FC = 0x82;
- P0 =AF_ID;
- L0 = length of AF_ID
B (Normative) AKMA profiles for Ua* protocols |R17| p. 23
B.1 TLS based protocols p. 22
B.1.1 General p. 23
This annex contains profiles of the share key-based UE authentication with certificate-based AF authentication and the shared key-based mutual authentication between UE and AF that are similar to the ones defined in TS 33.222.
B.1.2 Shared key-based UE authentication with certificate-based AF authentication p. 23
B.1.2.1 General p. 23
The following clause provides the changes needed to adapt the Ua protocol given in clause 5.3 of TS 33.222 to work with a KAF derived using the AKMA procedures.
B.1.2.2 Procedures p. 23
The procedures follow those given in clause 5.3.0 of TS 33.222 with the AKMA AF taking the role of the NAF from GBA (see TS 33.220), with the following changes.
At step 2, if the clients supports AKMA with this protocol then the client shall add the constant string "3gpp-akma" to the "User-Agent" HTTP header as product tokens as specified in RFC 7231.
At step 3, if the AF selects AKMA for deriving the key, then the AF shall include the "3GPP-bootstrapping-akma" within the WWW-Authenticate header field. If the AF has choice between GBA_Digest (see TS 33.220) and AKMA keying, then the AF shall select AKMA over GBA_Digest (see TS 33.222 for similar consideration between GBA methods).
At step 4, on receiving the response from the AF, the client shall verify that the FQDN in the realm attribute corresponds to the FQDN of the AF it established the TLS connection with. If failure the client shall terminate the TLS connection with the AF.
At step 5 given AKMA has been selected for keying, the client shall send a response with an Authorization header field where Digest is inserted using the A-KID as username. KAF shall be used as password in the Digest calculation.
At step 6 given AKMA has been selected for keying, the AF shall verify the value of the password attribute using KAF retrieved from AAnF using the A-KID received as username attribute in the query. If the AF is not able to obtain the AF-specific key when using AKMA mode, the AF shall respond with an appropriate error message not containing the realm attributes from step 3.
B.1.3 Shared key-based mutual authentication between UE and AF p. 23
B.1.3.1 General p. 23
The following clause provides the changes needed to adapt the Ua protocol given in clause 5.4 of TS 33.222 to work with a KAF derived using the AKMA procedures.
B.1.3.2 Procedures p. 24
B.1.3.2.1 Procedures for TLS 1.2 p. 24
The procedures follow those given in clause 5.4.0.1 of TS 33.222 with the AKMA AF taking the role of the NAF from GBA (see TS 33.220), with the following changes.
At step 2, the AF shall include a constant string "3GPP-AKMA" is used as PSK-identity hint to indicate that AKMA based keying is supported.
At step 3, the UE may use an AKMA generated key if support was indicated by the AF (even if GBA-based keys were also indicated as supported by the AF). To use AKMA generated key, the UE shall derive the TLS premaster secret from KAF and shall send a ClientKeyExchange message including a PSK identity consisting of "3GPP-AKMA" and the A-KID. If the UE has choice between GBA_Digest (see TS 33.220) and AKMA keying, then the UE shall select AKMA over GBA_Digest (see TS 33.222 for similar consideration between GBA methods).
At step 4, if the AF receives the "3GPP-AKMA" prefix and the A-KID in the ClientKeyExchange messages it fetches the AF specific shared secret (KAF) from the AAnF using the A-KID. The AF shall derive the TLS premaster secret from the AF specific key (KAF).
B.1.3.2.2 Procedures for TLS 1.3 p. 24
The procedures follow those given in clause 5.4.0.2 of TS 33.222 with the AKMA AF taking the role of the NAF from GBA (see TS 33.220), with the following changes.
In step 1, the PSK identities in the ClientHello shall include a prefix indicating the PSK-identity name space (i.e. "3GPP-AKMA") and the A-KID to indicate the UE supports keying with AKMA.
In step 2 if the AF is willing to establish a TLS tunnel using PSK authentication with AKMA keys, then the AF shall indicate the index of the AKMA psk identity in the ServerHello message. If the AF has choice between GBA_Digest (see TS 33.220) and AKMA keying, then the AF shall select AKMA over GBA_Digest (see TS 33.222 for similar consideration between GBA methods).
The UE and NAF shall derive the TLS external PSK from KAF.
$ Change history p. 25
