Issue 2633: Bi-Directional GIOP: which connections may be used? (firewall-rtf) Source: (, ) 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: End of Annotations:===== Date: Wed, 05 May 1999 17:57:36 +0100 From: Owen Rees To: OMG Issues cc: OMG Firewall RTF Subject: Bi-Directional GIOP: which connections may be used? Originator-Info: login-id=ore; server=ews.hpl.hp.com Content-Disposition: inline Is the means by which the server received a reference significant when deciding whether or not to use Bi-Directional GIOP, and on which connection? 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. This appears to be contradicted in 15.8.1 "the server may re-use any of the connections that were initiated by the client on which the listen point data was received." and "Typically, when the same client has multiple connections to the same server, the listen_points will be identical. However, if they differ they supplement each other i.e. any of the listen points received on any of the connections may be used." which suggests that the invocation may be made using Bi-Directional GIOP on a connection on which neither the reference, nor a matching ListenPoint was received. Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 Date: Wed, 05 May 1999 11:40:54 -0700 From: Sastry Malladi Organization: Oracle To: Owen Rees CC: OMG Issues , OMG Firewall RTF Subject: Re: Bi-Directional GIOP: which connections may be used? References: <2509087766.925927056@ews-proj-2.hpl.hp.com> I'm not sure about the wording, but my understanding is that, the client passes a context in which it indicates for what listening points, this connection may be used by the server when invoking client objects. The bidirecionness of the connection is not tied to just the objects that are passed on this connection. Anytime when the server tries to access a callback client object, it can check its connections list to see if any of the existing connections to the client allow using that connection as a bidirectional connection for the port contained in this callback object reference. I don't think it's mandatory for the server to do that, it's optional. There is no security breach either because, the server may or may not choose to use the bidirectional connection for the callback objects based on some policies. However, in the case of secure/SSL connections using bidirectional connection is a bit tricky, because there is no second authentication/handshake going on. The servers/clients may not use bidirectional connections in that case. This is my recollection. Martin will may have a better idea. Sastry Owen Rees wrote: > > Is the means by which the server received a reference significant > when > deciding whether or not to use Bi-Directional GIOP, and on which > connection? > > 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. > > This appears to be contradicted in 15.8.1 "the server may re-use any > of the connections that were initiated by the client on which the > listen point data was received." and "Typically, when the same > client > has multiple connections to the same server, the listen_points will > be > identical. However, if they differ they supplement each other > i.e. any > of the listen points received on any of the connections may be > used." > which suggests that the invocation may be made using Bi-Directional > GIOP on a connection on which neither the reference, nor a matching > ListenPoint was received. > > Regards, > Owen Rees > Hewlett Packard Laboratories, Bristol, UK > tel: +44 117 312 9439 fax: +44 117 312 9285 Sender: jon@floorboard.com Date: Wed, 05 May 1999 13:16:42 -0700 From: Jonathan Biggar X-Accept-Language: en To: Sastry Malladi CC: Owen Rees , OMG Firewall RTF , interop@omg.org, secsig@omg.org Subject: Re: Bi-Directional GIOP: which connections may be used? References: <2509087766.925927056@ews-proj-2.hpl.hp.com> <373090B6.52A78465@us.oracle.com> Sastry Malladi wrote: > > I'm not sure about the wording, but my understanding is that, the > client > passes a context in which it indicates for what listening points, > this > connection may be used by the server when invoking client > objects. The > bidirecionness of the connection is not tied to just the objects > that > are passed on this connection. Anytime when the server tries to > access a > callback client object, it can check its connections list to see if > any > of the existing connections to the client allow using that > connection as > a bidirectional connection for the port contained in this callback > object reference. I don't think it's mandatory for the server to do > that, it's optional. I agree that text in the bidirectional GIOP spec should be dropped that suggests that only the connection that the object reference was received on can be used for server to client invocations. Requiring this would be costly to ORB implementations that would have to track what connection a reference came in on, and cause interoperability problems, since the client could send the reference and then drop the connection, reestablish a new one, leaving the server with no current connection to use. Given that the intent of bidirectional GIOP is to allow controlled penetration of firewalls, this could result plenty of cases where the server can't reestablish contact with the client. > There is no security breach either because, the server may or may not > choose to use the bidirectional connection for the callback objects > based on some policies. However, in the case of secure/SSL connections > using bidirectional connection is a bit tricky, because there is no > second authentication/handshake going on. The servers/clients may not > use bidirectional connections in that case. As for the problem of rogue clients sending malicious listen point information, I think that there is still a problem here for some scenarios. 1. For SECIOP, there is a potential problem with interposing a rogue client inbetween the server and the real client. Even though the server must establish a new security context to send the invocation to the client, the rogue process could just forward the SECIOP messages through to the real client. The possible security breach here is minor, since all the rogue process could do is read traffic that is only integrity protected, which anyone with a tap on a LAN could do anyway. 2. For SSL, I believe the same problem applies. 3. The real problem is with plain old IIOP. At minimum, a rogue client could cause some significant denial-of-service attacks, by sucking up at least some of the invocations that should have gone to legitimate clients. At worst there is an additional risk of exposing sensitive information above and beyond the already inherent risk of a non-secure protocol. Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 5 May 1999 13:27:29 PDT Sender: Bill Janssen From: Bill Janssen To: Sastry Malladi , Jonathan Biggar Subject: Re: Bi-Directional GIOP: which connections may be used? CC: Owen Rees , OMG Firewall RTF , interop@omg.org, secsig@omg.org References: <2509087766.925927056@ews-proj-2.hpl.hp.com> <373090B6.52A78465@us.oracle.com> <3730A72A.74AACD14@floorboard.com> Excerpts from local.omg: 5-May-99 Re: Bi-Directional GIOP: wh.. Jonathan Biggar@floorboa (2912*) > At minimum, a rogue client > could cause some significant denial-of-service attacks, by sucking > up at > least some of the invocations that should have gone to legitimate > clients. At worst there is an additional risk of exposing sensitive > information above and beyond the already inherent risk of a > non-secure > protocol. Of course, servers worried about this could choose not to use the incoming connection as their path back to the client, and open a new connection. But yes, this is still worrisome. Bill Sender: jon@floorboard.com Date: Wed, 05 May 1999 13:34:33 -0700 From: Jonathan Biggar X-Accept-Language: en To: Bill Janssen CC: Sastry Malladi , Owen Rees , OMG Firewall RTF , interop@omg.org, secsig@omg.org Subject: Re: Bi-Directional GIOP: which connections may be used? References: <2509087766.925927056@ews-proj-2.hpl.hp.com> <373090B6.52A78465@us.oracle.com> <3730A72A.74AACD14@floorboard.com> Bill Janssen wrote: > > Excerpts from local.omg: 5-May-99 Re: Bi-Directional GIOP: > wh.. Jonathan > Biggar@floorboa (2912*) > > > At minimum, a rogue client > > could cause some significant denial-of-service attacks, by sucking > up at > > least some of the invocations that should have gone to legitimate > > clients. At worst there is an additional risk of exposing > sensitive > > information above and beyond the already inherent risk of a > non-secure > > protocol. > > Of course, servers worried about this could choose not to use the > incoming connection as their path back to the client, and open a new > connection. But yes, this is still worrisome. I understand that, but it doesn't work with the main intent of bidrectional GIOP, which is to allow controlled penetration of the firewall. If the server won't use bidirectional GIOP due to security concerns, what good is it? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 5 May 1999 14:13:01 PDT Sender: Bill Janssen From: Bill Janssen To: Sastry Malladi , Jonathan Biggar Subject: Re: Bi-Directional GIOP: which connections may be used? CC: Owen Rees , OMG Firewall RTF , interop@omg.org, secsig@omg.org References: <2509087766.925927056@ews-proj-2.hpl.hp.com> <373090B6.52A78465@us.oracle.com> <3730A72A.74AACD14@floorboard.com> I'm not sure it's helpful, but the ILU security architecture (ftp://ftp.parc.xerox.com/pub/ilu/2.0a14/manual-html/manual_14.html) seems to avoid this problem. In ILU, the security context is formed between the GIOP layer and the TCP layer. Thus, the client and server are each authenticated to each other before any GIOP traffic is allowed. This seems to avoid the problem. Bill Date: Wed, 5 May 1999 14:17:57 PDT Sender: Bill Janssen From: Bill Janssen To: Jonathan Biggar , Polar Humenn Subject: Re: Bi-Directional GIOP: which connections may be used? CC: Sastry Malladi , Owen Rees , OMG Firewall RTF , interop@omg.org, secsig@omg.org References: Excerpts from local.omg: 5-May-99 Re: Bi-Directional GIOP: wh.. Polar Humenn@adiron.com (5251*) > The server uses the BiDirectional GIOP and it > starts down loading data from my quicken program, or other things > off of > your machine, quite silently, and you have no idea. Only if your browser app cooperates in the theft. In the ILU implementation of HTTP-NG, we thought about this (the HTTP-NG transport `webmux' provides bi-directional connection (up to 126 in either direction over a single TCP connection)). We decided that bi-directionality on the client side should only be allowed if the client explicitly requests it by placing a particular credential in the credential pouch used when it opens a connection to a server. Bill X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 5 May 1999 17:04:31 -0400 (EDT) From: Polar Humenn To: Jonathan Biggar cc: Sastry Malladi , Owen Rees , OMG Firewall RTF , interop@omg.org, secsig@omg.org Subject: Re: Bi-Directional GIOP: which connections may be used? On Wed, 5 May 1999, Jonathan Biggar wrote: > Sastry Malladi wrote: > > > > I'm not sure about the wording, but my understanding is that, the > client > > passes a context in which it indicates for what listening points, > this > > connection may be used by the server when invoking client > objects. The > > bidirecionness of the connection is not tied to just the objects > that > > are passed on this connection. Anytime when the server tries to > access a > > callback client object, it can check its connections list to see > if any > > of the existing connections to the client allow using that > connection as > > a bidirectional connection for the port contained in this callback > > object reference. I don't think it's mandatory for the server to > do > > that, it's optional. I would say that server functionality can only be *optional*, because it cannot be enforced by the Client. Forcing an implementation detail like that on the server about what it sends back down the Bidirectional GIOP connection is immaterial. The problem is the Client protecting itself from rogue servers. > I agree that text in the bidirectional GIOP spec should be dropped that > suggests that only the connection that the object reference was received > on can be used for server to client invocations. Again, this is a Client enforcement point. A server would have to comply, if all Clients enforced this point. Agreeing with Jothathan (I think), this should be policy based on the client side. Sending some information to the server to help the server figure out what is acceptable behavior is probably the right thing to do. > Requiring this would > be costly to ORB implementations that would have to track what > connection a reference came in on, and cause interoperability > problems, > since the client could send the reference and then drop the > connection, > reestablish a new one, leaving the server with no current connection > to > use. It will be costly on the Client side anyway, if you needed to have access enforcement. > Given that the intent of bidirectional GIOP is to allow controlled > penetration of firewalls, this could result plenty of cases where > the > server can't reestablish contact with the client. > > There is no security breach either because, the server may or may > not > > choose to use the bidirectional connection for the callback > objects > > based on some policies. However, in the case of secure/SSL > connections > > using bidirectional connection is a bit tricky, because there is > no > > second authentication/handshake going on. The servers/clients may > not > > use bidirectional connections in that case. > > As for the problem of rogue clients sending malicious listen point > information, I think that there is still a problem here for some > scenarios. > > 1. For SECIOP, there is a potential problem with interposing a > rogue > client inbetween the server and the real client. Even though the > server > must establish a new security context to send the invocation to the > client, the rogue process could just forward the SECIOP messages > through > to the real client. The possible security breach here is minor, > since > all the rogue process could do is read traffic that is only > integrity > protected, which anyone with a tap on a LAN could do anyway. Sorry, Jonathan, I don't see why this is really a problem. A security association must be established. This should protect to the level it is needed. That all depends on the security mechanism used. > 2. For SSL, I believe the same problem applies. > 3. The real problem is with plain old IIOP. At minimum, a rogue > client > could cause some significant denial-of-service attacks, by sucking > up at > least some of the invocations that should have gone to legitimate > clients. At worst there is an additional risk of exposing sensitive > information above and beyond the already inherent risk of a > non-secure > protocol. Well that depends on your trust model. Having plain old IIOP just opens security breaches all over the place, because, behold, there is no real security. onal GIOP you had some smidgen of security just by the Client/Server orientation of the connection. Now, IIOP has become even more so insecure! Take a scenario that some well known persistent objects can be readily addressible, by well known object keys, whatever, on your Microsoft box. Although maybe it is not the case today, but it is a fairly easily thing to realize. Case in point, take the hypothetical CORBA object representing my Quicken program. As a casual web surfer I click on a button on a to get a picture of Bugs Bunny. The server uses the BiDirectional GIOP and it starts down loading data from my quicken program, or other things off of your machine, quite silently, and you have no idea. (I think a well known company was already accused of something along these lines with their web browser :) Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC President 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Wed, 05 May 1999 13:56:36 -0700 From: Sastry Malladi Organization: Oracle To: Bill Janssen CC: Sastry Malladi , Jonathan Biggar , Owen Rees , OMG Firewall RTF , interop@omg.org, secsig@omg.org Subject: Re: Bi-Directional GIOP: which connections may be used? References: <2509087766.925927056@ews-proj-2.hpl.hp.com> <373090B6.52A78465@us.oracle.com> <3730A72A.74AACD14@floorboard.com> This is what happens in IIOP/SSL connection anyways. Sastry Bill Janssen wrote: > > I'm not sure it's helpful, but the ILU security architecture > (ftp://ftp.parc.xerox.com/pub/ilu/2.0a14/manual-html/manual_14.html) > seems to avoid this problem. In ILU, the security context is formed > between the GIOP layer and the TCP layer. Thus, the client and > server > are each authenticated to each other before any GIOP traffic is > allowed. > This seems to avoid the problem. > > Bill Date: Wed, 05 May 1999 13:53:15 -0700 From: Sastry Malladi Organization: Oracle To: Jonathan Biggar CC: Sastry Malladi , Owen Rees , OMG Firewall RTF , interop@omg.org, secsig@omg.org Subject: Re: Bi-Directional GIOP: which connections may be used? References: <2509087766.925927056@ews-proj-2.hpl.hp.com> <373090B6.52A78465@us.oracle.com> <3730A72A.74AACD14@floorboard.com> Jonathan Biggar wrote: > > Sastry Malladi wrote: > > > > I'm not sure about the wording, but my understanding is that, the > client > > passes a context in which it indicates for what listening points, > this > > connection may be used by the server when invoking client > objects. The > > bidirecionness of the connection is not tied to just the objects > that > > are passed on this connection. Anytime when the server tries to > access a > > callback client object, it can check its connections list to see > if any > > of the existing connections to the client allow using that > connection as > > a bidirectional connection for the port contained in this callback > > object reference. I don't think it's mandatory for the server to > do > > that, it's optional. > > I agree that text in the bidirectional GIOP spec should be dropped > that > suggests that only the connection that the object reference was > received > on can be used for server to client invocations. Requiring this > would > be costly to ORB implementations that would have to track what > connection a reference came in on, and cause interoperability > problems, > since the client could send the reference and then drop the > connection, > reestablish a new one, leaving the server with no current connection > to > use. Given that the intent of bidirectional GIOP is to allow > controlled > penetration of firewalls, this could result plenty of cases where > the > server can't reestablish contact with the client. > > > There is no security breach either because, the server may or may > not > > choose to use the bidirectional connection for the callback > objects > > based on some policies. However, in the case of secure/SSL > connections > > using bidirectional connection is a bit tricky, because there is > no > > second authentication/handshake going on. The servers/clients may > not > > use bidirectional connections in that case. > > As for the problem of rogue clients sending malicious listen point > information, I think that there is still a problem here for some > scenarios. > > 1. For SECIOP, there is a potential problem with interposing a > rogue > client inbetween the server and the real client. Even though the > server > must establish a new security context to send the invocation to the > client, the rogue process could just forward the SECIOP messages > through > to the real client. The possible security breach here is minor, > since > all the rogue process could do is read traffic that is only > integrity > protected, which anyone with a tap on a LAN could do anyway. > > 2. For SSL, I believe the same problem applies. In case of either IIOP/SSL or SECIIOP, any clients/servers in the path leading from the original client to the end server should authenticate itself to the next one in line and so the chance of a malicious client getting in between is not a concern. However, for non secure connections someone could always tap the data on he wire. > > 3. The real problem is with plain old IIOP. At minimum, a rogue > client > could cause some significant denial-of-service attacks, by sucking > up at > least some of the invocations that should have gone to legitimate > clients. At worst there is an additional risk of exposing sensitive > information above and beyond the already inherent risk of a > non-secure > protocol. > > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org Sender: jon@floorboard.com Date: Wed, 05 May 1999 15:26:16 -0700 From: Jonathan Biggar X-Accept-Language: en To: Bill Janssen CC: Sastry Malladi , Owen Rees , OMG Firewall RTF , interop@omg.org, secsig@omg.org Subject: Re: Bi-Directional GIOP: which connections may be used? References: <2509087766.925927056@ews-proj-2.hpl.hp.com> <373090B6.52A78465@us.oracle.com> <3730A72A.74AACD14@floorboard.com> Bill Janssen wrote: > > I'm not sure it's helpful, but the ILU security architecture > (ftp://ftp.parc.xerox.com/pub/ilu/2.0a14/manual-html/manual_14.html) > seems to avoid this problem. In ILU, the security context is formed > between the GIOP layer and the TCP layer. Thus, the client and > server > are each authenticated to each other before any GIOP traffic is > allowed. > This seems to avoid the problem. How does this prevent a transport-level spoofer from interposing between the client & server? Even if it can't modify the messages, it can still read them and selectively deny service. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jon@floorboard.com Date: Wed, 05 May 1999 15:25:12 -0700 From: Jonathan Biggar X-Accept-Language: en To: Bill Janssen CC: Polar Humenn , Sastry Malladi , Owen Rees , OMG Firewall RTF , interop@omg.org, secsig@omg.org Subject: Re: Bi-Directional GIOP: which connections may be used? References: Bill Janssen wrote: > > Excerpts from local.omg: 5-May-99 Re: Bi-Directional GIOP: > wh.. Polar > Humenn@adiron.com (5251*) > > > The server uses the BiDirectional GIOP and it > > starts down loading data from my quicken program, or other things > off of > > your machine, quite silently, and you have no idea. > > Only if your browser app cooperates in the theft. > > In the ILU implementation of HTTP-NG, we thought about this (the > HTTP-NG > transport `webmux' provides bi-directional connection (up to 126 in > either direction over a single TCP connection)). We decided that > bi-directionality on the client side should only be allowed if the > client explicitly requests it by placing a particular credential in > the > credential pouch used when it opens a connection to a server. BiDir GIOP also does this, since the client must explicitly transmit the "listening point" service context to the server before BiDir GIOP can be activated. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jon@floorboard.com Date: Wed, 05 May 1999 15:23:43 -0700 From: Jonathan Biggar X-Accept-Language: en To: Polar Humenn CC: Sastry Malladi , Owen Rees , OMG Firewall RTF , interop@omg.org, secsig@omg.org Subject: Re: Bi-Directional GIOP: which connections may be used? References: Polar Humenn wrote: > > As for the problem of rogue clients sending malicious listen point > > information, I think that there is still a problem here for some > > scenarios. > > > > 1. For SECIOP, there is a potential problem with interposing a > rogue > > client inbetween the server and the real client. Even though the > server > > must establish a new security context to send the invocation to > the > > client, the rogue process could just forward the SECIOP messages > through > > to the real client. The possible security breach here is minor, > since > > all the rogue process could do is read traffic that is only > integrity > > protected, which anyone with a tap on a LAN could do anyway. > > Sorry, Jonathan, I don't see why this is really a problem. A > security > association must be established. This should protect to the level it > is > needed. That all depends on the security mechanism used. The problem exists, since SECIOP doesn't use transport level addresses as part of its authentication process. Thus, a rogue process can just forward the messages it receives at the transport layer between the real client and server and no one will be the wiser. Again, this is an additional risk, since it potentially allows anyone who can successfully connect to the server and provide listening point information to interpose between the server and a legitimate client. This allows anyone to potentially tap into any client-server conversation. > > 2. For SSL, I believe the same problem applies. > > 3. The real problem is with plain old IIOP. At minimum, a rogue > client > > could cause some significant denial-of-service attacks, by sucking > up at > > least some of the invocations that should have gone to legitimate > > clients. At worst there is an additional risk of exposing > sensitive > > information above and beyond the already inherent risk of a > non-secure > > protocol. > > Well that depends on your trust model. Having plain old IIOP just > opens > security breaches all over the place, because, behold, there is no > real > security. > > onal GIOP you had some smidgen of security > just by the Client/Server orientation of the connection. Now, IIOP > has > become even more so insecure! Right. What little level of protection that you could rely on before due to the connection-orientedness of the protocol is now broken! -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 5 May 1999 15:46:51 PDT Sender: Bill Janssen From: Bill Janssen To: Bill Janssen , Jonathan Biggar Subject: Re: Bi-Directional GIOP: which connections may be used? CC: Polar Humenn , Sastry Malladi , Owen Rees , OMG Firewall RTF , interop@omg.org, secsig@omg.org References: <3730C548.F39E1594@floorboard.com> Excerpts from direct: 5-May-99 Re: Bi-Directional GIOP: wh.. Jonathan Biggar@floorboa (1016*) > BiDir GIOP also does this, since the client must explicitly transmit the > "listening point" service context to the server before BiDir GIOP can be > activated. How does the application control this send? Bill Date: Wed, 5 May 1999 15:49:54 PDT Sender: Bill Janssen From: Bill Janssen To: Bill Janssen , Jonathan Biggar Subject: Re: Bi-Directional GIOP: which connections may be used? CC: Sastry Malladi , Owen Rees , OMG Firewall RTF , interop@omg.org, secsig@omg.org References: <2509087766.925927056@ews-proj-2.hpl.hp.com> <373090B6.52A78465@us.oracle.com> <3730A72A.74AACD14@floorboard.com> <3730C588.8EAF1602@floorboard.com> Whether it can `read' the messages depends on the security context selected, of course. Given a dual public-key system, it can only read the data if it has the private keys of both client and server. However, it can still disrupt communications by TCP-level spoofing, of course. Secure TCP is the answer to that one. Bill X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 5 May 1999 18:54:09 -0400 (EDT) From: Polar Humenn To: Jonathan Biggar cc: Sastry Malladi , Owen Rees , OMG Firewall RTF , interop@omg.org, secsig@omg.org Subject: Re: Bi-Directional GIOP: which connections may be used? On Wed, 5 May 1999, Jonathan Biggar wrote: > The problem exists, since SECIOP doesn't use transport level addresses > as part of its authentication process. I'll beg to differ. This depends on the security mechanism you are using and if it pays attention to GSS channel bindings. -Polar Sender: jon@floorboard.com Date: Wed, 05 May 1999 16:01:33 -0700 From: Jonathan Biggar X-Accept-Language: en To: Bill Janssen CC: Sastry Malladi , Owen Rees , OMG Firewall RTF , interop@omg.org, secsig@omg.org Subject: Re: Bi-Directional GIOP: which connections may be used? References: <2509087766.925927056@ews-proj-2.hpl.hp.com> <373090B6.52A78465@us.oracle.com> <3730A72A.74AACD14@floorboard.com> <3730C588.8EAF1602@floorboard.com> Bill Janssen wrote: > > Whether it can `read' the messages depends on the security context > selected, of course. Given a dual public-key system, it can only > read > the data if it has the private keys of both client and server. > However, > it can still disrupt communications by TCP-level spoofing, of > course. > Secure TCP is the answer to that one. My initial email stated that this problem was only an issue if the security context was not using confidentiality protection. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jon@floorboard.com Date: Wed, 05 May 1999 16:00:33 -0700 From: Jonathan Biggar X-Accept-Language: en To: Bill Janssen CC: Polar Humenn , Sastry Malladi , Owen Rees , OMG Firewall RTF , interop@omg.org, secsig@omg.org Subject: Re: Bi-Directional GIOP: which connections may be used? References: <3730C548.F39E1594@floorboard.com> Bill Janssen wrote: > > Excerpts from direct: 5-May-99 Re: Bi-Directional GIOP: > wh.. Jonathan > Biggar@floorboa (1016*) > > > BiDir GIOP also does this, since the client must explicitly > transmit the > > "listening point" service context to the server before BiDir GIOP > can be > > activated. > > How does the application control this send? The client is supposed to set it with a Policy object, but the spec doesn't exactly say where... I guess it's time to send another issue. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jon@floorboard.com Date: Wed, 05 May 1999 16:03:09 -0700 From: Jonathan Biggar X-Accept-Language: en To: Polar Humenn CC: Sastry Malladi , Owen Rees , OMG Firewall RTF , interop@omg.org, secsig@omg.org Subject: Re: Bi-Directional GIOP: which connections may be used? References: Polar Humenn wrote: > > On Wed, 5 May 1999, Jonathan Biggar wrote: > > > The problem exists, since SECIOP doesn't use transport level > addresses > > as part of its authentication process. > > I'll beg to differ. This depends on the security mechanism you are > using > and if it pays attention to GSS channel bindings. Ok, you got me. I'm not bit-by-bit familiar with the low level security protocols. Does this mean that some of the standard security mechanisms do have this hole? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jon@floorboard.com Date: Wed, 05 May 1999 23:36:41 -0700 From: Jonathan Biggar X-Accept-Language: en To: issues@omg.org, interop@omg.org Subject: Bidirectional GIOP issues for the Interop RTF 1. The spec describes the BidirectionalPolicy object, but is unclear exactly where and how the policy object is used. It mentions create_POA(). Is this the only place the policy object is used? I assume so. 2. If the BidirectionalPolicy is only used on create_POA(), this causes a problem for clients that want to implement callback objects the most natural way, using the root POA. Instead, they must explicitly create a child POA with the BidirectionalPolicy. 3. Associating this policy with the POA is wrong, since it inappropriately ties the POA concept to protocol listening points, which otherwise have no direct relationship in the ORB architecture. For clients and servers that mix POAs with this policy and without it, it is problematic to determine how and when to actually use bidirectional connections. I believe this policy should be applied to the ORB's global PolicyManager object using set_policy_overrides() instead. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org From: "Martin Chapman" To: , "Bill Janssen" Cc: "Polar Humenn" , "Sastry Malladi" , "Owen Rees" , "OMG Firewall RTF" , , Subject: RE: Bi-Directional GIOP: which connections may be used? Date: Thu, 6 May 1999 10:12:37 +0100 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal My you lot have been busy overnight! I'll reply to Owen's original mail next, but this was (i think ) an easy one to answer > -----Original Message----- > From: jon@floorboard.com [mailto:jon@floorboard.com] > Sent: 06 May 1999 00:01 > To: Bill Janssen > Cc: Polar Humenn; Sastry Malladi; Owen Rees; OMG Firewall RTF; > interop@omg.org; secsig@omg.org > Subject: Re: Bi-Directional GIOP: which connections may be used? > > > Bill Janssen wrote: > > > > Excerpts from direct: 5-May-99 Re: Bi-Directional GIOP: > wh.. Jonathan > > Biggar@floorboa (1016*) > > > > > BiDir GIOP also does this, since the client must explicitly > transmit the > > > "listening point" service context to the server before BiDir > GIOP can be > > > activated. > > > > How does the application control this send? > > The client is supposed to set it with a Policy object, but the spec > doesn't exactly say where... I guess it's time to send another > issue. The Policy is set on the callback object's POA, from Section 5.2: In the absence of a BidirectionalPolicy being passed in the PortableServer::POA::create_POA operation, a POA will assume a policy value of NORMAL. A client and a server ORB must each have a BidirectionalPolicy with a value of BOTH for bi-directional communication to take place. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org > Date: Thu, 06 May 1999 08:08:10 -0400 From: Paul H Kyzivat Organization: NobleNet To: Martin Chapman CC: jon@floorboard.com, Bill Janssen , Polar Humenn , Sastry Malladi , Owen Rees , OMG Firewall RTF , interop@omg.org, secsig@omg.org Subject: Re: Bi-Directional GIOP: which connections may be used? References: <000601be97a0$959230a0$0f01020a@dublin.iona.ie> I posted another issue on more or less the same point several months ago, but have yet to get a response to it. That issue explains problems with associating this mechanism with a POA, along similar lines to what Jonathan has posted. Paul Martin Chapman wrote: > > My you lot have been busy overnight! > I'll reply to Owen's original mail next, but this was (i think ) an > easy one > to answer > > > -----Original Message----- > > From: jon@floorboard.com [mailto:jon@floorboard.com] > > Sent: 06 May 1999 00:01 > > To: Bill Janssen > > Cc: Polar Humenn; Sastry Malladi; Owen Rees; OMG Firewall RTF; > > interop@omg.org; secsig@omg.org > > Subject: Re: Bi-Directional GIOP: which connections may be used? > > > > > > Bill Janssen wrote: > > > > > > Excerpts from direct: 5-May-99 Re: Bi-Directional GIOP: wh.. > Jonathan > > > Biggar@floorboa (1016*) > > > > > > > BiDir GIOP also does this, since the client must explicitly > > transmit the > > > > "listening point" service context to the server before BiDir > > GIOP can be > > > > activated. > > > > > > How does the application control this send? > > > > The client is supposed to set it with a Policy object, but the > spec > > doesn't exactly say where... I guess it's time to send another > issue. > > The Policy is set on the callback object's POA, from Section 5.2: > > In the absence of a BidirectionalPolicy being passed in the > PortableServer::POA::create_POA operation, a POA will assume > a > policy > value of NORMAL. > > A client and a server ORB must each have a > BidirectionalPolicy > with a value > of BOTH for bi-directional communication to take place. > > > > > -- > > Jon Biggar > > Floorboard Software > > jon@floorboard.com > > jon@biggar.org > > Cc: Martin Chapman , Juergen Boldt , firewall-rtf@emerald.omg.org, interop@omg.org Date: Sat, 08 May 1999 21:29:51 -0400 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies To: Jishnu Mukerji Original-CC: Martin Chapman , Juergen Boldt , firewall-rtf@emerald.omg.org, interop@omg.org Subject: Re: issue 2633 -- Firewall RTF Issue References: <000701be97a1$90694720$0f01020a@dublin.iona.ie> <37319C6B.7179F866@fpk.hp.com> I agree. Let the firewall folk work on the issues first (don't mess with supercillious protocol changes to destabilize the "frozen ogre" GIOP, the protocol everyone loves to hate :) ) with any chap 15 changes to be coordinated with the interop RTF. Jishnu Mukerji wrote: > > Martin Chapman wrote: > > > > Jishnu, > > We agreed with the interop RTF that until the firewall RTF > completes it's > > first round Bi-Dir GIOP remains under the firewall rtf. Clearly it > has to be > > done with coordination with interop but there are different > memberships that > > need to be respected (i.e. some of the firewall submitters are not > on the > > interop rtf and they still have veto powers.) > > Martin, > > As long as Firewall RTF does not try to shoehorn things into GIOP > put of > phase with the GIOP version cycle, it is OK. Also, the text that is > incorporated into Chapter 15 should be vetted through the interop > RTF. > Since it seems like I get to do the final editing, at the end of the > day > I don't want to have to play ping-pong between you and Tom to figure > out > what exact text goes into the spec. > > Now, given that the two RTFs involved are co-terminus in Jan 2000, > and > given that you and Tom are likely to continue to talk to each other > between now and then, I think it is OK to do it the way you suggest, > and > actually I seem to recall having agreed to that in the hazy past at > some > point.:-) > > So Juergen, toss those issue that you parked in a siding back into > the > Firewall track please. > > Cheers, > > Jishnu. > -- > Jishnu Mukerji > Systems Architect > > Email: jis@fpk.hp.com Hewlett-Packard EIAL, > Tel: +1 973 443 7528 300 Campus Drive, 2E-62, > Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. -- ---------------------------------------------------------------- Tom Rutt Tel: +1 732 949 7862 Lucent Technologies - Bell Laboratories Fax: +1 732 949 1196 Rm 4L-336, 101 Crawford Corner Rd eail: terutt@lucent.com Holmdel NJ, 07733 ---------------------------------------------- From: "Martin Chapman" To: , "Sastry Malladi" Cc: "Owen Rees" , "OMG Firewall RTF" , , Subject: RE: Bi-Directional GIOP: which connections may be used? Date: Mon, 10 May 1999 17:17:47 +0100 X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 > -----Original Message----- > From: jon@floorboard.com [mailto:jon@floorboard.com] > Sent: 05 May 1999 21:17 > To: Sastry Malladi > Cc: Owen Rees; OMG Firewall RTF; interop@omg.org; secsig@omg.org > Subject: Re: Bi-Directional GIOP: which connections may be used? > > > Sastry Malladi wrote: > > > > I'm not sure about the wording, but my understanding is that, the > client > > passes a context in which it indicates for what listening points, > this > > connection may be used by the server when invoking client > objects. The > > bidirecionness of the connection is not tied to just the objects > that > > are passed on this connection. Anytime when the server tries to > access a > > callback client object, it can check its connections list to see > if any > > of the existing connections to the client allow using that > connection as > > a bidirectional connection for the port contained in this callback > > object reference. I don't think it's mandatory for the server to > do > > that, it's optional. > > I agree that text in the bidirectional GIOP spec should be dropped > that > suggests that only the connection that the object reference was > received > on can be used for server to client invocations. Requiring this > would The spec doesn't say have this restriction at all. It does restict (although it does need to be clarified) to only using connections for callbacks after a bi-dir service context is passed on it. Hence a server is not restricted to the connection the IOR was received on, but any bi-dir connection to the client. > be costly to ORB implementations that would have to track what > connection a reference came in on, and cause interoperability > problems, > since the client could send the reference and then drop the > connection, > reestablish a new one, leaving the server with no current connection > to > use. Given that the intent of bidirectional GIOP is to allow > controlled > penetration of firewalls, this could result plenty of cases where > the > server can't reestablish contact with the client. > > > There is no security breach either because, the server may or may > not > > choose to use the bidirectional connection for the callback > objects > > based on some policies. However, in the case of secure/SSL > connections > > using bidirectional connection is a bit tricky, because there is > no > > second authentication/handshake going on. The servers/clients may > not > > use bidirectional connections in that case. > > As for the problem of rogue clients sending malicious listen point > information, I think that there is still a problem here for some > scenarios. > > 1. For SECIOP, there is a potential problem with interposing a > rogue > client inbetween the server and the real client. Even though the > server > must establish a new security context to send the invocation to the > client, the rogue process could just forward the SECIOP messages > through > to the real client. The possible security breach here is minor, > since > all the rogue process could do is read traffic that is only > integrity > protected, which anyone with a tap on a LAN could do anyway. > > 2. For SSL, I believe the same problem applies. > > 3. The real problem is with plain old IIOP. At minimum, a rogue > client > could cause some significant denial-of-service attacks, by sucking > up at > least some of the invocations that should have gone to legitimate > clients. At worst there is an additional risk of exposing sensitive > information above and beyond the already inherent risk of a > non-secure > protocol. > Agreed but I don't know what to do here, aprart from a bigger health warning in the spec!! Martin. Date: Tue, 11 May 1999 00:50:12 +0100 From: Owen Rees To: Martin Chapman , jon@floorboard.com, Sastry Malladi cc: Owen Rees , OMG Firewall RTF , interop@omg.org, secsig@omg.org Subject: RE: Bi-Directional GIOP: which connections may be used? Originator-Info: login-id=ore; server=ews.hpl.hp.com Content-Disposition: inline --On 10 May 1999, 17:17 +0100 Martin Chapman wrote: > > >> -----Original Message----- >> From: jon@floorboard.com [mailto:jon@floorboard.com] >> Sent: 05 May 1999 21:17 >> To: Sastry Malladi >> Cc: Owen Rees; OMG Firewall RTF; interop@omg.org; secsig@omg.org >> Subject: Re: Bi-Directional GIOP: which connections may be used? >> >> >> Sastry Malladi wrote: >> > >> > I'm not sure about the wording, but my understanding is that, the >> > client passes a context in which it indicates for what listening >> > points, this connection may be used by the server when invoking > client >> > objects. The bidirecionness of the connection is not tied to just > the >> > objects that are passed on this connection. Anytime when the > server >> > tries to access a callback client object, it can check its > connections >> > list to see if any of the existing connections to the client > allow >> > using that connection as a bidirectional connection for the port >> > contained in this callback object reference. I don't think it's >> > mandatory for the server to do that, it's optional. >> >> I agree that text in the bidirectional GIOP spec should be dropped > that >> suggests that only the connection that the object reference was > received >> on can be used for server to client invocations. Requiring this > would > > The spec doesn't say have this restriction at all. It does restict > (although it does need to be clarified) to only using connections > for > callbacks after a bi-dir service context is passed on it. Hence a > server > is not restricted to the connection the IOR was received on, but any > bi-dir connection to the client. > >> be costly to ORB implementations that would have to track what >> connection a reference came in on, and cause interoperability > problems, >> since the client could send the reference and then drop the > connection, >> reestablish a new one, leaving the server with no current > connection to >> use. Given that the intent of bidirectional GIOP is to allow > controlled >> penetration of firewalls, this could result plenty of cases where > the >> server can't reestablish contact with the client. >> >> > There is no security breach either because, the server may or may > not >> > choose to use the bidirectional connection for the callback > objects >> > based on some policies. However, in the case of secure/SSL > connections >> > using bidirectional connection is a bit tricky, because there is > no >> > second authentication/handshake going on. The servers/clients may > not >> > use bidirectional connections in that case. >> >> As for the problem of rogue clients sending malicious listen point >> information, I think that there is still a problem here for some >> scenarios. >> >> 1. For SECIOP, there is a potential problem with interposing a > rogue >> client inbetween the server and the real client. Even though the > server >> must establish a new security context to send the invocation to the >> client, the rogue process could just forward the SECIOP messages > through >> to the real client. The possible security breach here is minor, > since >> all the rogue process could do is read traffic that is only > integrity >> protected, which anyone with a tap on a LAN could do anyway. >> >> 2. For SSL, I believe the same problem applies. >> >> 3. The real problem is with plain old IIOP. At minimum, a rogue > client >> could cause some significant denial-of-service attacks, by sucking > up at >> least some of the invocations that should have gone to legitimate >> clients. At worst there is an additional risk of exposing > sensitive >> information above and beyond the already inherent risk of a > non-secure >> protocol. >> > > Agreed but I don't know what to do here, aprart from a bigger health > warning in the spec!! > > Martin. A bigger, and in particular more explicit health warning is what I would like to see. In particular, it should be made clear that a client outside the firewall can claim to be a server for any host, including a host inside the firewall. Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 Sender: jon@floorboard.com Date: Mon, 10 May 1999 17:03:00 -0700 From: Jonathan Biggar X-Accept-Language: en To: Owen Rees CC: Martin Chapman , Sastry Malladi , OMG Firewall RTF , interop@omg.org, secsig@omg.org Subject: Re: Bi-Directional GIOP: which connections may be used? References: <2965843434.926383812@rees-o-home-1.hpl.hp.com> Owen Rees wrote: > A bigger, and in particular more explicit health warning is what I > would > like to see. In particular, it should be made clear that a client > outside > the firewall can claim to be a server for any host, including a host > inside > the firewall. I just though of one possible "fix": allow a server to try to establish a connection to callback object via normal GIOP/IIOP mechanisms first, and if that fails, to then use bidirectional GIOP. This at least removes a significant number of the denial-of-service attacks, although it does slow down things a bit. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Mon, 06 Dec 1999 16:08:45 +0000 From: Owen Rees To: mchapman@iona.com, firewall-rtf@omg.org Subject: Re: Vote 1 draft 3 issue 2633 Message-ID: <3898687488.944496525@ews-proj-2.hpl.hp.com> In-Reply-To: <000001bf3d96$b9089780$4d01020a@leo.dublin.iona.ie> Originator-Info: login-id=ore; server=ticb.hpl.hp.com X-Mailer: Mulberry (Win32) [1.4.3, s/n P005-300802-001] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: J8`!!I%4e9Z=Je9&Tj!! I am going to vote NO on this one too - two points, one very small, the other I believe consistent with other changes, but not explicitly discussed. Rrather than go round again on 2240, I suggest we do 2633 separately, and fix them under that heading. --On 03 December 1999, 14:00 +0000 Martin Chapman wrote: > I moved issue 2633 into this vote since it is covered under 2240. Section 15.8 (of CORBA 2.3.1) page 15-53, para 2, in the last sentence: Replace: "exported by the client to the server via this connection will be sent back to the client on this same connection." With: "exported by the client to the server may be sent back to the client on this same connection." Deleting "via this connection" is for consistency with other changes clarifying the criteria for using the connection. Changing "will" to "may" recognises that there could be more than one connection on which the listen_point may have been sent. Section 15.8.1 page 15-55, para 3: Delete: "Typically, when the same client has multiple connections to the same server, the listen_points will be identical. However, if they differ, they supplement each other (i.e., any of the listen points received on any of the connections may be used)." I don't like this 'supplement' idea, I much prefer the simple "if and only if the matching listen_point came down this connection" rule. I believe that the new wording in the resolution of 2240 gives the simple rule. Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285