1、 ETSI TS 1Universal Mobile TelNetwork Authenti(3GPP TS 33.3TECHNICAL SPECIFICATION133 310 V13.1.0 (2016elecommunications System (LTE; k Domain Security (NDS); ntication Framework (AF) .310 version 13.1.0 Release 1316-04) (UMTS); 13) ETSI ETSI TS 133 310 V13.1.0 (2016-04)13GPP TS 33.310 version 13.1.
2、0 Release 13Reference RTS/TSGS-0333310vd10 Keywords LTE,SECURITY,UMTS ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-Prfecture de Grasse (06) N 78
3、03/88 Important notice The present document can be downloaded from: http:/www.etsi.org/standards-search The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the pri
4、or written authorization of ETSI. In case of any existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat. Users of the present
5、document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at http:/portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the
6、following services: https:/portal.etsi.org/People/CommiteeSupportStaff.aspx Copyright Notification No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI. The content of the
7、PDF version shall not be modified without the written authorization of ETSI. The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2016. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTMand the ETSI logo are Trade Marks of ETS
8、I registered for the benefit of its Members. 3GPPTM and LTE are Trade Marks of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. GSM and the GSM logo are Trade Marks registered and owned by the GSM Association. ETSI ETSI TS 133 310 V13.1.0 (2016-04)23GPP TS 33.3
9、10 version 13.1.0 Release 13Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000
10、 314: “Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards“, which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (https:/ipr.etsi.org/). Pursuant to the ETSI IPR Policy, no investig
11、ation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. Foreword This Technical Specifica
12、tion (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables.
13、 The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under http:/webapp.etsi.org/key/queryform.asp. Modal verbs terminology In the present document “shall“, “shall not“, “should“, “should not“, “may“, “need not“, “will“, “will not“, “can“ and “cannot“ are to be interpreted a
14、s described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions). “must“ and “must not“ are NOT allowed in ETSI deliverables except when used in direct citation. ETSI ETSI TS 133 310 V13.1.0 (2016-04)33GPP TS 33.310 version 13.1.0 Release 13Contents Intellectual P
15、roperty Rights 2g3Foreword . 2g3Modal verbs terminology 2g3Foreword . 6g3Introduction 6g31 Scope 7g32 References 8g33 Definitions and abbreviations . 9g33.1 Definitions 9g33.2 Abbreviations . 10g34 Introduction to Public Key Infrastructure (PKI) 10g34.1 Manual Cross-certification . 10g34.2 Cross-cer
16、tification with a Bridge CA . 11g35 Architecture and use cases of the NDS/AF 11g35.1 PKI architecture for NDS/AF . 11g35.1.1 General architecture 11g35.1.1.1 NDS/IP case 12g35.1.1.2 TLS case 13g35.2 Use cases 14g35.2.1 Operator Registration: Creation of interconnect agreement . 14g35.2.2 Establishme
17、nt of secure communications . 16g35.2.2.1 NDS/IP case 16g35.2.2.1.1 NDS/IP case for the Za interface . 16g35.2.2.1.2 NDS/IP case for the Zb-interface 16g35.2.2.2 TLS case 17g35.2.3 Operator deregistration: Termination of interconnect agreement . 18g35.2.3a Interconnection CA registration 18g35.2.3b
18、Interconnection CA deregistration 18g35.2.3c Interconnection CA certification creation . 18g35.2.3d Interconnection CA certification revocation . 19g35.2.3e Interconnection CA certification renewal . 19g35.2.4 SEG/TLS CA registration . 19g35.2.5 SEG/TLS CA deregistration . 19g35.2.6 SEG/TLS CA certi
19、ficate creation . 19g35.2.7 SEG/TLS CA certificate revocation . 20g35.2.8 SEG/TLS CA certificate renewal 20g35.2.9 End entity registration . 20g35.2.9.1 SEG registration 20g35.2.9.2 TLS client registration . 20g35.2.9.3 TLS server registration 20g35.2.9.4 NE registration 21g35.2.10 End entity deregi
20、stration . 21g35.2.10.1 SEG deregistration 21g35.2.10.2 TLS client deregistration . 21g35.2.10.3 TLS server deregistration 21g35.2.10.4 NE deregistration 21g35.2.11 End entity certificate creation . 21g35.2.12 End entity certificate revocation . 21g35.2.13 End entity certificate renewal . 21g35.2.14
21、 NE CA deregistration 21g35.2.15 NE CA certification creation 21g3ETSI ETSI TS 133 310 V13.1.0 (2016-04)43GPP TS 33.310 version 13.1.0 Release 135.2.16 NE CA certificate revocation 22g35.2.17 NE CA certificate renewal 22g36 Profiling 22g36.1 Certificate profiles 22g36.1.1 Common rules to all certifi
22、cates . 22g36.1.2 Interconnection CA Certificate profile . 23g36.1.3 SEG Certificate profile . 24g36.1.3a TLS entity certificate profile . 24g36.1.3b NE Certificate profile 24g36.1.4 SEG CA certificate profile 24g36.1.4a TLS client/server CA certificate profile 25g36.1.4b NE CA certificate profile 2
23、5g36.1a CRL profile 25g36.2 IKE negotiation and profiling . 26g36.2.1 Void 26g36.2.1b IKEv2 profile 26g36.2.2 Potential interoperability issues 26g36.2a TLS profiling 27g36.2a.1 TLS profile 27g36.2a.2 Potential interoperability issues 27g36.3 Path validation 27g36.3.1 Path validation profiling . 27g
24、37 Detailed description of architecture and mechanisms 27g37.1 Repositories 27g37.2 Life cycle management 30g37.3 Cross-certification 31g37.4 Revoking a SEG/TLS CA cross-certificate 31g37.5 Establishing secure connections between NDS/IP end entities using IKE on the Za interface 31g37.5a Establishin
25、g secure connections using TLS . 32g37.5b Establishing secure connections between NDS/IP entities on the Zb interface 32g37.6 CRL management . 32g38 Backward compatibility for NDS/IP NEs and SEGs . 33g39 Certificate enrolment for base stations . 34g39.1 General . 34g39.2 Architecture 34g39.3 Securit
26、y Mechanisms . 35g39.4 Certificate Profiles 35g39.4.1 General 35g39.4.2 Vendor Root CA Certificate . 35g39.4.3 Vendor CA Certificate 35g39.4.4 Vendor Base Station Certificate 35g39.4.5 Operator Root CA Certificate . 36g39.4.6 Operator RA/CA Certificate . 36g39.4.7 Intermediate Operator CA Certificat
27、e . 36g39.4.8 Operator Base Station Certificate . 36g39.5 CMPv2 Profiling 37g39.5.1 General Requirements . 37g39.5.2 Profile for the PKIMessage . 38g39.5.3 Profile for the PKIHeader Field 38g39.5.4 Profile for the PKIBody Field . 38g39.5.4.1 General 38g39.5.4.2 Initialization Request 39g39.5.4.3 Ini
28、tialization Response 39g39.5.4.4 Key Update Request and Key Update Response . 39g39.5.4.5 Certificate Confirm Request and Confirmation Response 40g39.6 CMPv2 Transport . 40g3Annex A: Void . 41g3ETSI ETSI TS 133 310 V13.1.0 (2016-04)53GPP TS 33.310 version 13.1.0 Release 13Annex B (informative): Deci
29、sion for the simple trust model 42g3B.1 Introduction 42g3B.2 Requirements for trust model in NDS/AF 42g3B.3 Cross-certification approaches . 42g3B.3.1 Manual Cross-certification . 42g3B.3.2 Cross-certification with a Bridge CA . 43g3B.4 Issues with the Bridge CA approach 43g3B.4.1 Need for nameConst
30、raint support in certificates or strong legal bindings and auditing . 43g3B.4.2 Preventing name collisions . 44g3B.4.3 Two redundant steps required for establishing trust . 44g3B.4.4 Long certificate chains connected with IKE implementation issues 44g3B.4.5 Lack of existing relevant Bridge CA experi
31、ences 45g3B.5 Feasibility of the direct cross-certification approach . 45g3B.5.1 Benefits of direct cross-certification. 45g3B.5.2 Memory and processing power requirements . 46g3B.5.3 Shortcomings 46g3B.5.4 Possible evolution path to a Bridge CA 46g3Annex C (informative): Decision for the CRL reposi
32、tory access protocol for SEGs . 47g3Annex D (informative): Decision for storing the cross-certificates in CR 48g3Annex E (normative): TLS protocol profile 49g3Annex F (informative): Manual handling of TLS certificates 51g3F.0 General . 51g3F.1 TLS certificate enrolment . 51g3F.2 TLS Certificate revo
33、cation . 51g3Annex G (informative): Example CMPv2 Message Flow for Initial Enrolment. 52g3Annex H (informative): Guidance on eNB Certificate Enrolment in MOCN LTE RAN sharing 55g3Annex I (informative): Change history . 56g3History 58g3ETSI ETSI TS 133 310 V13.1.0 (2016-04)63GPP TS 33.310 version 13.
34、1.0 Release 13Foreword This Technical Specification has been produced by the 3rdGeneration Partnership Project (3GPP). The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present do
35、cument, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows: Version x.y.z where: x the first digit: 1 presented to TSG for information; 2 presented to TSG for approval; 3 or greater indicates TSG approved document under change co
36、ntrol. y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document. Introduction For 3GPP systems there is a need for truly scalable entity
37、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 Secur
38、ity 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. Additiona
39、lly, requirements are presented for the used protocols and certificate profiles, to make it possible for operator IPsec and PKI implementations to interoperate. ETSI ETSI TS 133 310 V13.1.0 (2016-04)73GPP TS 33.310 version 13.1.0 Release 131 Scope The scope of this Technical Specification is limited
40、 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
41、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 domai
42、n 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 operators domain in case of Zb interface or in case of Za-interface between two security domains of the same operator. NOTE: In case two
43、 SEGs interconnect separate network regions under a single administrative authority (e.g. owned by the same mobile operator) then the Za-interface is not subject to interconnect agreements, but the decision on applying Za-interface is left to operators. The NDS architecture for IP-based protocols is
44、 illustrated in figure 1. ZaZbZbZbSEGASecurity Domain A Security Domain BSEGBNEA-1NEA-2ZbZbZbNEB-1NEB-2IKE “connection“ESP tunnelFigure 1: NDS architecture for IP-based protocols 1 In the case of TLS this Specification concentrates on authentication of TLS entities across inter-operator links. For e
45、xample, TLS is specified for inter-operator communications between IMS and non-IMS networks TS 33.203 9 and on the Zn interface in GBA TS 33.220 10. Authentication of TLS entities across intra-operator links is considered an internal issue for operators. However, NDS/AF can easily be adapted to the
46、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 operators domain. An Annex contains information on the manual handling of TLS certificates i
47、n case automatic enrolment and revocation according to NDS/AF for TLS is not implemented. ETSI ETSI TS 133 310 V13.1.0 (2016-04)83GPP TS 33.310 version 13.1.0 Release 132 References The following documents contain provisions which, through reference in this text, constitute provisions of the present
48、 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 (i
49、ncluding 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 3GPP TS 33.210: “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Network domain security; IP network layer security“. 2 IETF RFC 2986: “PKCS#10 Certification Request Syntax Specification Version 1.7“. 3 Void. 4 IETF RFC 4210: “Internet X.509 Public Key Infrastructure Certificate Management Protocol“. 5 IETF RFC 2252: “Lightweight Directo
