Maintained and edited by
Konstantin Beznosov
June 18, 1999
I could not find an answer to my question here, where else can I ask my question?
What is SecSIG?
Who contributed to this FAQ?
What magazine publications describe, review, compare, critique
CORBASEC?
Are there any papers or articles that compare CORBA security with
security of other distributed object computing frameworks such as Java RMI or
DCOM?
Where can I get a tutorial about CORBASEC?
Is there any group or lab research on CORBA security service?
Is there a set of UML diagrams for the CORBASEC Specification?
What are the shortcomings of CORBA Security service?
What about CSI with SSL?
What is the validity of a context?
Are the any interfaces specified in CORBASEC for controlling security
context by security-aware applications?
How to come up with application security design using CORBA Security
service?
How does a security-aware application specify the use of a specific
algorithms for supporting communication confidentiality and integrity?
How is related work at OMG on Security Administration and Common
Management Facilities ?
What is the granularity of access control on object invocations?
Where are access control lists stored?
How do servers ``know'' what domain to put new objects into and when to create
new security policy domains?
What about transient objects created by factories?
How would access control mechanisms be applied to secure, let's say, naming
service?
Where can I find some source code which implementation Security
Service?
Is there any document on how to implement the CORBA security service?
If I want implement the CORBA security service, what should I do?
Does the existing Authorization Service of CORBASec scale in a
"well" distributed-object environment?
What is the "public" security attribute of a principal?
Under what circumstances do Credentials contain the ``public'' attribute?
What is the value and the defining authority of the ``public'' attribute?
Where can I find an implementation of Security Services ?
Where can I find exactly what product implements what Security
level and options?
What ORBs claim to have ``security'' functionality?
Is there any free/trial/evaluation version of an ORB with Security
Service for Java?
What would be the most suitable ORB product(s) when buliding a
(very) small lab for evaluating, testing and implementing security functions
in a CORBA system?
Are CORBAsec implementations from the US generally subjected to
export control?
Is there a free implementation of CORBA SSL service that will work
with VisiBroker 3.* for Java?
Does the SSL-certificate certify the server or the object?
EXCEPT WHEN OTHERWISE STATED IN WRITING, THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE DOCUMENT AND INFORMATION CONTAINED IN IT "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY OF THE INFORMATION IN THE DOCUMENT IS WITH YOU. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE DOCUMENT AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE INFORMATION CONTAINED IN THE DOCUMENT (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES ), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
This document is copyrighted by its all contributors. and its maintainer . This document may be distributed under the terms of General Public License.
Who sponsors the FAQ?
The document is sponsored by the Center for Advanced Distributed System Engineering
at Florida International University
and by Baptist Health Systems of South Florida.
CORBA Security service specification is comparatively long (more than 300 pages) and complex. It is difficult to understand every point of the specification, and it is even more difficult to grasp the ``big'' picture of how everything is supposed to ``work.'' On the other hand, many different people (ORB developers, application developers, system and enterprise administrators, security guys, etc.) with different technical backgrounds want to understand different aspects of the specification and its implementations. Even more, sometimes the intent of the authors, expressed in the particular wording, is interpreted differently by different readers, which causes problems not only to those readers but also to others. Also, it was observed that when various working groups and teams begin discussions on CORBA security, they spend a substantial amount of effort and time just getting to the common ground and agreeing on a common understanding of security aspects of CORBA technology. This FAQ was created to help all those who need to understand CORBA Security service specification and to provide readers with additional information that could not be included in the specification but is considered useful to eliminate problems described above.
Answers that are new or are updated since the last month revision, are marked
with the sign `` ". Questions that do not have answers
yet are marked with the sign `` ''.
Changes in the text made since the last month revision are marked with change line the ones surrounding this paragraph.
Those who do or will use CORBA Security service specification or its implementation, or who is curious about security aspects of CORBA technology.
Find a question which is similar to yours. Read the answer to it.
If you want to grasp the context of the thread from which the answer was originated, and if the answer has an e-mail message ID of the original message, then use the ID to track down the thread in various archives and news groups. Read the thread to get better understanding and all details of the answer.
I could not find an answer to my question here, where else can I ask my question?
Send your questions to the mailing list on CORBA security (question Are there any newsgroups or mailing lists about CORBASEC that I can join?).
The intent of the list is to provide forum for discussing issues related to security in CORBA-based systems and applications.
Information on how to subscribe to the mail list is available at
http://www.cs.fiu.edu/~beznosov/corba/security/mail-list/
It's a majordomo-based mail list. Usual majordomo commands can be used with the list.
What is SecSIG?
SecRTF is OMG's revision task force created exclusively for revising CORBASEC.
The best way is to send an e-mail message to its maintainer (question Who is maintaining this FAQ?).
The best way is to send an e-mail message with contribution to its maintainer (question Who is maintaining this FAQ?).
Your contribution to this list is subject to its copyright policy described in section.
Who contributed to this FAQ?
The following is the list of people who contributed to this Q&A list (in alphabetical order):
![[*]](cross_ref_motif.gif)
,
4.1.31, 4.1.26,
6.1, 6.1,
3.11
,
4.1.26,
4.1.27, 4.1.28,
4.1.29,
4.3.3
The following is the list of wish items maintained by the maintainer. These are various wishes about this FAQ from different people. The list is used by the maintainer to improve the FAQ usefullness. Anyone who thinks they have a great idea about how to make the FAQ more helpfull to the Internet community, are welcome to send suggestions to the FAQ maintainer.
``CORBA Security Service'' is one of CORBA core services specified in CORBA 2.x and higher. Specification of it defines security functionality interfaces available in a CORBA ORB.
Konstantin Beznosov (December, 1997):
``CORBASEC'' is a shorter and more informal name for ``CORBA Security Service.''
Konstantin Beznosov (December, 1997):
There is no difference between ``CORBA Security Service'' and ``CORBASEC.''
Konstantin Beznosov (December, 1997):
CORBA stands for Common Object Request Broker Architecture. If you are reading these lines, you probably know something about CORBA. If not, read question Where can I find more about CORBA?.
Konstantin Beznosov (December, 1997):
The most comprehensive information about CORBA technology is available at the OMG web site.
Konstantin Beznosov (December, 1997):
Chapter 11 (28 pages) presents informal description of CORBASEC. The authors walk through key CORBASEC features (according to the book: authentication, privilege delegation, authorization, audit trail, non-repudiation, non-tampering and encryption, security domains, security policies management) and summarizes CORBASEC interfaces. It also walks through several scenarios of exercising security by security-aware applications. The level of the presentation does not assume any background in security and it requires nominal knowledge of the CORBA technology.
Book Information
What magazine publications describe, review, compare, critique
CORBASEC?
There is a brief description of a paper which appeared in Distributed Computing Magazine recently called : "Licensing and Metering" by Julia Miller and Alex Kotopoulis.
It covers several aspects of Security and may talk a little bit about our product Object/LM. If not there is info about that on our web pages. The full text of the article is available at: http://www.distributedcomputing.com.
It is titled: "CORBAsec: Securing Distributed Systems: Find out what CORBAsec has to offer for security-aware applications."
Are there any papers or articles that compare CORBA security with
security of other distributed object computing frameworks such as Java RMI or
DCOM?
Where can I get a tutorial about CORBASEC?
There was tutorial on CORBA Security service during the first day of the Second Workshop on Distributed Object Computing Security given by Bret Hartman (Concept Five Technologies, Inc.).
There is a downloadable presentation in PDF format on "Security Concepts for Distributed Component Systems" By Walt Smith of Tekna, which contains an overview of the CORBASEC architecture.
This was a presentation to the 21st National Information Systems Security Conference
It is available at: http://csrc.nist.gov/nissc/1998/proceedings/tutorB2.pdf.
G'unter Karjoth. Analysis of Authorization in CORBA Security. Technical report, IBM Research Division, Zurich Research Laboratory, December 1996.
Also, OMG Security Working Group released ``OMG White Paper on Security'' in 1994, where they described issues with security design in distributed object systems and outlinened CORBASEC model. The paper available at the OMG site as document 94-04-16.
Is there any group or lab research on CORBA security service?
Konstantin Beznosov (November, 1998): 1.2
Konstantin Beznosov (March, 1998): SecRTF (see question What is SecRTF?).
Konstantin Beznosov (March, 1998): Not yet.
Konstantin Beznosov (March, 1998): The OMG Technical Committee.
Konstantin Beznosov (March, 1998): Look at http://www.omg.org/issues/sec-rev.html.
Konstantin Beznosov (March, 1998): First, you want to make sure that the typo or the problem you found is not discovered by somebody else before. For it, you want to check the list of all outstanding issues on CORBASEC specification. (read question Where can I find a list of outstanding issues in CORBASEC specification?. The best way to submit a report on error or typo in CORBASEC specification is to send an e-mail message to SecRTF reporting it (question What is SecRTF?).
Is there a set of UML diagrams for the CORBASEC Specification?
Konstantin Beznosov (March, 1998): See question I found a typo in the specification, where can I submit it?.
Konstantin Beznosov (March, 1998): First, report the idea to SecRTF. They will consider the proposal and decide if it is valid and if it is in the scope of the revision TF or it goes beyond it. If it is in the scope of the RTF, then there will be a separate issue number assigned so that it can be tracked and eventually resolved. If the proposed improvement is beyond the RTF scope, your idea most probably should go trough the standard technology adoption process (i.e. with issuing an request for proposals (RFP)) in the OMG. Please refer to OMGweb site to find more information about how CORBA technologies are adopted.
What are the shortcomings of CORBA Security service?
Rajan Gupta (February, 1998): It is correct. In summary, CORBA security is Object Based Security Model while DCE security is more procedural.
Andreas Vogel (February, 1998): Essentially, the CORBA security service defines a framework and interfaces in which you can plug in security mechanisms of your choice. DCE has defined a set of mechanisms (one for each security concern) upfront.
Linda Gricius (March, 1998):
Principal authentication is the process of proving your identity to the security enforcing components of the system so that they can grant access to information and services based on who you are. This applies to both human users of the system as well as to applications.
A user or application that can authenticate itself is known as a principal. A principal has a name that uniquely identifies it.
For human users, the process of authenticating to the system is informally known as "logging on". In a typical system, an application is provided to collect information proving the user's identity. This application is often referred to as the "user sponsor". In order to successfully authenticate to the system, it is important that a principal can provide some proof that it is who it claims to be. Proof of authentication is usually achieved by demonstrating knowledge or possession of a "secret" known only to the "real principal", such as a password or cryptographic key.
It is important that a successfully authenticated principal can be given some unforgeable evidence that it has recently authenticated, in order to prevent the principal from having to continually re-authenticate itself to different parts of the system. The unforgeable evidence that is returned to authenticated principals is known as the principal's credentials.
Linda Gricius (March, 1998):
Credentials contain the security attributes of the principal, a "lifetime", and a few other fields. Credentials are used:
Authenticated attributes include identity attributes, which identify the principal, and privilege attributes, which grant rights to the principal.
Linda Gricius (March, 1998):
Attributes are type/value pairs that are associated with authenticated users, and held in their credentials. There are two types of attribute: identity attributes (known as identities) and privilege attributes (known as privileges).
An identity attribute has a value which identifies the principal. Examples of identity attributes that a principal might carry are AuditID (which is the label recorded in audit records relating to this principal, and which may be different from AccessID) and AccountingID, which is the number to be used when charging the principal for resources used.
A privilege is a right granted to a principal that enables them to perform some action that would otherwise be denied. Examples of privileges are AccessID (which is the name that they authenticated as) and Clearance level.
These are functions expected to be required in several ORBs, so are worth including in this specification, but are not generally required enough to form part of one of the main security functionality levels specified above. At present, there is only one such option in the specification, non-repudiation.
This specifies if and how the ORB fits with different Security services. There are two possibilities:
ORB Services replaceability. The ORB uses interceptor interfaces to call on object services, including the security ones. It must use the specified interceptor interfaces and call the interceptors in the specified order. An ORB conforming to this does not include any significant security-specific code, as that is in the interceptors.
Security Service replaceability. The ORB may or may not use interceptors, but all calls on Security services are made via the replaceability interfaces specified in Section 15.7, Implementor's Security Interfaces of the CORBASEC specification. There interfaces are positioned so that the Security services do not need to understand how the ORB works (for example, how the required policy objects are located), so they can be replaced independently of that knowledge.
If the ORB does not conform to one of these replaceability options, the standard security policies defined in the CORBASEC specification cannot be replaced by others, nor can the implementation of the Security services. For example, it would not be possible to replace the standard access policy by a label-based policy if one of the replaceability options is not supported. Note that some replaceability of the security mechanism used for security associations may still be provided if the implementation uses some standard generic interface for Security services, such as the Generic Security Service API (GSS-API).
Secure interoperability - Standard. An ORB conforming to standard secure interoperability can generate and use security information in the Interoperable Object Reference (IOR) and can send and receive secure requests to/from other ORBS using the General Inter-ORB Protocol/ Inter-ORB Interoperability Protocol (GIOP/IIOP) protocol, with the Secure Inter-ORB Protocol (SECIOP) enhancements defined in Section 15.8, Security and Interoperability, of the CORBASEC specification, if they both use the same underlying security technology.
Standard plus DCE-CIOP - Option. An ORB conforming to standard plus DCE-CIOP secure interoperability supports all functionality required by standard secure interoperability, and also provides secure interoperability (using the DCE Security services) between ORBs using the DCE-CIOP protocol.
If the ORB does not conform to one of these, it does not use the GIOP security enhancements, so will interoperate securely only in an environment-specific way.
Common Secure Interoperability (CSI) - confined to secure interoperability of object requests and replies via the GIOP/IIOP protocol.
[Bruno Traverson](September, 1998)13: Clause C.2 [ed: of the Appendix C in the CORBASEC sepcification v1.2] makes clear that conformance can be claimed at two levels:
Linda Gricius (March, 1998):
The CSI specification is part of the overall CORBASEC specification.
The Common Secure Interoperability specification defines the standards for common secure interoperability when using GIOP/IIOP, by defining:
An ORB conforming to CSI level 2 can support all the security functionality described in the CORBA Security specification. Facilities are more restricted at levels 0 and 1. The three levels are:
Linda Gricius (March, 1998):
CSI Common Security Protocols define the details of the tokens in the SECIOP messages. Three protocols are defined:
The GSS protocol is based on the IETF GSS Kerberos V5 definition, which specifies details of the use of Kerberos V5 with GSS-API. It includes updates to RFC 1510; e.g., how to carry delegation information. It is specified in RFC 1964. This itself is a profile of the Kerberos V5 mechanism as defined in IETF RFC 1510, September 1993.
What about CSI with SSL?
The SECIOP protocol establishes an association between the peers and then protects messages between them. The SECIOP protocol is security mechanism independent, but carries more primitive messages for mechanisms such as Kerberos that "do the hard work".
It's important to realise that these received credentials are not identical to the originator's since (for example) they may not necessarily be used for making further on going associations (called delegation), and they certainly won't allow the target to set_attributes (eg. change the current active role of the client). Perhaps "reconstructed" is a better way to view it.
The session key doesn't actually come from the initiator's Credentials, but rather from a complex (and mechanism specific) protocol message that is separate from the Credentials data - look at the SECIOP protocol EstablishContext message and the specific message contexts for mechanisms such as Kerberos and CSI-ECMA.
[ed: The communication is encrypted] if that's what policy requires. The message may just be integrity protected, or it may require no protection at all. There is also replay protection which is context based.
Subsequent SECIOP messages are all MessageInContext, quoting the context reference that was created when the target was first contacted.
What is the validity of a context?
Credentials are not "for" a host, a process or an object. They only describe the user (the principal in fact); they can be expressed at any host/process/object.
The granularity of how contexts are created between clients and targets depends on the security characteristics of the underlying operating system. In UNIX/NT type systems the context is established between the client's process and the target's process, rather than between hosts or objects. This is because the context contains secret keys and all objects (ie. application code) in a process have equal access to these keys, so there is no extra security gained by forming multiple contexts for objects in the same process - though it would do no harm. Processes are partitioned from each other by the OS, so there is some protection to be gained by forming different contexts for objects running in different processes. Similarly for different hosts.
If you wanted to share contexts more widely than between processes, you would have to jump through hoops to make the OS do that in a secure manner. Processes are the natural level of protection granularity - though some operating systems make take this to the thread level.
[ed: About necessity of establishing a new context:] If the 2nd object is co-located with the first in the same process, then the context can be re-used. If the objects are running in different processes, a new context must be established because the 2nd target has no idea what the session key(s) are that were established between the client and target A - it also did not directly authenticate the client itself, so it would have to trust the other process before it shared the context. That might not be a trust we can assume.
Are the any interfaces specified in CORBASEC for controlling security
context by security-aware applications?
Linda Gricius (March, 1998):
In a secure CORBA system, the same client calls the same target object that it would call in an unsecured system. The invocation request is intercepted by the ORB Security service at both client and target, and the level of protection required by the current policy settings is applied. Security may be enforced at the client side, the target side, or both. This includes support for any or all of the following:
It's important to note that object implementations do not need to be changed to fit into and be protected by a secure ORB. A distributed application may be made up of many small objects, and it is unusual for all the application developers to be sufficiently security knowledgeable to make the right calls on the security facilities.
John Sebes (April, 1998):
Briefly, the answers are: transport of client ID data is performed by CORBA security mechanisms. One does not need to pass user IDs as parameters, and even if one did, there would still be the authentication issue. Authentication functionality is part of the CORBA security mechanism for transporting client ID. There is no CORBA Security Service Context in IIOP per se, because the context data is carried as part of a security protocol for IIOP- either SSL or SecIOP.
As an example of how such things are done today, consider a typical IIOP/SSL implementation. There is no identity or authentication data in IIOP at all. The SSL session setup protocol includes authentication and exchange of digital certificates that include identity information. Security-aware applications can obtain client identity information either: (a) via CORBASEC interfaces for accessing the "Current" object, or (b) proprietary or ORB-specific interfaces for accessing data in X.509 certificates passed via SSL.
This should answer your questions with respect to mechanisms. However, there are several open issues for actually using these mechanisms, for example: availability of FSP from ORB vendors, implementation of CORBASEC, SSL, and/or SecIOP; integration/bundling of public-key infrastructure elements (e.g. certificate management); facilities for trust management in certificate evaluation (how can you control which certificates you actually believe?)
In summary, the mechanisms exist, but may not be available in FSP, and in any case require some careful thought for safe and effective use.
If you're concerned about authentication, your DNS lookup was not secure and it would give you confidence you were talking to the right name server. On the otherhand, the client could have a list of trust points (certificates) to compare the identity presented by servers against, and a rogue name service will not be able to direct you to a rogue target.
If you're concerned about privacy when communicating with the name service, someone could snoop the wire waiting for you to contact the name service and then watch where you go next. I would therefore argue that your privacy would be compromised anyway (with respect to the TCP association).
I realise an SSL based scheme might well be different in this respect, since an SSL client is more autonomous (not requiring the services of external objects in order to obtain Credentials, true?). But I'm not really sure about this ... hence the question 7.5.12.
I think that [ed: securing naming server] is not just an option, but a REQUIREMENT on clients, unless they can otherwise obtain a secure source of object references. Clients that don't do this can assume nothing about the true identity of the target - eg. whether data returned is trustworthy, or whether effects they believe they have produced have actually occurred. And this is true EVEN if they turn on EstablishTrustInTarget, which is particularly frightening.
If this is true, I think the consequences should be made much more visible to application writers. For example, one consequence is that security UNAWARE applications - those that can't call get_security_names and check them - MUST operate on a trusted source of object references, since they can't check security names for themselves.
How to come up with application security design using CORBA Security
service?
How does a security-aware application specify the use of a specific
algorithms for supporting communication confidentiality and integrity?
Actually, I think this is absolutely inappropriate, but I might be missing the essential points that justify this design. My question therefore is:
Given that the corba rights family is intended to serve most cases, what exactly are the semantic connotations for these four rights? Are they simply chosen in an ad hoc way, or is there some deeper reasoning behind this choice, such as why it would make administration easier in some cases? If so, how and in which cases?''
This is a good question, and one which we discussed extensively during the initial definition of the specification. The basic motivation for defining a small, standard set of rights and strongly encouraging everyone to live with that set is that there are a potentially unlimited number of methods in any given CORBA system (each new class can introduce large numbers of them), and the set of methods is semantically very complicated from the viewpoint of the administrator - methods with the same name may do different things, methods with different names may do the same thing, methods may have names which do not at all suggest their function or sensitivity, and methods belonging to the same class may have very different consequences if invoked on different instances with different internal states. This makes it almost impossible for administrators to manage policy using methods. Rights are thus introduced as a way to "group" methods. We could have stopped after introducing the notion of rights, and allowed implementors or even administrators to define arbitrary collections of rights, but we felt that this would lead to a chaotic situation in which the population of rights would be widely variable across different vendors' implementations and different customers' or even departments' deployments, making training and interoperability a nightmare.
We chose instead to conceive of rights as a kind of language, to be used definers of new object classes to communicate the sensitivity of their classes' methods to the security administrator. We defined a small language of rights which corresponded generally to the KINDS of operations which an object-oriented system's methods perform, namely:
method reads and returns one of the object's data members method writes one of the object's data members method executes one of the object's member functions
We defined a right corresponding to each of these basic KINDS of operations, and added one more right to deal with the real-world fact that some operations of the same KIND are more sensitive than others of the same KIND.
Hence the intended semantic connotations of the rights in the "corba" family are:
Clearly they aren't an exact match for all possible security policies in a CORBA environment, but I don't think a system which supports an exact match for all possible policies would be one which could be administered by normal humans.
If I got it right, individuals have a bunch of privilege attributes such as access_id, group, security clearance, role, etc. The administrator can grant rights to those attributes, for example rights to call read-methods (get), write-methods (set), or management-methods (manage). The DomainAccessPolicy object stores all this security data in a table, such as (simplified)
| Privilege attribute | Granted Rights |
| access_id:alice | get, set |
| access_id:bob | get, set |
On the target side, a "RequiredRights" table exists, specifying which rights are required for each method. For example
| Required Rights | Operation |
| get | m1 |
| get | m2 |
Now, because Alice holds get (and the set) right, she can call both methods. How could we specify get-permission on m1 for Alice, and on m2 for Bob, but no permission on m1 for Bob and on m2 for Alice?''
| Privilege attribute | Granted Rights |
| access_id:alice | get, set, do_m1 |
| access_id:bob | get, set, do_m2 |
| Required Rights | Operation |
| do_m1 | m1 |
| do_m2 | m2 |
On the other hand, the scheme does not scale up to large numbers of users (pricipals) and different object types, because the number of different combinations of granted/required rights is finite, so in order to avoid "rights clashes" like the one outlined in the first posting, you will again have to restrict your way of writing policies to relatively small domains - which is inconvenient if your policies happen to apply to large number of objects and principals. All in all, I'd say that there are quite a few limits in that paricular access model.
If protection is to be achieved on the basis of location, and CORBA does nothing to help verify location, yes. CORBA Security protection works on the basis of a principal's credential attributes, not its location. This is sometimes a surprise to people who are used to thinking about security in terms of firewalls and other such location/topological constraints.
How is related work at OMG on Security Administration and Common
Management Facilities ?
What is the granularity of access control on object invocations?
[ed. For more detailed and alternative answers see SecSIG mail list discussion
thread titled ``Granularity of Invocation Access Controls'']
Where are access control lists stored?
[ed. For more detailed and alternative answers see SecSIG mail list discussion thread titled ``Granularity of Invocation Access Controls'']
How do servers ``know'' what domain to put new objects into and when to create
new security policy domains?
[ed. For more detailed and alternative answers see SecSIG mail list discussion thread titled ``Granularity of Invocation Access Controls'']
ACLs certainly DON'T need to go away when the objects they control are destroyed. There's no reason "empty" domains shouldn't stay around - people might want to put new objects into them later.
What about transient objects created by factories?
[ed. For more detailed and alternative answers see SecSIG mail list discussion thread titled ``Granularity of Invocation Access Controls'']
How would access control mechanisms be applied to secure, let's say, naming
service?
The first thing you have to do is define a RequiredRights object that each context will have access to. Logically, all contexts will see the same required rights object, but that cannot be enforced, since the naming context can bind contexts of different services coming from anywhere.
But lets say for the moment, the naming service and each context in it prescribes to the same required rights object however that is done.
Give the "resolve" operation on the naming context interface the "0 0 get" right, (0=family definer, 0=family) give the "bind" and "bind_context" operations the "0 0 set" right, with a combinator of SecAllRights.
Now, set up a domain manager for each context! Each domain manager must have a SEPARATE Access Policy.
For each Access Policy you narrow it to a DomainAccessPolicy and you must give the "0 0 get" right to the one attribute that represents the user. (This could be SecAttributeType (0,1,2) Access Id (0=family definer, 1=family, 2=type). Give the "0 0 set" right to the attribute that represents users you want to be able to do binds.
Here are the limitations: The initial context will have a problem, however, that you cannot specify the "get" right for "ALL" users. One would think that you could specify that "no" rights are required for access to the initial context's "resolve" operation and that would do it. However, if everyone prescribes to the same RequiredRights object, your hosed, because you wouldn't be able to protect the "resolve" operation on other contexts.
We did an experiment a while ago, trying to map Unix id's into CORBA and use the naming service as a map of a Unix file system. Each context was a directory, and each file was a CosSerializable object (or some such animal).
For each context, the context had to create "on the fly" a domain manager and an AccessPolicy object (not a DomainAccessPolicy object). This was easy, since the Naming Service in question was a single server and could do these sorts of things.
The AccessPolicy object mapped a certain security attribute representing the user to its corresponding Unix id, and threw back the rights, "read", "write", "search", according to the permissions of the Unix id based on its authorization information on the local system, i.e. owner, group, other.
However, we couldn't do that kind of policy with a plain DomainAccessPolicy, because there isn't a way, unless we had some sort of "wild-card" security attribute, that you could say "other". But even then the specification of the DomainAccessPolicy rules aren't good enough to do an ordered check, say, first check "owner", then check "group", then check "other" relationships.
Naming context is an interface, so it needs to have an entry in a RequiredRights table. Add this interface to the system's unique RequiredRights object and set up required rights for the its methods. For purposes of argument, map "read" and "traverse" operations to the "g" right and other operations to "s". This may be too simplified; if a more complex mapping is required it's straightforward to produce it. If you need one, a custom rights family can be defined.
Right. Form a group "InitialContextAccessors". Add the privilege attribute corresponding to this group to the credential of each user who is to be granted full access to the initial context.
Right; form another group "InitialContextLimitedAccessors". Add the privilege attribute corresponding to this group to the credential of each of the users who does not have full access, but does have "read and traverse" access to the initial context.
Now put the context object into a domain. Give it an ACL with two entries; one which grants "gs" to "InitialContextAccessors" and another which grants "g" to InitialContextLimitedAccessors".
Not clear exactly what you mean here, but I'm guessing what you mean here is that the same users who have access to the parent context also have the same level of access to all embedded contexts; additionally some other set of users who do not have access to the initial context should have at least some rights (full access in your example) to the embedded context.
There are a couple of ways to do this; depending on your implementation you may have several options. If your implementation allows nested domains (i.e. domains within domains) then you've got an easy task here:
Simply create a new domain and put it in the first domain. Add the embedded context to the new domain. This will have the effect of causing the embedded context to inherit the policy governing the initial context. Now:
repeat the above recursively.
Where can I find some source code which implementation Security
Service?
Is there any document on how to implement the CORBA security service?
If I want implement the CORBA security service, what should I do?
The "credentials" object represents the "principal". It was defined with a number of different possible underlying security mechanisms in mind - which might use (PK) attribute certificates, Kerberos/DCE service tickets etc. Strictly, credentials can contain both unauthenticated and authenticated attributes (see 15.3.2) - the unauthenticated case being used mainly for "public" where the principal has no authenticated id, so only has access to public information.
CORBA Security defines the interfaces, not the architecture, in line with other OMG standards. As a security person, I clearly want to know if the credentials can have been tampered with, but that is a feature of the implementation, not the interfaces. So we said CORBA Security implementors must define "assurance" information about their products, including threat information, and users have to check that. Would the OMG rules allow statements about the level of authentication of the id and other attributes? If so, it would be nice to clarify this, though I'm not sure how easy it is to define. (The current spec allows different levels of security here and elsewhere).
Security attributes were intended to include both identities and privilege attributes - both seem needed. Therefore a "principal" definition which does not allow privilege attributes would seem a retrograde step.
We did not define the syntax of possible name types, though, as Nick says, this seems a good thing to add into the standard. The problem was that different underlying mechanisms use different name types e.g. X.509 names, DNS ones, operating system ones, so applications which need to be portable between different mechanisms should be able to work with different types.
We wanted to allow a range of access control mechanisms, including roles, groups, clearances etc, and also ones specific to particular organisations (for which we had seen requirements). Hence having privilege attributes as well as identities in the credentials. Specifying standards for more families, types, associated value syntaxes etc in the OMG standard would be good. (However, a quick look at the ietf draft of GAA_API seems more restricted than CORBA Security, and also includes an access decision interface which CORBA Security already has.)
The application sees a credentials list (rather than just a single credential) in cases where the delegation model used can provide both the credentials of the "initiating" principal and also credentials for one or more intermediates. The initiating principal is the one whose attributes will be used for access controls, auditing etc. However, the target application may not want to use these unless they have come via trusted intermediates (and may want to control access based on the intermediate's attributes in some cases). We discussed whether we could specify a recommended delegation model for CORBA Security, but there were several delegation models in existing implementations, all of which had pros (as well as cons). There did not seem any generally market preferred model, and we felt these delegation models were still immature, so we specified an application interface which allowed for the delegation models in a number of products, both secret and public key based ones - the ones we looked at included Kerberos, DCE, SESAME and Tivoli, all of which were different, hence the delegation variants defined in 15.3.6.3 etc. (We also looked at "reference restriction" forms of delegation such as Sun were implementing, but could not get an agreed definition, so did not include in the formal definiton). The semantics of the credentials list was not defined, as it is dependent on the mechanism (e.g. simple delegation would only provide a single credentials object, where composite and traced delegation would give a list), but the initiating principal's credentials are always first (the only ones wanted in many cases). OK, this was a bit of a cop-out, but is there yet a delegation model which is generally agreed enough yet (and being implemented) to include in CORBA Security as the standard?
... For the intial CORBA Security spec, delegation was discussed at length, and we found different models suited different requirements, but there was no one model which satisfied most requirements and was easier enough to administer. Simple delegation was the nearest (as it meets the ease of admin requirements, if not some of the control ones).
Does the existing Authorization Service of CORBASec scale in a
"well" distributed-object environment?
This part of security is enforced in the ORB, for example, through the "client access control interceptor" (Figure 15-53).
My question is: Can't the client circumvent the restrictions? Assume we use C++ for the application and the stubs objects. Now, does the ORB run in a different address space than the application
(incl. stubs)? Or is the client part of the ORB linked to the application at compile time (and thus running in the same address space)? If the ORB were in the same address space, then the client could just modify the ORB code to circumvent the policies that the administrator has imposed. Even if the ORB were running in a different address space, the client could still write a piece of software which behaves like the ORB, but leaves out the routines where administrative restrictions are enforced. The client could then his "custom ORB implementation" rather than the "real" ORB for communication, hereby circumventing administrative security policies.
In my Kerberos 5 based implementation I use GSS-API to get a ticket from outside the CORBA system. Then I use GSS-API to establish a security context between client and server. This is done at a very low level during the bind, before any IIOP messages are sent. If the server can't authenticate the client the connection is dropped. All IIOP messages are encrypted/decrypted using GSS function.
In theory such a system is quite bullet proof. In the real life an attacher might be able to exploit a buffer overrun on the server ORB and execute arbitrary code. There are some other possible attacks, too.
What is the "public" security attribute of a principal?
Under what circumstances do Credentials contain the ``public'' attribute?
What is the value and the defining authority of the ``public'' attribute?
Where can I find an implementation of Security Services ?
Alphabetical list of CORBA Security products or announcements about such products:
``... IntraVerse for CORBA (IVCorba(TM)) solves the primary problem limiting full CORBA deployment at many organizations, the need for security and authorization services. IVCorba 3.0 is the only enterprise CORBA single sign-on and authorization solution that supports secure interoperability between Object Request Brokers (ORBs) from multiple vendors, providing users with the flexibility in their development and deployment of CORBA applications.
Furthermore, IVCorba 3.0 provides the only CORBA Security Service to implement controlled delegation. This function provides the ability to pass user and server information with a transaction request, enabling extremely fine-grained access control.
...
IVCorba 3.0 provides full support for Iona (NASDAQ: IONA - news) OrbixWeb(TM) as well as Inprise (NASDAQ: INPR - news) VisiBroker(TM), the most widely deployed ORBs. By providing a cross-ORB external authorization solution, DASCOM has freed developers from trying to individually implement security services for each application as it is developed. Furthermore, IVCorba provides a single sign-on solution, enabling personalized services and simplified administration. Users can log in once and access all the resources that are appropriate for them.
...
Availability
IVCorba 3.0 began shipping June 14 on Solaris and Windows NT. For more information,
contact DASCOM at info@dascom.com. ``
ORBAsec SL2 2.0 from Adiron is a Java implemenation of CORBA Security giving programmers the ability to write objects and clients using encryption and authentication integrating with Kerberos authentication services or SSL. ORBAsec SL2 uses standard CORBA Security Level 2 interfaces from the CORBA Security Specification Revision 1.5. ORBAsec SL2 2.0 has been available since 2Q 1999.
``OrbixSecurity 3 ... available in Q3, 1999
OrbixSecurity 3 extends the security capability of the OrbixOTM container (OrbixSSL) by providing a manageable, scalable security infrastructure for Enterprise systems. A full implementation of the CORBA security service Level 1 and more, OrbixSecurity 3 delivers a comprehensive security service systems based on the IETF's Secure Socket Layer (SSL) security.
Secure your Enterprise system with OrbixSecurity 3
Based on, and incorporating all features of the IETF's SSL V3.0, OrbixSecurity 3 extends the functionality of SSL, adding CORBA Security Service Level 1 functionality and extra features such as an Administration GUI to make the creation and updating of security policies an easy, manageable and scalable task. OrbixSecurity 3 provides fine grained control of security in the system - security is added at the application level allowing access control checks to be performed on a per object, or even per method basis. CORBA Security Level 1+ Services enforce basic audit and access control functions in security-unaware applications, as well as providing limited Applications Programming Interfaces (APIs) for enabling security-aware applications to manage their own security. Ideal for Internet and Enterprise systems, OrbixSecurity 3 provides the following features and functionality:
All features of CORBA Level 1 Security including:
Managing large scale secure systems with OrbixSecurity 3
OrbixSecurity 3 is designed to make securing a large scale Enterprise system an easier task. CORBA Level 1 Security services provide security to applications that are typically unaware of the presence of the security service in the system, and can be added to applications without having to alter any existing code. This makes adding security to an existing system a much easier task. OrbixSecurity 3 also provides a comprehensive GUI interface to make implementing security policies quick and trouble free. A Java - based graphical user interface enables security administrators to easily create and update security policies.
OrbixSecurity 3 will provide full cross language functionality for both Orbix and OrbixWeb C++ and Java applications, and will be available on OrbixOTM 3 supported platforms.''
See section 5.2.2 for more information on OrbixSecurity.
Where can I find exactly what product implements what Security
level and options?
What ORBs claim to have ``security'' functionality?
Here is a list of those products that do not claim compliance with CORBA Security specification. Nonetheless they state that they have some security functionality. Read answer to question 5.1.1 to see what implementations of CORBASEC are available:
The beta features include:
For details, please see:
1. http://www.objectScape.com/jbroker.html for JBroker 2.0 data sheet
2. http://www.objectScape.com/performance.html for performance comparison with other commercial Java ORBs
3. http://www.objectScape.com/appserver.html for white paper on "Building an EJB Server using JBroker"
If you are interested in evaluating JBroker 2.0 for your projects, please send an email stating you interest to evaluations@objectScape.com. If your interests meet our beta objectives we will contact you with details on how to get our software.
It handles postage stamp (# of uses) and gas style (length of time) metering, plus authentication, authorization and encryption.
Is there any free/trial/evaluation version of an ORB with Security
Service for Java?
What would be the most suitable ORB product(s) when buliding a
(very) small lab for evaluating, testing and implementing security functions
in a CORBA system?
Are CORBAsec implementations from the US generally subjected to
export control?
Linda Gricius (March, 1998): DAIS is a CORBA 2.0 ORB, plus CORBA services,
developed by ICL. In 1997, ICL released the first Beta of the DAIS Security
service. Based on feedback from program participants, a second beta was released
in late 1997.
Linda Gricius (March, 1998): 1.0.2 beta.
Linda Gricius (March, 1998):
Required functionality - DAIS Security provides near level 2 conformance with the CORBASEC specification. The only Level 2 features not supported are: Multiple credentials for a user Delegation Application level audit and access control Administration by standard policy objects.
Security Functionality Options - DAIS Security does not support non-repudiation - the only CORBASEC option at this time.
Security Replaceability - ORB replaceability isn't supported. The ORB interceptors in DAIS Security version 1 are not standard. Services replaceability is supported (ORB security objects are implemented to CORBA standard interfaces and could therefore be replaced).
Secure Interoperability - In DAIS, secure associations are established using SECIOP messages in DAIS Security, but the SECIOP messages are carried inside IIOP requests rather than following the interoperability standard.
DAIS Security does not support DCE-CIOP.
Conformance to CSI Spec - DAIS (i.e. SESAME) generates full identity and privileges (i.e. it has ECMA PACs), which points DAIS at CSI level 2. But level 2 also has controlled delegation. The first release of DAIS doesn't support delegation, which points DAIS back at level 0. So DAIS does level 0, and bits of level 2 (the privileges in addition to identity), but don't do controlled delegation.
Linda Gricius (April, 1998):
Perhaps the best known security mechanism is Kerberos, which was developed by MIT. Kerberos does not provide all of the functionality required by the full CORBA Security model. Therefore, DAIS Security uses a different mechanism called SESAME, because ICL believes that the functionality of the full CORBA model is required to implement enterprise strength security systems. Basically SESAME implements the CSI-ECMA protocol of the CORBA Security interoperability specification. SESAME V4 is essentially Kerberos V5 extended in various ways (and rewritten), in accordance with the ECMA Security standard, known as ECMA-219.
Regardless of the security mechanism used, the DAIS Security service accesses the mechanism via a generic API, called the Generic Security Services API or GSS-API. This is a standard API that presents the same interface to the caller, regardless of the mechanism underneath being used to implement the functions.
Linda Gricius (April, 1998):
DAIS Security provides near level 2 conformance with the CORBASEC specification.
DAIS uses SESAME (CSI-ECMA) as it's security mechanism. This brings a rich set of features to the DAIS Security service implementation, including the use of roles and support for both public/private and secret key technologies.
In addition, DAIS Security provides a full GUI administration tool, which allows the administrator to manage principals, roles, trust relationships, domains, required rights, invocation policies, etc. The GUI is written in Java and is distributed - using DAIS Security itself to secure the communications. This provides much more functionality than what is defined in the CORBASEC specification.
DAIS Security also provides an integrated, offline public key certificate management system, which also has a secure distributed Java GUI.
DAIS Security also offers a SecurityLevel2 programming interface to security aware applications, currently in C++ only.
Linda Gricius (March, 1998):
Principals gain access to services by presenting credentials, which contain attributes, and give them access rights to services. These attributes can be assigned to each individual, or to a role. By then allowing a principal to authenticate with a given role, all of the attributes associated with that role are put into the principal's credentials.
So, the use of roles is more efficient when administering principals - rather than having to administer attributes for each principal, you can assign attributes to roles, and then allocate roles to principals.
Linda Gricius (March, 1998):
Public key users have an inherently stronger binary key with which to authenticate. The key is not memorable, and was not selected by the user in any case. Because of their strength, public keys need be changed less frequently - and the certificate that holds the public key contains a built-in lifetime to enforce its replacement after a chosen period. The involvement of trusted "officers" in the creation and maintenance of public keys is also inherently more secure, requiring the collaboration of more if they wanted to abuse the system.
Users that form associations with their public key do not require the services of a Key Distribution Service, even during inter-domain association, which is more efficient at runtime.
Public key users also have an advantage in being able to use the same key to authenticate to many principal domains (if they are configured as members of those domains). Their keys are trusted on the basis of a Certification Authority (CA), the scope of which may span many principal domains. So having authenticated once to the CA system in order to get a public/private key pair, the key may be used to authenticate the user wherever that CA is trusted (until the key expires).
Since public key certificates may be freely distributed and certified at the point of use, there is also a fundamental scalability advantage to systems that use public keys.
Linda Gricius (March, 1998):
Password users have a simple life - they carry their authentication information (their password) with them in their heads, and most users already understand the idea of passwords. This has the advantage of not requiring that they login at a workstation that has any secrets pre-installed for them. It is also conceptually and procedurally easier for them to be set up to use a password and change the password at regular intervals.
The disadvantage of using passwords is that, by depending on a comparatively short memorable string, a password is inherently weaker than a large binary key value. Users often choose very guessable passwords, or write them down, or never change them, or only change between a small number of alternatives.
In addition a KDS41 is required to form associations for clients that authenticate using passwords, and in the case of inter-domain invocations, the KDSs of both domains are involved. This is less efficient at runtime.
Password users that have accounts in several principal domains should have different passwords for each domain. Each password is only trusted for use between the user and one domain's Authentication Service (AS).
Linda Gricius (March, 1998):
DAIS Security supports three types of domain - principal, policy, and trusted identify domains.
The major security advantage in dividing a system into domains is to achieve separation of unrelated parts of an organization - either people/departments or sets of applications/data. By separating the system into domains, the appropriate security controls can be put in place for each domain, and access to information between parts can be controlled. If a domain member deliberately tries to damage the system, the damage they can do will be limited by their domain's security limitations.
The best separation of the security system is most likely to mimic organizational structures that you already have. For example, the reason the Sales department is separate from the Development department is that the two communities deal with different business processes, and consequently have different applications/data and security requirements. Furthermore, the two departments are unlikely to require access to each other's systems. By reflecting this in the domain structure, appropriate controls can be put in place to protect applications/data within domains and to control access between domains.
Principal domains are the easiest way to divide communities of users and application objects. By putting users and related applications in a principal domain, access to objects from users within the domain is possible, but access from users outside the domain has to be explicitly granted.
After separation of responsibilities, the second reason to divide a system into domains is to allow the overall size of the system to grow without unmanageable growth in the size of its parts. A small pilot system is unlikely to have a large number of users, roles, and applications. Therefore, little is to be gained by dividing the system into many principal and policy domains. The overhead of the extra effort to install and manage the system via multiple domains would outweigh the benefits. As an installation becomes larger, the benefits of splitting it into separate domains become more apparent - particularly in terms separation of responsibilities and of the workload on any one particular administrative or "run-time" security component.
Linda Gricius (April, 1998):
Within a principal domain, policy domains can be used to group object types (i.e., instances of an interface) and workstations into high, medium, and low security groups. You can have different policy settings for the same interface in different domains. Some groups of very sensitive objects would have very stringent access control requirements and message protection. Other groups may require little or no security because of their insensitive nature.
You can also achieve separation of domains by not defining certain target interface types in certain policy domains; e.g., if the "lowsec" domain doesn't have the interface "missile_launch" defined, then there's no way that clients from that domain can ever invoke objects of that type.
Linda Gricius (March, 1998):
More information about DAIS and DAIS security service can be found on its web site www.daisorb.com.
What is the conformance level of OrbixSecurity?
Where do I start from in order to use OrbixSecurity?
OrbixSecurity Application Development requires :
Dan Hushon (November, 1997): The Orbix documentation warns you that you should
not run the daemon from the root uid, as the root on another machine will be
able to control and invoke methods on the particular instance.
Dale Nagata (November, 1997): If the user Foo is allowed to invoke or launch the server Bar on host X, then any user on any remote machine Y can invoke or launch the server if Orbix thinks the user is Foo. What you do at the remote client to make Orbix think you are Foo is up to you, whether you actually login with that id, use a filter, or whatever.
But DCE uses a RPC call for client-server communication. The CORBA standard is based on connection-oriented calls or TCP calls. Does this mean that the OrbixSecurity is not CORBA complaint? Can somebody please clarify the authentication process used in OrbixSecurity.
Ludwig Brinckmann (June, 1998):
GSSAPI as such does not actually define how to log on to a system, but how to
exchange secure messages between authenticated principals. For this a principal
has to present its credentials to the GSSAPI routines. To obtain these
credentials, a DCE login is used. This actually requires a DCE installation
on the client machine and the protocol used for this is DCE RPC. Once the DCE
login context has been established, it is passed to the gssdce_login_context_to_cred
routine to obtain the GSSAPI credential. (The DCE implementation of GSSAPI provides
a few routines prefixed with gssdce that bridge between DCE and GSSAPI.)
The credential is then used in GSSAPI routines to for a handshake between client
and server and then to routines like gss_sign to encrypt the messages
between peers. Technically the Orbix/DCE security implementation is hybrid:
it uses DCE to establish the authentication of client and server and the Tickets
obtained are then used to encrypt IIOP traffic. This is good, because it provides
the best implementation of authentication available for the mass market and
bad, because you will need a separate DCE installation (with all the maintenance
and licensing costs).
Also, OrbixSecurity uses OrbixFilters. This is a potential problem if you use filters in your system since you cannot define the location of the security related filters within your filter chain.
Can we use Orbix security to provide Access control at Object instance
level?
Is there anybody who have came across this problem, or who have suggestions on how I should solve it?
Does anyone has experience on implementing system access control
and security service using VisiBroker for Java?
If there is a security service supported by omniORB and if not
are there any plans to create one?
Has anybody integrated DASCOM's Intraverse and Entrust (PKI), and
Iona's OrbixWeb?
Looking at the problem a bit more closely, there can be some nasty subtleties depending on what you are actually trying to secure. If you haven't already done so, you should read the recent thread in this [ed: comp.object.corba] group titled "Naming Service and SSL".
It is fair enough to want only "authorized clients" to write to a naming service, but (potentially) any object that wishes to export its object reference to a name server has to have some write permission, and also the permission to remove its own reference. It may be possible to give everyone the ability to export objrefs, but only privileged clients power to change the structure of the namespace - I'm affraid I don't know the name server interface well enough to say, but CORBA Security is capable of distinguishing different operations on an interface.
There can be bootstrap problems with secure name services in some CORBA Security systems. But these occur when you want to treat the name service as a source of TRUSTWORTHY object references. Basically, to bootstrap CORBA Security you may need to obtain some trustworthy object references (for example of Authentication and Privilege services) BEFORE you can talk securely to anyone, including the name service. I believe this situation is different for simple public key based systems (such as CORBA SSL) that can bootstrap without external object support.
The subtlety in the other thread is a consequence of the fact that CORBA Security does not guarantee that the security name embedded in an object reference is the CORRECT security name. Just because you secure access to the name server does not necessarily mean that clients are not exporting object references with false information in them. Changing the security name in an objref would allow an attacker to masquerade as the genuine object, even though the security service is active (including the EstablishTrustInTarget feature!).
To overcome this with a secure name service, you would need very application/system specific access controls (that look at message content) or you would have to trust your (exporting) clients. CORBA Security (appendix D.6.2 of the latest specification) says that end users (clients) of object references are responsible for verifying their security names unless they have a trusted source of objrefs. I'm just pointing out that putting access control and message protection on a name server doesn't necessarily provide a trusted source of objref CONTENTS.
It is sometimes perfectly possible for clients to know and check the security names of objects. For example in DAIS Security the bootstrap problem mentioned above is avoided because the authentication client can predict the correct security name of the appropriate Authentication and Privilege services for its particular domain. However, in general, it is very difficult for clients to know the correct name - and in the case of security UNAWARE applications they are not supposed to know anything about security anyway! This is also discussed (and solutions proposed) in the other thread.
How can security-aware applications apply confidentiality and integrity
to data (e.g. electronic documents)?
Is it possible to specify the data to be protected as a parameter
to the interface, or as data protection service?
Linda Gricius (March, 1998):
SESAME (a Secure European System for Applications in a Multi-vendor Environment) is a research and development project, partly funded by the European Commission under its RACE program. It is also the name of the technology that came out of that project.
SESAME is a construction kit - it is a set of security infrastructure components for product developers. In a nutshell, SESAME:
Linda Gricius (March, 1998):
This is what happens:
To access the distributed system, a user first authenticates to an Authentication Server to get a cryptographically protected token used to prove his or her identity. The user then presents the token to a Privilege Attribute Server to obtain a guaranteed set of access rights contained in a Privilege Attribute Certificate (or PAC). The PAC is a specific form of Access Control Certificate that conforms to ECMA and ISO/ITU-T standards. The promulgation, protection and use of PACs are central features of the SESAME design.
The PAC is presented by the user to a target application whenever access to a protected resource is needed. The target application makes an access control decision according to the user's security attributes from the PAC, and other access control information (for example an Access Control List) attached to the controlled resource. A PAC can be used more than once at more than one target application. It is digitally signed to prevent it being undetectably tampered with.
The PAC is cryptographically linked with the authenticated user to which it was issued, to prevent anyone other than the original owner (or one of their delegates) from using it. To provide this protection SESAME needs to establish temporary secret cryptographic keys shared pairwise between the participants. Kerberos key distribution protocols can be used for dialog key establishment, but they can also be either supplemented, or where appropriate completely replaced by public key technology. SESAME also supports Certification Authorities, X.509 Directory user certificates, following ISO/ITU-T standards.
User data passed in a dialogue between a client and a server can optionally be either integrity protected or confidentiality protected or both, using specially created Dialog Keys.
Linda Gricius (April, 1998):
Similar work, aimed specifically at UNIX systems, has been done by the Massachusetts Institute of Technology which has developed a basic distributed single sign-on technology called Kerberos. Kerberos has been proposed as an Internet standard (RFC1510).
In the light of this work, the SESAME project decided that in its early implementation some of the SESAME components would be accessible through the Kerberos V5 protocol (as specified in RFC1510), and would use Kerberos data structures, as well as new SESAME ones. This has shown unequivocally that a product quality approach reusing selected parts of the Kerberos specification is workable and that a world standard is possible incorporating features of both technologies. SESAME extends Kerberos in the following ways:
Linda Gricius (March, 1998):
SESAME's origins lie in the Open Systems Standards work of ECMA, the European Computer Manufacturers Association. In 1987 ECMA started its work on Security in Open Systems. It was here that the early ideas that are the basis of SESAME were formed. Following that first meeting, experts from all of the major computer manufacturers have at different times been involved in this work.
The Common Secure Interoperability (CSI) specification, which is part of the CORBASEC specification, defines the standards for common secure interoperability when using GIOP/IIOP. A part of this standard is the use of defined protocols. CSI-ECMA is one of these protocols.
How do I to get SESAME API?
Linda Gricius (April, 1998):
Another important development in the field of Open distributed system security has been the Generic Security Services Application Program Interface (GSS-API). This interface hides from its callers the details of the specific underlying security mechanism, leading to better application portability, and moving generally in the direction of a better interworking capability. The GSS-API is independent of communications, and only produces opaque tokens that must be transported separately (by any convenient scheme, such as SECIOP/GIOP).
A GSS-API implementation is viable across virtually any communications method. GSS-API is an Internet and X/Open standard. SESAME is accessed through the GSS-API, extended to support features needed to provide distributed Access Control.
How do I to get GSS API ?
The ORBacus Open Communications Interface (OCI) provides the architectural framework that enabled the ORBacus SSL plug-in to be developed without any changes to the ORB core. The ORBacus SSL plug-in replaces the IIOP protocol with the SSLIOP protocol defined as part of the OMG security specification. This protocol is simply IIOP over a secure SSL channel. Applications can be SSL-enabled through the addition of a few simple API calls. The plug-in provides you with full control over the cipher suites used for client/server connection establishment. Furthermore, your applications can use any combination of secure and insecure connections, all under the complete control of the developer.
Other features of ORBacus SSL include:
Is there a free implementation of CORBA SSL service that will work
with VisiBroker 3.* for Java?
You can enable SSL with any VisiBroker server by initializing the BOA with SSLTPool (if you pass the command line args into BOA_init, -OAid SSLTPool will do the trick) and initializing the SSL layer with a digital identity (you can do this with initializers to avoid modifying the code). The resulting IOR will contain an SSL component.
The problem is that IORs are not self securing. A security name (which I guess is the certificate name in SSL?) is included as a hint in the IOR (true?), but the system doesn't guarantee that the IOR hasn't been tampered with. So an attacker can tweak an object reference to use the security name of his own principal - something that he has the keys for - and then clients using that object reference think they are operating securely (which in a sense they are!), but are actually talking to the wrong object. All the ORB guarantees is that you are talking securely to the security name in the IOR, not that the name in the IOR is the one you want to talk to.
I understand how this works with the Kerberos and CSI-ECMA mechanisms, but I'm not sure how/if it's different with SSL. I see the problem as fundamental (there's no provable link between an object reference and the security name), so there must be an equivalent weakness in SSL based CORBA systems, true?
As E.6.2 [ed: D.6.2 in the current version of the spec] says, the onus is on the client to check the security name(s) of any target it intends to use, unless it has a trusted source of object references.
The addition of this check [ed: by client of the security name(s) of any target it intends to use] is pretty straight forward though and the ORB could do it for you. If a communicating party presents something like a wallet that not only contains credentials, but contains trustpoints (i.e. trusted certificates that aren't necessarily roots), the ORB can reject the connection if the target identity does not contain a trustpoint.
I believe that a security unaware application CAN operate in an environment where the source of object references is not necessarily trusted IF a wallet can be administered that contains trustpoints. Basically the wallet notion moves the source of trust to the wallet rather than relying on the source of object references.
Does the SSL-certificate certify the server or the object?
This document was generated using the LaTeX2HTML translator Version 98.1p1 release (March 2nd, 1998)
Copyright © 1993, 1994, 1995, 1996, 1997, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
The command line arguments were:
latex2html -no_navigation -dir CORBASEC-FAQ/multi-page -reuse 2 -local_icons -address -html_version 4.0 -numbered_footnotes -contents_in_navigation -toc_depth 0 -up_url CORBASEC-FAQ.html -up_title CORBASEC FAQ -show_section_numbers -verbosity 0 -split 0 -dir CORBASEC-FAQ/single-page CORBASEC-FAQ.tex.
The translation was initiated by on 1999-06-18
, "#2", on page .
.
.