TS 33.310
SA3
★
Network Domain Security (NDS) –
Authentication Framework (AF)
use "3GPP‑Page" to get the Word version
use "ETSI‑search" to get the PDF version
for a better overview, the Table of Contents (ToC) is reproduced
use "ETSI‑search" to get the PDF version
for a better overview, the Table of Contents (ToC) is reproduced
V16.3.0 (Wzip)
2020/03 57 p.
V15.2.0 (PDF)
2018/12 57 p.
V14.0.0
2016/12 58 p.
V13.2.0
2016/12 59 p.
V12.2.0
2014/09 58 p.
V11.2.0
2012/12 55 p.
V10.7.0
2012/12 56 p.
V9.8.0
2012/12 54 p.
V8.4.0
2010/06 45 p.
V7.1.0
2006/10 38 p.
V6.2.0
2004/09 31 p.
Rapporteur: Miss Jerichow, Anja
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.
The scope of thiS TS is limited to authentication of network elements, which are using NDS/IP or TLS.
full Table of Contents for TS 33.310 Word version: 16.2.0
1 Scope Word-p. 10
2 References
3 Definitions and abbreviations Word-p. 12
4 Introduction to Public Key Infrastructure (PKI)
5 Architecture and use cases of the NDS/AF
5.1 PKI architecture for NDS/AF
5.2 Use cases Word-p. 17
6 Profiling
5.2.1 Operator Registration: Creation of interconnect agreement
5.2.2 Establishment of secure communications Word-p. 19
5.2.3 Operator deregistration: Termination of interconnect agreement Word-p. 21
5.2.3a Interconnection CA registration [R7]
5.2.3b Interconnection CA deregistration [R7]
5.2.3c Interconnection CA certification creation [R7]
5.2.3d Interconnection CA certification revocation [R7] Word-p. 22
5.2.3e Interconnection CA certification renewal [R7]
5.2.4 SEG/TLS CA registration
5.2.5 SEG/TLS CA deregistration
5.2.6 SEG/TLS CA certificate creation
5.2.7 SEG/TLS CA certificate revocation Word-p. 23
5.2.8 SEG/TLS CA certificate renewal 
5.2.9 End entity registration
5.2.9 End entity registration
5.2.9.1 SEG registration [R7]
5.2.9.2 TLS client registration [R7]
5.2.9.3 TLS server registration [R7]
5.2.9.4 NE registration [R8] Word-p. 24
5.2.10 End entity deregistration
5.2.10.1 SEG deregistration [R7]
5.2.10.2 TLS client deregistration [R7]
5.2.10.3 TLS server deregistration [R7]
5.2.10.4 NE deregistration [R8]
5.2.11 End entity certificate creation
5.2.12 End entity certificate revocation
5.2.13 End entity certificate renewal
5.2.14 NE CA deregistration [R8]
5.2.15 NE CA certification creation [R8]
5.2.16 NE CA certificate revocation [R8] Word-p. 25
5.2.17 NE CA certificate renewal [R8]
6.1 Certificate profiles
7 Detailed description of architecture and mechanisms
6.1.1 Common rules to all certificates
6.1.2 Interconnection CA Certificate profile Word-p. 26
6.1.3 SEG Certificate profile
6.1.3a TLS entity certificate profile [R7] Word-p. 27
6.1.3b NE Certificate profile [R8]
6.1.4 SEG CA certificate profile
6.1.4a TLS client/server CA certificate profile [R7] Word-p. 28
6.1.4b NE CA certificate profile [R8]
6.1a CRL profile [R9]
6.2 IKE negotiation and profiling Word-p. 29
6.2a TLS profiling [R7] Word-p. 30
6.3 Path validation
6.1.2 Interconnection CA Certificate profile Word-p. 26
6.1.3 SEG Certificate profile
6.1.3a TLS entity certificate profile [R7] Word-p. 27
6.1.3b NE Certificate profile [R8]
6.1.4 SEG CA certificate profile
6.1.4a TLS client/server CA certificate profile [R7] Word-p. 28
6.1.4b NE CA certificate profile [R8]
7.1 Repositories
7.2 Life cycle management Word-p. 33
7.3 Cross-certification Word-p. 34
7.4 Revoking a SEG/TLS CA cross-certificate
7.5 Establishing secure connections between NDS/IP end entities using IKE on the Za interface
7.5a Establishing secure connections using TLS [R7] Word-p. 35
7.5b Establishing secure connections between NDS/IP entities on the Zb interface [R8]
7.6 CRL management
8 Backward compatibility for NDS/IP NE's and SEGs Word-p. 36
9 Certificate enrolment for base stations [R9] Word-p. 37
9.1 General
9.2 Architecture
9.3 Security Mechanisms Word-p. 38
9.4 Certificate Profiles
A Void
B Decision for the simple trust model Word-p. 45
9.4.1 General
9.4.2 Vendor Root CA Certificate
9.4.3 Vendor CA Certificate
9.4.4 Vendor Base Station Certificate
9.4.5 Operator Root CA Certificate Word-p. 39
9.4.6 Operator RA/CA Certificate
9.4.7 Intermediate Operator CA Certificate
9.4.8 Operator Base Station Certificate
9.5 CMPv2 Profiling Word-p. 40
9.5.1 General Requirements
9.5.2 Profile for the PKIMessage Word-p. 41
9.5.3 Profile for the PKIHeader Field
9.5.4 Profile for the PKIBody Field
9.6 CMPv2 Transport
B.1 Introduction
B.2 Requirements for trust model in NDS/AF
B.3 Cross-certification approaches
B.4 Issues with the Bridge CA approach
C Decision for the CRL repository access protocol for SEGs Word-p. 50
D Decision for storing the cross-certificates in CR Word-p. 51
E TLS protocol profile [R8] Word-p. 52
F Manual handling of TLS certificates [R8] Word-p. 55
G Example CMPv2 Message Flow for Initial Enrolment [R9] Word-p. 56
H Guidance on eNB Certificate Enrolment in MOCN LTE RAN sharing [R12] Word-p. 59
I Change history Word-p. 60
B.4.1 Need for nameConstraint support in certificates or strong legal bindings and auditing
B.4.2 Preventing name collisions Word-p. 47
B.4.3 Two redundant steps required for establishing trust
B.4.4 Long certificate chains connected with IKE implementation issues
B.4.5 Lack of existing relevant Bridge CA experiences Word-p. 48
B.5 Feasibility of the direct cross-certification approach
B.4.4 Long certificate chains connected with IKE implementation issues
B.4.5 Lack of existing relevant Bridge CA experiences Word-p. 48
