Issues for Firewall RTF mailing list

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
Issue 2240: Issue for Firewall RTF - Chapter 5 needs clarification
Issue 2261: passthrough connection
Issue 2304: issue with TCPfirewallMechanism
Issue 2455: Issue for Firewall RTF - HTTP tunnelling.
Issue 2461: question re BiDir IIOP
Issue 2633: Bi-Directional GIOP: which connections may be used?
Issue 2634: Bi-Directional GIOP: Masquerade security issue needs to be more explicit
Issue 2638: Outgoing local port in Bi-directional IIOP
Issue 2639: Firewall POA Policy does not control access
Issue 2641: Firewall Traversal algorithm
Issue 2648: new_target
Issue 2651: new_callback
Issue 2864: How to obtain initial reference to the GIOPProxy object
Issue 2865: Proxified object references
Issue 2866: Reusing PASSTHRU
Issue 2867: Clarification is needed on the passing of credentials
Issue 2868: Problems with routing and/or traversal of firewalls.
Issue 2869: Traversal algorithm not sufficient
Issue 3363: Use of PolicyType id

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

Summary: The firewall spec defines a number of tag values from OMG managed spaces.
 The values of these tags need to be assigned.
 

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.
 

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?

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.
 

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.
 

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?
 

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.
 

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.
 

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.
 

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.
 

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.
 

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.
 

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

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.
 

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."
 

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.   
 

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.  
 

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."
 

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.
 
 
 

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.