Comment on ODP Security ----------------------- This document comments on the ODP security in three different points of view: general issues about the work plan, answers to the direct questions in N10416, and comments to security work of OMG in general. In response to the call for comments on ODP Security based upon OMG Security Service (ISO/IEC JTC 1/SC21 N10416) we wish to point out the following general issues. - The ODP security standardisation should be divided in two parts, a security framework and a set of security function standards. The framework standard should be more general than the OMG security services, especially it should cover interoperability issues in a "global" environment. Most of the issues covered by OMG security services can be mapped to the security function standards. However, some architectural issues also find their place in the framework (see below). - We wish that the ODP Security model allows CORBA security services to be conformant at some level. To the questions stated in ISO/IEC JTC 1/SC21 N10416 we have the following answers. - Question A: Relationship between CORBA and ODP security models. We feel that the models have differing purposes and needs. The models do overlap, and on the overlapping area the CORBA security should be conformant with ODP security. - Question B: Technical possibilities to progress the OMG document to an ODP standard. We do not see need for such a process here. - Question C: Progression of the OMG document as it stands to an ODP standard. The OMG CORBA Security specification should NOT be progressed as it stands in a single document. The span of the document is not suited to the ODP work plan. For example, some of the issues addressed in CORBA security are already under work in the "Binding and Interface references". The OMG document does not discuss security between organisations. The OMG document does not include rules for identifying and managing of knowledge about the trustworthiness of a foreign system. The OMG document does not discuss multi-way bindings. The OMG document is based on ORB concepts. The structuring of the document is not comparable with the rest of the ODP standards. The ODP document should use ODP viewpoints as structuring rules. - Question D: Need for all OMG specification. Not all components of CORBA security specification are necessary in the context of ODP. Furthermore, some parts of the specification are too restrictive in the context of ODP. For example, the CORBA security specification discusses CORBA object references which are a lot more restrictive than ODP Interface references (still, CORBA IRs are conformant to ODP IRs). Similarly the concept of federations and IIOPs is too restricted for ODP. - Question E: Sufficiency of OMG specification. The OMG Security specification is not sufficient for ODP security. The OMG document itself claims that inter-organisational considerations need a separate RFP. This in an important area for ODP and thus it should be covered with new work. Security management should be included in the ODP security framework standard. In addition, the ODMA work should refer to that security management specification. - Question F: Contents and structure of ODP security framework standard The ODP framework discusses dynamically established federations between organisations as well as federations within organisations. The ODP security framework should provide a model that serves both levels. The model is therefore required to allow heterogeneous security solutions. Heterogeneity can appear in two forms that can be found from the OMG document. The document introduces multiple security policy domains and multiple security technology domains. The ODP security framework should provide concepts that allow interoperation across autonomous systems in such a way that the security level of the communication can be determined. The level of security involves both the target of communication and the communication channel. The security framework standard should be structured using viewpoint languages. The enterprise viewpoint should point out the heterogeneity of security technology and policies. The information viewpoint should consider security from the "quality of service" point of view. The computational viewpoint should identify activities such as non-repudiation, authentication, auditing, and secrecy. These activities should be defined in terms of collocation of trusted objects and levels of trust required for objects that are allowed to communicate. The computational specification should emphasise mechanisms that are needed and can be used for creating a trusted environment (including remote objects, organisations, etc, in addition to secure communication paths). Functions, such as access control, secure operation invocations, secure streams, auditing, cryptography, and non-repudiation, should not be covered by the framework standard. Comments on additional OMG security work. - OMG has produced an additional security related document, "Common Secure Interoperability" (ORBOS/96-06-20, July 1996), since the call ISO/IEC JTC 1/SC21 N10416 was initiated. We have studied this document, and feel that even it does not solve the above described problems in ODP context. - When combining OMG and ODP work, the basic problem is the term "interoperability" has a totally different scope and meaning.