ETSI TS 132 372-2017 Digital cellular telecommunications system (Phase 2+) (GSM) Universal Mobile Telecommunications System (UMTS) LTE Telecommunication management Security service_1.pdf

1、 ETSI TS 132 372 V14.0.0 (2017-04) Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); LTE; Telecommunication management; Security services for Integration Reference Point (IRP); Information Service (IS) (3GPP TS 32.372 version 14.0.0 Relea

2、se 14) TECHNICAL SPECIFICATION ETSI ETSI TS 132 372 V14.0.0 (2017-04)13GPP TS 32.372 version 14.0.0 Release 14Reference RTS/TSGS-0532372ve00 Keywords GSM,LTE,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 00

3、017 - NAF 742 C Association but non lucratif enregistre la Sous-Prfecture de Grasse (06) N 7803/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 e

4、lectronic and/or print versions of the present document shall not be modified without the prior 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

5、(PDF) version kept on a specific network drive within ETSI Secretariat. Users of the present 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/ETSIDel

6、iverableStatus.aspx If you find errors in the present document, please send your comment to one 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, inclu

7、ding photocopying and microfilm except as authorized by written permission of ETSI. The content 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 I

8、nstitute 2017. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTMand the ETSI logo are Trade Marks 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. oneM2M logo is protected for t

9、he benefit of its Members GSM and the GSM logo are Trade Marks registered and owned by the GSM Association. ETSI ETSI TS 132 372 V14.0.0 (2017-04)23GPP TS 32.372 version 14.0.0 Release 14Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declar

10、ed 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 314: “Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards“, which i

11、s 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 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 ET

12、SI 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 Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). The present document may refer to technical specifications or

13、reports using their 3GPP identities, UMTS identities or GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under http:/webapp.etsi.org/key/queryform.asp. Modal verbs term

14、inology In the present document “shall“, “shall not“, “should“, “should not“, “may“, “need not“, “will“, “will not“, “can“ and “cannot“ are to be interpreted 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 i

15、n ETSI deliverables except when used in direct citation. ETSI ETSI TS 132 372 V14.0.0 (2017-04)33GPP TS 32.372 version 14.0.0 Release 14Contents Intellectual Property Rights 2g3Foreword . 2g3Modal verbs terminology 2g3Foreword . 4g3Introduction 4g31 Scope 6g32 References 6g33 Definitions and abbrevi

16、ations . 6g33.1 Definitions 6g33.2 Abbreviations . 7g34 System overview 7g34.1 System context . 7g34.2 Security Architecture 8g34.2.1 Security Features offered by IP Transport Network (IPsec or NDS) 8g34.2.2 Limitations of IP transport layer security . 9g34.3 Compliance rules 9g35 Security Services

17、9g35.1 Authentication Security Service . 10g35.1.1 Mutual Authentication 10g35.2 Authorization Security Service . 11g35.3 Activity Log Security Service 12g35.4 File Integrity Security Service 12g36 Information Object Classes 12g36.1 Class diagram . 12g36.1.1 Attributes and Relationships . 13g36.1.1.

18、1 Class Diagram . 13g36.2 Information Object Class Definitions . 13g36.2.1 Credential 13g36.2.1.1 Definition 13g36.2.1.2 Attributes . 13g36.2.2 Signature . 13g36.2.2.1 Definition 13g36.2.2.2 Attributes . 13g36.4 Information attribute definition 13g36.4.1 Definition and legal values . 13g37 Interface

19、 definition . 14g37.1 Credential transfer interface . 14g37.2 Signature transfer Interface 14g3Annex A(informative): Change history . 15g3History 16g3ETSI ETSI TS 132 372 V14.0.0 (2017-04)43GPP TS 32.372 version 14.0.0 Release 14Foreword This Technical Specification has been produced by the 3rdGener

20、ation 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 document, it will be re-released by the TSG with an identifying change of release date

21、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 control. y the second digit is incremented for all changes of substance, i.e. technical

22、 enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document. Introduction The present document is part of a TS-family covering the 3rdGeneration Partnership Project; Technical Specification Group Services and System As

23、pects; Telecommunication management; as identified below: 32.371: “Security Management concept and requirements“. 32.372: “Security services for Integration Reference Points (IRP); Information Service (IS)“. 32.376: “Security services for Integration Reference Point (IRP); Solution Set (SS) definiti

24、ons“. In 3GPP SA5 context, IRPs are introduced to address process interfaces at the Itf-N interface. The Itf-N interface is built up by a number of Integration Reference Points (IRPs) and a related Name Convention, which realise the functional capabilities over this interface. The basic structure of

25、 the IRPs is defined in 3GPP TS 32.101 1 and 3GPP TS 32.102 2. An IRP consists of IRPManager and IRPAgent. Usually there are three types of transaction between IRPManager and IRPAgent, which are operation invocation, notification, and file transfer. However, there are different types of intentional

26、threats against the transaction between IRPManagers and IRPAgents. All the threats are potential risks of damage or degradation of telecommunication services, which operators should take measures to reduce or eliminate to secure the telecommunication service, network, and data. By introducing Securi

27、ty Management, the present document describes security mechanisms to relieve the threats between IRPManagers and IRPAgents. As described in 3GPP TS 32.101 1, the architecture of Security Management is divided into two layers: Layer A - Application Layer. Layer B - O Principles and high level require

28、ments“. 2 3GPP TS 32.102: “Telecommunication management; Architecture“. 3 ITU-T Recommendation M.3016 (1998): “TMN security overview“. 4 3GPP TS 33.102: “3G security; Security architecture“. 5 ITU-T Recommendation X.800: “Security Architecture for OSI for CCITT Applications“. 6 3GPP TS 32.371: “Tele

29、communication management; Security Management concept and requirements“. 7 3GPP TS 32.150: “Telecommunication management; Integration Reference Point (IRP) Concept and definitions“. 8 3GPP TS 32.373: “Telecommunication management; Security Service for Integration Reference Point (IRP):Common Object

30、Request Broker Architecture (CORBA) Solution“. 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the following terms and definitions apply. IRP: See 3GPP TS 32.101 1. IRPAgent: See 3GPP TS 32.102 2. IRPManager: See 3GPP TS 32.102 2. Operations System (OS): ind

31、icates a generic management system, independent of its location level within the management hierarchy ETSI ETSI TS 132 372 V14.0.0 (2017-04)73GPP TS 32.372 version 14.0.0 Release 14The present document makes use of the following terms and definitions from 3GPP TS 32.371 6: access control: prevention

32、 of unauthorized use of a resource, including the prevention of use of a resource in an unauthorized manner authentication: See data origin authentication and peer element authentication in 3GPP TS 32.371 6. authorization: granting of rights, which includes the granting of access based on access rig

33、hts credential: Authentication and Authorization data that can be used to authenticate the claimer is what it claims to be and authorize the claimers access rights signature: cryptographic information appended to the transferred management information that allows a receiver to verify integrity of th

34、e transferred management information. 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: CM Configuration Management EM Element Manager IOC Information Object Class IRP Integration Reference Point IS Information Service (see 3GPP TS 32.101 1) Itf-N Interfa

35、ce N NDS Network Domain Security NE Network Element NM Network ManagerNRM Network Resource Model OS Operations System PM Performance Management SAS Security Attribute Service TMN Telecom Management Network UML Unified Modelling Language (OMG) UMTS Universal Mobile Telecommunications System 4 System

36、overview 4.1 System context The general definition of the System Context for the present IRP is found in 3GPP TS 32.150 7, clause 4.7. In addition, the set of related IRP(s) relevant to the present IRP is shown in the two diagrams below. Figure 4.1.1: System Context A NEs EM IRPAgent IRPManager NM I

37、tf-N Se c u re d xxx IRPs ETSI ETSI TS 132 372 V14.0.0 (2017-04)83GPP TS 32.372 version 14.0.0 Release 14Figure 4.1.2: System Context B 4.2 Security Architecture Figure 4.2.1 shows a view of the architecture of the IRPAgent and IRPManager in the context of a Secured IRP. Secured communication betwee

38、n IRPManager and IRPAgent is realised by using one or more Security Services to address the specific identified threats Note that there is no mandatory need to support all of the security services, these services may be used on an as needed basis in order to counter identified threat(s). The agreeme

39、nts regarding which security services are necessary are subject to network operator and equipment vendor negotiation and are not the subject of standardization. ManagementInformationIRPManager IRPAgentSecurity Servicesused by IRPManagerSecurity ServicesUsed by IRPAgentItf-NFigure 4.2.1: Security Arc

40、hitecture for a secured IRP The environment in which the IRPManager and IRPAgent operate has a big impact on identifying set of potential threats and appropriate security services to be deployed. If the Itf-N used is within the operators closed network, which has no possibility of connection to exte

41、rnal pubic networks there may not be a need for using any security services. However if the Itf-N used can be accessed via a public network, then if Security Services are not used for the communication between yyyIRP and IRPManager then the IRP can be considered as being non-secured IRP. To enable S

42、ecured communication between a particular IRPManager and its corresponding yyyIRP, both have to use their respective IRPManager, and IRPAgent side Security Services appropriate to the identified threats. Some security services are expensive both in terms of license costs, and machine CPU cycles, it

43、is not advised to make use of all the security services unless they are indeed necessary as the resulting solution will be impacted both by costs such as larger processing machines (to cope with the additional protocols and authorization checking algorithms) with possibly degraded performance when c

44、ompared with an unsecured implementation. 4.2.1 Security Features offered by IP Transport Network (IPsec or NDS) The IP transport network may be protected by using IPSec, or NDS (Network Domain Security. Itf-N NE IRPAgent IRPManager NM Sec u re d xxx IRPs ETSI ETSI TS 132 372 V14.0.0 (2017-04)93GPP

45、TS 32.372 version 14.0.0 Release 14It is assumed throughout this IS that some of the Security Services are provided by a transport network which may be secured as per informative annexes A and B of 3GPP TS 32.371 6 to provide the following Security capabilities: 1. Confidentiality of authentication

46、information. 2. Confidentiality of session identification information. 3. Data integrity. 4.2.2 Limitations of IP transport layer security Figure 4.2.2 shows several inter connected ORBs which can communicate with each other. IPSec provides a protected point to point transport connection. However sh

47、ould any unprotected transport allow an alien ORB onto the CORBA bus, the “protected “ communications links will guard against an alien ORB, as it will share any inter-ORB communications via the IIOP protocol from any ORB which somehow gains access to the CORBA bus. Once access to the CORBA bus has

48、been obtained, normal inter ORB communications will permit access to any connected ORB, even if there is a point to point IPSec connection to the “protected“ ORB. Figure 4.2.2: TLS and ORB to ORB communication Risks For example ORB 3 uses an unprotected IP transport connection. Since ORB 3 can commu

49、nicate to ORB 2, it can also use any of the “protected“ ORBs 1,2, 4, 5 or 6. i.e. TLS needs to be used cautiously. In Summary, IPSEC is a cheap, and efficient manner of protecting point to point communications links. Care has to be taken in the overall design of the secure system regarding how all systems intercommunicate and the protection offered at each ORB in the network, as point to point security is only as strong as the weakest link. 4.3 Compliance rules All of the security services described in the present document may be used on