Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 33.501  Word version:  18.0.0

Top   Top   Up   Prev   Next
1…   4…   5…   6…   6.1.3…   6.1.4   6.2…   6.2.2…   6.3…   6.5…   6.7…   6.8…   6.9…   6.10…   6.12…   6.14   6.15   6.16   7…   7A…   7A.2.3…   7B…   8…   9…   10…   11…   13…   13.2.2…   13.2.4   13.3…   13.4…   14…   15…   A…   B…   C…   D…   G…   I…   J…   K…   O…   P…   S…   U…   X…   Y…

 

6.2.2  Key derivation and distribution schemep. 54

6.2.2.1  Keys in network entitiesp. 54

Keys in the ARPF
The ARPF shall process the long-term key K and any other sensitive data only in its secure environment. The key K shall be 128 bits or 256 bits long.
During an authentication and key agreement procedure, the ARPF shall derive CK' and IK' from K in case EAP-AKA' is used and derive KAUSF from K in case 5G AKA is used. The ARPF shall forward the derived keys to the AUSF.
The ARPF holds the Home Network Private Key that is used by the SIDF to deconceal the SUCI and reconstruct the SUPI. The generation and storage of this key material is out of scope of the present document.
Keys in the AUSF
In case EAP-AKA' is used as authentication method, the AUSF shall derive a key KAUSF from CK' and IK' for EAP-AKA' as specified in clause 6.1.3.1. In case that 5G AKA is used as authentication method, the UDM/ARPF shall generate the KAUSF as specified in clause 6.1.3.2.
The KAUSF may be stored in the AUSF between two subsequent authentication and key agreement procedures.
When the AUSF stores the KAUSF, the AUSF shall store the latest KAUSF generated after successful completion of the latest primary authentication. The authentication is considered as successful and the AUSF shall store the latest KAUSF or replace the old KAUSF with the new KAUSF (if the AMF(s) end up selecting the same AUSF instance for (re)authentication of the UE):
  • in case 5G AKA is used as authentication method, when the RES* and the XRES* are equal (see clause 6.1.3.2.0, Step 11).
  • in case EAP-AKA' is used as authentication method, when the AUSF sends an EAP-Success message to the SEAF (see clause 6.1.3.1, Step 10).
The AUSF shall generate the anchor key, also called KSEAF, from the authentication key material received from the ARPF during an authentication and key agreement procedure.
Keys in the SEAF
The SEAF receives the anchor key, KSEAF, from the AUSF upon a successful primary authentication procedure in each serving network.
The SEAF shall never transfer KSEAF to an entity outside the SEAF. Once KAMF is derived KSEAF shall be deleted.
The SEAF shall generate KAMF from KSEAF immediately following the authentication and key agreement procedure and hands it to the AMF.
Keys in the AMF
The AMF receives KAMF from the SEAF or from another AMF.
The AMF shall, based on policy, derive a key KAMF' from KAMF for transfer to another AMF in inter-AMF mobility. The receiving AMF shall use K'AMF as its key KAMF.
The AMF shall generate keys KNASint and KNASenc dedicated to protecting the NAS layer.
The AMF shall generate access network specific keys from KAMF. In particular,
  • the AMF shall generate KgNB and transfer it to the gNB.
  • the AMF shall generate NH and transfer it to the gNB, together with the corresponding NCC value.
    The AMF may also transfer an NH key, together with the corresponding NCC value, to another AMF, cf. clause 6.9.
  • the AMF shall generate KN3IWF and transfer it to the N3IWF when KAMF is received from SEAF, or when KAMF' is received from another AMF.
Keys in the NG-RAN
The NG-RAN (i.e., gNB or ng-eNB) receives KgNB and NH from the AMF. The ng-eNB uses KgNB as KeNB.
The NG-RAN (i.e., gNB or ng-eNB) shall generate all further access stratum (AS) keys from KgNB and /or NH.
Keys in the N3IWF
The N3IWF receives KN3IWF from the AMF.
The N3IWF shall use KN3IWF as the key MSK for IKEv2 between UE and N3IWF in the procedures for untrusted non-3GPP access, cf. clause 11.
 
Figure 6.2.2-1 shows the dependencies between the different keys, and how they are derived from the network nodes point of view.
Reproduction of 3GPP TS 33.501, Fig. 6.2.2-1: Key distribution and key derivation scheme for 5G for network nodes
Up

6.2.2.2  Keys in the UEp. 56

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.
Reproduction of 3GPP TS 33.501, Fig. 6.2.2-2: Key distribution and key derivation scheme for 5G for the UE
Up
Keys in the USIM
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.
Keys in the ME
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.
Up

6.2.3  Handling of user-related keysp. 58

6.2.3.1  Key settingp. 58

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

6.2.3.2  Key identificationp. 58

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

6.2.3.3  Key lifetimesp. 59

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

Up   Top   ToC