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:
-
Primary authentication
-
NAS key re-keying as described in clause 6.9.4.2
-
NAS key refresh as described in clause 6.9.4.3
-
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:
-
Inter-gNB-CU-handover as described in clause 6.9.2.3.1
-
State transitions as described in clause 6.8
-
AS key re-keying as described in clause 6.9.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.