Content for  TS 33.501  Word version:  18.3.0

  Figure 6.2.2-1 shows the dependencies between the different keys, and how they are derived from the network nodes point of view.

For every key in a network entity, there is a corresponding key in the UE. Figure 6.2.2-2 shows the corresponding relations and derivations as performed in the UE.

The USIM shall store the same long-term key K that is stored in the ARPF. During an authentication and key agreement procedure, the USIM shall generate key material from K that it forwards to the ME. If provisioned by the home operator, the USIM shall store the Home Network Public Key used for concealing the SUPI. The ME shall generate the KAUSF from the CK, IK received from the USIM. The generation of this key material is specific to the authentication method and is specified in clause 6.1.3. When 5G AKA is used, the generation of RES* from RES shall be performed by the ME. The UE shall store the latest KAUSF or replace the old KAUSF with the latest KAUSF, after successful completion of the latest primary authentication . If the USIM supports 5G parameters storage, KAUSF shall be stored in the USIM. Otherwise, KAUSF shall be stored in the non-volatile memory of the ME. In case 5G AKA is used as an authentication method, upon receiving the valid NAS Security Mode Command message from the AMF (to take the corresponding partial context derived from the newly generated KAUSF into use), the UE shall consider the performed primary authentication as successful and the UE shall store the newly generated KAUSF as the latest KAUSF or replace the old KAUSF with the latest KAUSF. In case of any key generating EAP method in the present document (EAP-AKA', EAP-TLS in Annex B, EAP methods in Annex I) is used as the authentication method for the primary (re)authentication, upon receiving the EAP-Success message, the primary authentication shall be considered as successful and the UE shall store the newly generated KAUSF as the latest KAUSF or replace the old KAUSF with the latest KAUSF. The ME shall perform the generation of KSEAF from the KAUSF. If the USIM supports 5G parameters storage, KSEAF shall be stored in the USIM. Otherwise, KSEAF shall be stored in the non-volatile memory of the ME. The ME shall perform the generation of KAMF. If the USIM supports 5G parameters storage, KAMF shall be stored in the USIM. Otherwise, KAMF shall be stored in the non-volatile memory of the ME. The ME shall perform the generation of all other subsequent keys that are derived from the KAMF. Any 5G security context, KAUSF and KSEAF that are stored at the ME shall be deleted from the ME if:

1. the USIM is removed from the ME when the ME is in power on state;
2. the ME is powered up and the ME discovers that the USIM is different from the one which was used to create the 5G security context;
3. the ME is powered up and the ME discovers that there is no USIM is present at the ME.

Key setting happens at the end of successful authentication procedure. Authentication and key setting may be initiated by the network as often as the network operator wishes when an active NAS connection exists. Key setting can occur as soon as the identity of the mobile subscriber (i.e. 5G-GUTI or SUPI) is known by the AMF. A successful run of 5G AKA or EAP AKA' results in a new KAMF that is stored in the UE and the AMF with a new partial, non-current security context. NAS keys (i.e. KNASint and KNASenc) and AS keys (i.e. KgNB, KRRCenc, KRRCint, KUPenc, KUPint) are derived from KAMF using the KDFs specified in Annex A. The NAS keys derived from the new KAMF are taken in use in the AMF and the UE by means of the NAS security mode command procedure (see subclause 6.7.2). The AS keys are taken into use with the AS security mode command procedure (see subclause 6.7.4) or with the key change on the fly procedure (see subclause 6.9.6). For the non-3GPP access, the key KN3IWF is derived from the KAMF. KN3IWF is stored in the UE and the N3IWF as specified in subclause 7.2.1. This key KN3IWF and the IPsec SA cryptographic keys are taken into use with the establishment of IPsec Security Association (SA) between the UE and the N3IWF.

The key KAMF shall be identified by the key set identifier ngKSI. ngKSI may be either of type native or of type mapped. An ngKSI shall be stored in the UE and the AMF together with KAMF and the temporary identifier 5G-GUTI, if available. A native ngKSI is associated with the KSEAF and KAMF derived during primary authentication. It is allocated by the SEAF and sent with the authentication request message to the UE where it is stored together with the KAMF. The purpose of the ngKSI is to make it possible for the UE and the AMF to identify a native security context without invoking the authentication procedure. This is used to allow re-use of the native security context during subsequent connection set-ups. A mapped ngKSI is associated with the KAMF derived from EPS keys during interworking, cf. clause 8 of the present document. It is generated in both the UE and the AMF respectively when deriving the mapped KAMF when moving from EPS to 5GS. The mapped ngKSI is stored together with the mapped KAMF. The purpose of the mapped ngKSI is to make it possible for the UE and the AMF to indicate the use of the mapped KAMF in interworking procedures (for details cf. clause 8). The format of ngKSI shall allow a recipient of such a parameter to distinguish whether the parameter is of type native or of type mapped. The format shall contain a type field and a value field. The type field indicates the type of the key set. The value field consists of three bits where seven values, excluding the value '111', are used to identify the key set. The value '111' is reserved to be used by the UE to indicate that a valid KAMF is not available for use. The format of ngKSI is described in TS 24.501 KNASenc and KNASint in the key hierarchy specified in clause 6.2.1, which are derived from KAMF, can be uniquely identified by ngKSI together with those parameters from the set {algorithm distinguisher, algorithm identifier}, which are used to derive these keys from KAMF. The KN3IWF can be uniquely determined by ngKSI together with the uplink NAS COUNT are used to derive it according to clause A.9. The initial KgNB can be uniquely determined by ngKSI, together with the uplink NAS COUNT are used to derive it according to clause A.9. The intermediate key NH as defined in clause 6.9.2.1.1 can be uniquely determined by ngKSI, together with the initial KgNB derived from the current 5G NAS security context for use during the ongoing CM-CONNECTED state and a counter counting how many NH-derivations have already been performed from this initial KgNB according to clause A.10. The next hop chaining counter, NCC, represents the 3 least significant bits of this counter. Intermediate key KNG-RAN*, as well as non-initial KgNB, defined in clause 6.9.2.1.1 can be uniquely identified by ngKSI together with those parameters from the set {KgNB or NH, sequence of PCIs and ARFCN-DLs}, which are used to derive these keys from KgNB or NH. KRRCint, KRRCenc, KUPint, and KUPenc in the key hierarchy specified in clause 6.2.1 can be uniquely identified by ngKSI together with those parameters from the set {algorithm distinguisher, algorithm identifier}, which are used to derive these keys from KgNB.

KAUSF, and KSEAF shall be created when running a successful primary authentication as described in clause 6.1.3. KAMF shall be created in the following cases:

1. Primary authentication
2. NAS key re-keying as described in clause 6.9.4.2
3. NAS key refresh as described in clause 6.9.4.3
4. Interworking procedures with EPS (cf. clause 8 and clause 10)

In case the UE does not have a valid KAMF, an ngKSI with value "111" shall be sent by the UE to the network, which can initiate (re)authentication procedure to get a new KAMF based on a successful primary authentication. KNASint and KNASenc are derived based on a KAMF when running a successful NAS SMC procedure as described in clause 6.7.2. KN3IWF is derived from KAMF and remains valid as long as the UE is connected to the 5GC over non- 3gpp access or until the UE is reauthenticated. KgNB and NH are derived based on KAMF or KgNB or NH in the following cases:

1. Inter-gNB-CU-handover as described in clause 6.9.2.3.1
2. State transitions as described in clause 6.8
3. AS key re-keying as described in clause 6.9.4.4
4. AS key refresh as described in clause 6.9.4.5

The KRRCint, KRRCenc, KUPint and KUPenc are derived based on KgNB after a new KgNB is derived.