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.