1、 AMERICAN NATIONAL STANDARD FOR TELECOMMUNICATIONS ATIS-1000034.2010 (R2015) NEXT GENERATION NETWORK (NGN): SECURITY MECHANISMS AND PROCEDURES As a leading technology and solutions development organization, ATIS brings together the top global ICT companies to advance the industrys most-pressing busi
2、ness priorities. Through ATIS committees and forums, nearly 200 companies address cloud services, device solutions, emergency services, M2M communications, cyber security, ehealth, network evolution, quality of service, billing support, operations, and more. These priorities follow a fast-track deve
3、lopment lifecycle from design and innovation through solutions that include standards, specifications, requirements, business use cases, software toolkits, and interoperability testing. ATIS is accredited by the American National Standards Institute (ANSI). ATIS is the North American Organizational
4、Partner for the 3rd Generation Partnership Project (3GPP), a founding Partner of oneM2M, a member and major U.S. contributor to the International Telecommunication Union (ITU) Radio and Telecommunications sectors, and a member of the Inter-American Telecommunication Commission (CITEL). For more info
5、rmation, visit . AMERICAN NATIONAL STANDARD Approval of an American National Standard requires review by ANSI that the requirements for due process, consensus, and other criteria for approval have been met by the standards developer. Consensus is established when, in the judgment of the ANSI Board o
6、f Standards Review, substantial agreement has been reached by directly and materially affected interests. Substantial agreement means much more than a simple majority, but not necessarily unanimity. Consensus requires that all views and objections be considered, and that a concerted effort be made t
7、owards their resolution. The use of American National Standards is completely voluntary; their existence does not in any respect preclude anyone, whether he has approved the standards or not, from manufacturing, marketing, purchasing, or using products, processes, or procedures not conforming to the
8、 standards. The American National Standards Institute does not develop standards and will in no circumstances give an interpretation of any American National Standard. Moreover, no person shall have the right or authority to issue an interpretation of an American National Standard in the name of the
9、 American National Standards Institute. Requests for interpretations should be addressed to the secretariat or sponsor whose name appears on the title page of this standard. CAUTION NOTICE: This American National Standard may be revised or withdrawn at any time. The procedures of the American Nation
10、al Standards Institute require that action be taken periodically to reaffirm, revise, or withdraw this standard. Purchasers of American National Standards may receive current information on all standards by calling or writing the American National Standards Institute. Notice of Disclaimer then discu
11、sses transport security for signalling and OAMP, and media security. It then describes audit-trail-related mechanisms and finally describes the provisioning. The security mechanisms described in this standard are based on use of the trust model defined in ATIS 100029.The list of security mechanisms
12、described in this standard is not exhaustive. NGN providers are encouraged to support additional security tools, capabilities and operational measures as needed beyond the mechanisms specified in this standard for NGN security protection. ATIS-1000034.2010 II Foreword The information contained in th
13、is Foreword is not part of this American National Standard (ANS) and has not been processed in accordance with ANSIs requirements for an ANS. As such, this Foreword may contain material that has not been subjected to public review or a consensus process. In addition, it does not contain requirements
14、 necessary for conformance to the Standard. The Alliance for Telecommunication Industry Solutions (ATIS) serves the public through improved understanding between providers, customers, and manufacturers. The Packet Technologies and Systems Committee (PTSC) develops and recommends standards and techni
15、cal reports related to services, architectures, and signaling, in addition to related subjects under consideration in other North American and international standards bodies. PTSC coordinates and develops standards and technical reports relevant to telecommunications networks in the U.S., reviews an
16、d prepares contributions on such matters for submission to U.S. ITU-T and U.S. ITU-R Study Groups or other standards organizations, and reviews for acceptability or per contra the positions of other countries in related standards development and takes or recommends appropriate actions. ANSI guidelin
17、es specify two categories of requirements: mandatory and recommendation. The mandatory requirements are designated by the word shall and recommendations by the word should. Where both a mandatory requirement and a recommendation are specified for the same criterion, the recommendation represents a g
18、oal currently identifiable as having distinct compatibility or performance advantages. Suggestions for improvement of this document are welcome. They should be sent to the Alliance for Telecommunications Industry Solutions, PTSC, 1200 G Street NW, Suite 500, Washington, DC 20005. At the time of cons
19、ensus on this document, PTSC, which was responsible for its development, had the following roster: M. Dolly, PTSC Chair (AT 1. trusted, 2. trusted but vulnerable, 3. un-trusted, that are dependent on operational control, location, and connectivity to other device/network elements. These three zones
20、are illustrated in the security trust model shown in Figure 1. Y2704(09)_F01TrustedzoneUntrusted zone Trusted butvulnerablezoneNetwork elements controlled bythe NGN providerNetwork elements not always controlledby the NGN providerNGNnetworkelementsNetworkborderelements(NBE)TETEProvider-controlledequ
21、ipment TE-BETETETE-BEFigure 1 Security trust model/ATIS-1000029 A “trusted network security zone” or “trusted zone” in short, is a zone where a NGN providers network elements and systems reside and never communicate directly with customer equipment or other domains. The common characteristics of NGN
22、 network elements in this zone are that 1). They are under the full control (for provisioning, maintenance, and operational control) of the NGN provider, 2) They are located in the NGN provider domain, and ATIS-1000034.2010 9 3) They communicate only with other elements in the “trusted” zone and wit
23、h elements in the “trusted-but-vulnerable” zone. It should not be assumed that because a network element is in a trusted zone, it is necessarily secure. The network elements in the “trusted zone” will be protected by a combination of various methods. Some examples are physical security of the NGN ne
24、twork elements, general hardening of the systems, use of secure signalling, security for management messages, and the use of a separate VPN within the (MPLS/)IP network. The same combination of methods is expected to be applied to secure communication within the “trusted” zone and between NGN networ
25、k elements in the “trusted” zone and the “trusted-but-vulnerable” zone. A “trusted but vulnerable network security zone”, or “trusted but vulnerable zone” in short, is a zone where the network elements/devices communicate with elements in the “un-trusted” zone, which is why they are “vulnerable”. In
26、 addition, they communicate with elements in the “trusted” zone. Like network elements in the “trusted” zone, the equipment is under the control of the NGN provider, though the equipment may be located within or outside the NGN providers premises. Their major security function is to protect the NEs
27、in the trusted zone from the security attacks originated in the un-trusted zone. The combination of methods applied to secure communication between NGN network elements in the “trusted-but-vulnerable” zone and the “untrusted” zone may differ from those used to secure communication in the “trusted” z
28、one. Elements that are located on the NGN providers domain with connectivity to elements outside the trusted zone are referred to as network border elements (NBEs). Examples of these are the: Network Border elements that interface to the service control or transport elements of the NGN provider in t
29、he trusted zone in order to provide the user/subscriber access to the NGN providers network for services and/or transport. Examples of these are access Session Border Controllers (SBCs) at the UNI and interconnect SBCs at the NNI. “Domain border elements (DBEs)” that reside on the border between two
30、 domains within a single service providers network. “Device configuration a base station router (BSR), a network element that integrates the base station, radio network controller and router functionalities for wireless access; an optical unit (ONU) within a user/subscribers residence. ATIS-1000034.
31、2010 10 The “trusted-but-vulnerable” zone, comprised of NBEs, will be protected by a combination of various methods. Some examples are physical security of the NGN network elements, general hardening of the systems, , use of secure signalling for all signalling messages sent to NGN network elements
32、in the “trusted” zone, security for OAMP messages, and packet filters and firewalls. An “un-trusted” zone includes all network elements of customer networks and possibly peer networks or other NGN provider domains which are connected to the NGN Providers network border elements. In the “un-trusted”
33、zone comprised of terminal equipment, equipment is not under the control of the NGN provider and it may be impossible to enforce the NGN providers security policy on the user. Still it is desirable to try to apply some security measures, and to that end, it is recommended that signalling, media, and
34、 OAMP interfaces be secured and the TE-BE located in the “un-trusted” zone, be hardened. However, security is less for communication with network elements in the “un-trusted” zone than for communication with network elements in the “trusted” zone. 7.2 Peering network trust model When an NGN is conne
35、cted to another network, the presence or absence of trust depends on: the physical interconnection, where the interconnection can range from a direct connection in a secure building to a connection between separate (possibly not secured) buildings via shared facilities; the peering model, where the
36、traffic can be exchanged directly between the two NGN service providers, or via one or more NGN transport providers; the business relationships among network, where there may be penalty clauses in the SLA, and/or a trust in the other NGN providers security policies; in general, NGN providers should
37、view other providers as un-trusted. Figure 2 shows an example when a connected network is judged un-trusted. Y2704(09)_F02TrustedzoneUntrusted zoneTrusted butvulnerablezoneNGNnetworkelementsNGNnetworkelementsDomainborderelements(DBE)Domainborderelements(DBE)Provider B fromprovider As point of viewPr
38、ovider AFigure 2 Peering trust model/ATIS-1000029 8 Identification, Authentication and Authorization Refer to ATIS-1000029, ATIS-1000030, ATIS-1000035, ITU-T Y.2701, ITU-T Y.2702, and ITU-T Y.2720 for information related to identification, authentication, authorization and identity management (IdM).
39、 ATIS-1000034.2010 11 This clause describes identification, authentication and authorization mechanisms, in particular, those concerning SIP-based services. The mechanisms concerning other services are for further study. 8.1 Subscribers A request for an NGN service is associated with a subscriber. T
40、his association is determined through identification of the request with the subscriber. Further identification (and associated authentication) of the End-User may be necessary depending on the SLA between the NGN provider and the Subscriber. This process can be achieved by using a functional elemen
41、t that facilitates identification and authentication of subscribers, devices or end-users (called an Authenticator). For example, Network Border Elements (NBE) with back-to-back user agent (B2BUA) functionality or P-CSC-FEs can be Authenticators of subscribers for SIP-based services. Identification
42、and authentication is achieved by exchanging and validating credentials between the Authenticator and the TE. 8.2 Network Element ATIS-1000029 and ITU-T Y.2701 recommends that Network Elements to be identified and authenticated for communications. If the Border Element receives the request from a NG
43、N Network Element in the Trusted Zone, the identification contained in the request may be considered accurate and not checked further subject to NGN provider security policy. If the Border Element receives requests from Network Elements in the un-trusted and the trusted-but vulnerable Zone, the Netw
44、ork Elements are recommended to be identified and authenticated and the communication privileges verified. Identification and authentication is achieved by exchanging and validating credentials between the Authenticator and the NE. 8.3 Credential usage in the NGN Security Credentials are used in NGN
45、 Security to identify and authenticate a Device, a Subscriber, or an End-User. These credentials are described in section 8.3.1. These credentials may take one of two different forms, either a X.509 public key certificate (described in clause 8.3.2) or a shared key (described in section 8.3.3). An X
46、.509 public key certificate may be used to establish a secure transport between the TE and the Authenticator (described in section 8.3.1) based on the NGN provider policy. The shared key may be used either to establish a secure transport, or in generating/verifying the response to an Authenticator -
47、initiated challenge (described in section 8.3.1) based on the NGN provider policy. 8.3.1 Device, Subscriber, and End-User Credentials Three distinct types of credentials are used in the NGN: 1. Device credentials, 2. Subscriber credentials, and 3. End-User credentials. ATIS-1000034.2010 12 Device cr
48、edentials may be supplied by the manufacturer with the device. For example, during the manufacture of the device, the device may have the credentials “burned in” from the manufacturer, which includes such information as the device serial number or the manufacturer. Device credentials identify and au
49、thenticate the device. An NGN provider may associate device credentials with a particular subscribers service to alleviate the need for subscriber credentials. In such cases requests from the device may be associated with a particular account based on the NGN provider policy. Subscriber credentials are used for association of the originator of an NGN request with a particular account. Subscriber credentials are entered (e.g., via download, SIM, etc.) in the devices capable of accepting such credentials. Subscriber credentials installed on a
