20 June 1998: Add URLs
17 June 1998
See related Tina: TINA and CRYSTINA
From: "christian masson" <interception50@hotmail.com> To: jya@pipeline.com Subject: CORBA SECURITY Date: Wed, 17 Jun 1998 02:57:44 PDT PART II CORBA SECURITY This work has been supported by the Swiss National Science Foundation as part of the Swiss Priority Programme Information and Communications Structures under project no. 5003-045364. Security is enforced using security functionality built into the system. The CORBA security (http://www.omg.org) Security spesification defines the following security functionality: . Identification and authentication of principals to verify they are who they claim to be. . Authorization and access control to decide wheter a principal can access an object. . Security auditing to make principals accountable for their security related actions. Auditing mechanisms are coupled with authentification functions in order to be able to identify the principal correctly. . Secure communication between objects, which requires the establishment of security associations between clients and target objects, and integrity and/or confidentiality protection of messages in transit between them. . Non-repudiation to provide evidence of actions such as proof of origin or receipt of data. . Administration of security information. Most of these security functions are perfomed during a secure object invocation, which is the basic notion of the specification. Each secure object invocation requires an established security association between the client and the target object. The security association is established by authentification between the client and the target, making the clint's security attributes (identity and privileges) available at the target side, and establishing the security context that will be used when protecting messages in transit between the client and the target object. The way of establishing a security association depends on the security policies that govern both the client and the target object. Associations will normally persist for many interactions. For each object invocation, the request from the client to the target object is subject to access control. Access control may take place at the client side, the target side, or both sides according to the access control policy. The access decision is based on the client's security attributes, the target's control attributes (e.g., the operation and data) and about the context (e.g., the current time). This general model enables a large variety of access control schemes, ranging from access control lists, over capabilities, to label based schemes. The scale of access control is specified, but it can be assumed that implementors will provide access control down to the granularity of operations. In many cases, objects perform operations on behlaf of the initiator, which can be a human user or a system entity, needs to delegate some or all of its privilege attributesto the intermediate objects that will act on its behalf. The CORBA Security specification is very general and enables virtually all kinds of delegation models (simple, composite, combined and trace delegation). The actual type of designation is selected according to the delegation policy either by the ORB system automatically, or by applications via well defined interfaces. Depending on the security policy, the integrity and/or confidentiality of the messages between the client and the target object may be protected, and optionally non-repudiation may be provided by cryptographic means. For the detection of actual or attempted security violations, security auditing is perfomed. Depending on the implementation, recording security relevant events may involve writing event information to a log, and/or generating an alarm. Audit policies specify which events should be audited under which circumstances. A distributed objects system may consist of a huge amount of objects with a possibly even larger amount of security associations between them. This fact raises the issue of scalability. In order to cope with the scalability problem, the notion of domains is introduced. Three types of domains with regard to security are defined by the CORBA Security specification: security policy domains, security environment domains, and security technology domains. A security policy domain is the scope over which a security policy is enforced. A security policy domain is administered by a single security authority. A security environment domain is a domain in which the enforcement of the security policy is achieved by local means (e.g., objects on the same machine). The security technology domain is a set of objects for which the same security technology (e.g. Kerberos(Neuman and Ts'o 1994)) is used to provide security. Each security domain contains a domain manager object that references the valid security policy objects for that domain. A security policy object (e.g., access control, delegation, secure invocation, or audit policy), which is defined and managed by the security administrator of the domain. Upon the creation of an object, the ORB implicitly associates the object with one or more security domains according to the construction policy (the objects can be moved between domains later on) and then transparently enforces the security policies of those domains. In this way, security is provided to all applications, even to those that are unaware of it. Additional security measures may be enforced by the applications themselves. This may be done by additional enforcement of administrator defined policies, and/or direct use of security features (e.g., non-repudiation) via application interfaces. The security measures enforced by the applications cannot override the security policies defined by the administrator. The rationale behind these two levels of security is the fact that in the general case, application developers cannot be expected to be aware of all the threats to which the system will be subject, and to put the right contermeasures in place. On the other hand, there are mission critical applications that require the application programmer to have more control over security. The security functionality described above is provided by ORB Security services that may rely on some underlying security technology, which itself may use operating system machanisms and additional security hardware. During secure object invocations, the ORB intercepts the requests and replies between the client and the target object and calls the appropriate security services. Some of the security services can be invoked by the applications directly, to enforce their own security preferences. An important aspect of this architecture is that the components that implement the security services are independent of any specific security technology. The spefification allows the use of an isolating interface (e.g., GSS-API(IETF 1993)) between this level and the security technology, allowing different security technologies to be accomodated within the architecture, such as technologies based on operating system protection mechanisms, existing security components (e.g., cryptographic libraries), or a set of distributed security services. The specification of secure interoperability between different CORBA implementations extends the CORBA 2.0 standard. A new protocol, the Secure Inter-ORB Protocol (SECIOP) is specified, which enables secure interactions of clients and target objects that reside on different ORBs, as long as the same security technology is used on both sides. The information, which security technology an object supports is part of the interoperable object reference (IOR). Based on the information in the IOR, a security context acceptable for both sides can be established. The establishment of the security association and the protection of messages are controlled by security tokens that are added to the inter-ORB protocols. Key management is not explicitly dealt with in the CORBA Security specification. The Common Secure Interoperability document (OMG 1996) specifies the use of the protocols of three security technologies within SECIOP, namely SPKM, Kerberos, and the ECMA security protocol. If the interoperability between the ORBs is based on DCE (OSF 1992), then the DCE security technology (X/Open 1994) based on the Kerberos protocols can also be used. A recent addendum (OMG 1997) allows also the Secure Socket Layer (SSL) (Netscape 1996 http://home.netscape.com/assist/security/ssl/) to be the basis of inter-ORB security. AUAP Access Related User Application SUAP Service Related User Application PA Provider Agent IA Initial Agent UA User Agent SF Service Factory USM User Session Manager SSM Service Session Manager CSM Communication Session Manager CPE Costumer Premises Equipment TCSM Terminal Communication Session Manager KTN Kernel Transport Network ODL Object Description Language NCCE Native Computing and Communications Environment ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com
From: "christian masson" <interception50@hotmail.com> To: jya@pipeline.com Subject: CrySTINA add Date: Fri, 19 Jun 1998 07:09:59 PDT URL SLL: http://www.psy.eq.edu.au:8080/~ftp/Crypto SLL-HTTP: http://www.news.com/News/Item/0,4,7483,00.html countermeasure: http://www.geocities.com/Eureka/Plaza/6333 https://www.thawte.com