1、EUROPEAN COMPUTER MANUFACTURERS ASSOCIATIONSTANDARD ECMA - 206Association Context Managementincluding Security Context ManagementDecember 1993Free copies of this document are available from ECMA,European Computer Manufacturers Association,114 Rue du Rhne - CH-1204 Geneva (Switzerland)Phone: +41 22 7
2、35 36 34 Fax: +41 22 786 52 31X.400: C=ch, A=arcom, P=ecma, O=genevanet,OU1=ecma, S=helpdeskInternet: helpdeskecma.chEUROPEAN COMPUTER MANUFACTURERS ASSOCIATIONSTANDARD ECMA - 206Association Context Managementincluding Security Context ManagementDecember 1993Brief historyECMA, ISO and ITU-T are work
3、ing on standards for distributed applications in an open systemenvironment. Security and management of the relationship between those applications (associationmanagement) is a major concern in information processing.In July 1988, ECMA TR/46, Security in Open Systems - A Security Framework, was publi
4、shed.Based on the concepts of this framework, ECMA-138, Security in Open Systems - Data Elements andService Definitions, was produced (December 1989). It defines a set of Security Services for use inthe Application Layer of the ISO OSI Reference Model. One of these services, the Secure AssociationSe
5、rvice, has been expanded and is incorporated in the present work.Most of the basic aspects of association management have been addressed by ISO in the work onACSE (ISO 8649).But complex association establishments (e.g. three-ways authentication) orassociation modifications are not covered by ACSE.Se
6、curity aspects of interconnection in the Application Layer are addressed by the Security ExchangeService Element defined in the Generic Upper Layers Security document (ISO/IEC DIS 11586). Butthis service does neither cover non-security aspects of associations nor propose a model fornegotiation of at
7、tributes.This ECMA Standard defines a flexible service and protocol which can manage all aspects ofassociations, from the simplest to the most complex, between distributed applications. It also definesa generic negotiation model for use by distributed applications.This ECMA Standard is based on the
8、practical experience of ECMA member Companies. It isoriented towards urgent and well understood needs.Adopted as an ECMA Standard by the General Assembly of December 1993.- i -Table of ContentsPage1Scope 12 Conformance 13 References 24 Definitions 34.1 Imported definitions 34.2 New definitions 34.2.
9、1 Abstract-association 34.2.2 Association-context 34.2.3 Association Context Management 34.2.4 Context Attribute 35 Notational Conventions 36 Acronyms and Abbreviations 37 General Description 47.1 Background 47.2 Introduction to ACM 48 Requirements 58.1 General Requirements 58.1.1 Flexible Applicati
10、on 58.1.2 Non-duplication 58.1.3 Mechanism Independence 58.2 Identification Requirements 58.2.1 Peer Entity Identification 58.2.2 End User Identification 58.3 Security Requirements 58.3.1 Peer Entity Authentication 58.3.2 End User Authentication 58.3.3 Data Confidentiality 58.3.4 Data Integrity 68.3
11、.5 Access Control/Authorisation 68.3.6 Non-Repudiation of Data 68.3.7 Association Audit 68.3.8 Availability 68.3.9 Security Recovery 68.4 Management Requirements 68.4.1 Policies 6- ii -8.4.2 Inter-Domain 68.4.3 Account Identification 68.5 User Access Requirements 68.5.1 Cultural Adaptation 68.6 Comm
12、unications Requirements 68.6.1 Combination 68.6.2 Simplicity 78.6.3 Communications Independence 78.7 Storage Requirements 78.8 Process Requirements 78.8.1 Client-Server Style 78.8.2 Interactive Applications 78.8.3 Proxy/Delegation 78.8.4 Execution Environment 79 Relationship to Other Standards and R
13、ecommendations 79.1 Communications Standards 79.2 Security Standards 79.3 Management Standards 79.4 Operating Systems and API Standards 79.5 Architecture Standards 710 Models 710.1 Associations and Contexts 710.2 Levels of Context 910.3 Operations on the Context 910.4 Abstract-Association Negotiatio
14、n Model 910.5 Nested Association-contexts 1010.6 Mapping of ACM to communication standards 1010.7 Management of Association Context Management 1010.7.1 Global Description 1010.7.2 Management Functions on ACM Managed Objects 1010.7.3 Relationship between ACM and other Management Functions 1111 Servic
15、e Description 1111.1 Model of Multiple Exchanges 1111.1.1 Model of Initiate Exchanges 1211.1.2 Model of Modify Exchanges 1211.2 Parameters for negotiating the association-context 1211.3 How to design and implement context parameters 1311.4 Key to parameter tables 1411.5 ACM-Initiate 1411.5.1 Paramet
16、ers 1411.5.2 Sequences 14- iii -11.6 ACM-Initiate-Continue 1411.6.1 Parameters 1511.6.2 Sequences 1511.7 ACM-Initiate-Complete 1511.7.1 Parameters 1511.7.2 Sequences 1611.8 ACM-Release 1711.8.1 Parameters 1711.8.2 Sequences 1711.9 ACM-Abort 1811.9.1 Parameters 1811.9.2 Sequences 1811.10 ACM-Modify 1
17、811.10.1 Parameters 1911.10.2 Sequences 1911.11 ACM-Modify-Continue 1911.11.1 Parameters 1911.11.2 Sequences 1911.7 ACM-Modify-Complete 1911.12.1 Parameters 1911.12.2 Sequences 2012 Protocol Abstract Syntax 2113 Protocol Mappings 2413.1 Introduction and Principles 2413.2 Application Contexts 2413.3
18、ACSE mapping 2413.3.1 ACMinitiateReq 2413.3.2 ACMinitiateContinueReq 2413.3.3 ACMinitiateCompleteReq 2413.3.4 ACMreleaseReq 2413.3.5 ACMreleaseResp 2513.3.6 ACMabortReq 2513.3.7 ACMmodifyReq / ACMmodifyContinueReq / ACMmodifyCompleteReq 2513.4 ROSE mapping 2513.5 Mappings to OSI RPC 2513.5.1 Introdu
19、ction 2513.5.2 Mapping on to OSI Basic RPC ASO Service 2513.5.3 Mapping on to OSI Basic RPC ASO-association Service 2614 Protocol State Tables 2714.1 States 2714.2 Events 27- iv -14.3 Actions 28Annex A (Informative) ACM negotiation protocol example 31A.1 Requirements 31A.2 Data structure specificati
20、on 31A.3 Example: Association requiring a signed PAC 32Annex B (Informative) Relationship to Kerberos version 5 33B.1 Introduction 33B.2 Kerberos Version 5 Client-Server Protocol 33B.3 Mapping of KRB_AP_REQ and KRB_AP_REP 33B.4 Mapping of KRB_ERROR 34Annex C (Informative) Relationship to GSS-API 35C
21、.1 Introduction 35C.2 Security Context Establishment 35C.3 Security Context Deletion 36C.4 Security Context Modification 36C.5 GSS-API Output Token 36Annex D (Informative) Relationship to OSI-TP 37Annex E (Informative) Managed objects 39E.1 Introduction 39E.2 acmService Class 39E.3 abstractAssociati
22、on Class 401ScopeThis Standard: Defines a model for management of the characteristics of associations between applications in a distributedsystem. The associations can be for interactive (e.g. VT) and non-interactive (e.g. FTAM) applications. Is a framework to provide achievement of availability, in
23、tegrity and confidentiality of an association. It does notdefine how to use specific security mechanisms to protect an association. Defines an Association Context Information Model which is the “language“ to manage the characteristics ofassociations. Defines Service and Protocol for association cont
24、ext management that meets the requirements for a SecureAssociation Service as defined in ECMA-138. Maps association management to a (non-exclusive) set of application layer protocols: ACSE, ROSE, OSI-RPC. Is security policy independent. (e.g. an association might be either application- or system-ini
25、tiated). Supports associations across multiple domains.This Standard does not: Define mechanisms for: authentication, access control, confidentiality, integrity or cryptographic keymanagement. Specify how security services like authentication, access control, confidentiality, integrity or cryptograp
26、hic keymanagement are applied to or initialised in an abstract-association, but it provides the framework to enable theseservices. Specify an Inter-Domain Facility Define an API which can service distributed applications to establish associations. Enforce Association Context Management, but defines
27、a framework of how to achieve it in a standardised way.The field of application of this ECMA Standard is the design and implementation of distributed open systems thatsupport access of users to applications and access between distributed applications.2 ConformanceIn order to conform to this Standard
28、, an implementation shall:a declare which ACM protocol version(s) it supports;b provide the means to send and receive the following ACM PDUs with the syntax defined in clause 13 of thisStandard: ACMinitiateReq, ACMinitiateCompleteReq, ACMreleaseReq, ACMreleaseResp and ACMabortReq;c declare which of
29、the following optional ACM PDUs it can send and/or receive: ACMinitiateContinueReq,ACMmodifyReq, ACMmodifyContinueReq and ACMmodifyCompleteReq;d for all PDUs under (b) and (c) above, provide the means to engage in all and only the sequences defined inclause 13 of this Standard;e for all PDUs under (
30、b) and (c) above, provide the means to encode when sending and to accept when receiving,all those fields which are declared without the ASN.1 keyword OPTIONAL in clause 12 of this Standard;f for all PDUs under (b) and (c) above, declare which OPTIONAL fields it can encode and/or accept;g encode and
31、accept all PDUs under (b) and (c) above, and all fields under (e) and (f) above, according to theASN.1 Basic Encoding Rules (ISO 8825-1);NOTEThis condition does not preclude the use of other encoding rules as an optional alternative.- 2 -h provide a specification in the public domain, or a reference
32、 to such a specification, of a mapping of allsupported ACM PDUs on to underlying communications services.NOTEIt is not required that the supported mappings include any of those specified in clause 13 of this Standard.3 ReferencesECMA TR/46 Security in Open Systems: A Security Framework (1989)ECMA-13
33、8 Security in Open Systems: Data Elements and Service Definitions (1988)ECMA-apa Authentication and Privilege Attribute Security Application with Related KeyDistribution Functions (in preparation)ISO 7498: 1989 Information Processing Systems - Open Systems Interconnection - Reference ModelISO 8326:
34、1987 Information Processing Systems - Open Systems Interconnection - ConnectionOriented Session ServiceISO 8649: 1988 Information Processing Systems - Open Systems Interconnection - Service Definitionfor the Association Control Service ElementISO 8650: 1990 Information Processing Systems - Open Syst
35、ems Interconnection - ProtocolSpecification for the Association Control Service ElementISO 8822: 1988 Information Processing Systems - Open Systems Interconnection - ConnectionOriented Presentation ServiceISO 8824: 1993 Information Processing Systems - Open Systems Interconnection - Specification of
36、Abstract Syntax Notation One (ASN.1)ISO 8824-2: 1993 Information Technology Systems - Open Systems Interconnection - Abstract SyntaxNotation One (ASN.1) - Part 2: Information Object SpecificationISO 8825-1: 1993 Information Processing Systems - Open Systems Interconnection - Specification ofEncoding
37、 Rules for Abstract Syntax Notation One (ASN.1) - Part 1 - Basic EncodingRulesISO/IEC 9072: 1989 Information Processing Systems - Open Systems Interconnection - Remote OperationSyntax, Service Definition and ProtocolISO/IEC 9545: 1989 Information Processing Systems - Open Systems Interconnection - A
38、pplication LayerStructureISO/IEC 9545/DAM 1: 1992 Information Technology - Open Systems Interconnection - Application LayerStructure - Amendment 1: Extended Application Layer StructureISO/IEC 9594-8: 1990 The Directory: Authentication Framework (ITU-T Rec. X.509)ISO/IEC 9595: 1991 Information Proces
39、sing Systems - Open Systems Interconnection - CommonManagement Information ServiceISO/IEC 10165-4: 1992 Information Processing Systems - Open Systems Interconnection - Structure ofManagement Information - Part 4 Guidelines for the Definition of ManagedObjectsISO/IEC 10745: 1993 Information Processin
40、g Systems - Open Systems Interconnection - Upper LayerSecurity ModelISO/IEC CD 11578 Information Technology - Open Systems Interconnection - Remote Procedure CallSpecification. (Four parts).ISO/IEC DIS 11586-2 Generic Upper Layers Security - Part 2: Security Exchange Service Element (SESE)Service de
41、finition- 3 -ISO/IEC CD 10746-1 Basic Reference Model of Open Distributed Processing - Part 1: Overview and Guideto UseISO/IEC JTC1/SC27 N782 Working Draft - Security Information ObjectsInternet RFC 1510 The Kerberos Network Authentication Service (V5) (J. Kohl it can only beused to carry context in
42、formation which does not need to be acknowledged. The responder rejects the association and the reject-reason is “see returned parameters“. Then this parametercarries context-parameters that were not proposed and that would have been appropriate to propose.initiator-context-id: identifier chosen by
43、the initiator of the ACM-Initiate primitive to refer to the context beingcreated.responder-context-id: identifier chosen by the responder to the ACM-Initiate primitive to refer to the contextbeing created.The parameters initiator-context-id and responder-context-id are only present in a positive ACM
44、-Initiate-Complete, when no ACM-Initiate-Continue was previously sent and when initiator-context-id was present inACM-Initiate (see 10.5).result: indicates whether the responding service user accepts or rejects the proposed abstract-association. Valuesare: accept rejectreject-reason: shall be includ
45、ed if result = reject, otherwise omitted. Values are: no reason given context not authorised see returned parameters no common ACMSE version11.7.2 Sequences11.7.2.1 Two-way initialisation of abstract-associationThe following shows the sequence of actions performed by both sides when an abstract-asso
46、ciation issuccessfully established with two messages.Initiator ResponderAuthorise abstract-associationPreliminary definition of the contextMake ACM-Initiate.req Receive ACM-Initiate.indDecide to accept the contextInitialise association-contextInvoke the applicationReceive ACM-Initiate-Complete.ind R
47、eceive ACM-Initiate.indDecide to continue the initialisationFurther definition of the contextReceive ACM-Initiate-Continue.ind Receive ACM-Initiate-Complete.indInitialise the association-contextInvoke the application11.8 ACM-ReleaseReleases an established abstract-association, deletes the associatio
48、n-context at the initiator and at the responderside.req ind rsp cnfrelease-reasonresultreject-reasonO=MC=11.8.1 Parametersrelease-reason: the reason for requesting the release of the abstract-association. Values are: no reason given normal release (end of work) context modifications not agreedresult
49、: indicates whether the responding service user agrees to terminate the abstract-association or not. Valuesare: accept rejectreject-reason: the reason for rejecting the release of the abstract-association. Values are: no reason given external dependencies: this context cannot be released as its existence depends on existing externaldependencies (e.g. other related contexts).11.8.2 Sequences11.8.2.1 Successful release of the abstract-associationThe following shows the sequence of actions performed by both sides when an abstract-association issuccessfully relea
