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 clause A.2 of TS 33.402 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 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.

  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 distinguisher (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.

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. As N5CW devices do not support NAS over non-3GPP access, the Uplink NAS COUNT shall be set to 0 for KTWIF key generation, see clause 7A.2.4. Similarly, the AUN3 devices do not support NAS over non-3GPP access, the Uplink NAS COUNT shall be set to 0 for KWAGF key generation, see clause 7B.7.3.

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 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, i.e. UE parameters update list as given in clause 9.11.3.53A of TS 24.501 (starting from octet 23),
• 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.

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