>		  Interoperating between Security Domains
>
>		    Charles M. Schmidt and Vipin Swarup
>       The MITRE Corporation, 202 Burlington Road, Bedford, MA 01730
>			{schmidtc, swarup}@mitre.org
>
>
>The CORBA Security Service and the Common Secure Interoperability
>Specifications define an architecture for secure interoperation between
>objects.  However, these specifications define interfaces and protocols for
>secure interoperation only when all objects reside in domains that support
>the same security technology.  In contrast, we are studying protocols and
>interfaces that would allow objects to interoperate securely, even when
>their domains do not support the same security policies or mechanisms.
>
>Domains may have varying trust in other domains; they may support differing
>security policies; and they may not have mechanisms to enforce other
>policies.  Thus, three types of machinery are needed to support secure
>interoperability:
>
>1. Trust management mechanisms quantify both the trust one principal
>   (object, domain, etc.) places in another and also the degree of security
>   it wishes to impose on its interactions with other principals.
>
>   Such mechanisms enable principals to decide when to believe that their
>   security policies will be enforced effectively.  This requires a careful
>   elucidation of the trust relationships between the various entities in
>   this architecture.  Trust relationships include, for example, the trust
>   an object has in its ORB, the trust a domain has in the endorsers of
>   object implementations, and the trust between domains.  In previous work,
>   we have studied the trust relationships between principals in mobile
>   agent systems; we are studying the applicability of that work to this
>   situation.
>
>2. Negotiation protocols enable objects in different domains to agree on a
>   security policy to govern a set of interactions between them and on
>   security mechanisms to enforce the security policy.
>
>   If objects in different domains establish trust in each other, they must
>   agree on a specific security policy to govern their interaction.  They
>   must also agree to use specific security mechanisms (e.g., Kerberos) to
>   enforce the security policy.  A negotiation protocol enables its
>   participants to reach such agreements by using a language for
>   representing security policies with operations for combining represented
>   policies.  In this way, the participants can agree on a security policy
>   that is at least as strong as their own individual policies.
>
>3. Mobility protocols enable a domain to transmit security mechanisms (in
>   the form of mobile objects) that allow the receiving domain to enforce
>   the negotiated policy.
>
>   We assume that application-level objects implement security mechanisms
>   and that ORB interceptors invoke methods of these security mechanism
>   objects to enforce a desired security policy.  Objects that negotiate a
>   security policy might reside in domains that do not possess all the
>   mechanism objects needed to implement the negotiated policy.  In this
>   case, a mobility protocol will enable these mechanism objects to be
>   transferred between domains (for instance, via the externalization
>   service).  The domains can then use these mechanism objects to secure the
>   interactions among their objects.
>
>We are examining how the above security mechanisms can facilitate secure
>interoperation between security domains.
>
>
>