My 3GPP 33.501 notes

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.

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.

To Telecommunications Info