Issues for Firewall RTF mailing list

To comment on any of these issues, send email to [email protected]. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to [email protected].

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 1996: The values of these tags need to be assigned Jira Issue CORBA26-100
Issue 2240: Issue for Firewall RTF - Chapter 5 needs clarification Jira Issue CORBA26-101
Issue 2261: passthrough connection Jira Issue CORBA26-102
Issue 2304: issue with TCPfirewallMechanism Jira Issue CORBA26-103
Issue 2455: Issue for Firewall RTF - HTTP tunnelling. Jira Issue CORBA26-104
Issue 2461: question re BiDir IIOP Jira Issue CORBA23-247
Issue 2633: Bi-Directional GIOP: which connections may be used? Jira Issue CORBA26-129
Issue 2634: Bi-Directional GIOP: Masquerade security issue needs to be more explicit Jira Issue CORBA26-130
Issue 2638: Outgoing local port in Bi-directional IIOP Jira Issue CORBA26-131
Issue 2639: Firewall POA Policy does not control access Jira Issue CORBA26-132
Issue 2641: Firewall Traversal algorithm Jira Issue CORBA26-133
Issue 2648: new_target Jira Issue CORBA26-134
Issue 2651: new_callback Jira Issue CORBA26-135
Issue 2864: How to obtain initial reference to the GIOPProxy object Jira Issue CORBA26-136
Issue 2865: Proxified object references Jira Issue CORBA26-137
Issue 2866: Reusing PASSTHRU Jira Issue CORBA26-138
Issue 2867: Clarification is needed on the passing of credentials Jira Issue CORBA26-139
Issue 2868: Problems with routing and/or traversal of firewalls. Jira Issue CORBA26-140
Issue 2869: Traversal algorithm not sufficient Jira Issue CORBA26-141
Issue 3363: Use of PolicyType id Jira Issue CORBA26-151

Issue 1996: The values of these tags need to be assigned (firewall-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The firewall spec defines a number of tag values from OMG managed spaces.   The values of these tags need to be assigned.    

Resolution:
Revised Text:
Actions taken:
September 24, 1998: received issue

Discussion:


Issue 2240: Issue for Firewall RTF - Chapter 5 needs clarification (firewall-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity:
Summary:
Summary: Chapter 5 - Bi-directional GIOP misled me in a number of points, even after   numerous readings and a discussion with an author.  I believe the chapter   contains all the pertinent information; it just has to be a bit more   carefully presented.    

Resolution:
Revised Text:
Actions taken:
December 7, 1998: received issue

Discussion:


Issue 2261: passthrough connection (firewall-rtf)

Click
here for this issue's archive.
Nature: Clarification
Severity:
Summary:
Summary:    I would like to get some clarification on the PASSTHROUGH/Untrusted Proxy   issue.      In page 4-45, the spec says "It is possible to support pass-through through   multiple proxies. For example if in the above example there was another   proxy B2 between B and C, during processing the new_target operation from A,   B can try to establish a pass-through connection to C via a call to   new_target on B2. If this fails, due to NO_PERMISSION for example, B should   fall back to try to connect through B2 using the NORMAL mode.".      If the connection (B - B2) is NORMAL, the whole connection is not a   PASSTHROUGH since the client will see the B2"s identity in the SSL session.   Should B throw back the NO_PERMISSION to the client if B get NO_PERMISSION   from B2 for PASSTHROUGH connection? If the answer is no (seems to me that is   what spec says), does this mean that it is possible that the client request   a PASSTHROUGH connection but actually get a NORMAL connection? 

Resolution:
Revised Text:
Actions taken:
December 16, 1998: received issue

Discussion:


Issue 2304: issue with TCPfirewallMechanism (firewall-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The issue comes from the following configuration:      Client - Tcp Firewall - Giop Proxy Server - Server      The server"s IOR will contains a FirewallComponent, which includes two   FirewallMechanisms - a TcpFirewallMechanism and a GIOPProxy.  The issue   comes when the GIOP Proxy has multiple profiles, which may have different   host/port, and the TcpFirewallMechanism can only have one host/port. Does   that mean for any host/port specified in one of the GIOP Proxy "s profiles,   you always to connect to the host/port specified in the   TcpFirewallMechanism? This seems unrealistic since the Tcp firewall usually   provide a one-to-one mapping.    

Resolution:
Revised Text:
Actions taken:
January 13, 1999: received issue

Discussion:


Issue 2455: Issue for Firewall RTF - HTTP tunnelling. (firewall-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The submission makes no mention of HTTP tunnelling. There are many            firewalls which filter HTTP, FTP and email related traffic. Is the            omission based on the assumption that such firewalls will comprise            a CORBA conformant GIOP proxy on a well-known IIOP port? The Bi-            directional GIOP specification suggests not (section 5-1,            paragraph 2).               Is tunnelling regarded as an implementation matter? If so there            will be important issues such as relaxing GIOP/HTTP mapping and            security which the specification should clarify.    

Resolution:
Revised Text:
Actions taken:
February 17, 1999: received issue

Discussion:


Issue 2461: question re BiDir IIOP (firewall-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: I am having difficulty understanding the intended use of   BiDirPolicy::BidirectionalPolicy. This is described (in section 15.9) as   a POA policy to be passed to create_POA. That section also says that   both client and server must have the policy with the value of BOTH for   bi-directional communication to take place.      My problem is that I don"t see how this policy applies to a particular   POA. Once bi-directional communication has been negotiated on a   connection, it applies to any request targetted at the negotiated   address(es), regardless of what POA is the recipient of the request. Nor   is it tied to the lifetime of a particular POA. And, what is supposed to   happen if one POA has the policy with value BOTH, and another POA has   the policy with value NORMAL?    

Resolution: :BidirectionalPolicy. This is described (in section 15.9) as
Revised Text:
Actions taken:
February 19, 1999: received issue
March 22, 2000: closed issue

Discussion:


Issue 2633: Bi-Directional GIOP: which connections may be used? (firewall-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: In ptc/98-10-11 15.8 from the end of the fourth paragraph "any   requests from the server on an objects exported by the client to the   server via this connection will be sent back to the client on this   same connection." to the eleventh paragraph "If the client initiates a   new connection it is not foreseen here that the server can use that   connection for requests on the object exported previously." it seems   to be implied that a reference must be passed via a connection if that   connection is to be used to invoke the referenced object with   Bi-Directional GIOP.    

Resolution:
Revised Text:
Actions taken:
May 5, 1999: received issue

Discussion:


Issue 2634: Bi-Directional GIOP: Masquerade security issue needs to be more explicit (firewall-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The remark about masquerade at the end of ptc/98-10-11 15.8 is not   explicit enough. This is an important security issue and it needs to   be made explicit that a malicious client may claim that its connection   is Bi-Directional for use with any host and port it chooses, in particular   it may specifiy the host and port of security sensitive objects.      In general, a server that has accepted an incoming connection has no   way to discover the identity or verify the integrity of the client   that initiated the connection.    

Resolution:
Revised Text:
Actions taken:
May 5, 1999: received issue

Discussion:


Issue 2638: Outgoing local port in Bi-directional IIOP (firewall-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: In ptc/98-10-11 5.8.1 it says "If a client has not set up any mechanism for   traditional-style callbacks using a listening socket, then the port entry   in its IOR must be set to the outgoing connection"s local port (as   retrieved using the getsockname() sockets API call)". At IOR creation time   there may be no connection, or there may be many, so the mandated local   port may be non-existent or ambiguous.      This topic was discussed on the firewall-rtf list during Feb-Mar 1999 but   was not raised as an issue.    

Resolution:
Revised Text:
Actions taken:
May 6, 1999: received issue

Discussion:


Issue 2639: Firewall POA Policy does not control access (firewall-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: In orbos/98-07-03 4.9 it says "However, it is desirable to provide a   portable means by which the object implementor can decide whether an   object could be accessible through a firewall. The following POA   policy is defined for this purpose:" but this policy can at most   control what components are included in references created by the   POA. Since the references do not have any mechanism to defend against   forgery, exclusion of a FirewallMechanism component does not prevent   access through a firewall. If an attacker obtains some other reference   with the FirewallMechanism component(s), it can convert a reference   created under NO_EXPORT into the reference that would have been   created under EXPORT.      The description of the policy needs to be changed to make it clear   that the policy does not imply any access control enforcement. The   ability of an attacker to forge references, either by combining parts   of other references, or otherwise, should be explicitly stated as a   security issue that must be addressed by means outside this   specification.    

Resolution:
Revised Text:
Actions taken:
May 6, 1999: received issue

Discussion:


Issue 2641: Firewall Traversal algorithm (firewall-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: The description of firewall traversal in orbos/98-07-03 4.11 has some   significant unstated assumptions, and prescribes an algorithm that has   several flaws.      In orbos/98-07-03 4.11 it says: "A client will determine if it needs   to go through a firewall to make a request on the target object. If   the client is in the same domain a direct invocation can be made. The   client can determine this be examining the host address information in   the target IOR." This assumes that the enclave structure maps to host   addresses in some way known to all clients. This needs to be made more   explicit.    

Resolution:
Revised Text:
Actions taken:
May 7, 1999: received issue

Discussion:


Issue 2648: new_target (firewall-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: Section 4.7.4 - description of new_target operation.      The first para states:      "The new_target operation informs the firewall that it should prepare itself   to    receive requests destined for the specified target. The object returned   from this    operation is the destination on the firewall to which a request on the   target should be    sent i.e. the object_key in the return object should be used in the GIOP   request header."      and the last para says:      "The object returned by the new_target operation must contain an object key   which    allows the proxy to uniquely identify the target. A client is not required   to open a new    connection to the proxy server, even when the target object(s) are located   in different    servers."      The last sentence implies that the IOR returned from the new_target has the   same host/port number as the GIOPProxy. This may not be true. For example if   a firewall is load balancing across ports and network interfaces, the   host/ports may be differnt, and in this situation a new connection is   required.    

Resolution:
Revised Text:
Actions taken:
May 10, 1999: received issue

Discussion:


Issue 2651: new_callback (firewall-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: OMG document orbos/98-07-03, section 4.7.4 under new_callback page 4-16,   the first paragraph reads      When the client side object adapter creates the object reference for the   callback object, it may invoke the    new_callback operation on the outermost inbound GIOP Proxy on the server   side and pass the callback object as the argument.      Say, there are no client-side firewalls and there is only one   server-side GIOPproxy firewall.      1. how does the object adapter or the client orb get access to the IOR   of the GIOPProxy object ???   2. how does the object adpater know that the object that is being   created/instantiated will be used as a callback   object ??      Does POA provide any m 

Resolution:
Revised Text:
Actions taken:
May 13, 1999: received issue

Discussion:


Issue 2864: How to obtain initial reference to the GIOPProxy object (firewall-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: Description:   		The specification does not outline a specific method by   which to obtain the initial reference to the GIOPProxy object.  We believe   that an interoperable solution for obtaining this initial reference is   needed in order to insure that all implementations will be able to be   correctly configured to contact all other implementations.    

Resolution:
Revised Text:
Actions taken:
August 24, 1999: received issue

Discussion:


Issue 2865: Proxified object references (firewall-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: 		Proxified object references obtained by invoking   new_target() should not be passed between ORBs.  Instead the original IOR   containing the target and firewall information should be passed.  The reason   for this is that the IOR does not contain enough information to inform the   second ORB whether or not it is a reference for a NORMAL or PASSTHRU   connection, or whether it is a proxified reference at all.  This issue is   very tightly related to issue 2, so we will describe how it fails for each   of the possible solutions to the PASSTHRU establishment problem outlined in   issue 2.     		One solution for which this is not an issue is the solution   of using a port per target.  However, this is not a viable solution because   it is restrictive and will fail under moderate load.   For solution 1 we   don"t have a problem because no object reference is returned by   set_target(), therefore it cannot be passed to other ORBs.  For solution 2   we have a problem because the second ORB won"t know whether it is supposed   to first invoke start_passthru() or simply start making requests.  Therefore   it may get a connection type that it wasn"t expecting.  For solution 3 we   have a problem because once the original connection has been made, the   reference is invalid.  This occurs because the firewall does not have   knowledge of how many clients are expected to try to connect to that target,   and it may attempt to claim that port for reuse before another client has   connected.           	Proposed Solution:   		The passing of object references obtained by invoking   new_target() should be expressly prohibited by the specification.  One   example is, "The object reference returned by new_target() may not be passed   to another client.  Instead the original reference that was passed as the   argument to new_target() must be passed to the second client, and the second   client will follow the rules of the traversal algorithm to reach the desired   target."    

Resolution:
Revised Text:
Actions taken:
August 24, 1999: received issue

Discussion:


Issue 2866: Reusing PASSTHRU (firewall-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: 	Description:   		Reusing PASSTHRU connections by the firewall should be   expressly disallowed by the specification.  With the current wording of the   specification, a vendor may attempt to reuse PASSTHRU connections.  While   this will work in some cases, it is not interoperable because there are   cases  when reusing PASSTHRU connections will not work.  For example,   connection reuse when SSL is in use will not work because all of the   information that distinguishes data streams is contained within the   encrypted portion of SSL packets.  If two SSL connections try to share a   single connection, there will be an SSL protocol failure because the server   will not be able to separate the data streams before it processes the SSL   packet.       

Resolution:
Revised Text:
Actions taken:
August 24, 1999: received issue

Discussion:


Issue 2867: Clarification is needed on the passing of credentials (firewall-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: 	Description:   		Clarification is needed on the passing of credentials.   Section 4.7.3 states that "Since all proxies will have access to the IOR of   the target object, and the certificate of the client, they can judge whether   this client may use a pass-through connection or not."  Section 4.12 states   that "When a client establishes a normal connection to a target via a   trusted proxy and uses a secure transport (e.g. IIOP/SSL), in order to   achieve end-to-end authentication, the proxy will have to forward the   client"s certificate/identity to the server."  Section 4.12 implies that the   ForwardedIdentity service context will only be used when using a secure   transport, but section 4.7.3 implies that the client certificate will always   be available.  In fact, the ForwardedIdentity service context should only be   used in the case of a NORMAL connection using a secure transport because   those are the only conditions under which there is a notion of trust between   a requestor and the recipient of that request.  This means that the only   mechanism upon which to base a decision of whether or not to allow a   PASSTHRU connection is the source host address/port.      

Resolution:
Revised Text:
Actions taken:
August 24, 1999: received issue

Discussion:


Issue 2868: Problems with routing and/or traversal of firewalls. (firewall-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: Issues 7-9 refer to problems with routing and/or traversal of firewalls.   These problems arise due to a lack of required information about firewall   topology in the IOR.  Most of these problems could be eliminated if it were   required that the servers place the entire chain of server-side firewalls   that must be traversed into the IOR.  Specifically, the first paragraph in   section 4.8 should be modified so that the entire chain of firewalls is   always required, or those situations in which it should be required should   be stated.  Some of those situations are outlined in the following issues.   Specifically, it is incorrect to state that "strictly it is only necessary   to convey information on the outermost inbound firewall."    

Resolution:
Revised Text:
Actions taken:
August 24, 1999: received issue

Discussion:


Issue 2869: Traversal algorithm not sufficient (firewall-rtf)

Click
here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:
Summary: 	Description:   		There may be some network topologies where the traversal   algorithm is not sufficient for a firewall to find a server.  This is due to   an unstated assumption that all addresses within the outermost inbound   firewall are addressable from the outermost inbound firewall.  Consider for   example the following topology:                                                                  |-----*Firewall   B*-----Network B           Internet  ------*Firewall A*----------  |                                                   |-----*Firewall   C*-----Network C                                                   |                                            Service Network (DMZ)      		Assume that the addresses on the service network are   globally routable addresses, Network B uses RFC 1597 addresses and Network C   uses RFC 1597 addresses.  This topology could be possible, say for a   government agency that has sub-agencies that share some resources (service   network) but maintain separately administrated networks.  In this case the   outermost inbound firewall for a server on Network B or C is Firewall A.   However, when new target is invoked on Firewall A, it won"t know from the   host address whether to open a connection to Firewall B or Firewall C.        	Proposed Solution:   		There are several possible solutions to this problem:   		1)	Explicitly state the assumption described in the   description section   		2)	Mandate that implementations allow for the   configuration of the next inbound firewalls    		3)	Mandate that servers on Network B or C in such   configurations use Firewall B or C as the outermost inbound firewall.      		There may be other solutions to this problem.  These were   the ones that immediately presented themselves.          

Resolution:
Revised Text:
Actions taken:
August 24, 1999: received issue

Discussion:


Issue 3363: Use of PolicyType id (firewall-rtf)

Click
here for this issue's archive.
Source: Micro Focus (Dr. Jishnu Mukerji, jishnu(at)microfocus.com)
Nature: Uncategorized Issue
Severity:
Summary:
While editing the changes from the Firewall RTF into Core Chapter 15 I noticed a  curious thing in the Firewall RTF report. It seems that the RTF chose to re-use  a PolicyType id for a new and different policy while obsoleting a published one.  The PolicyType Id in question is 37, which used to be BIDIRECTIONAL_POLICY_TYPE  associated with the structure BiDirPolicy::BidirectionalPolicy    and is now proposed to be BIDIRECTIONAL_INVOKE_POLICY associated with structure  BiDirPolicy::InvokeMode.    This appears to me to be a dangerous practice, since the fact that the published  standard may have been implemented by someone using the obsolete definition.    I would like to suggest that the recommendation of the Firewall RTF be modified  leaving the published policy type and policy as is with a note stating that it  is obsolete, and a new policy type id be allocated for  BIDIRECTIONAL_INVOKE_POLICY.

Resolution:
Revised Text:
Actions taken:
February 25, 2000: received issue
March 22, 2000: closed issue; Closed; No Change