Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 33.501  Word version:  16.3.0

Top   Top   Up   Prev   Next
1…   4…   5…   6…   6.2…   6.3…   6.5…   6.8…   6.9…   6.10…   6.12…   6.14   6.15   6.16   7…   7A…   7B…   8…   9…   10…   11…   13…   13.3…   13.4…   14…   15…   A…   B…   C…   D…   G…   K…   O…

 

A (Normative)  Key derivation functionsWord‑p. 192

A.1  KDF interface and input parameter construction

A.1.1  General

All key derivations (including input parameter encoding) for 5GC shall be performed using the key derivation function (KDF) specified in Annex B.2.0 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

The FC number space used is controlled by TS 33.220, FC values allocated for the present document are in range of 0x69 - 0x76.

A.2  K AUSF derivation function

This clause applies to 5G AKA only.
When deriving a K AUSF from CK, IK and the serving network name when producing authentication vectors, and when the UE computes K AUSF during 5G AKA, the following parameters shall be used to form the input S to the KDF:
  • FC = 0x6A;
  • P0 = serving network name;
  • L0 = length of the serving network name (variable length as specified in TS 24.501);
  • P1 = SQN ⊕ AK,
  • L1 = length of SQN ⊕ AK (i.e. 0x00 0x06).
The XOR of the Sequence Number (SQN) and the Anonymity Key (AK) is sent to the UE as a part of the Authentication Token (AUTN), see TS 33.102. If AK is not used, AK shall be treated in accordance with TS 33.102, i.e. as 000…0.
The serving network name shall be constructed as specified in clause 6.1.1.4.
The input key KEY shall be equal to the concatenation CK || IK of CK and IK.
Up

A.3  CK' and IK' derivation function

When deriving CK' and IK' then the KDF of TS 33.402 clause A.2 shall be used with the following exception: the serving network name (specified in clause 6.1.1.4) shall be used as the value of access network identity (P0).

A.4  RES* and XRES* derivation functionWord‑p. 193
When deriving RES* from RES, RAND, and serving network name in the UE and when deriving XRES* from XRES, RAND, and the serving network name in the ARPF, the following parameters shall be used to form the input S to the KDF.
  • FC = 0x6B,
  • P0 = serving network name,
  • L0 = length of the serving network name (variable length as specified in 24.501 [35]),
  • P1 = RAND,
  • L1 = length of RAND (i.e. 0x00 0x10),
  • P2 = RES or XRES,
  • L2 = length RES or XRES (i.e. variable length between 0x00 0x04 and 0x00 0x10).
The input key KEY shall be equal to the concatenation CK || IK of CK and IK.
The serving network name shall be constructed as specified in clause 6.1.1.4.
The (X)RES* is identified with the 128 least significant bits of the output of the KDF.
Up

A.5  HRES* and HXRES* derivation function

When deriving HRES* from RES* in the SEAF and when deriving HXRES* from XRES* in the AUSF the following parameters shall be used to form the input S to the SHA-256 hashing algorithm:
  • P0 = RAND,
  • P1 = RES* or XRES*,
The input S shall be equal to the concatenation P0||P1 of the P0 and P1.
The H(X)RES* is identified with the 128 least significant bits of the output of the SHA-256 function.

A.6  K SEAF derivation function

When deriving a K SEAF from K AUSF, the following parameters shall be used to form the input S to the KDF:
  • FC = 0x6C,
  • P0 = <serving network name>,
  • L0 = length of <serving network name>.
The input key KEY shall be K AUSF.
The serving network name shall be constructed as specified in clause 6.1.1.4.

A.7  K AMF derivation functionWord‑p. 194

A.7.0  Parameters for the input S to the KDF

When deriving a K AMF from K SEAF the following parameters shall be used to form the input S to the KDF.
  • FC = 0x6D
  • P0 = IMSI or NAI or GCI or GLI
  • L0 = P0 length - number of octets in P0
  • P1 = ABBA parameter
  • L1 = P1 length - number of octets in P1
The input key KEY shall be the 256-bit K SEAF.
For P0, when the SUPI type is IMSI, P0 shall be set to IMSI as defined in clause 2.2 of TS 23.003. For P0, when the SUPI type is network specific identifier, the P0 shall be set to Network Access Identifier (NAI) as defined in clause 28.7.2 of TS 23.003. When the SUPI type is GLI, P0 shall be set to GLI taking format of NAIas defined in clause 28.15.2 of TS 23.003. When the SUPI type is GCI, P0 shall be set to GLI taking format of NAIas defined in clause 28.16.2 of TS 23.003. P0 shall be represented as a character string as specified in B.2.1.2 of TS 33.220, for both SUPI types.
For ABBA parameter values please refer to clause A.7.1.
Up

A.7.1  ABBA parameter values

ABBA parameter is provided to the UE from SEAF and shall be used as an input parameter for K AMF derivation. To support flexible set of security features ABBA parameter is defined when security features change. To ensure forward compatibility, the ABBA parameter is a variable length parameter.
The SEAF shall set the ABBA parameter to 0x0000. The UE shall use the ABBA parameter provided by the SEAF in the calculation of K AMF.
The following values have been defined for this parameter.
ABBA parameter value
Description

0x0000
Initial set of security features defined for 5GS.

Up

A.8  Algorithm key derivation functions

When deriving keys for NAS integrity and NAS encryption algorithms from K AMF in the AMF and UE or ciphering and integrity keys from K gNB/ KSN in the gNB and UE, the following parameters shall be used to form the string S.
  • FC = 0x69
  • P0 = algorithm type distinguisher
  • L0 = length of algorithm type distinguisher (i.e. 0x00 0x01)
  • P1 = algorithm identity
  • L1 = length of algorithm identity (i.e. 0x00 0x01)
The algorithm type distinguisher shall be N-NAS-enc-alg for NAS encryption algorithms and N-NAS-int-alg for NAS integrity protection algorithms. The algorithm type distinguisher shall be N-RRC-enc-alg for RRC encryption algorithms, N-RRC-int-alg for RRC integrity protection algorithms, N-UP-enc-alg for UP encryption algorithms and N-UP-int-alg for UP integrity protection algorithms (see Table A.8-1). The values 0x00 and 0x07 to 0xf0 are reserved for future use, and the values 0xf1 to 0xff are reserved for private use.
Algorithm distinguisher
Value

N-NAS-enc-alg
0x01
N-NAS-int-alg
0x02
N-RRC-enc-alg
0x03
N-RRC-int-alg
0x04
N-UP-enc-alg
0x05
N-UP-int-alg
0x06

The algorithm identity (as specified in clause 5) shall be put in the four least significant bits of the octet. The two least significant bits of the four most significant bits are reserved for future use, and the two most significant bits of the most significant nibble are reserved for private use. The entire four most significant bits shall be set to all zeros.
For the derivation of integrity and ciphering keys used between the UE and gNB, the input key shall be the 256-bit K gNB// KSN. For the derivation of integrity and ciphering keys used between the UE and AMF, the input key shall be the 256-bit K AMF.
For an algorithm key of length n bits, where n is less or equal to 256, the n least significant bits of the 256 bits of the KDF output shall be used as the algorithm key.
Up

A.9  K gNB, K WAGF, K TNGF, K TWIF and K N3IWF derivation functionWord‑p. 195
When deriving the keys K gNB, K WAGF, K TNGF, K TWIF and K N3IWF from K AMF and the uplink NAS COUNT in the UE and the AMF the following parameters shall be used to form the input S to the KDF.
  • FC = 0x6E
  • P0 = Uplink NAS COUNT
  • L0 = length of uplink NAS COUNT (i.e. 0x00 0x04)
  • P1 = Access type distinguisher
  • L1 = length of Access type distiguisher (i.e. 0x00 0x01)
The values for the access type distinguisher are defined in table A.9-1. The values 0x00 and 0x03 to 0xf0 are reserved for future use, and the values 0xf1 to 0xff are reserved for private use.
The access type distinguisher shall be set to the value for 3GPP (0x01) when deriving K gNB. The access type distinguisher shall be set to the value for non-3GPP (0x02) when deriving K N3IWF, K WAGF, K TWIF or K TNGF..
Access type distinguisher
Value

3GPP access
0x01
Non 3GPP access
0x02

The input key KEY shall be the 256-bit K AMF.
This function is applied when cryptographically protected 5G radio bearers are established and when a key change on-the-fly is performed.
Up

A.10  NH derivation functionWord‑p. 196
When deriving a NH from K AMF the following parameters shall be used to form the input S to the KDF.
  • FC = 0x6F
  • P0 = SYNC-input
  • L0 = length of SYNC-input (i.e. 0x00 0x20)
The SYNC-input parameter shall be the newly derived K gNB for the initial NH derivation, and the previous NH for all subsequent derivations. This results in a NH chain, where the next NH is always fresh and derived from the previous NH.
The input key KEY shall be the 256-bit K AMF.
Up

A.11  K NG-RAN* derivation function for target gNB

When deriving a K NG-RAN* from current K gNB or from fresh NH and the target physical cell ID in the UE and NG-RAN for handover purposes and transition from RRC_INACTIVE to RRC_CONNECTED states the following parameters shall be used to form the input S to the KDF.
  • FC = 0x70
  • P0 = PCI (target physical cell id)
  • L0 = length of PCI (i.e. 0x00 0x02)
  • P1 = ARFCN-DL (the absolute frequency of SSB of the target PCell as specified in clause 13.3 of TS 38.300)
  • L1 = length of ARFCN-DL (i.e. 0x00 0x03)
The input key KEY shall be the 256-bit NH when the index NCC in the handover increases, otherwise the current 256-bit K gNB(when source is gNB) or K eNB (when source is ng-eNB).
Up

A.12  K NG-RAN* derivation function for target ng-eNB

When deriving a K NG-RAN* from current K gNB or from fresh NH and the target physical cell ID in the UE and NG-RAN for handover purposes and transition from RRC_INACTIVE to RRC_CONNECTED states the following parameters shall be used to form the input S to the KDF.
  • FC = 0x71
  • P0 = PCI (target physical cell id)
  • L0 = length of PCI (i.e. 0x00 0x02)
  • P1 = EARFCN-DL (target physical cell downlink frequency)
  • L1 = length of EARFCN-DL (i.e. 0x00 0x03)
The input key KEY shall be the 256-bit NH when the index NCC in the handover increases, otherwise the current 256-bit K gNB (when source is gNB) or K eNB (when source is ng-eNB).
Up

A.13  K AMF to K AMF' derivation in mobilityWord‑p. 197
Derivation of K AMF' from K AMF during mobility shall use the following input parameters.
  • FC = 0x72
  • P0 = DIRECTION
  • L0 = length of DIRECTION (i.e. 0x00 0x01)
  • P1 = COUNT,
  • L1 = length of COUNT (i.e. 0x00 0x04)
The input key KEY shall be K AMF.
When K AMF' is derived in handover, DIRECTION shall be 0x01 and COUNT shall be the downlink NAS COUNT of the 3GPP access.
When K AMF' is derived in idle mode mobility (i.e., mobility registration update), DIRECTION shall be 0x00 and COUNT shall be the uplink NAS COUNT of the 3GPP access used in the Registration Request.
Up

A.14  K AMF to K ASME' derivation for interworking

A.14.1  Idle mode mobility

This input string is used when there is a need to derive K'ASME from K AMF during mapping of security contexts from 5G to EPS at idle mode mobility. The following input parameters shall be used.
  • FC = 0x73
  • P0 = NAS Uplink COUNT value
  • L0 = length of NAS Uplink COUNT value (i.e. 0x00 0x04)
The input key KEY shall be K AMF.

A.14.2  Handover

This input string is used when there is a need to derive K ASME' from K AMF during mapping of security contexts from 5G to EPS at handovers. The following input parameters shall be used.
  • FC = 0x74
  • P0 = NAS Downlink COUNT value
  • L0 = length of NAS Downlink COUNT value (i.e. 0x00 0x04)
The input key KEY shall be K AMF.

A.15  K ASME to K AMF' derivation for interworking

A.15.1  Idle mode mobility

This input string is used when there is a need to derive K AMF' from K ASME during mapping of security contexts from EPS to 5G at idle mode mobility. The following input parameters shall be used.
  • FC = 0x75
  • P0 = NAS Uplink COUNT value
  • L0 = length of NAS Uplink COUNT value (i.e. 0x00 0x04)
The input key KEY shall be K ASME.

A.15.2  HandoverWord‑p. 198
This input string is used when there is a need to derive K AMF' from K ASME during mapping of security contexts from EPS to 5G at handovers. The following input parameters shall be used.
  • FC = 0x76
  • P0 = NH value
  • L0 = length of NH value (i.e. 0x00 0x20)
The input key KEY shall be K ASME.

A.16  Derivation of KSN for dual connectivity

This input string is used when the MN and UE derive KSN during dual connectivity. The following input parameters shall be used:
  • FC =0x79,
  • P0 = Value of the SN Counter as a non-negative integer,
  • L0 = length of the SN Counter value (i.e. 0x00 0x02) .
The input key KEY shall be Kng-eNB when the MN is an ng-eNB and K gNB when the MN is a gNB.

A.17  SoR-MAC-IAUSF generation function

When deriving a SoR-MAC-IAUSF from K AUSF, the following parameters shall be used to form the input S to the KDF.
  • FC = 0x77,
  • P0 = SoR header,
  • L0 = length of SoR header,
  • P1 = CounterSoR,
  • L1 = length of CounterSoR,
  • P2 = PLMN ID and access technology list,
  • L2 = length of PLMN ID and access technology list.
The input key KEY shall be K AUSF.
PLMN ID and access technology list parameter is included for SoR-MAC-IAUSF generation only if the list input is included in the Nausf_SoRProtection service operation message, otherwise P2 and L2 are not included.
The SoR-MAC-IAUSF is identified with the 128 least significant bits of the output of the KDF.
Up

A.18  SoR-MAC-IUE generation functionWord‑p. 199
When deriving a SoR-MAC-IUE from K AUSF, the following parameters shall be used to form the input S to the KDF.
  • FC = 0x78,
  • P0 = 0x01 (SoR Acknowledgement: Verified the Steering Information List successfully),
  • L0 = length of SoR Acknowledgement (i.e. 0x00 0x01),
  • P1 = CounterSoR,
  • L1 = length of CounterSoR.
The input key KEY shall be K AUSF.
The SoR-MAC-IUE is identified with the 128 least significant bits of the output of the KDF.

A.19  UPU-MAC-IAUSF generation function

When deriving a UPU-MAC-IAUSF from K AUSF, the following parameters shall be used to form the input S to the KDF.
  • FC = 0x7B,
  • P0 = UE Parameters Update Data,
  • L0 = length of UE Parameters Update Data
  • P1 = CounterUPU
  • L1 = length of CounterUPU
The input key Key shall be K AUSF.
The UPU-MAC-IAUSF is identified with the 128 least significant bits of the output of the KDF.

A.20  UPU-MAC-IUE generation function

When deriving a UPU-MAC-IUE from K AUSF, the following parameters shall be used to form the input S to the KDF.
  • FC = 0x7C,
  • P0 = 0x01 (UPU Acknowledgement: Verified the UE Parameters Update Data successfully)
  • L0 = length of UPU Acknowledgement (i.e. 0x00 0x01)
  • P1 = CounterUPU
  • L1 = length of CounterUPU
The input key Key shall be K AUSF.
The UPU-MAC-IUE is identified with the 128 least significant bits of the output of the KDF.

A.21  K AMF to K ASME_SRVCC derivation for interworking |R16|

This input string is used when there is a need to derive K ASME_SRVCC from K AMF during SRVCC from 5G to UTRAN CS. The following input parameters shall be used.
  • FC = 0x7D
  • P0 = NAS Downlink COUNT value
  • L0 = length of NAS Downlink COUNT value (i.e. 0x00 0x04)
The input key KEY shall be K AMF.

A.22  K TIPSec and K TNAP derivation function |R16|Word‑p. 200
When deriving a K TIPSec from K TNGF and when deriving a K TNAP from K TNGF the following parameters shall be used to form the input S to the KDF.
  • FC = TBD
  • P0 = Usage type distinguisher
  • L0 = length of Usage type distinguisher (i.e. 0x00 0x01)
Editor's Note: The FC value needs to be specified.
The values for the Usage type distinguisher are defined in table A.22-1. The values 0x00 and 0x03 to 0xf0 are reserved for future use, and the values 0xf1 to 0xff are reserved for private use.
The Usage type distinguisher shall be set to the value for IPSec (0x01) when deriving K TIPSec. The Usage type distinguisher shall be set to the value for TNAP (0x02) when deriving K TNAP.
The input key KEY shall be the 256-bit K TNGF or K TWIF.
Usage type distinguisher
Value

IPSec
0x01
TNAP
0x02

Up

A.23  K IAB generation function |R16|

This input string is used when the IAB-node and the IAB-donor derive KIAB (PSK) for establishment of secure F1 interface. The following parameters shall be used to form the input S to the KDF:
  • FC = 0xaa,
  • P0 = IAB-donor-CU IP address,
  • L0 = length of IAB-donor-CU IP address,
  • P1 = IAB-node DU IP address,
  • L1 = length of IAB-node DU IP address.
The input key KEY shall be K gNB, if the key K gNB is in possession of the IAB-UE functionality in the IAB-node and in the IAB-donor-CU, after the IAB-UE setup procedure (Phase-1).
The input key KEY shall be S-K gNB, if the key S-K gNB is in possession of the IAB-UE functionality in the IAB-node and in the IAB-donor-CU, after dual connectivity procedure.
The entire output of the KDF (256 bits) is used as the KIAB.
Up

Up   Top   ToC