Tech-invite3GPPspaceIETF RFCsSIP
index21222324252627282931323334353637384‑5x

Content for  TS 33.501  Word version:  18.0.0

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

 

U  Primary authentication using EAP-TTLS in SNPNs |R17|p. 267

U.1  Introductionp. 267

In SNPN, when a credential holder is located outside of the 5GC of the SNPN, EAP-TTLS can be used to authenticate the UE. EAP-TTLS consists of two phases of authentication. In the first phase, a TLS tunnel is established between the UE and the EAP-TTLS server on AUSF. In the second phase, a legacy authentication protocol can be run between the UE and the credential holder (namely AAA) through the established TLS tunnel.
After the successful completion of EAP-TTLS, the AUSF and the UE derive the KAUSF from the EMSK.
UE is provisioned with a trust anchor to enable verification of the EAP-TTLS server certificate. The provisioning of trust anchor on the UE is outside the scope of this document.
Up

U.2  Procedurep. 267

Reproduction of 3GPP TS 33.501, Fig. U.2-1: Primary authentication using EAP-TTLS and AAA
Up
Step 0.
The UE is configured with the trust anchor needed to authenticate the certificate of the EAP-TTLS server running on the AUSF. Further, the UE is configured with the credentials required to authenticate with the AAA server.
Steps 1-17 are same as the steps 1-17 in clause B.2.1.1 in Annex B, except in the following steps:
Step 1.
The SUPI in the NAI format, i.e., username@realm, is used.
Step 5.
EAP-TTLS is selected by the UDM as the authentication method.
Step 6-17.
EAP-TTLS phase 1 is executed between the AUSF and the UE. EAP-Type is set to EAP-TTLS and the authentication of the UE using TLS client certificate is skipped. Since TLS client certificate is not used in EAP-TTLS, the UE need not be configured with UE certificate.
Step 18-27.
After EAP-TTLS phase 1 is successfully completed, the UE runs EAP-TTLS phase 2 authentication with the AAA as specified in RFC 5281 via NSSAAF. The phase 2 authentication method used is outside the scope of the present document but MS-CHAPv2 is depicted here as an example to show that the Nnssaaf_AIW_Authentication service offered by NSSAAF carries AVPs if the phase 2 authentication method is non-EAP.NOTE: As referenced in Section 14.1.11 of RFC 5281, allowing the use of phase 2 (inner) authentication method outside of tunnelled protocol leads to Man-in-the-Middle (MitM) vulnerability. Thus, it is assumed that the UE does not allow the use of phase 2 authentication method outside of TLS tunnel (i.e., the UE does not respond to requests for phase 2 authentication outside of the TLS tunnel). In environments where the use of phase 2 authentication outside of the tunnelled protocol cannot be prevented, EAP-TTLS implementations need to address this vulnerability by using EAP channel binding or cryptographic binding described in RFC 6678.
Step 28-31.
After EAP-TTLS phase 2 authentication is successfully completed, the rest of the procedures are same as steps 18-21 described in clause B.2.1.1, except that the EAP-Type is set to EAP-TTLS in the EAP Response message from the UE to the AUSF.
Up

V (Normative)  User consent requirements and mechanisms |R17|p. 270

V.1  Generalp. 270

V.1.1  Scopep. 270

User consent can be required for 3GPP features depending on local regulations. Therefore, this Annex describes the generic security requirements and procedures to support user consent enforcement in 3GPP services. While the use cases can differ, the Annex focuses on the common and generic aspects related to the storage, checking and revocation of the user consent.
The user consent related requirements and mechanism in the present document are applicable only when it is required by regional regulations or operator's local policy, not otherwise.
The term data processing in this Annex is used to convey the same meaning as in [101].
Up

V.1.2  Relationship between end-users and subscriberp. 270

It is assumed that the user consent is obtained from the end-users. The end-user(s) is the subscriber itself or authorize the subscriber to provide consent on behalf of the end-users. Alternatively, the end-users are authorized by the subscriber to provide the consent. That means user consent is always tied to the subscription information. How authorization is provided between the subscriber and the end-users is out-of-scope of this specification.

V.2  Requirementsp. 270

The UDM shall support the following services related to the user consent.
  • Retrieval of user consent parameters.
  • Notification of user consent parameters change.
The user consent parameters shall be stored in the UDM/UDR as subscription data.
The user consent parameters shall be bound to a SUPI/GPSI.
The user consent parameters shall be bound to the purpose of data processing.
The user consent parameters shall include whether the user consent is granted or not.
The user consent shall be effective only after the point in time that user consent was given.The user consent shall be effective until revoked. It means that there is no expiry/validity timer for the user consent parameters stored in the subscription data.
Up

V.3  User consent checkp. 270

Any NF that is deemed an enforcement point for user consent shall support to retrieve the user consent parameters from the UDM.
Any NF that is deemed an enforcement point for user consent shall not accept any services or requests for data processing unless user consent is granted.
Any NF that is deemed an enforcement point for user consent shall determine the purpose of data processing prior to the data processing. If the purpose of data processing is not implicitly known from the service request, the user consent enforcement point shall request it or otherwise deny the service.
NFs obtaining or checking the user consent parameters shall consider the user consent parameters as effective until revoked.
Up

V.4  User consent revocationp. 271

Any NF that is deemed an enforcement point for user consent shall support subscription to the user consent parameter change notification provided by the UDM.
Consumer NFs (processing the data pertaining to user consent) shall subscribe to UDM for user consent parameter change notification, except if the consent enforcement NF that is deemed an enforcement point is tracking of those NFs and is actively informing those consumer NFs in case of user consent revocation.
Upon notification of user consent revocation, any NF that is deemed an enforcement point for user consent shall no longer accept any service request for data processing subject to a revoked user consent.
Upon notification of user consent revocation, any NF that is deemed an enforcement point for user consent may notify other NFs to halt the processing of the data subject to the revoked user consent.
Upon notification of user consent revocation, NFs (processing the data pertaining to the revoked consent) shall halt processing and collection of the data.
Upon notification of user consent revocation, NFs may delete, quarantine, or temporarily retain the data pertaining to the revoked user consent based on local policies and legal constraints.
Up

W (Normative)  Security for multicast/broadcast service for 3GPP service |R17|p. 272

W.1  Generalp. 272

This clause describes the security requirements, procedures and handling for 5G Multicast/Broadcast Service (MBS).The general features for 5G MBS are described in TS 23.247.
NOTE: Security for Multicast-broadcast service for roaming is not supported.

W.2  Security requirementsp. 272

W.2.1  Requirements of MBSFp. 272

The security requirements on the NEF described in clause 5.9.2.3 of present document also apply to MBSF.

W.2.2  Requirements of MBSTFp. 272

The security requirements on the NEF described in clause 5.9.2.3 of present document also apply to MBSTF.

W.3  Security mechanisms for xMB-C/MB2-C and xMB-U/MB2-U interfacep. 272

The security aspects defined in clause 12 in present document is applicable for both MBSF and MBSTF. TLS based solution are reused to protect the interface xMB-C/MB2-C and xMB-U/MB2-U between AF and 5GC in MBS.

W.4  Security mechanisms for MBS traffic transmissionp. 272

W.4.1  Key derivation, management and distributionp. 272

W.4.1.1  Generalp. 272

If the security protection of MBS traffic is required, confidentiality and integrity protection as specified in clause 5.3 of TS 33.246 apply. The control-plane procedure and user-plane procedure are optionally supported in service layer. The control-plane procedure is only applicable for multicast sessions, while the user-plane procedure is applicable for both multicast sessions and broadcast sessions. The user plane security between UE and RAN shall be deactivated when 5GC shared MBS traffic delivery method for MBS data transmission is used to avoid redundant protection.
Up

W.4.1.2  Control-plane procedurep. 272

The multicast session security context consists of the MBS session ID, MBS keys and the corresponding key ID. The MBS keys include MBS Service Key (MSK) and MBS Traffic Key (MTK). MBS traffic is protected with the MTK. The MSK is used to protect the MTK when the MTK is delivered to the UE. The identification for every MSK and MTK are determined as specified in Clause 6.3.2.1 and clause 6.3.3.1 of TS 33.246.
The MBSF determines whether security protection to be applied or not for the MBS session based on locally configured policy or based on the information provided by the AF. If security protection to be applied, then the MBSF shall create the multicast session security context by generating the MSK and its key ID for a MBS session. Afterwards, the MBSF distributes the MSK with MBS session ID and its key ID to the MB-SMF and MBSTF. The MBSF shall also distribute them to MB-SMF either upon request by the MB-SMF (i.e., pull) or when a new MSK is generated (i.e., push). The MBSF may also include the MSK lifetime when it distributes the MSK to MBSTF.
Upon receiving the MSK from the MBSF, the MBSTF generates the MTK and its key ID for the MBS traffic protection. A new MTK may be generated based on the MBS session security policy. When the MBSTF generates a new MTK, the MBSTF shall multicast the MTK and its key ID after protecting it using the MSK as specified in TS 33.246. The MBSTF shall also provide the new MTK and its key ID to the MBSF.
During the MBS session creation for multicast communication as specified in clause 7.1.1 of TS 23.247, after receiving the description for an MBS session from the AF of content provider, the MBSF shall create the multicast session security context by generating an MSK and acquiring an MTK from the MBSTF. Afterwards, the MBSF distributes the muticast session security context to the MB-SMF via the Nmbsmf_MBSSession_Create Request message.
In the multicast session join and session establishment procedure, the SMF interacts with the MB-SMF to obtain the multicast session security context. Absence of the multicast security context indicates that security protection is not applied for the MBS session. The SMF shall provide the multicast session security context to the UE if received from the MB-SMF and the UE is authorized to use the required multicast service. The UE shall use the MTK in the received multicast session security context, to process the protected MBS traffic until it receives a new MTK update over the user-plane.
The MSK may be updated based on the request from MB-SMF or AS (e.g., due to the change of authorization information) or based on the local policy (e.g., key lifetime expiration). When the MSK is updated, the MBSF shall send the new MSK with MBS session ID and its key ID to the MB-SMF and then the MB-SMF shall trigger the session update as specified in clause 7.2.6 in TS 23.247. The MSK with MBS session ID and the corresponding key ID are delivered to the UEs that has joined the multicast session. The MBSF shall also send the new MSK with MBS session ID and its key ID to the MBSTF. The MBSTF may request a MSK to the MBSF when it does not have a valid MSK (e.g., due to the current MSK expiration).
The MTK may be updated based on the change of the authorization information or based on the local policy (e.g. key lifetime expiration). In such cases, the MBSF or MB-SMF may trigger the MTK update to the MBSTF. The key update request message shall include the MBS session ID. If the MBSTF has generated a new MTK, the MBSTF shall provide the new MTK to the MBSF. To improve the efficiency of MTK update, the updated MTK is delivered from MBSTF to the UE using MIKEY over UDP as specified in clause 6.3.3.2 of TS 33.246. The MSK is used to protect the updated MTK. The UE shall not send an error message to the MBSTF as a result of receiving an MTK message.
Up

W.4.1.3  User-plane procedurep. 273

The UE registers to the MBS service and receives the MBS traffic as specified in TS 33.246 with the following changes.
  • Multicast/Broadcast ServiceMBS Security Function (MBSSF) takes the role of the BM-SC in TS 33.246.
  • The UE authenticates to the MBSSF (i.e. MBSF or MBSTF) based on the GBA as in MBMS security (see TS 33.246) or based on the AKMA (see TS 33.535). When the AKMA is used, the MRK is derived from the KAF as specified in Annex F of TS 33.246 by replacing the Ks_NAF for the GBA_ME run with KAF. Furthermore, when the AKMA is used, the MUK is set to KAF. When the authorization of MBS service to the UE is required, the user id (e.g., GPSI) provided to the MBSSF by the AAnF shall be used.
  • The identifier(s) of MBS user service(s) in TS 26.502 is included in local configuration in MBSSF or in UDM as part of MBS subscription data for a UE, which identifies the user service(s) that the UE is allowed to join. After receiving the HTTP POST message(see clause 6.3.2 of TS 33.246) that] includes the identifier(s) of MBS user service(s), MBSSF shall authorize the UE based on local configuration if available. If no local configuration is available, the MBSSF should send verification request with user id (e.g., IMPI in GBA or GPSI in AKMA) and identifier(s) of MBS user service(s) to UDM to acquire the authorization result. If the UE is authorized, the MBSSF registers the UE to the MBS user service(s).
Up

W.4.2  Protection of the traffic transmissionp. 274

The service protection description in the Service Announcement implies the protection requirement of the traffic transmission in case the security protection is provided in service layer. It may include indications for which security procedures are supported by the network: control-plane procedure or user-plane procedure. If the support for user-plane procedure is indicated then the description should include also an indication of whether GBA or/and AKMA is supported.
The actual method of protection may vary depending on the type of data being transmitted, e.g. media streaming application or file download. Clause 6.6.2 and clause 6.6.3 of TS 33.246 apply to the protection of streaming data and protection of download data, respectively.
Up

W.4.3  Authentication and authorization aspects for the multicast sessionp. 274

The support for the optional-to-use authentication and authorization procedure for a 5G multicast session is specified in this clause.
AKMA/GBA is supported for authentication and authorization in user-plane procedure for security protection of MBS traffic, as specified in clause W.4.1.3 of the present document.

W.5  Security protection for interworking between 5MBS and eMBMSp. 274

Interworking between 5G MBS and eMBMS is supported at service layer. The procedures for inter system mobility with interworking at service layer is specified in clause 7.4 in TS 23.247.
The joint BM-SC+MBSF/MBSTF functionality provides the security protection for MBS traffic. During inter-system mobility, when the target system is EPS, the security protection specified in TS 33.246 applies. The security protection specified in present document applies to the case when the target system is 5GS.
Up

Up   Top   ToC