ANSI ATIS 1000055-2013 Emergency Telecommunications Service (ETS) Core Network Security Requirements.pdf

1、AMERICAN NATIONAL STANDARD FOR TELECOMMUNICATIONS ATIS-1000055.2013(R2018) EMERGENCY TELECOMMUNICATIONS SERVICE (ETS): CORE NETWORK SECURITY REQUIREMENTS As a leading technology and solutions development organization, ATIS brings together the top global ICT companies to advance the industrys most-pr

2、essing business 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

3、-track development 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 Orga

4、nizational 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). Fo

5、r more information, 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 AN

6、SI Board of 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

7、 be made towards 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 conform

8、ing to the 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 n

9、ame of the 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 Ameri

10、can National 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

11、it authenticates only the device, which allows anyone possessing the device to invoke Priority Services. The remainder of this clause discusses methods to address the drawbacks of each of these methods. 5.2 Enhancing Device Subscription Validation The drawback to device subscription validation is th

12、at it does not explicitly authenticate the Priority Services User, but rather the PS Users device, as was mentioned above. Two methods of resolving the weakness of this approach use the notion of a secret possessed by the device owner: 1. The Priority Services User can be required to use the capabil

13、ities available in many, if not all, modern UE devices that force the PS User to supply an authenticator (e.g., an n-digit PIN) that the UE must recognize before it will permit itself to be used. Such an authenticator would bind the PS User to the device, and thus, in essence, authenticate the PS Us

14、er during the device subscription validation process. 2. Alternatively, the Priority Services User can be required to provide a Priority Services PIN that authenticates the PS User in exactly the same way it authenticates the GETS-AN user. To support this alternative, Identity Management (IdM) mecha

15、nisms could be used to correlate and bind the authorization of a Priority Services User via his Priority Services PIN with the identification and authentication of a subscribed user device based on a subscription profile. For example, to accomplish this, after a Priority Services User attaches to th

16、e access network and registers with the Core IMS, and a Priority Services ATIS-1000055.2013 14 session is invoked, an IdM application requests device identification and authentication from the Home Subscriber Server (HSS) and then sends a challenge to the Priority Services User to request his assign

17、ed PIN. The Priority Services User authentication is correlated with and bound to the device information to verify authorization for the NGN Priority Services. O-3. For NGN GETS-FC, it is desirable that Service Providers offer a capability to authenticate both the UE and the Priority Services User a

18、nd bind the two to verify authorization to use NGN Priority Service. As also shown in Table 2, this is applicable to the NGN GETS-FC Invocation. The first option can be enforced through OEC policy that, if not already in existence, can be produced and levied on each Priority Services User. The secon

19、d option requires that the Service Provider support a new authentication method. This will require necessary prototyping and testing prior to mandating the support of such mechanism. 5.3 Enhancing PIN Authentication only the correct answer to the query. (It is unclear how reliable voice recognition

20、would be, since stress can cause changes in the speakers voice, which could lead to a large number of failed recognitions.) 2. Use of hardware tokens carried by each Priority Services User and verifiable by an NGN Priority Services application. One-time PINs generated by a hardware token and synchro

21、nized with the application would overcome most, if not all, of the problems associated with theft of PINs. Both of these methods are two-factor authentication schemes that require two pieces of information from the user prior to granting access. The first uses two things the user knows (a PIN and an

22、 answer); the second uses one thing he possesses (a one-time PIN on a token) and one thing he knows (a permanent PIN). Other two-factor authentication schemes exist, but they typically work for more sophisticated devices than a phone and so are not practical as a general authentication method for Pr

23、iority Services. As an aside, it was stated earlier that the PIN cannot be changed by the Priority Services User. Though this might seem a drawback, it is probably a reasonable limitation, since allowing the Priority Services User to change his PIN also permits an attacker who has compromised the PI

24、N to change it and thus deny service to the PINs owner. Furthermore, an attacker who has stolen the PINs of many Priority Services Users could easily engineer large-scale denial of service of those users whose PINs had been stolen. (By contrast, an attacker who has merely stolen a PIN can use it to

25、place calls and perhaps listen in on NS/EP conference calls, but cannot deny service to the PIN owner.) The capability to allow the Priority Services User to change his PIN safely could be managed via a PIN-changing application that prompts the Priority Services User for a special PIN (a PIN-update

26、PIN) before it will change the PIN. However, the degree of risk mitigation gained by allowing Priority Services Users to change their PINs must be evaluated before such an application is considered. In particular, its advantage over the current no-change strategy must be determined, especially since

27、 Priority Services Users have no obvious incentive to change their PINs unless forced to do so. Table 2 summarizes various NGN Priority Services voice call invocation types, current authentication and authorization methods, and suggested future authentication and authorization methods to be consider

28、ed. It is self-explanatory except possibly for the rightmost column, Authentication and Authorization Proposed Enhanced Methods, which is intended to reflect the idea that the present methods are to be augmented by the proposed methods in this column. The fact that several proposed methods are liste

29、d is merely to suggest the alternatives and does not imply that all are to be used simultaneously. ATIS-1000055.2013 16 Table 2: NGN Priority Services Existing and Proposed Enhanced Authentication and Authorization Methods for Voice Services Service Invocation Type UE Type Destination DN Type Authen

30、tication and Authorization Present Methods Authentication and Authorization Proposed Enhanced Methods GETS-AN or 8YY GETS-AN Any general purpose UE (fixed or mobile) that supports basic voice calls Normal NANP or E.164 number (or a number that has been forwarded to such number) PIN Authentication Ca

31、lling Privileges Authorization Audio-based Query-response12One-time PIN GETS-NT or a DN forwarded to GETS-NT PIN Authentication Calling Privileges Authorization Number Translation Audio-based Query-response One-time PIN GETS-PDN or a DN forwarded to GETS-PDN DN forwarded to GETS-AN13Limit forwarding

32、 to GETS-AN as a Destination DN GETS-NT Translated routable number PIN Authentication Calling Privileges Authorization Number Translation Audio-based Query-response One-time PIN GETS-FC Voice-capable UE with subscription Normal NANP or E.164 number (or a number that has been forwarded to such number

33、) UE authentication and Subscription Validation Calling Privileges Authorization Audio-based Query-response Priority Services User and UE Authenticator Binding of Priority Services User and UE authentication GETS-NT or a DN forwarded to GETS-NT GETS-AN or a DN forwarded to GETS-AN The proposed authe

34、ntication and authorization methods are expected to have a low to medium effect on the user in terms of additional time and effort needed to invoke Priority Services. This “user experience” is an important 12One approach is to have the network prompt the NGN Priority Service User to respond with a s

35、ecret after a successful PIN authentication. It is assumed that the Service User has pre-recorded a secret audio response when prompted during the initial NGN Priority Service activation process and that the response has been acknowledged by the Service User and then securely stored by the network.

36、The network will play back the pre-recorded query to allow the NGN Priority Service User to provide the correct response and thus authenticate himself. 13This will result in a recursive looping scenario if attackers using stolen PINs reenter the same destination DNs. In extreme cases, this may cause

37、 localized network congestion. ATIS-1000055.2013 17 consideration, since it must not pose a distraction or an impediment to the user. The usability of any replacement method should, in fact, be better in terms of ease of use (such as remembering pieces of information, keeping track of and manipulati

38、ng a token, typing a PIN or password, and speedily completing the authentication process). The proposed authentication and authorization methods are expected to provide a medium to high level of protection when compared to the current methods, which are estimated to be below par by todays security c

39、onventions. On the down side, they are expected to impose some increases in the complexity of: The user experience, which is likely to vary from application to application (e.g., authentication for an e-mail versus for voice calls). Operations the administrative effort needed to support Priority Ser

40、vices. These complexities, along with the technical complexity associated with these proposed methods, should be tagged as areas for careful study should the proposed methods be deemed worth implementing. In addition, these enhancements should be considered in the context of Priority Services applic

41、ations beyond voice applications. Specifically, applications such as priority data services would require a higher degree of assurance or confidence of the Priority Services Users identity and of the level of authorization to access the application and its associated resource. In addition, enhanced

42、authentication mechanisms may not necessarily have to be supported for all applications and all Priority Services Users. For example, strong authentication could be applied to a smaller population of Priority Services User as a factor of the privileges or resources being authorized. O-4. In addition

43、 to the existing PIN-based and subscription-based (single-factor) authentication methods, it is desirable that the Service Provider offer capabilities for two or more factor authentication of the Priority Services User for selected Priority Services. Proposed enhanced authentication methods may incl

44、ude the use of: (a) Audio-based query-response using speech or voice recognition technology. (b) One-time authentication. (c) Binding of the Priority Services User and UE authentication. (d) Biometric methods. In addition to enhanced capabilities for authenticating the user, NGN Priority Services wi

45、ll need to be augmented with capabilities that permit monitoring of PIN and subscription validation activities for Priority Services usage. The following requirements address these points. 5.4 Authentication of NGN Priority Services, Service Provider Priority Services Users of GETS-AN, 8YY GETS-AN,

46、GETS-NT, and GETS-PDN services authenticate themselves to the Service Provider using a PIN at the application layer. However, the Service Provider does not authenticate itself to the user except to provide the expected prompts and service logic. Similarly, for GETS-FC the subscribed UE does not auth

47、enticate the Service Provider except for the case of 4G technologies such as Evolved Packet System/Long Term Evolution (EPS/LTE). Capabilities to allow the Priority Services User to identify and authenticate the Service Provider would minimize risks associated with imposter Service Providers (e.g.,

48、threat of an attacker inserting fake access network equipment masquerading as a legitimate Service Provider). O-5. It is desirable that the Service Provider provide capabilities for the Priority Services User to identify and authenticate the Service Provider. The ability of the Priority Services Use

49、r to verify that it is attached to a legitimate Service Provider home core network, serving, or visiting network and obtain NGN Priority Services from a legitimate Service Provider would provide protection against attackers masquerading as a legitimate Service Provider. ATIS-1000055.2013 18 NOTE: This objective may be changed to a requirement after further study. Specifically, this objective may have to be a requirement for NGN Priority Services applications beyond voice. NOTE: Specific measures or capabilities that could be used are for further study. For example, a simple mu