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.
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.
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.
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).
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.
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.
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.
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.
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 |
0x0000 | Initial set of security features defined for 5GS. |
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-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
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.
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 access | 0x01 |
Non 3GPP access | 0x02 |
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.
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.
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).
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 |
IPSec | 0x01 |
TNAP | 0x02 |
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..