20 June 1998: Add URLs
17 June 1998
From: "christian masson" <interception50@hotmail.com> To: jya@pipeline.com Subject: CRYSTINA SECURITY Date: Wed, 17 Jun 1998 05:36:40 PDT PART III The CRYSTINA SECURITY ARCHITECTURE Security features in TINA at various levels. To ease integration in applications, as much functionality as possible should be prtovided as self-contained DPE security services. However, the DPE should also provide lower level DPE security mechanisms to the applications for handling application specific security tasks. The DPE security services are exclusively based on the DPE security mechanisms. The implementation of these mechanisms may directly use cryptographic mechanisms or may be built on availble higher level security technologie, sduch as Kerberos. THe underlying security technology may use the same cryptographic mechanisms as the DPE security mechanisms or proprietary implementations. The use of cryptographic mechanisms and/or higher level security technology may be accomplshed through standardized interfaces (e.g., GSS-API) to facilitate the integration of existing products into the DPE. Above the DPE level, there are special security services, which also rely exclusively on the DPE security services and mechanisms. They are used by TINA applications, but are applications themselves. The special security services are not implemented on each DPE node. Examples are electronic cash support or notary services. Since the TINA DPE is provided by CORBA products, a natural starting point for the TINA security architecture is the CORBA Security specification. The generality of the CORBA Security specification makes it suitable to be the basis of security for a broad spectrum of business applications. In some respects, it's even more general than required, and it's questionable wheter this rich functionality is necessary for certain families of applications, such as telecommunication services based on the TINA architecture. TINA service components are implemented as TINA COs or CO groups. TINA COs may have multiple interfaces, as opposed to CORBA objects, which have exactly one interface. Each interface of a TINA CO will be implemented by a dedicated CORBA object, and thus each TINA CO will be realized as a set of CORBA objects (Kitson 1995). Since the functionality offered by a TINA CO is structured into intefaces according to the coherence of subfunctionalities, access control to a TINA CO can be applied at the granularity of TINA CO interfaces, which means that we only need to control access to whole CORBA objects. Furthermore, TINA service components always act on behalf of the stakeholder that owns them, therefore it is sufficient to support identity based access control schemes at the target side and no delegation is required. For other aspects, secure interoperability provided by CORBA security may not be sufficient for the TINA architecture. Secure interoperation between objects depends on the membership of the objects to security policy domains, security technology domains and ORB technology domain, and that each boundary between TINA administrative domains it also a boundary between security technology domains (Staamann et al. 1997). The latter reflects that stakeholders with various kinds of customer premises equipment, varying priorities regarding security, and under possibly different national laws cannot be assumed to have the same security technologies. Interoperability between objects in different security policy domains can, thus, only be achieved if both domains agree on a common security policy for the respective interactions. This common security policy can be negotiated at invocation time or in advance. Objects in different ORB technology domains can interact securely using the SECIOP, as long as the same security technology is used at both sides. According to the CORBA Security specification, interaction of objects in different security technology domains requires a security technology gateway. However, this may cause a trust problem, because such a gateway cannot be realized without the administrators of both security domains trusting each other or a third party that runs the gateway. A less restrictive solution that is not supported by CORBA would be to negotiate the security technology, as well. When a client invokes an operation on a target object, a request and in most cases a reply are passed between them. According to the CORBA Security specification and based on the observation of various CORBA implementations, the request and the reply can be intercepted at two levels: at the request level, where we have access to the request and the reply as structured data, and at the message level, where the request and the reply are available as an unstructured buffer containing the respective messages in a serialized form. These two levels of interceptions are very well adapted to support the enforcement of security, since some of the security services (e.g., access control) can best be perfomed on structured requests where the information about the involved principals and the operation is directly available, while other security functions (e.g., encryption) can more naturaly be applied to unstructured raw data. Each request is intercepted by the request level interceptor at the client side. If there is no security association established between this client and target object, then the Security Association Setup Service is called and a security assocation is established between them. This means mutual authentification security policy negotiation and exchange of security related parameters (e.g., cryptographic keys, initialization vectors, etc.). The Security Association Service uses the identity information of the stakeholder that owns the client in the authentication process. Based on the authenticated identity of the client, access control on the target object can be perfomed in this phase. If the access is not allowed, then the association is not established at all, and the client is not allowed, then the association is not established at all, and the client is notified. An established security association is represented by security context information on both sides. Then the request is processed further according to the negotiated security policy /e.g., the Non-repudiation Service is called, if it is mandated). On its way to the network, the request is intercepted by the message level interceptor as well, which calls the Secure Invocation Service. According to the negociated security policy, integrity and/or confidentiality protection is applied using the security context information established before. The request is then passed to the ORB Core, which transfers it to the target side. At the target side, the applied services are called in reverse order (with the exception of the Security Association Setup Service, since the association has already been established). Each service can call the Audit Service, if an event occurs that should be audited (e.g., an integrity violation has been detected). The placement of Security Management Services at the edge of the ORB system indicates that these services are usually called by management applications on behalf of the security administrator. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com
From: "christian masson" <interception50@hotmail.com> To: jya@pipeline.com Subject: CRYSTINA SECURITY ARCHITECTURE Date: Wed, 17 Jun 1998 06:58:32 PDT PART III The CRYSTINA SECURITY ARCHITECTURE IMPLEMENTATION OF THE MODEL The SEcurity ASsociation Setup Service, the Audit services, and the Security Management Services are realized by a Domain Security Manager object as an independant CORBA service. The Domain Security Manager object provides interfaces . to applications, through which they can request the setup of new security associations, get established context information, and set security preferences that are not conflicting with the domain security policy, . to other Domain Security Manager objects, through which they can authenticate each other, negotiate policies and exchange keys, and . to management applications, through which they can manage credential and policy objects. The Domain Security Manager object is unique in each domain and available to all applications in the domain. The established security association between a client and a target object is represented by the Security Context objects contain all the information of the association and provide the Secure Invocation and Non-repudiation Services. Access control is performed explicitly at association setup time,therefore it does not have to be perfomed by the Context objects. Access control is implicitly provided for each invocation within a security association by the identification of the client. In order to identify the right local Context object that should be applied to handle the current invocation, a Local Context Manager is required, which manages the various local Contexts. The Local Context Manager requests the association establishment and downloads the context information from the Domain Security Manager. The Context and the Local Context Manager objects are not CORBA objects, they do not have visible interfaces. This implementation realizes the CrySTINA model by tracing a secure object invocation. The client's request is intercepted by the request level interceptor at the client side. This interceptor invokes the Local Context Manager to obtain the context that should be applied to the request. If there is a context already established between this client and target, then the Local Context Manager returns a reference to it. If there is no such context, then the Local Context Manager calls the Domain Security Manager to establish one. The Domain Security Manager object uses the identity information of the stakeholder that owns the clientin the context establishment process. This information is stored in the Credentials object. Once the context is established, the Local Context Manager downloads it, and returns a reference for it to the request level interceptors. Explicit access control is perfomed by the Domain Security Manager in the association establishment phase. Access is allowed or denied at object granularity level. If access is allowed, then the association is established between the client and the target, and the Local Context Manager returns a reference to the appropriate Context object; otherwise no association is established, and the Local Context Manager raises an exception. When the request level interceptor obtains the reference to the Context object, it calls it with the request as the parameter. The Context object will perform the required services on the request (e.g., non-repudiation of origin) according to the security policy. Then, the request is passed on and it is intercepted by the message level interceptor. This interceptor already knows which Context to apply, and it can call this Context object with the message parameter. Note, that at this level we have access to the message as an unstructured stream of bytes, so the Context object can easily perform the Secure Invocation Services, accordingto the security policy. The last step is to put a special security header atthe beginning of the message that contains the necessary information for the target side message level interceptor toidentify which context it should use to reclaim the message. Then the protected message is passed to the ORB Core that sends it to the target. At the target side, the incoming message is intercepted by the message level interceptor. This interceptor interprets the security header, and calls the Local Context Manager with the parameters found in the security header (e.g., a context ID) to obtain a reference to the Context object that should be used for this message. If the context is already available (i.e., this is not the first message from the given client); then a reference to it is returned by the Local Context Manager, otherwise the Local Context Manager first downloads the context from the Domain Security Manager, and then passes the reference to the interceptor. Note, that the context is already available at the Domain Security Manager, because the association is already established between the client and the target by the time when the mesage arrives at the target. In the next step, the request is intercepted by the request level interceptor. The interceptor already knows which Context object with the request as the parameter. The Context object performs the appropriate operations on the request. The fact that the request arrived at the target side request level interceptor already means that acess is allowed. Finally the request is passed to the target object. The reply is handled in a similar way. The difference is that the interceptors already knows which context to apply because they have temporarily stored this information when handling the request. CONCLUSION Unlike the CORBA security architecture, CrySTINA can cope with the heterogeneity of security policies and security technologies, which must be excepted as a side effect of the selfadministration of the administrative domains in TINA. (future work: implementation using a commercial ORB product (Orbix 1997) and a free Java CORBA implementation produced at the Free University Berlin called JacORB (Brose 1997). project no 5003-045364 ______________________________________________________ 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