My 3GPP 33.501 notes

§ 1 Scope

This document specifies the security architecture, i.e., the security features and the security mechanisms for the 5G System and the 5G Core, and the security procedures performed within the 5G System including the 5G Core and the 5G New Radio.

Definitions

5G security context

The state that is established locally at the UE and a serving network domain and represented by the "5G security context data" stored at the UE and a serving network.

NOTE 1: The "5G security context data" consists of the 5G NAS security context, and the 5G AS security context for 3GPP access and/or the 5G AS security context for non-3GPP access.

NOTE 2: A 5G security context has type "mapped", "full native" or "partial native". Its state can either be "current" or "non-current". A context can be of one type only and be in one state at a time. The state of a particular context type can change over time. A partial native context can be transformed into a full native. No other type transformations are possible.

5G AS security context for 3GPP access

The cryptographic keys at AS level with their identifiers, the Next Hop parameter (NH), the Next Hop Chaining Counter parameter (NCC) used for next hop access key derivation, the identifiers of the selected AS level cryptographic algorithms, the UE security capabilities, and the UP Security Policy at the network side, UP security activation status and the counters used for replay protection.

NOTE 3: NH and NCC need to be stored also at the AMF during connected mode.

NOTE 4: UP security activation status is sent from gNB/ng-eNB in step 1b in clause 6.6.2 corresponding to the active PDU session(s).

5G AS security context for non-3GPP access

The key KN3IWF, the cryptographic keys, cryptographic algorithms and tunnel security association parameters used at IPsec layer for the protection of IPsec SA.

5G AS Secondary Cell security context

The cryptographic keys at AS level for secondary cell with their identifiers, the identifier of the selected AS level cryptographic algorithms for secondary cell, the UP Security Policy at the network side, and counters used for replay protection.

Home Network Public Key Identifier

An identifier used to indicate which public/private key pair is used for SUPI protection and de-concealment of the SUCI.

subscription credential(s)

The set of values in the USIM and in the home operator's network, consisting of at least the long-term key(s) and the subscription identifier SUPI, used to uniquely identify a subscription and to mutually authenticate the UE and 5G core network.

subscription identifier de-concealing function

The Subscription Identifier De-concealing Function (SIDF) service offered by the network function UDM in the home network of the subscriber responsible for de-concealing the SUPI from the SUCI.

UE 5G security capability

The UE security capabilities for 5G AS and 5G NAS.

UE security capabilities

The set of identifiers corresponding to the ciphering and integrity algorithms implemented in the UE.

NOTE 9: This includes capabilities for NG-RAN and 5G NAS, and includes capabilities for EPS, UTRAN and GERAN if these access types are supported by the UE.

Security Domains § 4.1

• Network access security (I): the set of security features that enable a UE to authenticate and access services via the network securely, including the 3GPP access and Non-3GPP access, and in particularly, to protect against attacks on the (radio) interfaces. In addition, it includes the security context delivery from SN to AN for the access security.
• Network domain security (II): the set of security features that enable network nodes to securely exchange signalling data and user plane data.
• User domain security (III): the set of security features that secure the user access to mobile equipment.
• Application domain security (IV): the set of security features that enable applications in the user domain and in the provider domain to exchange messages securely. Application domain security is out of scope of the present document.
• SBA domain security (V): the set of security features that enables network functions of the SBA architecture to securely communicate within the serving network domain and with other network domains . Such features include network function registration, discovery, and authorization security aspects, as well as the protection for the service-based interfaces. SBA domain security is a new security feature compared to TS 33.401.
• Visibility and configurability of security (VI): the set of features that enable the user to be informed whether a security feature is in operation or not.

The 5G System architecture introduces the following security entities in the 5G Core network § 4.3

• AUSF: AUthentication Server Function;
• ARPF: Authentication credential Repository and Processing Function;
• SIDF: Subscription Identifier De-concealing Function;
• SEAF: SEcurity Anchor Function.

General Security Requirements § 5.1

Mitigation of bidding down attacks § 5.1.1

An attacker could attempt a bidding down attack by making UE and the network entities respectively believe that the other side does not support a security feature, even when both sides support security feature. It shall be ensured that a bidding down attack, in the above sense, can be prevented.

Authentication and Authorization § 5.1.2

The 5G system shall satisfy the following requirements.

Subscription authentication: The serving network shall authenticate the Subscription Permanent Identifier (SUPI) in the process of authentication and key agreement between UE and network.

Serving network authentication: The UE shall authenticate the serving network identifier through implicit key authentication.

NOTE 1: The meaning of 'implicit key authentication' here is that authentication is provided through the successful use of keys resulting from authentication and key agreement in subsequent procedures.

NOTE 2: The preceding requirement does not imply that the UE authenticates a particular entity, e.g. an AMF, within a serving network.

UE authorization: The serving network shall authorize the UE through the subscription profile obtained from the home network. UE authorization is based on the authenticated SUPI.

Serving network authorization by the home network: Assurance shall be provided to the UE that it is connected to a serving network that is authorized by the home network to provide services to the UE. This authorization is 'implicit' in the sense that it is implied by a successful authentication and key agreement run.

Access network authorization: Assurance shall be provided to the UE that it is connected to an access network that is authorized by the serving network to provide services to the UE. This authorization is 'implicit' in the sense that it is implied by a successful establishment of access network security. This access network authorization applies to all types of access networks.

Unauthenticated Emergency Services: In order to meet regulatory requirements in some regions, the 5G system shall support unauthenticated access for emergency services. This requirement applies to all MEs and only to those serving networks where regulatory requirements for unauthenticated emergency services exist. Serving networks located in regions where unauthenticated emergency services are forbidden shall not support this feature.

Requirements of UE § 5.2

Subscriber privacy § 5.2.5

The UE shall support 5G Globally Unique Temporary Identifier (5G-GUTI).

The SUPI should not be transferred in clear text over NG-RAN except routing information, e.g. Mobile Country Code (MCC) and Mobile Network Code (MNC).

The Home Network Public Key shall be stored in the Universal Subscriber Identity Module (USIM).

The protection scheme identifier shall be stored in the USIM.

The Home Network Public Key Identifier shall be stored in the USIM.

The SUCI calculation indication, either USIM or Mobile Equipment (ME) calculating the SUCI, shall be stored in USIM.

The Mobile Equipment (ME) shall support the null-scheme. If the home network has not provisioned the Home Network Public Key in USIM, the SUPI protection in initial registration procedure is not provided. In this case, the null-scheme shall be used by the ME.

Based on home operator's decision, indicated by the USIM, the calculation of the SUCI shall be performed either by the USIM or by the Mobile Equipment (ME).

NOTE 1: If the SUCI calculation indication is not present, the calculation is in the ME.

In case of an unauthenticated emergency call, privacy protection for SUPI is not required.

Provisioning, and updating the Home Network Public Key, Home Network Public Key Identifier, protection scheme identifier, Routing Indicator, and SUCI calculation indication in the USIM shall be in the control of the home network operator.

NOTE 2: The provisioning and updating of the Home Network Public Key, Home Network Public Key Identifier, protection scheme identifier, and SUCI calculation indication is out of the scope of the present document. It can be implemented using, e.g. the Over the Air (OTA) mechanism. Routing Indicator can be updated, e.g., by OTA or as defined in clause 6.15.

Subscriber privacy enablement shall be under the control of the home network of the subscriber.

The UE shall only send the PEI in the NAS protocol after NAS security context is established, unless during emergency registration when no NAS security context can be established.

The Routing Indicator shall be stored in the USIM. If the Routing Indicator is not present in the USIM, the ME shall set it to a default value as defined in TS 23.003.

Requirements of AMF § 5.5

Subscriber privacy § 5.5.3

The AMF shall support to trigger primary authentication using the SUCI. The AMF shall support assigning 5G-GUTI to the UE. The AMF shall support reallocating 5G-GUTI to UE. The AMF shall be able to confirm SUPI from UE and from home network. The AMF shall deny service to the UE if this confirmation fails.

Requirements on SEAF § 5.6

The security anchor function (SEAF) provides the authentication functionality via the AMF in the serving network.

The SEAF shall fulfil the following requirements:

• The SEAF shall support primary authentication using SUCI.

Requirements of UDM § 5.8

Subscriber privacy related requirements to UDM and SIDF § 5.8.2

The SIDF is responsible for de-concealment of the SUCI and shall fulfil the following requirements:

• The SIDF shall be a service offered by UDM.
• The SIDF shall resolve the SUPI from the SUCI based on the protection scheme used to generate the SUCI.

The Home Network Private Key used for subscriber privacy shall be protected from physical attacks in the UDM.

The UDM shall hold the Home Network Public Key Identifier(s) for the private/public key pair(s) used for subscriber privacy.

The algorithm used for subscriber privacy shall be executed in the secure environment of the UDM.

Requirements on AUSF § 5.8a

The Authentication server function (AUSF) shall handle authentication requests for both, 3GPP access and non-3GPP access.

The AUSF shall provide SUPI to the VPLMN only after authentication confirmation if authentication request with SUCI was sent by VPLMN.

The AUSF shall inform the UDM that a successful or unsuccessful authentication of a subscriber has occurred.

Security procedures between UE and 5G network functions § 6

6.1 Primary authentication and key agreement

6.1.1 Authentication framework

General § 6.1.1.1

The purpose of the primary authentication and key agreement procedures is to enable mutual authentication between the UE and the network and provide keying material that can be used between the UE and the serving network in subsequent security procedures. The keying material generated by the primary authentication and key agreement procedure results in an anchor key called the K_SEAF provided by the AUSF of the home network to the SEAF of the serving network.

Keys for more than one security context can be derived from the K_SEAF without the need of a new authentication run. A concrete example of this is that an authentication run over a 3GPP access network can also provide keys to establish security between the UE and a N3IWF used in untrusted non-3GPP access.

The anchor key K_SEAF is derived from an intermediate key called the K_AUSF. The K_AUSF is established between the UE and HN resulting from the primary authentication procedure. The K_AUSF may be securely stored in the AUSF based on the home operator's policy on using such key e.g. if the control plane solution for Steering of Roaming (see clause 6.14) or UE Parameter Update procedures (see clause 6.15) or Authentication and Key Management for Applications (AKMA) are supported by the HPLMN.

NOTE A: For standalone non-public networks when an authentication method other than 5G Authentication and Key Agreement (AKA) or Extensible Authentication Protocol AKA (EAP-AKA') is used, Annex I.2 applies.

NOTE 1: This feature is an optimization that might be useful, for example, when a UE registers to different serving networks for 3GPP-defined access and untrusted non-3GPP access (this is possible according to TS 23.501 [2]). The details of this feature are operator-specific and not in scope of this document.

NOTE 2: A subsequent authentication based on the K_AUSF stored in the AUSF gives somewhat weaker guarantees than an authentication directly involving the ARPF and the USIM. It is rather comparable to fast re-authentication in EAP-AKA'.

UE and serving network shall support EAP-AKA' and 5G AKA authentication methods.

NOTE 2b: It is the home operator's decision which authentication method is selected.

The USIM shall reside on a UICC. The UICC may be removable or non-removable.

NOTE 3: For non-3GPP access networks USIM applies in case of terminal with 3GPP access capabilities.

If the terminal supports 3GPP access capabilities, the credentials used with EAP-AKA' and 5G AKA for non-3GPP access networks shall reside on the UICC.

NOTE 4: EAP-AKA' and 5G AKA are the only authentication methods that are supported in UE and serving network, hence only they are described in sub-clause 6.1.3 of the present document. For a private network using the 5G system as specified in [7] an example of how additional authentication methods can be used with the EAP framework is given in the informative Annex B.

NOTE 5: For non-public network (NPN) security the Annex I of the present document provides details.

Upon successful completion of the 5G AKA primary authentication, the AMF shall initiate NAS security mode command procedure (see clause 6.7.2) with the UE.

NOTE 6: The reason to mandatory run the NAS SMC procedure after primary authentication is because the UE does not store the new derived K_AUSF until receiving the NAS SMC message. The new partial native NAS security context is taken into use. It is specified in clause 6.9.4.4 whether AS key re-keying is performed.

EAP framework § 6.1.1.2

The EAP framework is specified in RFC 3748. It defines the following roles: peer, pass-through authenticator and back-end authentication server. The back-end authentication server acts as the EAP server, which terminates the EAP authentication method with the peer. In the 5G system, the EAP framework is supported in the following way:

• The UE takes the role of the peer.
• The SEAF takes the role of pass-through authenticator.
• The AUSF takes the role of the backend authentication server.

Construction of the serving network name § 6.1.1.4

See specification. Format is 5G.<SN Id> where 5G represents service code and <SN Id> is Serving Network Identifier.

6.3 Security Contexts

6.3.2 Multiple registrations in same or different serving networks

6.3.2.0 General

There are two cases where the UE can be multiple registered in different PLMN's serving networks or in the same PLMN's serving networks. The first case is when the UE is registered in one PLMN serving network over a certain type of access (e.g. 3GPP) and is registered to another PLMN serving network over the other type of access (e.g. non-3GPP). The second case is where the UE is registered in the same AMF in the same PLMN serving network over both 3GPP and non-3GPP accesses. The UE will establish two NAS connections with the network in both cases.

NOTE: The UE uses the same subscription credential(s) for multiple registrations in the same or different serving networks.

6.3.2.1 Multiple registrations in different PLMNs

The UE shall independently maintain and use two different 5G security contexts, one per PLMN's serving network. Each security context shall be established separately via a successful primary authentication procedure with the Home PLMN.

The ME shall store the two different 5G security contexts on the USIM if the USIM supports the 5G parameters storage. If the USIM does not support the 5G parameters storage, then the ME shall store the two different 5G security contexts in the ME non-volatile memory. Both of the two different 5G security contexts are current 5G security context.

The latest K_AUSF result of the successful completion of the latest primary authentication shall be used by the UE and the HN regardless over which access network type (3GPP or non-3GPP) it was generated.

The HN shall keep the latest K_AUSF generated during successful authentication over a given access even if the UE is deregistered from that access, but the UE is registered via another access.

6.3.2.2 Multiple registrations in the same PLMN

When the UE is registered in the same AMF in the same PLMN serving network over both 3GPP and non-3GPP accesses, the UE shall establish two NAS connections with the network. Upon receiving the registration request message, the AMF should check whether the UE is authenticated by the network. The AMF may decide to skip a new authentication run in case there is an available 5G security context for this UE by means of 5G-GUTI, e.g. when the UE successfully registered to 3GPP access.

If the UE registers to the same AMF via non-3GPP access, the AMF can decide not to run a new authentication if it has an available security context to use. In this case, the UE shall directly take into use the available common 5G NAS security context and use it to protect the registration over the non-3GPP access. If there are stored NAS counts for the non-3GPP access for the PLMN in the UE, then the stored NAS counts for the non-3GPP access for the PLMN shall be used to protect the registration over the non-3GPP access. Otherwise, the common 5G NAS security context is taken into use for the first time (partial) over non-3GPP access. In this case, the UL NAS COUNT value and DL NAS COUNT value for the non-3GPP access needs to be set to zero by the UE before the UE is taking the 5G NAS security context into use over non 3GPP access.

The AMF and the UE shall establish a common NAS security context consisting of a single set of NAS keys and algorithm at the time of first registration over any access. The AMF and the UE shall also store parameters specific to each NAS connection in the common NAS security context including two pairs of NAS COUNTs for each access (i.e. 3GPP access and non-3GPP access). The connection specific parameters are specified in clause 6.4.2.2 of the present document.

6.4 NAS security mechanisms

6.4.1 General

This sub-clause describes the security mechanisms for the protection of NAS signalling and data between the UE and the AMF over the N1 reference point. This protection involves both integrity and confidentiality protection. The security parameters for NAS protection are part of the 5G security context described in sub-clause 6.3 of the present document.

6.4.2 Security for multiple NAS connections

6.4.2.1 Multiple active NAS connections with different PLMNs

TS 23.501 has a scenario when the UE is registered to a VPLMN's serving network via 3GPP access and to another VPLMN's or HPLMN's serving network via non-3GPP access at the same time. When the UE is registered in one PLMN's serving network over a certain type of access (e.g. 3GPP) and is registered to another PLMN's serving network over another type of access (e.g. non-3GPP), then the UE has two active NAS connections with different AMF's in different PLMNs. As described in clause 6.3.2.1, the UE shall independently maintain and use two different 5G security contexts, one per PLMN serving network. The 5G security context maintained by the UE shall contain the full set of 5G parameters, including NAS context parameters for 3GPP and non-3GPP access types per PLMN. In case of connection to two different PLMNs, it is necessary to maintain a complete 5G NAS security context for each PLMN independently, each with all associated parameters (such as two pairs of NAS COUNTs, i.e. one pair for 3GPP access and one pair for non-3GPP access).

Each security context shall be established separately via a successful primary authentication procedure with the Home PLMN.

All the NAS and AS security mechanisms defined for single registration mode are applicable independently on each access using the corresponding 5G security context.

NOTE: The UE belongs to a single HPLMN.

6.4.2.2 Multiple active NAS connections in the same PLMN's serving network

When the UE is registered in a serving network over two types of access (e.g. 3GPP and non-3GPP), then the UE has two active NAS connections with the same AMF. A common 5G NAS security context is created during the registration procedure over the first access type.

In order to realize cryptographic separation and replay protection, the common NAS security-context shall have parameters specific to each NAS connection. The connection specific parameters include a pair of NAS COUNTs for uplink and downlink and unique NAS connection identifier. The value of the unique NAS connection identifier shall be set to "0x01" for 3GPP access and set to "0x02" for non-3GPP access. All other parameters as e.g. algorithm identifiers in the common NAS security context are common to multiple NAS connections.

In non-mobility cases, when the UE is simultaneously registered over both types of accesses, and if NAS key re-keying as described in clause 6.9.4.2 or if NAS key refresh as described in clause 6.9.4.3 takes place over one of the accesses (say access A):

1. If the other access (access B) is in CM-CONNECTED state, then the new NAS security context shall only be activated over that access (access A). The UE and the AMF shall not change the NAS security context in use on the other access (say access B). In order to activate the new NAS security context over the other access (access B), the AMF shall trigger a NAS Security Mode Command (SMC) run over that access either in the current running procedure or a subsequent NAS procedure. During the second NAS SMC run (on access B), the AMF shall include the same ngKSI associated with the new NAS security context and the same algorithm choices as for the first access. After a successful second NAS SMC procedure over the other access (access B), both the UE and the AMF shall delete the old NAS security context.
2. Whenever the AMF sends a NAS SMC over access (access A) and AMF considers the UE to not be in CM-CONNECTED state on the other access (access B), the AMF shall additionally activate (if not already in use on the other access) the security context that is active on the other accesses. Similarly, whenever the UE receives a NAS SMC over the access (access A) and UE is not in CM-CONNECTED state on the other access (access B), the UE additionally activates (if not already in use on the other access) the security context on the other access.

In case of 3GPP access mobility or interworking with EPS, the following procedures apply:

1. If the UE is in CM-CONNECTED state on the non-3GPP access, then:
1. if the AMF does not have the security context the UE is using on the non-3GPP access (e.g. K_AMF change on 3GPP access when the AMF changes), then in order to activate the same NAS security context that is in use over the 3GPP access the AMF shall run a NAS SMC procedure on the non-3GPP access; or
2. in the case of handover from EPS, then a mapped context will be in use on the 3GPP access and a different security context will be active on the non-3GPP access. To align the security contexts in use over both accesses, the AMF shall run a NAS SMC procedure over one access to take into use on that access the security context that is in use on the other access. In the case that a native security context is in use on the non-3GPP access, then the NAS SMC procedure shall be on the 3GPP access to take the native security context into use.
2. Whenever the AMF sends a Registration Accept over the 3GPP access and AMF considers the UE to not be in CM-CONNECTED state on the non-3GPP access, the AMF shall activate (if not already in use on the non-3GPP access) the security context that is in use on the 3GPP access on the non-3GPP access. The AMF shall keep a native security context that was in use on non-3GPP access if the security context in use on the 3GPP access is a mapped security context. In order to take this native security context into use, the AMF shall run a NAS SMC procedure.

Similarly, whenever the UE receives a Registration Accept over the 3GPP access and UE is not in CM-CONNECTED state on the non-3GPP access, the UE activates (if not already in use on the non-3GPP access) the security context that is in use on the 3GPP access on the non-3GPP access. The UE shall keep a native security context that was in use on non-3GPP access if the security context in use on the 3GPP access is a mapped security context.

To recover from a failure to align the NAS security contexts due to a state mis-match between AMF and UE, the AMF can align the security contexts in use on the 3GPP and non-3GPP access using the a NAS SMC procedure during a subsequent registration procedure (that was either initiated by the UE or sent in response to a Service Reject if the UE sends a Service Request).

6.4.3 NAS integrity mechanisms

See spec for details...

6.4.3.0 General

Integrity protection for NAS signalling messages shall be provided as part of the NAS protocol.

6.4.4 NAS confidentiality mechanisms

See spec for details...

6.4.4.0 General

Confidentiality protection for NAS signalling messages shall be provided as part of the NAS protocol.

6.4.5 Handling of NAS COUNTs

See spec for details...

6.4.6 Protection of initial NAS message

The initial NAS message is the first NAS message that is sent after the UE transitions from the idle state. The UE shall send a limited set of IEs (called the cleartext IEs) including those needed to establish security in the initial message when it has no NAS security context.

When the UE has a NAS security context, the UE shall send a message that has the complete initial NAS message ciphered in a NAS Container along with the cleartext IEs with whole message integrity protected.

The complete initial message is included in the NAS Security Mode Complete (SMC) message in a NAS Container when needed (e.g. AMF cannot find the used security context) in the latter case and always in the former case as described below.

Note: See 3GPP TS 24.501 5.4.2 for Security Mode Control procedure or my security mode control notes

In case the UE selects a PLMN other than Registered PLMN/EPLMN in the 5GMM-IDLE state and the UE has a NAS security context containing the NEA0, then the UE shall discard the NAS security context and shall follow the procedure specified in this clause for protection of initial NAS message.

The protection of the initial NAS message proceeds as shown in Figure 6.4.6-1 and following.

Step 1: The UE shall send the initial NAS message to the AMF.

• If the UE has no NAS security context, the initial NAS message shall only contain the cleartext IEs, i.e. subscription identifiers (e.g. SUCI or GUTIs), UE security capabilities, ngKSI, indication that the UE is moving from EPC, Additional GUTI, and IE containing the TAU Request in the case idle mobility from LTE.
• If the UE has a NAS security context, the message sent shall contain the information given above in cleartext and the complete initial NAS message ciphered in a NAS container which is ciphered. With a NAS security context, the sent message shall also be integrity protected. In the case that the initial NAS message was protected and the AMF has the same security context, then steps 2 to 4 may be omitted In this case the AMF shall use the complete initial NAS message that is in the NAS container as the message to respond to..

Step 2: If the AMF is not able to find the security context locally or from last visited AMF, or if the integrity check fails, then the AMF shall initiate an authentication procedure with the UE. If the AMF fetches old security context from the last visited AMF, the AMF may decipher the NAS container with the same security context, and get the initial NAS message, then the step 2b to 4 may be omitted. If the AMF fetches new K_AMF from the last visited AMF (receiving keyAmfChangeInd), the step 2b may be omitted.

Step 3: If the authentication of the UE is successful, the AMF shall send the NAS Security Mode Command message. If the initial NAS message was protected but did not pass the integrity check (due either to a MAC failure or the AMF not being able to find the used security context) or the AMF could not decrypt the complete initial NAS message in the NAS container (due to receiving "keyAmfChangeInd" from the last visited AMF), then the AMF shall include in the Security Mode Command message a flag requesting the UE to send the complete initial NAS message in the NAS Security Mode Complete message.

Step 4: The UE shall send the NAS Security Mode Complete message to the network in response to a NAS Security Mode Command message. The NAS Security Mode Complete message shall be ciphered and integrity protected. Furthermore the NAS Security Mode Complete message shall include the complete initial NAS message in a NAS Container if either requested by the AMF or the UE sent the initial NAS message unprotected. The AMF shall use the complete initial NAS message that is in the NAS container as the message to respond to.

Step 5: The AMF shall send its response to the Initial NAS message. This message shall be ciphered and integrity protected.

6.4.7 Security aspects of SMS over NAS

Specific services of SMS over NAS are defined in TS 23.501, and procedures for SMS over NAS are specified in TS 23.502.

For registration and de-registration procedures for SMS over NAS, the details are specified in subclause 4.13.3.1 and 4.13.3.2 in TS 23.502. The NAS message can be protected by NAS security mechanisms.

For MO/MT SMS over NAS via 3GPP/non-3GPP when the UE has already activated NAS security with the AMF before sending/receiving SMS, the NAS Transport message shall be ciphered and integrity protected using the NAS security context by the UE/AMF as described in sub-clause 6.4 in the present document.

6.5 RRC security mechanisms

See spec for details...

6.7 Security algorithm selection, key establishment and security mode command procedure

6.7.1 Procedures for NAS algorithm selection

6.7.1.1 Initial NAS security context establishment

Each AMF shall be configured via network management with lists of algorithms which are allowed for usage. There shall be one list for NAS integrity algorithms, and one for NAS ciphering algorithms. These lists shall be ordered according to a priority decided by the operator.

To establish the NAS security context, the AMF shall choose one NAS ciphering algorithm and one NAS integrity protection algorithm. The AMF shall then initiate a NAS security mode command procedure, and include the chosen algorithm and UE security capabilities (to detect modification of the UE security capabilities by an attacker) in the message to the UE (see sub-clause 6.7.2 of the present document). The AMF shall select the NAS algorithm which have the highest priority according to the ordered lists.

6.7.1.2 AMF change

If the change of the AMF at N2-Handover or mobility registration update results in the change of algorithm to be used for establishing NAS security, the target AMF shall indicate the selected algorithm to the UE as defined in Clause 6.9.2.3.3 for N2-Handover (i.e., using NAS Container) and Clause 6.9.3 for mobility registration update (i.e., using NAS SMC). The AMF shall select the NAS algorithm which has the highest priority according to the ordered lists (see sub-clause 6.7.1.1 of the present document).

6.7.2 NAS security mode command procedure

See spec for details...

6.12 Subscription identifier privacy

6.12.1 Subscription permanent identifier

In the 5G system, the globally unique 5G subscription permanent identifier is called SUPI as defined in 3GPP TS 23.501. The SUCI is a privacy preserving identifier containing the concealed SUPI.

The SUPI is privacy protected over-the-air by using the SUCI which is described in clause 6.12.2. Handling of SUPI and privacy provisioning related to concealing the SUPI shall be done according to the requirements specified in clause 5 and details provided in clause 6.12.2.

6.12.2 Subscription concealed identifier

subscription concealed identifier

A one-time use subscription identifier, called the SUbscription Concealed Identifier (SUCI), which contains the Scheme-Output, and additional non-concealed information needed for home network routing and protection scheme usage.

The SUbscription Concealed Identifier, called SUCI, is a privacy preserving identifier containing the concealed SUPI.

The UE shall generate a SUCI using a protection scheme with the raw public key, i.e. the Home Network Public Key, that was securely provisioned in control of the home network. The protection schemes shall be the ones specified in Annex C of this document or the ones specified by the HPLMN.

The UE shall construct a scheme-input from the subscription identifier part of the SUPI as follows:

• For SUPIs containing IMSI, the subscription identifier part of the SUPI includes the MSIN of the IMSI as defined in TS 23.003.
• For SUPIs taking the form of a NAI, the subscription identifier part of the SUPI includes the "username" portion of the NAI as defined in NAI RFC 7542.

The UE shall execute the protection scheme with the constructed scheme-input as input and take the output as the Scheme Output.

The UE shall not conceal the Home Network Identifier and the Routing Indicator.

For SUPIs containing IMSI, the UE shall construct the SUCI with the following data fields:

• The SUPI Type as defined in TS 23.003 identifies the type of the SUPI concealed in the SUCI.
• The Home Network Identifier is set to the MCC and MNC of the IMSI as specified in 23.003.
• The Routing Indicator as specified in TS 23.003.
• The Protection Scheme Identifier as specified in Annex C of this specification.
• The Home Network Public Key Identifier as specified in this document and detailed in TS 23.003.
• The Scheme Output as specified in this document and detailed in TS 23.003.

For SUPIs containing Network Specific Identifier, the UE shall construct the SUCI in NAI format with the following data fields:

• realm part of the SUCI is set to the realm part of the SUPI.
• username part of the SUCI is formatted as specified in TS 23.003 using the SUPI Type, Routing Indicator, the Protection Scheme Identifier, the Home Network Public Key Identifier and the Scheme Output.

NOTE 1: The format of the SUPI protection scheme identifiers is defined in Annex C.

NOTE 2: The identifier and the format of the Scheme Output are defined by the protection schemes in Annex C. In case of non-null-schemes, the freshness and randomness of the SUCI will be taken care of by the corresponding SUPI protection schemes.

NOTE 2a: In case of null-scheme being used, the Home Network Public Key Identifier is set to a default value as described in TS 23.003.

The UE shall include a SUCI only in the following 5G NAS messages:

• if the UE is sending a Registration Request message of type "initial registration" to a PLMN for which the UE does not already have a 5G-GUTI, the UE shall include a SUCI to the Registration Request message, or
• if the UE responds to an Identity Request message by which the network requests the UE to provide its permanent identifier, the UE includes a SUCI in the Identity Response message as specified in clause 6.12.4.
• if the UE is sending a De-Registration Request message to a PLMN during an initial registration procedure for which the UE did not receive the registration accept message with 5G-GUTI, the UE shall include the SUCI used in the initial registration to the De-Registration Request message.

NOTE 3: In response to the Identity Request message, the UE never sends the SUPI.

The UE shall generate a SUCI using "null-scheme" only in the following cases:

• if the UE is making an unauthenticated emergency session and it does not have a 5G-GUTI to the chosen PLMN, or
• if the home network has configured "null-scheme" to be used, or
• if the home network has not provisioned the public key needed to generate a SUCI.

If the operator's decision, indicated by the USIM, is that the USIM shall calculate the SUCI, then the USIM shall not give the ME any parameter for the calculation of the SUCI including the Home Network Public Key Identifier, the Home Network Public Key, and the Protection Scheme Identifier. If the ME determines that the calculation of the SUCI, indicated by the USIM, shall be performed by the USIM, the ME shall delete any previously received or locally cached parameters for the calculation of the SUCI including the SUPI Type, the Routing Indicator, the Home Network Public Key Identifier, the Home Network Public Key and the Protection Scheme Identifier. The operator should use proprietary identifier for protection schemes if the operator chooses that the calculation of the SUCI shall be done in USIM.

If the operator's decision is that ME shall calculate the SUCI, the home network operator shall provision in the USIM an ordered priority list of the protection scheme identifiers that the operator allows. The priority list of protection scheme identifiers in the USIM shall only contain protection scheme identifiers specified in Annex C, and the list may contain one or more protection schemes identifiers. The ME shall read the SUCI calculation information from the USIM, including the SUPI, the SUPI Type, the Routing Indicator, the Home Network Public Key Identifier, the Home Network Public Key and the list of protection scheme identifiers. The ME shall select the protection scheme from its supported schemes that has the highest priority in the list are obtained from the USIM.

The ME shall calculate the SUCI using the null-scheme if the Home Network Public Key or the priority list are not provisioned in the USIM.

NOTE 4: The above feature is introduced since additional protection schemes could be specified in the future for a release newer than the ME release. In this case, the protection scheme selected by older MEs may not be the protection scheme with the highest priority in the list of the USIM.

6.12.3 Subscription temporary identifier

A new 5G-GUTI shall be sent to a UE only after a successful activation of NAS security. The 5G-GUTI is defined in TS 23.003.

Upon receiving Registration Request message of type "initial registration" or "mobility registration update" from a UE, the AMF shall send a new 5G-GUTI to the UE in the registration procedure.

Upon receiving Registration Request message of type "periodic registration update" from a UE, the AMF should send a new 5G-GUTI to the UE in the registration procedure.

Upon receiving Service Request message sent by the UE in response to a Paging message, the AMF shall send a new 5G-GUTI to the UE. This new 5G-GUTI shall be sent before the current NAS signalling connection is released or the N1 NAS signalling connection is suspended.

Upon receiving an indication from the lower layers that the RRC connection has been resumed for a UE in 5GMM-IDLE mode with suspend indication in response to a Paging message, the AMF shall send a new 5G-GUTI to the UE. This new 5G-GUTI shall be sent before the current NAS signalling connection is released or the suspension of the N1 NAS signalling connection.

NOTE 1: It is left to implementation to re-assign 5G-GUTI more frequently than in cases mentioned above, for example after a Service Request message from the UE not triggered by the network.

NOTE 2: It is left to implementation to generate 5G-GUTI containing 5G-TMSI that uniquely identifies the UE within the AMF.

5G-TMSI generation should be following the best practices of unpredictable identifier generation.

A new I-RNTI shall be sent to a UE only after a successful activation of AS security.

On transition of UE to RRC INACTIVE state requested by gNB during RRC Resume procedure or RNAU procedure, the gNB shall assign a new I-RNTI to the UE.

6.12.4 Subscription identification procedure

The subscriber identification mechanism may be invoked by the serving network when the UE cannot be identified by means of a temporary identity (5G-GUTI). In particular, it should be used when the serving network cannot retrieve the SUPI based on the 5G-GUTI by which the subscriber identifies itself on the radio path.

The mechanism described in following figure allows the identification of a UE on the radio path by means of the SUCI.

The mechanism is initiated by the AMF that requests the UE to send its SUCI.

The UE shall calculate a fresh SUCI from SUPI using the Home Network Public Key, and respond with Identity Response carrying the SUCI. The UE shall implement a mechanism to limit the frequency at which the UE responds with a fresh SUCI to an Identity Request for a given 5G-GUTI.

NOTE 1: If the UE is using any other scheme than the null-scheme, the SUCI does not reveal the SUPI.

AMF may initiate authentication with AUSF to receive SUPI as specified in clause 6.1.3.

In case the UE registers for Emergency Services and receives an Identity Request, the UE shall use the null-scheme for generating the SUCI in the Identity Response.

NOTE 2: Registration for Emergency does not provide subscription identifier confidentiality.

6.12.5 Subscription identifier de-concealing function (SIDF)

SIDF is responsible for de-concealing the SUPI from the SUCI. When the Home Network Public Key is used for encryption of SUPI, the SIDF shall use the Home Network Private Key that is securely stored in the home operator's network to decrypt the SUCI. The de-concealment shall take place at the UDM. Access rights to the SIDF shall be defined, such that only a network element of the home network is allowed to request SIDF.

NOTE: One UDM can comprise several UDM instances. The Routing Indicator in the SUCI can be used to identify the right UDM instance that is capable of serving a subscriber.

Annex C (normative): Protection schemes for concealing the subscription permanent identifier

C.2 Null-scheme

The null-scheme shall be implemented such that it returns the same output as the input, which applies to both encryption and decryption.

When using the null-scheme, the SUCI does not conceal the SUPI and therefore the newly generated SUCIs do not need to be fresh.

NOTE 1: The reason for mentioning the non-freshness is that, normally, in order to attain unlinkability (i.e., to make it infeasible for over-the-air attacker to link SUCIs together), it is necessary for newly generated SUCIs to be fresh. But, in case of the null-scheme, the SUCI does not conceal the SUPI. So unlinkability is irrelevant.

NOTE 2: The null-scheme provides no privacy protection.

C.3 Elliptic Curve Integrated Encryption Scheme (ECIES)

C.3.1 General

... Processing on UE side and home network side are described in high level in clauses C.3.2 and C.3.3.

When the SUPI is of type IMSI, the subscription identifier part of the IMSI (i.e., MSIN) that is used to construct the scheme-input shall be coded as hexadecimal digits using packed BCD coding where the order of digits within an octet is same as the order of MSIN digits specified in Figure 9.11.3.4.3a of TS 24.501. If the MSIN is composed of an odd number of digits, then the bits 5 to 8 of final octet shall be coded as "1111".

When the SUPI is of type network specific identifier, the subscription identifier part of the SUPI that is used to construct the scheme-input shall follow the encoding rules specified in Annex B.2.1.2 of TS 33.220. ...

See spec for details.

Annex F (normative): 3GPP 5G profile for EAP-AKA'

F.2 Subscriber privacy

EAP-AKA' includes optional support for identity privacy mechanism that protects the privacy against passive eavesdropping. The mechanism is described in RFC 4187 clause 4.1.1.2, and it uses pseudonyms that are delivered from the EAP server to the peer as part of an EAP-AKA exchange. The privacy mechanism described in RFC 4187 corresponds to the privacy provided by 5G-GUTI, however, assignment of 5G-GUTI is done outside the EAP framework in 5GS.

TS 33.501 assumes that the SUCI is sent outside the EAP messages, however, the peer may still receive EAP-Request/Identity or EAP-Request/AKA-Identity messages. Table F.2-1 specifies how the 5G UE shall behave when receiving such requests.

To Telecommunications Info