>Abstract for OMG/NSA Workshop on Distributed Object Computing Security
>
>Title: Multi-Protocol Authentication Gateway for CORBA over the Internet
>Authors: Michelle Abram, John Sebes, Deborah Shands
>
>Authentication is a critical part of CORBA security. Cryptographically
>based distributed authentication technology is essential for identification
>of remote clients accessing local CORBA-based objects. Distributed
>authentication is particularly important for inter-enterprise CORBA
>computing over the Internet, where one organization must be able to
>identify principals of other organizations, and determine whether they are
>authorized for access to local resources. However, there is no single
>security technology for CORBA authentication. There are various
>technologies (such as SSL, Kerberos, DCE, Sesame, and SPKM) that are
>supported by one or more ORB vendors, or soon may be. As a consequence, it
>is quite possible that two enterprises may wish to engage in CORBA-based
>Internet computing, but have ORBs that do not use the same security
>technology for distributed authentication. In such cases, end-to-end
>security interoperability is not achievable without some form of security
>gateway.  The Sigma research project (funded by
>DARPA, RL, and NSA) at Trusted Information Systems is developing a
>multi-protocol authentication gateway for CORBA over the Internet.  
>
>The Sigma ORB Gateway (ORBgw) is a network perimeter security device that
>provides authentication and access control for CORBA distributed object
>requests entering an enterprise network, or enclave, from other networks
>such as the Internet. A key feature of the ORBgw is its support for
>multiple security technologies and authentication techniques. The ORBgw's
>authentication component consumes CORBA object request messages (in the
>form of IIOP protocol messages) transported with any one of several
>security technologies. The ORBgw validates the authentication credentials
>of an incoming IIOP message, even when the authentication technique is not
>used by the ORB of the ORBgw's enclave. Based on validated authentication
>data and meta-data, the ORBgw performs IIOP message filtering, permitting a
>request message to flow into the enclave only if the authenticated
>requestor is authorized to invoke the requested operation on the target
>object. When messages flow through, they are transported from the ORBgw to
>the target object server using the security technology of the enclave's
>ORB, even if the request was sent using a different technology. This
>message filtering is a form of access control that is similar to that
>performed by ORBs but is broader in scope. The ORBgw supports multiple
>authentication technologies, centrally implements a single policy on all
>outside access, and provides the critical element of trust management of
>foreign credentials. As a result, the enclave's ORB can delegate to the
>ORBgw the responsibility of authentication and access control of object
>requests from other enclaves.
>
>For each request message, the end result of Sigma ORB Gateway
>authentication processing is a mapping from the requester's
>authentication data to an equivalence class of principals. All members
>of such an equivalence class - called a domain, in Sigma
>terminology-have equal authorization to an access class of CORBA
>objects. The computation of this mapping, i.e. domain derivation, is
>accomplished by a number of steps. The first step is performed by one
>of several authentication modules, each of which is an adapter/wrapper
>of a single distributed authentication technique. The result of this
>step is a set of validated authentication data, together with
>meta-data about the authentication technology and credential. For
>example, one message may be characterized by the following
>information: identity="Fred Nertz", mechanism="SSLv3", CA="XYZcorp
>CA", IPsec-authenticated IP source address="192.70.78.8". The second
>step is a trust analysis, in which the output of the previous phase is
>filtered to eliminate data and meta-data that are not trustworthy.
>This results in a relative integral trust rating for the
>authentication data.  The third step is to match the trust-rated
>authentication data against a set of domain membership rules.
>For example, this domain derivation step might match a rule which
>states that Fred Nertz is a member of Domain Beta if all of the
>following apply: authentication via SSLv3; certificate from XYZ Corp;
>trust rating of 5 or greater. After domain derivation, the domain is
>used in the access control computation referred to above.
>
>Currently, SSL is supported as a CORBA security technology and IP
>source address data can be used in the formulation of domain
>derivation rules as well as data from X.509 certificates. We are
>working on two other areas: use of IPsec to authenticate source
>addresses, and use of DCE as a CORBA security technology.  We have
>developed two policy languages: TMeL, for the statement of trust
>rating rules; and DSPeL, for the formulation of domain mapping
>rules. For each language, we have a prototype GUI for the composition
>for policies. The authentication, trust management, and domain
>derivation machinery has been integrated into our ORB Gateway
>prototype, which we have demonstrated as interoperable with three
>ORBs: ILU, Orbix, and Visibroker.
>
>
>
>
>
>
>
>Terry C. Vickers Benzel
>Trusted Information Systems, Inc.
>3415 S. Sepulveda Blvd., Suite 700
>Los Angeles, CA 90034
>310-737-1744 x 124
>Fax 310-737-1755
>
>