ATIS 1000030-2008 Authentication and Authorization Requirements for Next Generation Network (NGN).pdf

1、 AMERICAN NATIONAL STANDARD FOR TELECOMMUNICATIONS ATIS-1000030.2008(R2013) Authentication and Authorization Requirements for Next Generation Network (NGN) As a leading technology and solutions development organization, ATIS brings together the top global ICT companies to advance the industrys most-

2、pressing 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 fa

3、st-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 Or

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

5、For 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

6、ANSI 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 effo

7、rt 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 confo

8、rming 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

9、 name 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 Ame

10、rican 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 Disclaime

11、r and the principal is the source of a data item available to the verifier (data origin authentication). Entity authentication provides corroboration of the identity of a principal, within the context of a communication relationship. The principals authenticated identity is assured only when an auth

12、entication service is invoked. ATIS-1000030.2008 7 Notes: 1. When using data origin authentication, it is also necessary to have adequate assurance that the data has not been modified. This may be accomplished by using an integrity service, for example: by using environments in which data cannot be

13、altered; by verifying that the data received matches a digital fingerprint of the data sent; by using a digital signature mechanism; or by using a symmetric cryptographic algorithm. 2. The term “communications relationship” used in defining entity authentication may be interpreted in a broad way and

14、 could refer, for example, to an OSI connection, inter-process communication, or interaction between a user and a terminal. 5.1.2 Identifiers A principal is an entity whose identity can be authenticated. A principal has one or more distinguishing identifiers associated with it. Authentication servic

15、es are used by an entity to verify purported identities of principals. A principals identity which has been so verified is called an authenticated identity. Similarly, a principal whose identity has been verified is called an authenticated entity. Examples of principals that can be identified and he

16、nce authenticated are, but are not limited to: human users; NGN providers; processes; real open systems; OSI layer entities; enterprises, and flows in the bearer, signalling and management traffic. Distinguishing identifiers are used to unambiguous claim an identity within a given security domain. D

17、istinguishing identifiers distinguish a principal from others in the same domain, in one of two ways: 1. by virtue of membership in a group of entities considered equivalent for purposes of authentication (in this case the entire group is considered to be one principal and has one distinguishing ide

18、ntifier); or 2. by identifying one and only one entity. When authentication takes place between different security domains, a distinguishing identifier may not be sufficient to unambiguously identify an entity, as different security domain authorities may use the same distinguishing identifiers. In

19、this case, distinguishing identifiers have to be used in conjunction with a security domain identifier in order to provide an unambiguous identifier for the entity. ATIS-1000030.2008 8 LegacyTerminalsNote: Gateway (GW) may exist in either Transport Stratum or End-User Functions.*LegacyTerminalsTrans

20、port StratumService StratumEnd-UserFunctionsApplication FunctionsCore transport FunctionsNGNTerminals CustomerNetworksOtherNetworksApplication Support Functions and Service Support FunctionsCore TransportFunctions OtherNetworksEdgeFunctions Access Transport FunctionsServiceControl FunctionsNetwork A

21、ccessAttachment FunctionsNetwork Attachment Control Functions(NACF)ccess NetworkFunctions Resource and AdmissionControl Functions (RACF)UserProfileFunctionsT. UserProfileFunctionsGWOther NGN ServiceComponentsPSTN / ISDN EmulationService ComponentIP Multimedia Component network addresses; AP-titles a

22、nd AE-titles; object identifiers; names of persons (unambiguous within the context of the domain); quintuples that contain: o source IP address, o destination IP address, o source port number, o destination port number, and o protocol number. 5.1.3 Authentication Entities The term “claimant” is used

23、 to describe the entity which is or represents a principal for the purposes of authentication. A claimant includes the functions necessary for engaging in an authentication exchange on behalf of a principal. ATIS-1000030.2008 9 The term “verifier” is used to describe the entity which is or represent

24、s the entity requiring an authenticated identity. A verifier includes the functions necessary for engaging in an authentication exchange to request verification of a claimed identity. An entity involved in mutual authentication will assume both claimant and verifier roles. The term “trusted third pa

25、rty” is used to describe a security authority or its agent, trusted by other entities with respect to security-related activities. In the context of this document, a trusted third party is trusted by a claimant and/or a verifier for the purposes of authentication. NOTE A claimant or verifier may spa

26、n multiple functional components, possibly residing in different open systems. 5.1.4 Authentication Information The types of authentication information (AI) described in this standard are: exchange authentication information (exchange AI); claim authentication information (claim AI); verification au

27、thentication information (verification AI). The term “authentication exchange” is used to describe a sequence of one or more transfers of exchange AI for the purposes of performing an authentication. Figure 2 illustrates the relationship among a claimant, a verifier, and a trusted third party. Figur

28、e 2 also illustrates, the three types of authentication information that may make up an authentication exchange. Claimant VerifierTrusted 3rdParty (s)Verification AIClaim AIClaim AI Verification AIExchangeAIExchangeAIExchange and/or VerificatioAIFigure 2 Relationship Between Claimant, Verifier and T

29、rusted Third Party ATIS-1000030.2008 10 In some cases, in order to generate exchange AI, a claimant may need to interact with a trusted third party. Similarly, in order to verify exchange AI, a verifier may need to interact with a trusted third party. In these cases the trusted third party may hold

30、verification AI related to a principal. It is also possible that a trusted third party is used in the transfer of exchange AI. Depending on the exchange, the third party may take on the role of a claimant relative to the verifier. The Claimant and Verifier may also need to hold authentication inform

31、ation to be used in authenticating the trusted third party. 5.1.5 Multi-Factor Authentication Multi-factor authentication involves validating the authenticity of the identity of a principal by verifying multiple identifiers and attributes associated with the principal. Generally, multifactor authent

32、ication can be organized based on the following grouping of authentication attributes: 1. Something you are (e.g., physical or behavioural characteristics of a end user or customers characteristic or attribute that is being compared such as typing patterns, voice recognition) 2. Something you have (

33、e.g., a drivers license, or a security token) 3. Something you know (e.g., a password, pin number, security image). The most common example of a single-factor authentication key is a password (something you know). Sometimes passwords, by themselves, do not provide sufficient confidence in the identi

34、ty of an entity, and stronger forms of authentication, involving other authentication keys, would be required for access to certain NGN resources, applications and services. This would depend on the risks associated with the likelihood of unauthorized entities obtaining access to the NGN resources,

35、applications and services. The authentication factors and keys should be selected based on the risks to be addressed. Specifically the impacts of unauthorized entities obtaining access to NGN resources, applications and services would have to be assessed to determine the required authentication. Exa

36、mple electronic authentication keys are: Passwords Hardware tokens Software tokens One-time password device tokens. The use of passwords for authentication is widely established. The “password” is a secret that a claimant memorizes and uses to authenticate his or her identity. Passwords are typicall

37、y character strings or images that the subscriber memorizes and must identify when presented along with other similar images. However, password systems are susceptible to many attacks. Additional protections for the communication channel can be used to protect the password, but this still does not p

38、revent all attacks. ATIS-1000030.2008 11 Hardware tokens are specialised hardware devices that protect secrets (normally cryptographic keys) and perform cryptographic operations. Authentication is accomplished by proving possession of the device and control of the key. The cryptographic operations s

39、upport authentication of both parties and the protection of the communication channel used for the authentication exchange. Software tokens are essentially software implementations of hardware tokens and share many of the advantages of hardware tokens (e.g., a cryptographic key that is typically sto

40、red on disk or some other media). The soft token key can be encrypted under a key derived from some activation data. Typically, the activation data is a password known only to the user, so a password is required to activate the token. Authentication is accomplished by proving possession and control

41、of the key. As with hardware tokens, software tokens support authentication of both parties and protection of the communication channel used for the authentication exchange. A one-time password device token is a personal hardware device that generates “one time” passwords for use in authentication.

42、One-time password systems rely on a series of passwords generated using special algorithms. Each password of the series is called a one-time password as it is distinct from the others generated and can only be used once. A wide variety of one-time password systems exist that provide varying protecti

43、on against attacks. 5.2 Authentication Threats Authentication factors and keys can be attacked as follows: 1. “Something you are” - replicating the customers characteristic or attribute that is being compared (for example, fingerprints, typing patterns). 2. “Something you have” - obtaining or copyin

44、g what the customer has 3. “Something you know” - discovering what the customer knows. In general authentication threats can be divided into threats that involve attacks against the authentication protocol, and other attacks that may reveal either token values, or compromise confidential information

45、. Using multiple authentication factors improves security because multiple methods must be subverted. Using a hardware device (something you have) that is not easily copied also reduces the scope of an attack, as it is expected that the owner will notice the loss of the device. Authentication keys b

46、ased on software or hardware tokens may be combined with activation data (e.g. a password) to implement two-factor authentication so that the authentication is not reliant on possession of the token alone. A customer may subvert the authentication system by deliberately divulging their one-factor au

47、thentication key to an accomplice and then denying it later, with the aim of repudiating subsequent successful authentications. The use of multiple authentication factors makes such a denial less credible and may deter such attacks. 5.2.1 Authentication Protocol Threats Example authentication protoc

48、ol threats include: 1. Eavesdroppers: ATIS-1000030.2008 12 Eavesdroppers observing authentication protocol message exchanges for later analysis Eavesdroppers attempting to obtain tokens to pose as claimants. 2. Impostors: Impostor claimants posing as subscribers to the verifiers to test guessed toke

49、ns or obtain other information about a specific subscriber Impostor verifiers posing as verifiers to legitimate subscriber claimants to obtain tokens that can then be used to impersonate subscribers to legitimate verifiers Impostor relying parties posing as the relying party system to verifiers to obtain sensitive user information. 3. Hijackers: Hijackers who take over an authenticated session and pose as subscribers to relying parties to obtain sensitive information or input invalid information Hijackers who take over an