20 June 1998: Add URLs

17 June 1998

See related TINA and CORBA


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