ETSI TS 133 310-2017 Universal Mobile Telecommunications System (UMTS) LTE Network Domain Security (NDS) Authentication Framework (AF) (V14 0 0 3GPP TS 33 310 version 14 0 0 Releas.pdf

《ETSI TS 133 310-2017 Universal Mobile Telecommunications System (UMTS) LTE Network Domain Security (NDS) Authentication Framework (AF) (V14 0 0 3GPP TS 33 310 version 14 0 0 Releas.pdf》由会员分享，可在线阅读，更多相关《ETSI TS 133 310-2017 Universal Mobile Telecommunications System (UMTS) LTE Network Domain Security (NDS) Authentication Framework (AF) (V14 0 0 3GPP TS 33 310 version 14 0 0 Releas.pdf（59页珍藏版）》请在麦多课文档分享上搜索。

1、 ETSI TS 1Universal Mobile TelNetwork Authenti(3GPP TS 33.3TECHNICAL SPECIFICATION133 310 V13.2.0 (2017elecommunications System (LTE; k Domain Security (NDS); ntication Framework (AF) .310 version 13.2.0 Release 1317-01) (UMTS); 13) ETSI ETSI TS 133 310 V13.2.0 (2017-01)13GPP TS 33.310 version 13.2.

2、0 Release 13Reference RTS/TSGS-0333310vd20 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 https:/portal.etsi.org/TB/ETSIDeliverableStatus.aspx If you find errors in the present document, please send your comment to o

6、ne of the 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 conte

7、nt of the 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 2017. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTMand the ETSI logo are Trade Ma

8、rks of ETSI 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.2.0 (2017-01)23G

9、PP TS 33.310 version 13.2.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 E

10、TSI SR 000 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, n

11、o investigation, 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

12、 Specification (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 del

13、iverables. 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 int

14、erpreted as 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.2.0 (2017-01)33GPP TS 33.310 version 13.2.0 Release 13Contents Inte

15、llectual Property Rights 2g3Foreword . 2g3Modal verbs terminology 2g3Foreword . 6g3Introduction 6g31 Scope 7g32 References 7g33 Definitions and abbreviations . 9g33.1 Definitions 9g33.2 Abbreviations . 10g34 Introduction to Public Key Infrastructure (PKI) 10g34.1 Manual Cross-certification . 10g34.2

16、 Cross-certification with a Bridge CA . 10g35 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 E

17、stablishment of secure communications . 15g35.2.2.1 NDS/IP case 15g35.2.2.1.1 NDS/IP case for the Za interface . 15g35.2.2.1.2 NDS/IP case for the Zb-interface 16g35.2.2.2 TLS case 16g35.2.3 Operator deregistration: Termination of interconnect agreement . 18g35.2.3a Interconnection CA registration 1

18、8g35.2.3b Interconnection CA deregistration 18g35.2.3c Interconnection CA certification creation . 18g35.2.3d Interconnection CA certification revocation . 18g35.2.3e Interconnection CA certification renewal . 19g35.2.4 SEG/TLS CA registration . 19g35.2.5 SEG/TLS CA deregistration . 19g35.2.6 SEG/TL

19、S CA certificate creation . 19g35.2.7 SEG/TLS CA certificate revocation . 19g35.2.8 SEG/TLS CA certificate renewal 19g35.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 20g35.2.10 End ent

20、ity deregistration . 20g35.2.10.1 SEG deregistration 20g35.2.10.2 TLS client deregistration . 20g35.2.10.3 TLS server deregistration 20g35.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 .

21、21g35.2.14 NE CA deregistration 21g35.2.15 NE CA certification creation 21g3ETSI ETSI TS 133 310 V13.2.0 (2017-01)43GPP TS 33.310 version 13.2.0 Release 135.2.16 NE CA certificate revocation 21g35.2.17 NE CA certificate renewal 21g36 Profiling 22g36.1 Certificate profiles 22g36.1.1 Common rules to a

22、ll certificates . 22g36.1.2 Interconnection CA Certificate profile . 23g36.1.3 SEG Certificate profile . 23g36.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 24g36.1.4b NE CA certificate

23、 profile 25g36.1a CRL profile 25g36.2 IKE negotiation and profiling . 25g36.2.1 Void 25g36.2.1b IKEv2 profile 26g36.2.2 Potential interoperability issues 26g36.2a TLS profiling 26g36.2a.1 TLS profile 26g36.2a.2 Potential interoperability issues 27g36.3 Path validation 27g36.3.1 Path validation profi

24、ling . 27g37 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 E

25、stablishing 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

26、.3 Security 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

27、Certificate . 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

28、.5.4.3 Initialization 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 (informative): Void . 41g3ETSI ETSI TS 133 310 V13.2.0 (2017-01)53GPP TS 33.310 version 13.2.0 Release 13Ann

29、ex B (informative): Decision 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 43g3

30、B.4.1 Need for nameConstraint 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 r

31、elevant Bridge CA experiences 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): Dec

32、ision for the CRL repository 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 . 51

33、g3F.2 TLS Certificate revocation . 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.2.0 (2017-01)6

34、3GPP TS 33.310 version 13.2.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

35、contents of the present document, 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 approve

36、d document under change control. 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

37、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 o

38、f 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 effec

39、ts 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. ETSI ETSI TS 133 310 V13.2.0 (2017-01)73GPP TS 33.310 version 13.2.0 Release 131 Scope The scope of this Technica

40、l 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 correspond

41、ing 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 a

42、nd 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 operators domain in case of Zb interface or in case of Za-interface between two security domains of the same o

43、perator. NOTE: In case two 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

44、 for IP-based protocols is 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 i

45、nter-operator links. For example, 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

46、 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 operators domain. An Annex contains information on the manual hand

47、ling of TLS certificates in case automatic enrolment and revocation according to NDS/AF for TLS is not implemented. 2 References The following documents contain provisions which, through reference in this text, constitute provisions of the present document. - References are either specific (identifi

48、ed by date of publication, edition number, version number, etc.) or non-specific. ETSI ETSI TS 133 310 V13.2.0 (2017-01)83GPP TS 33.310 version 13.2.0 Release 13- For a specific reference, subsequent revisions do not apply. - For a non-specific reference, the latest version applies. In the case of a

49、 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 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