Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TR 33.776  Word version:  19.0.0

Top   Top   None   None   Next
0…   5…

 

0  Introductionp. 7

5G Service Based Architecture (SBA) is secured using X.509 certificates across the large number of SBA components and corresponding Network Functions (NFs). Virtualization and increased modularity of NFs has resulted in multi-vendor environments becoming more prevalent. It is now common for NFs to come from different vendors and for the cloud native environment in which they run to come from yet another vendor and for all of these to be independent of the Certificate Authority that is authoritative for the certificates used to secure communications. In such deployments, it is impractical to manage certificates manually.
Automated Certificate Management Environment (ACME) [2] was defined specifically for automated certificate management and is particularly well suited for some scenarios. Infrastructure deployment such as NFs deployed on cloud native platforms often have built-in support for ACME, so it is a natural fit. Another important benefit of ACME is automated validation of authority to represent an identifier (i.e., to be authoritative for the resource for which the certificate is issued). This is particularly helpful for multi-vendor environments and in cross-carrier scenarios.
Additional work is required to determine the feasibility of the use of ACME in 5G SBA.
Up

1  Scopep. 8

The scope of this document is to identify key issues and study solutions addressed using ACME for automated certificate management in SBA.
Areas of study include:
  • Automated certificate management protocol and procedures for certificate life cycle events (i.e., enrolment, renewal, and revocation) within 5G SBA (i.e., to be used by operator CAs and all 5GC NFs including NRF, SCP, SEPP, etc.), including the following:
    • ACME transport and request/response messages for 5G SBA use cases
    • ACME certificate profiles for all 5G SBA entities
  • Mechanisms for establishing initial trust and chain of trust of Certificate Authority hierarchies, including the following:
    • Existing ACME challenge types and if any new challenge types are needed for 3GPP use cases:
      • Creation, deletion, rotation, revocation and storage of the certificates
    • Ability to automate ACME challenge validation
    • Suitability of existing mechanisms when 5G SBA is for standalone NPN (SNPN)
  • Call flow of the messages exchanged between different entities in the chain of trust.
Up

2  Referencesp. 8

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
  • References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
  • For a specific reference, subsequent revisions do not apply.
  • For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]
TR 21.905: "Vocabulary for 3GPP Specifications".
[2]
RFC 8555:  "Automatic Certificate Management Environment (ACME)".
[3]
TS 33.310: "Network Domain Security (NDS); Authentication Framework (AF) ".
[4]
RFC 8738:  "Automated Certificate Management Environment (ACME) IP Identifier Validation Extension".
[5]
RFC 8739:  "Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME)".
[6]
RFC 8823:  "Extensions to Automatic Certificate Management Environment for End-User S/MIME Certificates".
[7]
SP-231787: "New Study of ACME for Automated Certificate Management in SBA".
[8]
TS 33.501: "Security architecture and procedures for 5G System".
[9]
RFC 9447:  "Automated Certificate Management Environment (ACME) Challenges Using an Authority Token".
[10]
RFC 9448:  "TNAuthList Profile of Automated Certificate Management Environment (ACME) Authority Token".
[11]
TS 23.502: "Procedures for the 5G System (5GS)".
[12]
RFC 7519:  " JSON Web Token (JWT)".
[13]
TS 29.571: "5G System; Common Data Types for Service Based Interfaces; Stage 3".
[14]
RFC 9110:  "HTTP Semantics".
[15]
RFC 7515:  "JSON Web Signature (JWS)".
[16]
RFC 4122:  "Universally Unique IDentifier (UUID) URN Namespace".
[17]
TS 23.003: "Numbering, addressing and identification".
[18]
RFC 5280:  "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile".
[19]
RFC 8738:  "Automated Certificate Management Environment (ACME) IP Identifier Validation Extension".
[20]
RFC 8126:  "Guidelines for Writing an IANA Considerations Section in RFCs".
Up

3  Definitions of terms, symbols and abbreviationsp. 9

3.1  Termsp. 9

For the purposes of the present document, the terms given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.
Void.

3.2  Symbolsp. 9

For the purposes of the present document, the following symbols apply:
Void.

3.3  Abbreviationsp. 9

For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.
CA
Certificate Authority
NPN
Non-Public Network
NRF
Network Repository Function
SCP
Service Communication Proxy
SEPP
Security Edge Protection Proxy
SNPN
Stand-Alone Non-Public Network
Up

4  Assumptionsp. 10

Clause 10 of TS 33.310 specifies a framework for certificate provisioning and managements for 5G NFs. Though the enrolment protocol is CMPv2, many of the procedures, such as those for initial trust establishment and for certificate revocation status verification, are independent of the enrolment protocol. Therefore, many of the procedures are expected to be re-used.

Up   Top   ToC