Section: 6.2.3.2 Key identification
Content: 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. NOTE 1: The 5G-GUTI points to the AMF where the KAMF is stored. 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 [35] 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. NOTE 2: In addition to 5G security contexts, the UE may also cache EPS security contexts. These EPS security contexts are identified by the eKSI, as defined in TS 33.401[ 3GPP System Architecture Evolution (SAE); Security architecture ]  [10].