Content for TS 33.310 Word version: 19.1.0
0 Introduction
1 Scope
2 References
3 Definitions and abbreviations
3.1 Definitions
3.2 Abbreviations
4 Introduction to Public Key Infrastructure (PKI)
4.1 Manual Cross-certification
4.2 Cross-certification with a Bridge CA
...
...
0 Introduction p. 7
For 3GPP systems there is a need for truly scalable entity Authentication Framework (AF) since an increasing number of network elements and interfaces are covered by security mechanisms.
This specification provides a highly scalable entity authentication framework for 3GPP network nodes. This framework is developed in the context of the Network Domain Security work item, which effectively limits the scope to the control plane entities of the core network. Thus, the Authentication Framework will provide entity authentication for the nodes that are using NDS/IP.
Feasible trust models (i.e. how CAs are organized) and their effects are provided. Additionally, requirements are presented for the used protocols and certificate profiles, to make it possible for operator IPsec and PKI implementations to interoperate.
1 Scope p. 8
The scope of this Technical Specification is limited to authentication of network elements, which are using NDS/IP or TLS, and to Certificate Enrolment for Base Stations as described in the present document.
In the case of NDS/IP this specification includes both the authentication of Security Gateways (SEG) at the corresponding Za-interfaces and the authentication between NEs and between NEs and SEGs at the Zb-interface. Authentication of end entities (i.e. NEs and SEGs) in the intra-operator domain is considered an internal issue for operators. This is quite much in line with [1] which states that only Za is mandatory and that the security domain operator can decide if the Zb-interface is deployed or not, as the Zb-interface is optional for implementation. Validity of certificates may be restricted to the operator's domain in case of Zb interface or in case of Za-interface between two security domains of the same operator.
The NDS architecture for IP-based protocols is illustrated in Figure 1.
![Reproduction of 3GPP TS 33.310, Fig. 1: NDS architecture for IP-based protocols [1]](../img/tinv-33-310-1.gif)
In the case of TLS this Specification concentrates on authentication of TLS entities across inter-operator links. For example, TLS is specified for inter-operator communications between IMS and non-IMS networks TS 33.203 and on the Zn' interface in GBA TS 33.220. Authentication of TLS entities across intra-operator links is considered an internal issue for operators. However, NDS/AF can easily be adapted to the intra-operator use case since it is just a simplification of the inter-operator case when all TLS NEs and the PKI infrastructure belong to the same operator. Validity of certificates may be restricted to the operator's domain. An Annex contains information on the manual handling of TLS certificates in case automatic enrolment and revocation according to NDS/AF for TLS is not implemented.
2 References p. 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]
TS 33.210: "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Network domain security; IP network layer security".
[2]
RFC 2986: "PKCS#10 Certification Request Syntax Specification Version 1.7".
[3] Void.
[4]
RFC 4210: "Internet X.509 Public Key Infrastructure Certificate Management Protocol".
[5]
RFC 2252: "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions".
[6] Void.
[7]
"PKI basics - A Technical Perspective", November 2002, http://www.oasis-pki.org/pdfs/PKI_Basics-A_technical_perspective.pdf .
[8]
TR 21.905: "Vocabulary for 3GPP Specifications".
[9]
TS 33.203: "Access security for IP-based services".
[10]
TS 33.220: "Generic Authentication Architecture: Generic Bootstrapping Architecture".
[11] Void.
[12] Void.
[13] Void.
[14]
RFC 5280: "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile".
[15]
RFC 4945: "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX".
[16] Void.
[17] Void.
[18]
RFC 6712: "Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP)".
[19]
RFC 4211: "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)".
[20]
RFC 2818: "HTTP Over TLS".
[21]
RFC 5922: "Domain Certificates in the Session Initiation Protocol (SIP)".
[22]
RFC 5924: "Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates".
[23] Void.
[24] Void.
[25]
RFC 1035: "Domain Names - Implementation and Specification".
[26] Void.
[27] Void.
[28] Void.
[29] Void.
[30] Void.
[31]
TS 23.251: "Network sharing; Architecture and functional description".
[32]
TS 32.508: "Telecommunication management; Procedure flows for multi-vendor plug-and-play eNode B connection to the network".
[33]
TS 32.509: "Telecommunication management; Data formats for multi-vendor plug and play eNode B connection to the network".
[34] Void.
[35] Void.
[36] Void.
[37] Void.
[38] Void.
[39] Void.
[40] Void.
[41] Void.
[42]
RFC 7296: "Internet Key Exchange Protocol Version 2 (IKEv2)".
[43]
RFC 7427: "Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)".
[44] Void.
[45] Void.
[46] Void.
[47]
RFC 6960: " X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP".
[48]
RFC 8201: "Path MTU Discovery for IP version 6".
[49]
RFC 8446: "The Transport Layer Security (TLS) Protocol Version 1.3".
[50]
RFC 9113: "HTTP/2".
[51]
RFC 6066: "Transport Layer Security (TLS) Extensions: Extension Definitions".
[52]
RFC 6125: "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)".
[53]
RFC 7633: "X.509v3 Transport Layer Security (TLS) Feature Extension".
[54]
RFC 5246: "The Transport Layer Security (TLS) Protocol Version 1.2".
[55]
TS 23.003: "Numbering, addressing and identification".
[56]
TS 29.510: "5G System; Network function repository services; Stage 3".
[57]
TS 29.571: "5G System; Common Data Types for Service Based Interfaces; Stage 3".
[58]
RFC 6979: "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)".
[59]
CA-Browser-Forum-BR-1.8.0, August 2021, https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.8.0.pdf .
[60]
GSMA FS.34: Key Management for 4G and 5G inter-PLMN Security, https://www.gsma.com/security/resources/fs-34-key-management-for-4g-and-5g-inter-plmn-security/ .
[61]
RFC 9310: "X.509 Certificate Extension for 5G Network Function Types".
[62]
TS 33.501: "Security architecture and procedures for 5G system".
[63]
draft-ietf-lamps-nf-eku-01: "X.509 Certificate Extended Key Usage (EKU) for 5G Network Functions".
[64]
RFC 4122:" A Universally Unique Identifier (UUID) URN Namespace".
[65]
RFC 9110: "HTTP Semantics".
3 Definitions and abbreviations p. 11
3.1 Definitions p. 11
For the purposes of the present document, the definitions given in TR 21.905 and the following definitions apply:
CA:
"Certification Authority", a PKI entity issuing X.509 certificates
Interconnection CA:
The CA that issues cross-certificates on behalf of a particular operator to the SEG CAs of other domains with which the operator's SEGs have interconnection.
Interconnect Agreement:
In the context of this specification an interconnect agreement is an agreement by two operators to establish secure communications. This may be for the purpose of protecting various forms of communications between the operators, e.g. GPRS roaming, MMS interconnect, WLAN roaming and IMS interconnect.
Local CR:
Repository that contains cross-certificates.
Local CRL:
Repository that contains cross-certificate revocations.
OSCP:
Online Certificate Status Protocol. Protocol for revocation checking which is can also be used offline in so called "OCSP stapling". Can be used instead of CRL or together with CRL.
PSK:
Pre-Shared Key. Method of authentication used by IKE between SEG in NDS/IP [1].
Public CRL:
Repository that contains revocations of SEG and CA certificates and can be accessed by other operators.
RA:
"Registration Authority", an optional PKI entity that does not issue certificates and is separate from the CA.
RA/CA:
The PKI entity or entities in the operator network issuing certificates, and making them available to base stations via CMPv2.
SEG CA:
The CA that issues end entity certificates to SEGs within a particular operator's domain.
3.2 Abbreviations p. 12
For the purposes of the present document, the abbreviations given in TR 21.905 and the following abbreviations apply:
AF
Authentication Framework
CA
Certification Authority
CR
Certificate Repository
CRL
Certificate Revocation List
GBA
Generic Bootstrapping Architecture
IMS
IP Multimedia Subsystem
NDS
Network Domain Security
OCSP
Online Certificate Status Protocol
PKCS
Public-Key Cryptography Standards
PKI
Public Key Infrastructure
POP
Proof Of Possession
PSK
Pre-Shared Key
RA
Registration Authority
SEG
Security Gateway
VPN
Virtual Private Network
Za
Interface between SEGs belonging to different networks/security domains (a Za interface may be an intra or an inter operator interface).
Zb
Interface between SEGs and NEs and interface between NEs within the same network/security domain
4 Introduction to Public Key Infrastructure (PKI) p. 12
PKI Forum's "PKI basics - A Technical Perspective" [7] provides a concise vendor neutral introduction to the PKI technology. Thus only two cross-certification aspects are described in this introduction section.
Cross-certification is a process that establishes a trust relationship between two authorities. When an authority A is cross-certified with authority B, the authority A has chosen to trust certificates issued by the authority B. Cross-certification process enables the users under both authorities to trust the other authority's certificates. Trust in this context equals being able to authenticate.
4.1 Manual Cross-certification p. 12
Mutual cross-certifications are established directly between the authorities. This approach is often called manual cross-certification. In manual cross-certification the authority makes decisions about trust locally. When an authority A chooses to trust an authority B, the authority A signs the certificate of the authority B and distributes the new certificate (B's certificate signed by A) locally.
The disadvantage of this approach is that it often results in scenarios where there needs to be a lot of certificates available for the entities doing the trust decisions: There needs to be a certificate signed by the local authority for each security domain the local authority wishes to trust. However, all the certificates can be configured locally and are locally signed, so the management of them is often flexible.
4.2 Cross-certification with a Bridge CA p. 12
The bridge CA is a concept that reduces the amount of certificates that needs to be configured for the entity that does the certificate checking. The name "bridge" is descriptive; when two authorities are mutually cross-certified with the bridge, the authorities do not need to know about each other. Authorities can still trust each other because the trust in this model is transitive (A trusts bridge, bridge trusts B, thus A trusts B and vice versa). The bridge CA acts like a bridge between the authorities. However, the two authorities shall also trust that the bridge does the right thing for them. All the decisions about trust can be delegated to the bridge, which is desirable in some use cases. If the bridge decides to cross-certify with an authority M, the previously cross-certified authorities start to trust M automatically.
Bridge CA style cross-certifications are useful in scenarios where all entities share a common authority that everybody believes to work correctly for them. If an authority needs to restrict the trust or access control derived from the bridge CA, it additionally needs to implement those restrictions.
