ETSI GS INS 004-2010 Identity and access management for Networks and Services Dynamic federation negotiation and trust management in IdM systems《网络和业务的身份和接入管理 IdM系统中动态联合协商和信任管理(版本1_1.pdf

《ETSI GS INS 004-2010 Identity and access management for Networks and Services Dynamic federation negotiation and trust management in IdM systems《网络和业务的身份和接入管理 IdM系统中动态联合协商和信任管理(版本1_1.pdf》由会员分享，可在线阅读，更多相关《ETSI GS INS 004-2010 Identity and access management for Networks and Services Dynamic federation negotiation and trust management in IdM systems《网络和业务的身份和接入管理 IdM系统中动态联合协商和信任管理(版本1_1.pdf（18页珍藏版）》请在麦多课文档分享上搜索。

1、 ETSI GS INS 004 V1.1.1 (2010-11)Group Specification Identity and access management for Networks and Services;Dynamic federation negotiation andtrust management in IdM systemsDisclaimer This document has been produced and approved by the ETSI Industry Specification Group Identity and Access Manageme

2、nt for Networks and Services (ISG INS) and represents the views of those members who participated in this ISG. It does not necessarily represent the views of the entire ETSI membership. ETSI ETSI GS INS 004 V1.1.1 (2010-11) 2Reference DGS/INS-004 Keywords access, ID, management, network, service, sy

3、stem 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 7803/88 Important notice Individual copies of the present document

4、can be downloaded from: http:/www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, t

5、he reference shall be the printing on ETSI printers of the 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 do

6、cuments is available at http:/portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following services: http:/portal.etsi.org/chaircor/ETSI_support.asp Copyright Notification No part may be reproduced except as authorized by written p

7、ermission. The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2010. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTM, TIPHONTM, the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Me

8、mbers. 3GPPTM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. LTE is a Trade Mark of ETSI currently being registered for the benefit of its Members and of the 3GPP Organizational Partners. GSM and the GSM logo are Trade Marks registered and

9、owned by the GSM Association. ETSI ETSI GS INS 004 V1.1.1 (2010-11) 3Contents Intellectual Property Rights 4g3Foreword . 4g31 Scope 5g32 References 5g32.1 Normative references . 5g32.2 Informative references 5g33 Abbreviations . 6g34 Introduction 6g34.1 Level of Assurance (LoA) 6g34.2 Metric . 8g35

10、Scenarios and Use Cases 8g35.1 Scenario 1: Service-bound access 8g35.2 Scenario 2a: Trust based on reputation . 9g35.3 Scenario 2b: Trust based on reputation 9g35.4 Scenario 3: Identity Broker - Grid computing 10g35.5 Scenario 4: Smart Personal Networks 11g35.5.1 Scenario Description: Health Monitor

11、ing . 11g36 Requirements 12g37 Current Status . 13g37.1 Involved SDO . 13g37.1.1 Open Identity Solutions for Open Government 14g37.1.2 Open Identity Exchange 15g37.1.3 Roles and Relationships 15g37.1.4 Kantara Initiative 16g37.1.5 Identity Assurance Certification Program . 16g37.1.6 IAF Identity Ass

12、urance Levels: Snapshot View . 16g37.1.7 Interoperability Certification Program 16g37.2 Conclusion 17g38 Authors 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

13、 (http:/webapp.etsi.org/IPR/home.asp). 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 ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be,

14、or may become, essential to the present document. Foreword This Group Specification (GS) has been produced by ETSI Industry Specification (ISG) Identity and access management for Networks and Services (INS). ETSI ETSI GS INS 004 V1.1.1 (2010-11) 51 Scope The present document will describe a problem

15、statement to federation establishment based on dynamic SLA negotiations, so called “ad hoc federations“. Therefore in the first part the basic technologies, Level of Assurance and Metrics, are described, use cases presented and requirements derived. In the second part are the efforts of current SDOs

16、 shown. 2 References References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the reference document (including any amendment

17、s) applies. Referenced documents which are not found to be publicly available in the expected location might be found at http:/docbox.etsi.org/Reference. NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee their long term validity. 2.1 Norma

18、tive references The following referenced documents are necessary for the application of the present document. Not applicable. 2.2 Informative references The following referenced documents are not necessary for the application of the present document but they assist the user with regard to a particul

19、ar subject area. i.1 SWIFT Deliverable D302: “Specification of General Identity-centric Security Model that supports user control of privacy“. NOTE: Available at: http:/www.ist-swift.org/component/option,com_docman/task,doc_download/gid,17/Itemid,37/ i.2 SWIFT Deliverable 202 Gap Analysis and Archit

20、ecture Requirements. NOTE: Available at: http:/www.ist-swift.org/component/option,com_docman/task,doc_download/gid,10/Itemid,37/ i.3 Open Identity Exchange (OIX). NOTE: http:/ i.4 Kantara Initiative. NOTE: Available at: http:/www.kantarainitiative.org/ i.5 NIST SP 800-63: “Electronic Authentication

21、Guideline“. NOTE: Available at: http:/csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf ETSI ETSI GS INS 004 V1.1.1 (2010-11) 63 Abbreviations For the purposes of the present document, the following abbreviations apply: AH-F Ad Hoc Federation API Application Programming Interface AuthN A

22、uthentication HSP Hot Spot Provider IAF Identity Assurance Framwork IAWG Identity Assurance Work Group ICAM Identity, Credential and Access Management ICF Information Card Foundation Id-FF Identity Federation Framework IdP Identity ProviderIT Information Technology LA Liberty Alliance LoA Level of A

23、ssurance NIST National Institute of Standards and Technology OAuth Open Authentication OIDF OpenID Foundation OITF Open Identity Trust Framework OIX Open Identity Exchange OMB Office of Management and Budget OTP One Time Password PAN Personal Area Network PIN Personal Identification Number PN Person

24、al Network PN-F Personal Network Federation QoS Quality of Service SDO Standards Developing Organization SIM Subscriber Identity Module SP Service Provider TFP trust framework provider UMTS Universal Mobile Telecommunications System URL Uniform Resource Locator WLAN Wireless Local Area Network WPAN

25、Wireless Personal Area Network XMPP Extensible Messaging and Presence Protocol 4 Introduction Due to increasing usage of Internet services the conventional use of bilateral contracts between Service Providers, Network Providers and the Identity Providers is no longer sufficient. Currently the most u

26、sed and mature standard for federated service usage is the approach of Liberty Alliance / Kantara (LA). LA specified the Identity Federation Framework (Id-FF) which describes the processes for gaining Level of Assurance (LoA). Today there are a lot of new services which are provided by small compani

27、es or even by individuals, which cannot afford the time and money to fulfil the processes described in the Id-FF. To provide services and make them billable, techniques are required which give the possibility of ad hoc federation. Such techniques must provide function to evaluate LoA under considera

28、tion of reputation, quality of credentials and risk taking as described in D302 i.1. In the present document the terms of LoA and Metric are defined in the context of ad hoc federation, use cases introduced and requirements to a solution defined. 4.1 Level of Assurance (LoA) Whereas there are severa

29、l standards for LoA depending on the subject, in the context of add-hoc federation and trust management, we refer to the NIST 800-63 i.5. Based on the identified risk of the provided IT-systems with respect to authentication, the US Office of Management and Budget (OMB) defined four different levels

30、 of identity assurance. ETSI ETSI GS INS 004 V1.1.1 (2010-11) 7The level of identity assurance describes the degree of certainty that the credentials presented by the end user have been legally acquired. The following four levels have been defined: Level 1: Little or no confidence in the asserted id

31、entitys validity. Level 2: Some confidence in the asserted identitys validity. Level 3: High confidence in the asserted identitys validity. Level 4: Very high confidence in the asserted identitys validity. The higher the risk that a resource is exposed, the higher the level of assurance should be. I

32、n order to identify the risks and select the appropriate level of assurance, the OMB defined a 5 step process. This process can be generalized as follows: Step 1: Conduct a risk assessment of system. Step 2: Map identified risks to the required assurance level. Step 3: Select technology based on the

33、 NIST e-authentication technical guidance. Step 4: After implementation, validate that the information system has operationally achieved the required assurance level. Step 5: Periodically reassess the information system to determine technology refresh requirements. In the context of the present docu

34、ment we assume that the underlying systems and protocols are secure and concentrate on the authentication context of user registration, how the user authenticated to the current session, the reputation of the user and the Identity Provider as depicted in Figure 1. Figure 1: LoA composition Authentic

35、ation Method on Registration: this input parameter should indicate which method was used when the user registered to the Identity Provider (IdP), this could be PostIdent, E-Mail verification, etc. Authentication Method of Current Session: this input parameter should indicate which authentication met

36、hod was used for the current network / online session, e.g. username/password, username/one time password, SIM-Card, etc. Reputation of Service Requester: this input parameter should indicate where the user is known by others, e.g. other services, social networks, etc. Reputation of Identity Provide

37、r: at last it is also important which reputation has the IdP of the service requester, who claims to know the user and the aforementioned input parameters are qualified, e.g. a big operator or company the service provider may trust more than an unknown small company. The service delivery decision de

38、pends on the LoA and internal risk taking factors. To qualify these internal factors and to compose the LoA, metrics are necessary so the parameters can be compared and computed. ETSI ETSI GS INS 004 V1.1.1 (2010-11) 84.2 Metric As Tom DeMarco stated, “You cant control what you cant measure“ and so

39、it is when a decision for service delivery has to be computed. As shown in Figure 1 there are several influences to the decision making and these influences are in itself multi factored. To measure these factors, adequate metrics has to be developed to quantify and qualify them. This means, through

40、the metric, to define the semantic of the data which are used to compose the LoA. To calculate a factor that indicates a positive delivery decision, the parameters have to be normalised, categorised and compared to the parameters which are needed to describe a particular business model. One solution

41、 could be order the parameter through ontologys of each domain, so they can be compared and weighted. Whatever metric system will be developed it has to be standardised and the definitions shout be available to every buddy involved in the process. Only if there is a common understanding what a facto

42、r and the associated value means, e.g. who is the IdP, what age has the user, which cost factors are involved, which authentication method was used, etc. it will be possible to come to a valuable decision. 5 Scenarios and Use Cases 5.1 Scenario 1: Service-bound access A user is within reach of a hot

43、-spot and wants to access an online flight service. The hot-spot provider (HSP) recognizes that the user is currently not authenticated to the network. Based on the URL the user wants to reach, the HSP tries to contact the flight service and asks if the flight service is willing to pay for the acces

44、s and if the flight service will pay the HSP grands access to the user, but only to this requested service. The user checks the flight dates and leaves the hot-spot. Alternatively the flight service authenticates the user or redirects him to his IdP and provides the service only if the user is prope

45、rly authenticated and authorized. g44g381g410g94g393g381g410g87g396g381g448g349g282g286g396 g38g367g349g336g346g410g3g400g286g396g448g349g272g286g1005g856g3g100g396g455g3g410g381g3g396g286g258g272g346g3g296g367g349g336g346g410g3g400g286g396g448g349g272g286g1006g856g3g4g400g364g400g3g296g381g396g3g39

46、3g258g455g373g286g374g410g1007g856g3g38g381g396g449g258g396g282g349g374g336g3g437g400g286g396g3g396g286g395g437g286g400g410g1008g856g3g94g286g396g448g349g272g286g3g282g286g367g349g448g286g396g455g87g258g455g373g286g374g410g3g374g286g336g381g410g349g258g410g349g381g374g75g374g367g349g374g286g3g876g3g

47、381g296g296g367g349g374g286g3g393g258g455g373g286g374g410Figure 2: Service-Bound Access simplified ETSI ETSI GS INS 004 V1.1.1 (2010-11) 95.2 Scenario 2a: Trust based on reputation A user wants to download a song from a service provider (SP). The SP asks how the payment will be done. The user decide

48、s to use the service anonymous and provides an authentication token from his Identity provider (IdP). The SP checks who issued the token and because it is from a big network operator where the customer is known by PostIdent (confirmation of identity at the post office), he trusts the user. The SP as

49、ks the IdP if the token is valid and if the IdP will charge the user for the song. If the IdP agrees, they negotiate a transaction token and the user can download the song. The ISP charges the user and pays the SP. g47g282g286g374g410g349g410g455g3g87g396g381g448g349g282g286g396g1006g856g3g94g286g396g448g349g272g286g3g396g286g395g437g286g400g410g4g437g410g346g286g374g410g349g272g258g410g349g381g374g3g87g396g381g272g286g400g400g1007g856g3g90g286g395g437g286g400g410g3g393g258g455g373g286g374g410g3g373g286g410g346