B.1 TLS based protocols
33.5353GPPAuthentication and Key Management for Applications (AKMA) based on 3GPP credentials in the 5G System (5GS)Release 17TS
B.1.1 General
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 3GPP TS 33.222 [7].
B.1.2 Shared key-based UE authentication with certificate-based AF authentication
B.1.2.1 General
The following clause provides the changes needed to adapt the Ua protocol given in clause 5.3 of TS 33.222 [7] to work with a KAF derived using the AKMA procedures.
B.1.2.2 Procedures
The procedures follow those given in clause 5.3.0 of TS 33.222 [7] with the AKMA AF taking the role of the NAF from GBA (see TS 33.220 [4]), 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 IETF RFC 7231 [10].
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 [4]) and AKMA keying, then the AF shall select AKMA over GBA_Digest (see TS 33.222 [7] for similar consideration between GBA methods).
NOTE 1: The choice between AKMA and AKA-based GBA is application dependent.
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
B.1.3.1 General
The following clause provides the changes needed to adapt the Ua protocol given in clause 5.4 of TS 33.222 [7] to work with a KAF derived using the AKMA procedures.
B.1.3.2 Procedures
B.1.3.2.1 Procedures for TLS 1.2
The procedures follow those given in clause 5.4.0.1 of TS 33.222 [7] with the AKMA AF taking the role of the NAF from GBA (see TS 33.220 [4]), 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 [4]) and AKMA keying, then the UE shall select AKMA over GBA_Digest (see TS 33.222 [7] for similar consideration between GBA methods).
NOTE 1: The choice between AKMA and AKA-based GBA is application dependent.
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
The procedures follow those given in clause 5.4.0.2 of TS 33.222 [7] with the AKMA AF taking the role of the NAF from GBA (see TS 33.220 [4]), 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 [4]) and AKMA keying, then the AF shall select AKMA over GBA_Digest (see TS 33.222 [7] for similar consideration between GBA methods).
NOTE 1: The choice between AKMA and AKA-based GBA is application dependent.
The UE and NAF shall derive the TLS external PSK from KAF.
Annex C (informative):
Change history
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2020-06 |
SA#88-e |
SP-200381 |
EditHelp review. Presented for information and approval |
1.0.0 |
|||
|
2020-07 |
SA#88-e |
Upgrade to change control version |
16.0.0 |
||||
|
2020-09 |
SA#89-e |
SP-200708 |
0001 |
– |
D |
Add Abbreviations to clause 3.3 |
16.1.0 |
|
2020-09 |
SA#89-e |
SP-200708 |
0009 |
1 |
F |
Clarifications on error response handling in AKMA process |
16.1.0 |
|
2020-09 |
SA#89-e |
SP-200708 |
0013 |
1 |
F |
Re-authentication in AKMA |
16.1.0 |
|
2020-09 |
SA#89-e |
SP-200708 |
0020 |
– |
F |
Adding AKMA context description |
16.1.0 |
|
2020-09 |
SA#89-e |
SP-200708 |
0023 |
1 |
F |
Corrections and clarifications to clause 4 |
16.1.0 |
|
2020-09 |
SA#89-e |
SP-200708 |
0024 |
1 |
F |
Corrections to AKMA key lifetimes |
16.1.0 |
|
2020-09 |
SA#89-e |
SP-200708 |
0025 |
1 |
F |
Corrections and clarifications to AKMA procedures |
16.1.0 |
|
2020-09 |
SA#89-e |
SP-200708 |
0026 |
1 |
F |
Assignment of FC values for key derivations |
16.1.0 |
|
2020-09 |
SA#89-e |
SP-200708 |
0027 |
– |
F |
Specification of value of SUPI for key derivations |
16.1.0 |
|
2020-09 |
SA#89-e |
SP-200708 |
0032 |
1 |
F |
AKMA SBA interface clarifications |
16.1.0 |
|
2020-09 |
SA#89-e |
SP-200708 |
0034 |
1 |
F |
Several clarifications and editorials |
16.1.0 |
|
2020-12 |
SA#90e |
SP-201006 |
0043 |
– |
F |
Lifetime of KAF expiration |
16.2.0 |
|
2020-12 |
SA#90e |
SP-201006 |
0045 |
– |
F |
Corrections of clause 6.1 |
16.2.0 |
|
2020-12 |
SA#90e |
SP-201006 |
0046 |
– |
F |
Editorial modifications of AKMA |
16.2.0 |
|
2020-12 |
SA#90e |
SP-201006 |
0053 |
1 |
F |
Update of the reference point interface names of AKMA |
16.2.0 |
|
2020-12 |
SA#90e |
SP-201006 |
0047 |
– |
F |
Adding details of AKMA application key generation in the UE |
17.0.0 |
|
2021-03 |
SA#91e |
SP-210118 |
0055 |
1 |
B |
AAnF checks AKMA service for UE and AF in clause 6.3 |
17.1.0 |
|
2021-03 |
SA#91e |
SP-210118 |
0056 |
1 |
B |
Add AAnF selection function to AF |
17.1.0 |
|
2021-03 |
SA#91e |
SP-210118 |
0057 |
1 |
B |
Add Application Key Get service in clause 7.1 |
17.1.0 |
|
2021-03 |
SA#91e |
SP-210118 |
0060 |
1 |
F |
KAF lifetime expiration in clause 5.2 |
17.1.0 |
|
2021-03 |
SA#91e |
SP-210118 |
0062 |
1 |
F |
Clarification on A-KID generation |
17.1.0 |
|
2021-06 |
SA#92e |
SP-210438 |
0066 |
2 |
B |
Profiling the GBA TLS protocols for use with AKMA |
17.2.0 |
|
2021-06 |
SA#92e |
SP-210436 |
0072 |
1 |
F |
AAnF AKMA context removal |
17.2.0 |
|
2021-06 |
SA#92e |
SP-210436 |
0075 |
1 |
D |
Add an abbreviation to AKMA |
17.2.0 |
|
2021-06 |
SA#92e |
SP-210436 |
0076 |
1 |
F |
Clarification on AAnF Selection |
17.2.0 |
|
2021-06 |
SA#92e |
SP-210436 |
0077 |
– |
F |
Editoral Change |
17.2.0 |
|
2021-06 |
SA#92e |
SP-210436 |
0079 |
1 |
F |
AKMA Anchor Function selection clause |
17.2.0 |
|
2021-06 |
SA#92e |
SP-210436 |
0081 |
1 |
F |
AKMA UE aspects |
17.2.0 |
|
2021-06 |
SA#92e |
Correcting implementation error for CR0076 |
17.2.1 |
||||
|
2021-09 |
SA#93e |
SP-210842 |
0088 |
– |
F |
Update clause 6.1 about Routing identifier |
17.3.0 |
|
2021-09 |
SA#93e |
SP-210841 |
0090 |
1 |
F |
Add step 4 in annex B.1.2.2 |
17.3.0 |
|
2021-09 |
SA#93e |
SP-210842 |
0093 |
1 |
F |
Clarification on AAnF selection in clause 6.3 |
17.3.0 |
|
2021-12 |
SA#94e |
SP-211374 |
0098 |
1 |
F |
Corrections to the TLS with AKMA specification |
17.4.0 |
|
2021-12 |
SA#94e |
SP-211374 |
0099 |
1 |
B |
Adding TLS 1.3 with AKMA keys |
17.4.0 |
|
2021-12 |
SA#94e |
SP-211373 |
0101 |
– |
F |
Clarification on Kaf lifetime in Clause 5.2 |
17.4.0 |
|
2021-12 |
SA#94e |
SP-211374 |
0103 |
1 |
F |
Delete the GBA_Digest in annex B.1.2.2 |
17.4.0 |
|
2021-12 |
SA#94e |
SP-211373 |
0104 |
1 |
F |
Clean up for clause 6.6.1 |
17.4.0 |
|
2021-12 |
SA#94e |
SP-211373 |
0108 |
– |
F |
Sending UE ID to the AKMA AF |
17.4.0 |
|
2022-03 |
SA#95e |
SP-220207 |
0115 |
1 |
F |
Add a Note about the Kaf refresh |
17.5.0 |
|
2022-03 |
SA#95e |
SP-220207 |
0116 |
– |
F |
Add function description about AAnF in 4.2.1 |
17.5.0 |
|
2022-03 |
SA#95e |
SP-220207 |
0121 |
1 |
B |
New AAnF application key get service without SUPI |
17.5.0 |
|
2022-03 |
SA#95e |
SP-220207 |
0122 |
1 |
B |
Clarification on indication to UE when KAF is expired |
17.5.0 |
|
2022-03 |
SA#95e |
SP-220207 |
0123 |
– |
D |
Clean up for TS 33.535 |
17.5.0 |
|
2022-03 |
SA#95e |
SP-220208 |
0124 |
1 |
F |
Adding text on preferring AKMA keys to GBA Digest |
17.5.0 |
|
2022-06 |
SA#95e |
SP-220545 |
0125 |
– |
F |
Aligning text for AKMA procedure |
17.6.0 |
|
2022-06 |
SA#95e |
SP-220544 |
0126 |
1 |
F |
Clarification on anonymization api |
17.6.0 |
|
2022-06 |
SA#95e |
SP-220545 |
0127 |
1 |
F |
Correct AAnF service in clause 6.3 |
17.6.0 |
|
2022-06 |
SA#95e |
SP-220545 |
0128 |
1 |
F |
NF selects AAnF in clause 6.7 |
17.6.0 |
|
2022-06 |
SA#95e |
SP-220545 |
0129 |
1 |
F |
Clarification on the description about AAnF |
17.6.0 |
|
2022-09 |
SA#97e |
SP-220883 |
0132 |
1 |
F |
Add ApplicationKey_ AnonUser_Get into table 7.1.1-1 |
17.7.0 |
|
2022-09 |
SA#97e |
SP-220883 |
0137 |
– |
F |
A few clarifications to TS 33.535 |
17.7.0 |