Difference between revisions of "My 3GPP 33.501 notes"

From Got Opinion Wiki
Jump to navigation Jump to search
Line 121: Line 121:
The AUSF shall inform the UDM that a successful or unsuccessful authentication of a subscriber has occurred.
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<sub>SEAF</sub> 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<sub>SEAF</sub> 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<sub>SEAF</sub> is derived from an intermediate key called the K<sub>AUSF</sub>. The K<sub>AUSF</sub> is established between the UE and HN resulting from the primary authentication procedure. The K<sub>AUSF</sub> 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<sub>AUSF</sub> 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<sub>AUSF</sub> 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.


<center>[[Telecommunications_info|To Telecommunications Info]]</center>
<center>[[Telecommunications_info|To Telecommunications Info]]</center>

Revision as of 11:58, 14 September 2022

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.

Requirements of UE § 5.2

Subscriber privacy § 5.2.5

The UE shall support 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 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 ME calculating the SUCI, shall be stored in USIM.

The 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 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 [19].

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 KSEAF 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 KSEAF 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 KSEAF is derived from an intermediate key called the KAUSF. The KAUSF is established between the UE and HN resulting from the primary authentication procedure. The KAUSF 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 KAUSF 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 KAUSF 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.

To Telecommunications Info