ETSI EG 202 067-2002 Universal Communications Identifier (UCI) System Framework (V1 1 1)《通用通信标识符(UCI) 系统框架(版本1 1 1)》.pdf

《ETSI EG 202 067-2002 Universal Communications Identifier (UCI) System Framework (V1 1 1)《通用通信标识符(UCI) 系统框架(版本1 1 1)》.pdf》由会员分享，可在线阅读，更多相关《ETSI EG 202 067-2002 Universal Communications Identifier (UCI) System Framework (V1 1 1)《通用通信标识符(UCI) 系统框架(版本1 1 1)》.pdf（135页珍藏版）》请在麦多课文档分享上搜索。

1、ETSI EG 202 067 1.1.1 (2002-09) ETSI Guide U n ive rsal Com m u n cat ions I dent if er (U C i); System framework 2 ETSI EG 202 067 VI .I .I (2002-09) Reference DEG/HF-00025 Keywords addressing, UCI ETSI 650 Route des Lucioles F-O6921 Sophia Antipolis Cedex - FRANCE Tel.:+33492944200 Fax:+3349365471

2、6 Siret No 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-prfecture de Grasse (06) No 7803/88 Important notice Individual copies of the present document can be downloaded from: http:lwmv.etsi .arq The present document may be made available in more than one electronic v

3、ersion 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, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI

4、 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 ha p:/pa rta I. etsi I a rgltbistat uslstatus .as p If you find errors in the present docum

5、ent, send your comment to: Cori vriaht Notifica tion No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. O European Telecommunications Standards Institute 2002. All rights reserved. DECTTM, PLUGTESTSTM

6、and UMTSTMare Trade Marks of ETSI registered for the benefit of its Members. TIPHONTM and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 3GPPTM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partner

7、s. ETSI 3 ETSI EG 202 067 VI . 1 . 1 (2002-09) Contents Intellectual Property Rights 7 Foreword . 7 Introduction 7 1 2 3 3.1 3.2 4 5 6 6.1 6.2 6.3 6.4 6.5 7 7.1 7.2 7.3 7.4 8 9 9.1 9.2 9.3 Scope 9 References 10 Definitions and abbreviations . 10 Definitions . . 10 Abbreviations . 11 Void 11 The Univ

8、ersal Communications Identifier (UCI) . 12 UCI functional entities . 12 UCI system overview . 12 The Personal User Agent (PUA) . . 13 The Service Agent (SA) . 14 Relationships between principal UCI entities . 14 Other entities . . 15 System capabilities related to user input/output . 16 System capab

9、ilities (internal/automated) . . 22 Service capabilities relating to UCI security . . 26 System capabilities relating to the UCI . . 29 Capabilities for UCI-based communications systems 16 UCI Technical Requirements . 31 UCI system dialogues, services and processes . 35 System dialogues . . 35 Suppo

10、rt services . 36 Kev txocesses . 37 dI 9.3.1 Terminal/User registration and authentication . . 37 9.3.2 Basic UCI communication Set-up . 38 9.3.3 PUA and terminal profile management . . 40 Communication using UCIs . 40 10 10.1 PUA to PUA communication - basic . 40 10.2 41 10.3 UCI communication with

11、 non-UCI users . 42 11 UCI Privacy Protection 43 11.1 Background . 43 11.2 UCI-based privacy control . . 43 12 UCI Data 44 12.1 Stored Data . 44 12.1.1 Terminal Data . 46 12.1.2 PUA Data . . 47 12.1.3 SA Data . 49 12.1.4 Service Data . . 50 12.1.5 User provided UCI Data . 51 12.2 Acquisition of netw

12、ork, service and application data . 51 12.3 PUA rules . 52 13 UCI security framework . 52 13.1 Security objectives definition 52 13.1.1 General security objectives 53 PUA to PUA communication - linked PUAS ETSI 4 ETSI EG 202 067 VI .I .I (2002-09) 13.1.2 13.1.3 13.1.4 13.1.5 13.2 13.2.1 13.2.2 13.2.

13、3 13.2.4 13.3 13.3.1 13.3.2 13.3.3 13.3.4 13.3.5 13.3.6 13.3.7 13.4 13.5 13.6 13.6.1 13.6.2 13.6.3 13.6.4 13.6.5 13.6.6 13.7 13.8 13.9 Users objectives 53 Service and network providers obj 53 Manufacturers objectives . .54 UCI system security objectives . .54 A model for UCI security analysis . .54

14、Communication subjects 55 Information flow paths. 55 Functions and services . 55 Boundaries . 55 Forms of attack 56 E ave sdropping . 56 . 56 . 56 Unauthorized access . 56 . 56 Threats to UCI system Countermeasures Intrusion detection systems . Location specific service binding . UCI system security

15、 features Security mechanisms Threats after application of countermeasures. 14 Administrative issues . 60 15 Key standards activities. .6 1 Annex A (informative): A. 1 Introduction 62 A.2 Mobile worker scenario . .62 A.2.1 Key UCI capabilities illustrated by this scenario . A.2.2 Scenario descriptio

16、n . A.2.3 Discussion A.2.3.1 Step 1 - Inco A.2.3.2 Step 2 - Incoming email whilst Francois is out of the office A.2.3.3 A.3 Home scenario 69 UCI scenarios . 62 . s is in the office Step 3 - Responding to Duboiss original email A.3.1 Key UCI capabilities illustrated by this scenario 69 A.3.2 Scenario

17、 description . 69 A.3.3 Discussion 71 A.3.3.1 Step 1 - Jenny makes outgoing call. 71 A.3.3.2 73 A.3.3.3 . .74 A.3.3.4 75 A.3.3.5 76 A.4 Tennis club scenario . 78 A.4.1 78 A.4.2 Scenario description . 78 A.4.3 Discussion . .79 A.4.3.1 Step 1 - Configuration Management . 79 A.4.3.2 Step 2 - Club membe

18、rship enquiry . 81 Step 2 - Mike updates his profile Step 3 - Mike searches for old school friend Step 4 - Old school friend returns call Step 5 - Old school friend roams onto Key UCI capabilities illustrated by this scenario . A.4.3.3 A.4.3.4 Step 3 - Response to club membership enquiry Step 4 - Fu

19、rther club membership enquiry 83 85 ETSI 5 ETSI EG 202 067 VI . 1 . 1 (2002-09) A.4.3.5 A.4.3.6 A.5 A.5.1 Key UCI capabilities illustrated by this scenario . A.5.2 Scenario description . A.5.3 Discussion A.5.3.1 guration management . A.5.3.2 Step 2 - Inbound Engineering Club Communication A.5.3.3 A.

20、6 Corporate Scenario . 98 A.6.1 Key UCI capabilities illustrated by this scenario . 98 A.6.2 Scenario description . 98 A.6.3 Discussion . 99 s wife . 99 A.6.3.1 A.6.3.2 Step 2 - Incoming voice call from Albert . 101 A.6.3.3 Step 3 - Incoming voice call from conference organizer 102 A.6.3.4 Step 4 -

21、Automatic update of user profile . 105 A.6.3.5 Step 5 - Do NOT Disturb . 106 A.6.3.6 Step 6 - Email redirected ed as FAX 107 PUA acting as a personal assistant scenario . 109 A.7.1 Key UCI capabilities illustrated by this scenario 109 A.7.2 Scenario description . 109 A.7.3 Discussion . 110 A.7.3.1 S

22、tep 1 - Scheduling a multiparty CO 110 A.7.3.2 113 A.7.3.3 Step 3 - email of proposal . 115 Annex B (informative): User Requirements for communications systems using UCIs . 116 B . 1.1 Origin of the user requirements . 116 B . 1.3 System re-engineering . 116 B . 1.4 Dependencies and con . 116 B.2 Ge

23、neric requirements . 116 B.3 Human factors requirements 121 Annex C (informative): Standards Bodies related to UCI Technical Requirements . 124 C.l Personal User Agent Technical Requirements . 125 C.2 Service Agent . 126 Step 5 . Communication for the Club Treasurer Step 6 . Non-PUA User makes Tenni

24、s Club cal 87 . 89 Multiple role scenario . 91 Step 3 - Outbound Engineering Club Communication . . A.7 Step 2 - Conference call in action . B . 1 Notes relating to the user requirements 116 B . 1.2 Assumptions concerning the Universal Communications Identifier 116 C.3 C.4 Terminals and end-user app

25、lications 126 UCI and identification verifiers 127 Annex D (informative): Security Mechanisms . 128 D . 1 Public. private and secret keys . 128 D.1.1 Symmetric key advantages and disadvantages . 128 D.1.2 Asymmetric key advantages and disadvantages . 129 D . 1.3 General encryption management problem

26、s 129 D . 1.4 Can encryption be perfect . 129 D.2 Internet Key Exchange (IKE) . 129 D.2.1 Overview 129 D.2.2 What IKE achieves . 130 D.2.3 IKE in UCI . 130 D.3 Digital signature and signature in general 130 D.3.1 Digital signature and UCI . 130 ETSI 6 ETSI EG 202 067 VI . 1 . 1 (2002-09) Annex E (in

27、formative): Security risk assessment 131 E . 1 Initial risk assessment . 131 E.2 Final risk assessment 132 Annex F (informative): Comparison of the UCI approach with ENUM 133 F.l ENUM 133 F.2 UCI . 133 F.3 Similarities between ENUM and UCI 133 F.4 Differences between ENUM and UCI 134 F.5 Summary 134

28、 History 135 ETSI 7 ETSI EG 202 067 VI .I .I (2002-09) Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and

29、can be found in ETSI SR O00 3 14: “Intellectual Property Rights (7PRs); Essential, orpotentially Essential, IPRs notlJied to ETSI in respect ofETSI standards“, which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (5). Pursuant to the ETSI IPR Policy, no i

30、nvestigation, 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 O00 3 14 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. Foreword This ETSI Guide

31、(EG) has been produced by ETSI Technical Committee Human Factors (HF). I n t rod uct ion EG 20 1 940 11 introduced the concept of a Universal Communications Identifier (UCI) to provide a flexible means of identification in an increasingly communications intensive world. To achieve its full potential

32、 the UCI needs to operate within an architecture capable of supporting the concept of personal control of communication. The UCI being used within the architecture described in the present document overcomes the many limitations that arise from the use of the identifiers in current communications sy

33、stems. When the UCI is used it: can identiSl the user in a meaningful way; minimizes the need to for a user to have many different identifiers for a range of different communications services; provides the potential for veriSling the true identity of the originator or recipient of a communication; i

34、s unchanged when moving to a different service provider or service type; and may provide a common environment for the management and control of all personal communications irrespective of service type (as opposed to a range of different control mechanisms that are service specific). The UCI may offe

35、r additional benefits arising from the application of rules stored in a personal profile contained in a Personal User Agent (PUA). These rules operate with a wide range of information including: the identity (UCI) of people attempting to communicate with the user; the date and time when communicatio

36、n is attempted; the location of the user; the urgency of the communication; whether the originator of a communication has a work or a personal status; and the users preferences for how they wish to be reached (which services and which terminals). The operation of these rules can permit a very high d

37、egree of control over the users communications. EG 201 940 i gives some scenarios illustrating the potential power and flexibility of UCI-based communication. Further examples are given in more detail in annex A. ETSI 8 ETSI EG 202 067 VI .I .I (2002-09) Parts of the present document, in particular

38、the scenarios, imply a great deal of complex rule driven behaviour. This behaviour would come from advanced PUAs intercommunicating. In the early phases of UCI it is possible that not all PUAs will support such behaviour. ETSI 9 ETSI EG 202 067 VI .I .I (2002-09) 1 Scope The present document: define

39、s the system architecture and operations needed for a Universal Communications (UCI) implementation capitalizing on existing and emerging standards; identifies and documents the standards that are available (or that will be available) to enable the UCI to be implemented. In line with the above one o

40、f the prime requirements during development of the UCI concept has been to minimize the number of specialized technical requirements necessary for its implementation. Similarly the assumption has been that most of the functionality necessary to put UCI into practice will appear as part of the natura

41、l evolution of a future communications network architecture (the rapid evolution of services such as Presence and Location Based Services indicate that this assumption is realistic). With regard to standardization, the approach taken has been to avoid promoting the creation of new standards solely f

42、or the purpose of creating UCI systems when existing or developing standards can be used, amended, or extended. The main UCI functional entities are described in clause 6. Clauses 7 and 8 describe the required capabilities of UCI systems and list the technical requirements for UCI. Details of UCI di

43、alogues, services, processes are contained in clause 9. Descriptions of communication using UCIs and of how UCI assists in personal privacy protection follow in clauses 10 and 11. Descriptions of the data handled in UCI systems and a UCI Security Framework are in clauses 12 and 13. Finally, in the m

44、ain document, a brief introduction to UCI administrative issues and to the principal standards that could support UCI is contained in clauses 14 and 15. Annex A contains a number of scenarios that illustrate the UCI being used in everyday tasks. Each scenario describes how UCIs might be used in real

45、istic communications related situations. Both the user experience and key elements of underlying system behaviour that produces that experience are shown. The scenarios: show how meeting the user requirements described in Annex B enables realistic and powerful usage scenarios to be delivered; help t

46、o identiSl and validate the system capabilities that are needed to deliver the required behaviour of UCI-based communication. Annex B contains a systematic analysis of the user requirements (first defined in EG 201 940 i) which have been used to defie the UCI architecture. Each requirement is descri

47、bed in detail with particular reference to which requirements are mutually supportive and which are potentially in conflict. Annex C lists Standards Bodies which are potentially related to the UCI Technical Requirements. Annex D gives a summary of security mechanisms that may be of relevance to UCI.

48、 Annex E is a security risk assessment of UCI, primarily from the end-user security perspective. Annex F draws comparisons between UCI and ENUM. ETSI 10 ETSI EG 202 067 VI .I .I (2002-09) 2 Re fe re nces The following documents contain provisions which, through reference in this text, constitute pro

49、visions of the present document. References are either specific (identified by date of publication andor edition number or version number) or non-specific. For a specific reference, subsequent revisions do not apply. For a non-specific reference, the latest version applies. il 21 31 ETSI EG 201 940: “Human Factors (HF); User identification solutions in converging networks“. IETF RFC 2916: “E.164 number and DNS“. IETF RFC 2267: “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing“. IRTF RFC 2409: “The Inte