Tech-invite  3GPPspace  IETF RFCs  SIP
index  21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 33.501  Word version:  18.0.0

Top   Top   Up   Prev   Next
1…   4…   5…   6…   6.1.3…   6.1.4   6.2…   6.2.2…   6.3…   6.5…   6.7…   6.8…   6.9…   6.10…   6.12…   6.14   6.15   6.16   7…   7A…   7A.2.3…   7B…   8…   9…   10…   11…   13…   13.2.2…   13.2.4   13.3…   13.4…   14…   15…   A…   B…   C…   D…   G…   I…   J…   K…   O…   P…   S…   U…   X…   Y… 
A Key derivation functions  A.1 KDF interface and input parameter construction  A.2 KAUSF derivation function  A.3 CK' and IK' derivation function  A.4 RES* and XRES* derivation function  A.5 HRES* and HXRES* derivation function  A.6 KSEAF derivation function  A.7 KAMF derivation function  A.8 Algorithm key derivation functions  A.9 KgNB, KWAGF, KTNGF, KTWIF and KN3IWF derivation function  A.10 NH derivation function  A.11 KNG-RAN* derivation function for target gNB  A.12 KNG-RAN* derivation function for target ng-eNB  A.13 KAMF to KAMF' derivation in mobility  A.14 KAMF to KASME' derivation for interworking  A.15 KASME to KAMF' derivation for interworking  A.16 Derivation of KSN for dual connectivity  A.17 SoR-MAC-IAUSF generation function  A.18 SoR-MAC-IUE/SoR-XMAC-IUE generation function  A.19 UPU-MAC-IAUSF generation function  A.20 UPU-MAC-IUE/UPU-XMAC-IUE generation function  A.21 KAMF to KASME_SRVCC derivation for interworking  A.22 KTIPSec and KTNAP derivation function  A.23 KIAB generation function 
...

 

A (Normative)  Key derivation functions  p. 204

A.1  KDF interface and input parameter construction  p. 204

A.1.1  General  p. 204

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.
Up

A.1.2  FC value allocations  p. 204

The FC number space used is controlled by TS 33.220, FC values allocated for the present document are in range of 0x69 - 0x79, 0x7B - 0x7D and 0x83-0x84.

A.2  KAUSF derivation function  p. 204

This clause applies to 5G AKA only.
When deriving a KAUSF from CK, IK and the serving network name when producing authentication vectors, and when the UE computes KAUSF 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 24.501 [35]);
  • 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  p. 204

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 function  p. 205

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  p. 205

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  KSEAF derivation function  p. 205

When deriving a KSEAF from KAUSF, 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 KAUSF.
The serving network name shall be constructed as specified in clause 6.1.1.4.
Up

A.7  KAMF derivation function  p. 206

A.7.0  Parameters for the input S to the KDF  p. 206

When deriving a KAMF from KSEAF 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 KSEAF.
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 clause 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  p. 206

ABBA parameter is provided to the UE from SEAF and shall be used as an input parameter for KAMF 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 KAMF.
The following values have been defined for this parameter.
ABBA parameter value Description
0x0000Initial set of security features defined for 5GS.
Up

A.8  Algorithm key derivation functions  p. 206

When deriving keys for NAS integrity and NAS encryption algorithms from KAMF in the AMF and UE or ciphering and integrity keys from KgNB/ 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-alg0x01
N-NAS-int-alg0x02
N-RRC-enc-alg0x03
N-RRC-int-alg0x04
N-UP-enc-alg0x05
N-UP-int-alg0x06
 
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 KgNB/ KSN. For the derivation of integrity and ciphering keys used between the UE and AMF, the input key shall be the 256-bit KAMF.
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  KgNB, KWAGF, KTNGF, KTWIF and KN3IWF derivation function  p. 207

When deriving the keys KgNB, KWAGF, KTNGF, KTWIF and KN3IWF from KAMF 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 KgNB. The access type distinguisher shall be set to the value for non-3GPP (0x02) when deriving KN3IWF, KWAGF, KTWIF or KTNGF.
Access type distinguisher Value
3GPP access0x01
Non 3GPP access0x02
 
The input key KEY shall be the 256-bit KAMF.
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 function  p. 208

When deriving a NH from KAMF 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 KgNB 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 KAMF.
Up

A.11  KNG-RAN* derivation function for target gNB  p. 208

When deriving a KNG-RAN* from current KgNB 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 KgNB(when source is gNB) or KeNB (when source is ng-eNB).
Up

A.12  KNG-RAN* derivation function for target ng-eNB  p. 208

When deriving a KNG-RAN* from current KgNB 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 KgNB (when source is gNB) or KeNB (when source is ng-eNB).
Up

A.13  KAMF to KAMF' derivation in mobility  p. 209

Derivation of KAMF' from KAMF 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 KAMF.
When KAMF' is derived in handover, DIRECTION shall be 0x01 and COUNT shall be the downlink NAS COUNT of the 3GPP access.
When KAMF' 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  KAMF to KASME' derivation for interworking  p. 209

A.14.1  Idle mode mobility  p. 209

This input string is used when there is a need to derive KASME' from KAMF 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 KAMF.

A.14.2  Handover  p. 209

This input string is used when there is a need to derive KASME' from KAMF 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 KAMF.

A.15  KASME to KAMF' derivation for interworking  p. 209

A.15.1  Idle mode mobility  p. 209

This input string is used when there is a need to derive KAMF' from KASME 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 of the TAU message included in the Registration Request message
  • L0 = length of NAS Uplink COUNT value of the TAU message included in the Registration Request message (i.e. 0x00 0x04)
The input key KEY shall be KASME.
Up

A.15.2  Handover  p. 210

This input string is used when there is a need to derive KAMF' from KASME 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 KASME.

A.16  Derivation of KSN for dual connectivity  p. 210

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 KeNB when the MN is an ng-eNB and KgNB when the MN is a gNB.

A.17  SoR-MAC-IAUSF generation function  p. 210

When deriving a SoR-MAC-IAUSF from KAUSF, 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 = octets included in SoR transparent container (in clause 9.11.3.51 of TS 24.501) beyond (and not including) octet 22,
  • L2 = length of list data included in P2
The input key KEY shall be KAUSF.
The selection of parameters included in P2 shall be the same as the selection of input to the Nausf_SoRProtection service operation. If none of these parameters are included in Nausf_SoRProtection service operation, P2 and L2 are not included for SoR-MAC-IAUSF generation.
The SOR header is either received from the requester NF (e.g UDM), or constructed by the AUSF, as described in clause 9.11.3.51 of TS 24.501, based on the information received from the requester NF (e.g. UDM), i.e. ACK Indication and List of preferred PLMN/access technology combinations or secured packet (if provided).
The SoR-MAC-IAUSF is identified with the 128 least significant bits of the output of the KDF.
Up

A.18  SoR-MAC-IUE/SoR-XMAC-IUE generation function  p. 211

When deriving a SoR-MAC-IUE / SoR-MAC-IIUE from KAUSF, the following parameters shall be used to form the input S to the KDF.
  • FC = 0x78,
  • P0 = 0x01 (SoR Acknowledgement: Verified the Steering of Roaming Information successfully),
  • L0 = length of SoR Acknowledgement (i.e. 0x00 0x01),
  • P1 = CounterSoR,
  • L1 = length of CounterSoR.
The input key KEY shall be KAUSF.
The SoR-MAC-IUE / SoR-MAC-IIUE is identified with the 128 least significant bits of the output of the KDF.
Up

A.19  UPU-MAC-IAUSF generation function  p. 211

When deriving a UPU-MAC-IAUSF from KAUSF, 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 KAUSF.
The UPU-MAC-IAUSF is identified with the 128 least significant bits of the output of the KDF.
Up

A.20  UPU-MAC-IUE/UPU-XMAC-IUE generation function  p. 211

When deriving a UPU-MAC-IUE / UPU-MAC-IIUE from KAUSF, 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 KAUSF.
The UPU-MAC-IUE / UPU-MAC-IIUE is identified with the 128 least significant bits of the output of the KDF.
Up

A.21  KAMF to KASME_SRVCC derivation for interworking |R16|  p. 212

This input string is used when there is a need to derive KASME_SRVCC from KAMF 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 KAMF.

A.22  KTIPSec and KTNAP derivation function |R16|  p. 212

When deriving a KTIPSec from KTNGF and when deriving a KTNAP from KTWIF or KTNGF the following parameters shall be used to form the input S to the KDF.
  • FC = 0x84
  • P0 = Usage type distinguisher
  • L0 = length of Usage type distinguisher (i.e. 0x00 0x01)
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 KTIPSec. The Usage type distinguisher shall be set to the value for TNAP (0x02) when deriving KTNAP.
The input key KEY shall be the 256-bit KTNGF or KTWIF.
Usage type distinguisher Value
IPSec0x01
TNAP0x02
Up

A.23  KIAB generation function |R16|  p. 212

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 = 0x83,
  • 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 KgNB, if the key KgNB is in possession of the IAB-UE functionality in the IAB-node and in the IAB-donor-CU (also when acts as MN for NR-DC scenario), after the IAB-UE setup procedure (Phase-1).
The input key KEY shall be S-KgNB, if the key S-KgNB is in possession of the IAB-UE functionality in the IAB-node and in the IAB-donor-CU (acts as a SN for EN-DC scenario), after dual connectivity procedure.
The input key KEY shall be KSN, if the key KSN is in possession of the IAB-UE functionality in the IAB-node and in the IAB-donor-CU (acts as a SN for NR-DC scenario), after dual connectivity procedure.
For P0, in case of CP-UP separation of IAB-donor-CU,
  • P0 shall be set to IAB-donor-CU-CP IP address for deriving KIAB-CU-CP.
  • P0 shall be set to IAB-donor-CU-UP IP address for deriving KIAB-CU-UP.
The entire output of the KDF (256 bits) is used as the KIAB or KIAB-CU-CP or KIAB-CU-UP..
Up

Up   Top   ToC