Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 33.501  Word version:  16.3.0

Top   Top   Up   Prev   Next
1…   4…   5…   6…   6.2…   6.3…   6.5…   6.8…   6.9…   6.10…   6.12…   6.14   6.15   6.16   7…   7A…   7B…   8…   9…   10…   11…   13…   13.3…   13.4…   14…   15…   A…   B…   C…   D…   G…   K…   O…

 

6.2  Key hierarchy, key derivation, and distribution schemeWord‑p. 48

6.2.1  Key hierarchy

Requirements on 5GC and NG-RAN related to keys are described in clause 5.1.3. The following describes the keys of the key hierarchy generation in a 5GS in detail.:
Reproduction of 3GPP TS 33.501, Figure 6.2.1-1: Key hierarchy generation in 5GS
Up
The keys related to authentication (see Figure 6.2.1-1) include the following keys: K, CK/IK. In case of EAP-AKA', the keys CK', IK' are derived from CK, IK as specified in clause 6.1.3.1.
The key hierarchy (see Figure 6.2.1-1) includes the following keys: K AUSF, K SEAF, K AMF, K NASint, K NASenc, K N3IWF, K gNB, K RRCint, K RRCenc, K UPint and K UPenc.
Keys for AUSF in home network:
  • K AUSF is a key derived
    • by ME and AUSF from CK', IK' in case of EAP-AKA', CK' and IK' is received by AUSF as a part of transformed AV from ARPF; or,
    • by ME and ARPF from CK, IK in case of 5G AKA, K AUSF is received by AUSF as a part of the 5G HE AV from ARPF.
  • K SEAF is an anchor key derived by ME and AUSF from K AUSF. K SEAF is provided by AUSF to the SEAF in the serving network.
Key for AMF in serving network:
  • K AMF is a key derived by ME and SEAF from K SEAF. K AMF is further derived by ME and source AMF when performing horizontal key derivation.
Keys for NAS signalling:
  • K NASint is a key derived by ME and AMF from K AMF, which shall only be used for the protection of NAS signalling with a particular integrity algorithm.
  • K NASenc is a key derived by ME and AMF from K AMF, which shall only be used for the protection of NAS signalling with a particular encryption algorithm.
Key for NG-RAN:
  • K gNB is a key derived by ME and AMF from K AMF. K gNB is further derived by ME and source gNB when performing horizontal or vertical key derivation. The K gNB is used as K eNB between ME and ng-eNB.
Keys for UP traffic:
  • K UPenc is a key derived by ME and gNB from K gNB, which shall only be used for the protection of UP traffic with a particular encryption algorithm.
  • K UPint is a key derived by ME and gNB from K gNB, which shall only be used for the protection of UP traffic between ME and gNB with a particular integrity algorithm.
Keys for RRC signalling:
  • K RRCint is a key derived by ME and gNB from K gNB, which shall only be used for the protection of RRC signalling with a particular integrity algorithm.
  • K RRCenc is a key derived by ME and gNB from K gNB, which shall only be used for the protection of RRC signalling with a particular encryption algorithm.
Intermediate keys:
  • NH is a key derived by ME and AMF to provide forward security as described in Clause A.10.
  • K NG-RAN * is a key derived by ME and NG-RAN (i.e., gNB or ng-eNB) when performing a horizontal or vertical key derivation as specified in Clause 6.9. 2.1.1 using a KDF as specified in Clause A.11/A.12.
    - K'AMF is a key that can be derived by ME and AMF when the UE moves from one AMF to another during inter-AMF mobility as specified in Clause 6.9.3 using a KDF as specified in Annex A.13.
Key for the non-3GPP access:
  • K N3IWF is a key derived by ME and AMF from K AMF for the non-3GPP access. K N3IWF is not forwarded between N3IWFs.
Up

6.2.2  Key derivation and distribution schemeWord‑p. 50

6.2.2.1  Keys in network entities

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 K AUSF 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 K AUSF from CK' and IK' for EAP-AKA' as specified in clause 6.1.3.1. The K AUSF may be stored in the AUSF between two subsequent authentication and key agreement procedures.
The AUSF shall generate the anchor key, also called K SEAF, 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, K SEAF, from the AUSF upon a successful primary authentication procedure in each serving network.
The SEAF shall never transfer K SEAF to an entity outside the SEAF. Once K AMF is derived K SEAF shall be deleted.
The SEAF shall generate K AMF from K SEAF immediately following the authentication and key agreement procedure and hands it to the AMF.
Keys in the AMF
The AMF receives K AMF from the SEAF or from another AMF.
The AMF shall, based on policy, derive a key K'AMF from K AMF for transfer to another AMF in inter-AMF mobility. The receiving AMF shall use K'AMF as its key K AMF.
The AMF shall generate keys K NASint and K NASenc dedicated to protecting the NAS layer.
The AMF shall generate access network specific keys from K AMF. In particular,
  • the AMF shall generate K gNB 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 K N3IWF and transfer it to the N3IWF when K AMF is received from SEAF, or when K'AMF is received from another AMF.
Keys in the NG-RAN
The NG-RAN (i.e., gNB or ng-eNB) receives K gNB and NH from the AMF. The ng-eNB uses K gNB as K eNB.
The NG-RAN (i.e., gNB or ng-eNB) shall generate all further access stratum (AS) keys from K gNB and /or NH.
Keys in the N3IWF
The N3IWF receives K N3IWF from the AMF.
The N3IWF shall use K N3IWF 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.
[not reproduced yet]
Figure 6.2.2-1: Key distribution and key derivation scheme for 5G for network nodes
Up

6.2.2.2  Keys in the UEWord‑p. 51
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.
[not reproduced yet]
Figure 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 K AUSF 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 K AUSF . If the USIM supports 5G parameters storage, K AUSF shall be stored in the USIM. Otherwise, K AUSF shall be stored in the non-volatile memory of the ME.
The ME shall perform the generation of K SEAF from the K AUSF. If the USIM supports 5G parameters storage, K SEAF shall be stored in the USIM. Otherwise, K SEAF shall be stored in the non-volatile memory of the ME.
The ME shall perform the generation of K AMF. If the USIM supports 5G parameters storage, K AMF shall be stored in the USIM. Otherwise, K AMF 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 K AMF.
Any 5G security context, K AUSF and K SEAF 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 keysWord‑p. 53

6.2.3.1  Key setting

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 K AMF that is stored in the UE and the AMF with a new partial, non-current security context.
NAS keys (i.e. K NASint and K NASenc) and AS keys (i.e. K gNB, K RRCenc, K RRCint, K UPenc, K UPint) are derived from K AMF using the KDFs specified in Annex A. The NAS keys derived from the new K AMF 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 K N3IWF is derived from the K AMF. K N3IWF is stored in the UE and the N3IWF as specified in subclause 7.2.1. This key K N3IWF 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 identification

The key K AMF 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 K AMF and the temporary identifier 5G-GUTI, if available.
A native ngKSI is associated with the K SEAF and K AMF 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 K AMF. 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 K AMF 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 K AMF when moving from EPS to 5GS. The mapped ngKSI is stored together with the mapped K AMF.
The purpose of the mapped ngKSI is to make it possible for the UE and the AMF to indicate the use of the mapped K AMF 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 K AMF is not available for use. The format of ngKSI is described in [35]
K NASenc and K NASint in the key hierarchy specified in clause 6.2.1, which are derived from K AMF, 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 K AMF.
The K N3IWF can be uniquely determined by ngKSI together with the uplink NAS COUNT are used to derive it according to clause A.9.
The initial K gNB 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 K gNB 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 K gNB according to clause A.10. The next hop chaining counter, NCC, represents the 3 least significant bits of this counter.
Intermediate key K NG-RAN*, as well as non-initial K gNB, defined in clause 6.9.2.1.1 can be uniquely identified by ngKSI together with those parameters from the set {K gNB or NH, sequence of PCIs and ARFCN-DLs}, which are used to derive these keys from K gNB or NH.
K RRCint, K RRCenc, K UPint, and K UPenc 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 K gNB.
Up

6.2.3.3  Key lifetimesWord‑p. 54
K AUSF, and K SEAF shall be created when running a successful primary authentication as described in clause 6.1.3.
K AMF 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. clauses 8 and 10)
In case the UE does not have a valid K AMF, an ngKSI with value "111" shall be sent by the UE to the network, which can initiate (re)authentication procedure to get a new K AMF based on a successful primary authentication.
K NASint and K NASenc are derived based on a K AMF when running a successful NAS SMC procedure as described in clause 6.7.2.
K N3IWF is derived from K AMF and remains valid as long as the UE is connected to the 5GC over non- 3gpp access or until the UE is reauthenticated.
K gNB and NH are derived based on K AMF or K gNB 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 K RRCint, K RRCenc, K UPint and K UPenc are derived based on K gNB after a new K gNB is derived.
Up


Up   Top   ToC