CORBA 3 Firewall Specification
As detailed in the CORBA 3 Firewall specification at http---www.omg.org-cgi-bin-doc-orbos-98-05-04
with erratum at http---www.omg.org-cgi-bin-doc-orbos-98-07-04
By Kevin Kuphal
Introduction
The CORBA 3 specification for firewalls evolved from the need to have the CORBA communications protocol (IIOP) work seamlessly with firewall products. This was done by defining the GIOP protocol which is implemented by IIOP which maps GIOP to the TCP protocol. While there is nothing inherent in IIOP that prohibits firewall products from working with it, it does not expose any means for firewall configurations to act upon the protocol itself to determine security rules.
This exploration of the specification concentrates on the protocol issues surrounding running CORBA in a firewall environment. While mention is made of specific CORBA objects enhancing the use of CORBA in such an environment, an analysis of those specific objects is cannot be found here. For detailed information on object for firewalls in CORBA, you should visit the specification directly at the link above.
Current implementations
The current state of CORBA interaction with firewalls involves active participation from the client, server, and firewall. The firewall must explicitly know ahead of time the ports that the server is listening on for IIOP and configure them to be opened for the client who must also know this information. While this is not a serious problem, it is not elegant and does not allow for more than a simple allow or deny configuration.
Solutions
The CORBA 3 specification seeks to address firewall issues with several solutions none of which are exclusive to the others.
The first solution is the creation of new data elements in IORs (Interoperable Object Reference) that allow CORBA applications to send detailed information to a variety of firewalls including socks proxy firewalls, GIOP proxy firewalls, and TCP firewalls. This detailed information allows compliant firewalls to examine the IIOP traffic and make educated decisions about security based on that data. For details of these IORs, please see the specification at the link at the top of the page.
The second solution adds support for SSL (Secure Socket Layer) to IIOP over firewalls. SSL is very popular for securing IIOP traffic. By allowing this traffic over firewalls, the transaction is secured over the entire path. SSL however introduces a problem in that it inherently prohibits examination of the data by the network along the way. The CORBA 3 firewall specification provides for this by specifying a method of communication such that there are two distinct SSL transactions sent, one for the client to the proxy and a second for the proxy to the server. This allows for the proxy/firewall to examine the appropriate information as provided for in the first solution while still maintaining the security of the entire transaction between the client and the server.
The third solution provided for by this specification is in the support for callbacks. In the current callback specification, server hosts contact client workstations by initiating a TCP connection. It is uncommon for firewalls to allow this type of communication initiating from an external server to an internal workstation. This specification provides for callbacks in two ways. The first is by allowing bi-directional communication where a server reuses a client initiated TCP connection. This works for situations where clients are being called back by the server they originally communicated with. Since this may not always be the case, GIOP proxy functionality is also introduced.
Functionality required by GIOP proxy firewalls
The specification outlines the features that must be provided by a compliant proxy firewall. These features could be implemented as part of a firewall product or even in a separate proxy server.
Specifics of Firewall Specification
The firewall specification introduces some concepts that must be defined before a discussion of the firewall specification can continue.
Enclave – An enclave is a group of objects protected by either an inbound or outbound firewall.
Inbound firewall – Designed to protect enclaves from unauthorized access from external sources.
Outbound firewall – Designed to restrict enclaves from accessing external sources.
Enclaves may be nested in that one enclave may contain another. An example of this might be a separation between engineering and finance departments within a single organization. Each department and the organization are enclaves, each with their own set of access rules governing their firewalls.
ORBs and Firewalls
An ORB needs two pieces of information to connect to an object in another ORB. First, the outbound firewalls that must be traversed must be known, and second, the inbound firewalls must be known. Since all of this information may not be known by a single client, no assumptions other than that the client knows of its own first outbound firewall can be made.
There are two basic types of firewalls: transport level and application level. Transport level firewalls are concerned only with host and port information. The actual application riding on the transport is irrelevant to the firewall. Since IIOP is only defined operating on TCP, these firewalls are known as TCP firewalls.
Application level firewalls are aware of the application protocol being carried on them. They use this information to determine access instead of only examining the host and port combinations.
The CORBA 3 firewall specification recognizes three firewall types: TCP firewalls, SOCKSv5 firewalls, and GIOP Proxies. The specification could be expanded to cover more in the future.
TCP Firewalls
TCP firewalls are transport level firewalls. Since they are not concerned with the application protocol being transported, no changes to IIOP are required to support TCP firewalls. The only recommendation the specification makes is to define, as most TCP/IP applications do, "well-known" ports for IIOP traffic to make an attempt to standardize the TCP ports used by IIOP traffic. Ports for both IIOP and IIOP/SSL have yet to be defined by the OMG or included in the latest CORBA 3 specification.
SOCKS proxies are application level firewalls. The client applications, in order to use a SOCKS proxy, must use a TCP/IP library that has been "SOCKSified" or made to use SOCKS proxies. As a result, no code changes to existing CORBA applications need to be made. The only change that needs to occur to transport IIOP over SOCKS proxies is for client applications to substitute a standard TCP/IP library with a SOCKS compliant library. This holds true for CORBA 3 applications as well as existing CORBA 2 implementations.
A GIOP proxy is one that intimately understands IIOP messages. Such a proxy relays messages between clients and servers and is implemented as a CORBA Object. This does not require the firewall to be a full CORBA ORB, but only for the GIOP Proxy Object to behave properly. As a result, the GIOP Proxy is a server to the client and a client to the server.
GIOP Proxies operate in two modes: normal and passthrough. In normal mode, the GIOP proxy terminates each connection, examines the data, and makes determinations on whether to allow traffic based on those examinations. If it is determined to block traffic, the proxy responds with the traditional NO_PERMISSION. As a result, the client and the server are not even aware that a proxy is involved.
Since normal modes allows the proxy to examine the data, a security risk is exposed. There may be cases where the client and/or server find this unacceptable. In those cases, passthrough mode can be requested, but not always allowed, from the proxy. If used, the proxy simple passes on the GIOP messages with no examination.
It is important to note that passthrough mode can be denied but normal mode is always available. It is also important to note that passthrough mode, while capable of being denied, must be supported by the proxy.
IIOP/SSL over firewalls seeks to allow the same level of access control for SSL communications as normal IIOP communications. This requires the proxy to be able to access the client SSL certificate along the path of the communication. This flies directly in the face of SSL and in fact is explicitly protected against to avoid "man in the middle" attacks on SSL. As such, a higher level solution is needed.
Proxies that support IIOP/SSL fall into two categories: trusted and untrusted.
Trusted proxies will have access to the IOR and certificate of the client for access control. Untrusted proxies work in passthrough mode where access control is then handled by the server.
Callbacks are important for asynchronous communications. Proxies introduce problems
with callbacks since they, by default, restrict such reverse communications from a server
to a client. Bi-directional GIOP is introduced to solve this problem by allowing servers
to reinitialize previously used client communications ports for the purpose of initiating
callbacks. Bi-directional GIOP falls short when the IOR for one client is passed between
servers. This results in the new server being unable to reinitialize the communications
channel. To solve this issue, clients may call a function on the GIOP proxy to generate an
IOR that will allow transfer between servers such that a new server can initiate a
connection to the proxy at which time the proxy will reinitialize its connection to
the client to initiate the callback.
Conclusion
Supporting firewalls in CORBA is a relatively simple matter for simple support. For firewalls to take advantage of advanced security features, the CORBA 3 specification has defined a series of objects (IORs) to achieve this. While not required for CORBA to operate over a firewall, it provides the granularity needed and desired by most security administrators regarding application level access.
The specification, while still in development, definitely needs to define a standard
port for CORBA to operate on giving a common interface for applications to
communicate. The remainder of the specification aptly describes and provides a means
for CORBA to operate effectively over a firewall. Existing implementations suffer
from nonstandard implementations of firewall support as well as a lack of granularity
needed to operate in a truly secure environment. This specification does an
effective job of solving those issues.