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