Issue 2634: Bi-Directional GIOP: Masquerade security issue needs to be more explicit (firewall-rtf) Source: (, ) 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: End of Annotations:===== Date: Wed, 05 May 1999 18:23:38 +0100 From: Owen Rees To: OMG Issues cc: OMG Firewall RTF Subject: Bi-Directional GIOP: Masquerade security issue needs to be more explicit. Originator-Info: login-id=ore; server=ews.hpl.hp.com Content-Disposition: inline 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. Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 6 May 1999 12:58:33 -0400 (EDT) From: Polar Humenn To: Owen Rees cc: Jonathan Biggar , Sastry Malladi , OMG Firewall RTF , interop@omg.org, secsig@omg.org Subject: Re: Issue 2634 masquerade (was Re: Bi-Directional GIOP: which connections may be used?) On Thu, 6 May 1999, Owen Rees wrote: > My main concern is that Bi-Directional IIOP creates the opportunity to > undermine the partitioning of the network into enclaves separated by > firewalls. ORBs and applications will have to be much more careful about > the targets of invocations since the endpoint may be the other side of the > firewall compared to its apparent or assumed location. Or disregard BiDirGIOP all together and go with a bonefied CORBA Security architecture and kill off the security lame Java Sandbox, which pretty much started this mess. 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 From: Zahid Ahmed To: Polar Humenn , Owen Rees Cc: Jonathan Biggar , Sastry Malladi , OMG Firewall RTF , interop@omg.org, secsig@omg.org Subject: RE: Issue 2634 masquerade (was Re: Bi-Directional GIOP: which con nections may be used?) Date: Thu, 6 May 1999 11:52:04 -0700 I think the point was made earlier that masquerading should not be an issue: 1) if the two peers are mutually authenticated during IIOP/SSL connection as included in the Firewall spec; 2) if an authorization service is used before target object invocation takes place. I would add to the above two steps, a step# 0: 0) which rejects connections request by checking if the peer's identity is a recognized as a registered identity in the identity database maintained in each peer's domain. If it is not a registered identity, it should be rejected before authorization step. However, the problem is that SSL handshake includes a simple authentication scheme of the peer based on public/private key verification. That's not enough to guarantee if the key-holder is really a registered user of the other peer's domain. Hence, with SSL, you would have to do step#0 after SSL connection succeded by a pre-authorization service which would have to be a fault-tolerant service to handle denial-of-service attacks. Obviously, this implies defining the right protocol with the CRL databases as well. How does this compare with enterprise class Web Servers such as IIS and Netscape Servers handling this problem? thanks. Zahid Ahmed Commerce One, Inc. (formely Veo Systems, Inc) Commerce Security Architect email: zahmed@veosystems.com v: (650)-623-2814 fax: (650)-938-8055 > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Thursday, May 06, 1999 9:59 AM > To: Owen Rees > Cc: Jonathan Biggar; Sastry Malladi; OMG Firewall RTF; > interop@omg.org; > secsig@omg.org > Subject: Re: Issue 2634 masquerade (was Re: Bi-Directional GIOP: > which > connections may be used?) > > > On Thu, 6 May 1999, Owen Rees wrote: > > > My main concern is that Bi-Directional IIOP creates the > opportunity to > > undermine the partitioning of the network into enclaves separated > by > > firewalls. ORBs and applications will have to be much more > careful about > > the targets of invocations since the endpoint may be the > other side of the > > firewall compared to its apparent or assumed location. > > Or disregard BiDirGIOP all together and go with a bonefied > CORBA Security > architecture and kill off the security lame Java Sandbox, which > pretty > much started this mess. > > 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 > From: Zahid Ahmed To: Jonathan Biggar , OMG Firewall RTF , Owen Rees Cc: Polar Humenn , Sastry Malladi , interop@omg.org, OMG Firewall RTF , secsig@omg.org Subject: RE: Issue 2634 masquerade (was Re: Bi-Directional GIOP: which co nnections may be used?) Date: Thu, 6 May 1999 18:06:42 -0700 Ok, if the listening point data is unauthenticated, it's a problem across firewalls only. Within intranets/extranets we can consider listening point data to be trusted with the steps noted in attached. There seem to be two options for dealing with listening points outside firewall: 1) use of secure DNS to trust domain info (look at RFC 2538) 2) IIOP Firewall Proxies should include proxy credential (public cert) that can be authenticated in addition to peer's credential (pub cert) I believe #2 is already captured in omg firewall specs? If that's true, what's the issue? Otherwise, IIOP would need to restrict itself to one way calls (like http/web servers) over internet. Zahid Ahmed Commerce One, Inc. (formely Veo Systems,Inc.) Commerce Security Architect email: zahid.ahmed@commerceone.com v: (650)-623-2814 fax: (650)-938-8055 > -----Original Message----- > From: Jonathan Biggar [mailto:jon@floorboard.com] > Sent: Thursday, May 06, 1999 12:59 PM > To: Zahid Ahmed > Cc: Polar Humenn; Owen Rees; Sastry Malladi; OMG Firewall RTF; > interop@omg.org; secsig@omg.org > Subject: Re: Issue 2634 masquerade (was Re: Bi-Directional GIOP: > which > connections may be used?) > > > Zahid Ahmed wrote: > > > > I think the point was made earlier that masquerading > > should not be an issue: > > > > 1) if the two peers are mutually authenticated during IIOP/SSL > > connection as included in the Firewall spec; > > > > 2) if an authorization service is used before target object > > invocation takes place. > > > > I would add to the above two steps, a step# 0: > > > > 0) which rejects connections request by checking if the > > peer's identity is a recognized as a registered identity > > in the identity database maintained in each peer's domain. > > > > If it is not a registered identity, it should be rejected before > > authorization step. However, the problem is that SSL handshake > > includes a simple authentication scheme of the peer based on > > public/private key verification. That's not enough to guarantee > > if the key-holder is really a registered user of the other peer's > > domain. Hence, with SSL, you would have to do step#0 after SSL > > connection succeded by a pre-authorization service which would > > have to be a fault-tolerant service to handle denial-of-service > > attacks. Obviously, this implies defining the right protocol > > with the CRL databases as well. > > The problem is that the "listening point" data is provided as > a list of > transport level addresses. For TCP/IP, these are not and > cannot be used > as reliable identifiers. > The risks that I identified still remain: > > 1. A rogue client can proceed with a denial-of-service attack by > claiming to service "listening points" that it does not in fact > service. I don't see any mechanism for a server to protect > it from this > attack except for refusing to use bidirectional GIOP at all. > > 2. For security protocols that do not embed the client's transport > address as part of the initial handshake, a rogue client can > interpose > itself between the real client and server and monitor traffic. > > > How does this compare with enterprise class Web Servers such > > as IIS and Netscape Servers handling this problem? > > I don't think that it applies, since http is a one way client-server > protocol. The problem with bidirectional GIOP is that the > conversation > is two way and the "listening point" information is fundamentally > unathenicated. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org > Sender: jon@floorboard.com Date: Thu, 06 May 1999 12:59:06 -0700 From: Jonathan Biggar X-Accept-Language: en To: Zahid Ahmed CC: Polar Humenn , Owen Rees , Sastry Malladi , OMG Firewall RTF , interop@omg.org, secsig@omg.org Subject: Re: Issue 2634 masquerade (was Re: Bi-Directional GIOP: which connections may be used?) References: Zahid Ahmed wrote: > > I think the point was made earlier that masquerading > should not be an issue: > > 1) if the two peers are mutually authenticated during IIOP/SSL > connection as included in the Firewall spec; > > 2) if an authorization service is used before target object > invocation takes place. > > I would add to the above two steps, a step# 0: > > 0) which rejects connections request by checking if the > peer's identity is a recognized as a registered identity > in the identity database maintained in each peer's domain. > > If it is not a registered identity, it should be rejected before > authorization step. However, the problem is that SSL handshake > includes a simple authentication scheme of the peer based on > public/private key verification. That's not enough to guarantee > if the key-holder is really a registered user of the other peer's > domain. Hence, with SSL, you would have to do step#0 after SSL > connection succeded by a pre-authorization service which would > have to be a fault-tolerant service to handle denial-of-service > attacks. Obviously, this implies defining the right protocol > with the CRL databases as well. The problem is that the "listening point" data is provided as a list of transport level addresses. For TCP/IP, these are not and cannot be used as reliable identifiers. The risks that I identified still remain: 1. A rogue client can proceed with a denial-of-service attack by claiming to service "listening points" that it does not in fact service. I don't see any mechanism for a server to protect it from this attack except for refusing to use bidirectional GIOP at all. 2. For security protocols that do not embed the client's transport address as part of the initial handshake, a rogue client can interpose itself between the real client and server and monitor traffic. > How does this compare with enterprise class Web Servers such > as IIS and Netscape Servers handling this problem? I don't think that it applies, since http is a one way client-server protocol. The problem with bidirectional GIOP is that the conversation is two way and the "listening point" information is fundamentally unathenicated. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Fri, 7 May 1999 09:15:03 -0400 (EDT) From: Polar Humenn To: Zahid Ahmed cc: Jonathan Biggar , OMG Firewall RTF , Owen Rees , Sastry Malladi , interop@omg.org, secsig@omg.org Subject: RE: Issue 2634 masquerade (was Re: Bi-Directional GIOP: which co nnections may be used?) On Thu, 6 May 1999, Zahid Ahmed wrote: > Ok, if the listening point data is unauthenticated, it's a > problem across firewalls only. Within intranets/extranets we > can consider listening point data to be trusted with the > steps noted in attached. > > There seem to be two options for dealing with listening points > outside firewall: > > 1) use of secure DNS to trust domain info (look at RFC 2538) > 2) IIOP Firewall Proxies should include proxy credential (public > cert) > that can be authenticated in addition to peer's credential (pub > cert) > > I believe #2 is already captured in omg firewall specs? If that's > true, what's the issue? In #2 where does this proxy credential live? In the IOR? In the Service Context? The IOR is not integrity protected. Therefore, it can be mucked with, captured and reused. If it's in the service context, since IIOP is has no integrity protection in the protocol, the "proxy credential", can captured and reused. > Otherwise, IIOP would need to restrict itself to one way calls > (like http/web servers) over internet. It most definately should. 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 X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Fri, 7 May 1999 09:21:25 -0400 (EDT) From: Polar Humenn To: "gene.jarboe" cc: Zahid Ahmed , Jonathan Biggar , OMG Firewall RTF , Owen Rees , Sastry Malladi , interop@omg.org, secsig@omg.org Subject: Re: Issue 2634 masquerade (was Re: Bi-Directional GIOP: which connections may be used?) On Fri, 7 May 1999, gene.jarboe wrote: > Zahid Ahmed and et al., > > I believe that the CORBA security needs to start discussing > about > the "Trusted Computing Base (TCB)" issues in addition to your points > below. Even if your organization uses a "secure DNS to trust domain > info," how does an organization protect itself from > hackers/attackers > or insiders having access to operating systems nodes both within or > outside an organization? Discuss away Jene! What's on your mind? > It seems to me that early on within the CORBA Security > specification, the CORBASec authors stated, if I remember correctly, > that their security is only as good as the local operating system. > Thus, if the bad people of this world have access to the local > nodes' > operating system, CORBASec still can be bypassed. Is this still true > today? Yes, Gene, CORBA security is only as good as the local operating system. There are many trust issues even with the concern of your hardware, such as keyboards and monitors. You never know where Winn Swartau's Information Warrior may be lurking about, much like McCarthy's communists :). Anyway, it's a cost/risk based decision. 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: Fri, 07 May 1999 08:17:07 -0400 From: "gene.jarboe" Subject: Re: Issue 2634 masquerade (was Re: Bi-Directional GIOP: which connections may be used?) To: Zahid Ahmed , Jonathan Biggar , OMG Firewall RTF , Owen Rees Cc: Polar Humenn , Sastry Malladi , interop@omg.org, OMG Firewall RTF , secsig@omg.org Reply-to: "gene.jarboe" X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-MSMail-priority: Normal Zahid Ahmed and et al., I believe that the CORBA security needs to start discussing about the "Trusted Computing Base (TCB)" issues in addition to your points below. Even if your organization uses a "secure DNS to trust domain info," how does an organization protect itself from hackers/attackers or insiders having access to operating systems nodes both within or outside an organization? It seems to me that early on within the CORBA Security specification, the CORBASec authors stated, if I remember correctly, that their security is only as good as the local operating system. Thus, if the bad people of this world have access to the local nodes' operating system, CORBASec still can be bypassed. Is this still true today? Regards, Gene Jarboe Promia, Inc. -----Original Message----- From: Zahid Ahmed To: Jonathan Biggar ; OMG Firewall RTF ; Owen Rees Cc: Polar Humenn ; Sastry Malladi ; interop@omg.org ; OMG Firewall RTF ; secsig@omg.org Date: Thursday, May 06, 1999 10:18 PM Subject: RE: Issue 2634 masquerade (was Re: Bi-Directional GIOP: which connections may be used?) >Ok, if the listening point data is unauthenticated, it's a >problem across firewalls only. Within intranets/extranets we >can consider listening point data to be trusted with the >steps noted in attached. > >There seem to be two options for dealing with listening points >outside firewall: > >1) use of secure DNS to trust domain info (look at RFC 2538) >2) IIOP Firewall Proxies should include proxy credential (public cert) > that can be authenticated in addition to peer's credential (pub cert) > >I believe #2 is already captured in omg firewall specs? If that's >true, what's the issue? > >Otherwise, IIOP would need to restrict itself to one way calls >(like http/web servers) over internet. > >Zahid Ahmed Commerce One, Inc. (formely Veo Systems,Inc.) >Commerce Security Architect >email: zahid.ahmed@commerceone.com >v: (650)-623-2814 >fax: (650)-938-8055 > >> -----Original Message----- >> From: Jonathan Biggar [mailto:jon@floorboard.com] >> Sent: Thursday, May 06, 1999 12:59 PM >> To: Zahid Ahmed >> Cc: Polar Humenn; Owen Rees; Sastry Malladi; OMG Firewall RTF; >> interop@omg.org; secsig@omg.org >> Subject: Re: Issue 2634 masquerade (was Re: Bi-Directional GIOP: which >> connections may be used?) >> >> >> Zahid Ahmed wrote: >> > >> > I think the point was made earlier that masquerading >> > should not be an issue: >> > >> > 1) if the two peers are mutually authenticated during IIOP/SSL >> > connection as included in the Firewall spec; >> > >> > 2) if an authorization service is used before target object >> > invocation takes place. >> > >> > I would add to the above two steps, a step# 0: >> > >> > 0) which rejects connections request by checking if the >> > peer's identity is a recognized as a registered identity >> > in the identity database maintained in each peer's domain. >> > >> > If it is not a registered identity, it should be rejected before >> > authorization step. However, the problem is that SSL handshake >> > includes a simple authentication scheme of the peer based on >> > public/private key verification. That's not enough to guarantee >> > if the key-holder is really a registered user of the other peer's >> > domain. Hence, with SSL, you would have to do step#0 after SSL >> > connection succeded by a pre-authorization service which would >> > have to be a fault-tolerant service to handle denial-of-service >> > attacks. Obviously, this implies defining the right protocol >> > with the CRL databases as well. >> >> The problem is that the "listening point" data is provided as >> a list of >> transport level addresses. For TCP/IP, these are not and >> cannot be used >> as reliable identifiers. >> The risks that I identified still remain: >> >> 1. A rogue client can proceed with a denial-of-service attack by >> claiming to service "listening points" that it does not in fact >> service. I don't see any mechanism for a server to protect >> it from this >> attack except for refusing to use bidirectional GIOP at all. >> >> 2. For security protocols that do not embed the client's transport >> address as part of the initial handshake, a rogue client can interpose >> itself between the real client and server and monitor traffic. >> >> > How does this compare with enterprise class Web Servers such >> > as IIS and Netscape Servers handling this problem? >> >> I don't think that it applies, since http is a one way client-server >> protocol. The problem with bidirectional GIOP is that the >> conversation >> is two way and the "listening point" information is fundamentally >> unathenicated. >> >> -- >> Jon Biggar >> Floorboard Software >> jon@floorboard.com >> jon@biggar.org >> > Date: Fri, 07 May 1999 10:20:31 -0400 From: "gene.jarboe" Subject: Re: Issue 2634 masquerade (was Re: Bi-Directional GIOP: whichconnections may be used?) To: Polar Humenn Cc: secsig@omg.org, interop@omg.org, Sastry Malladi , Owen Rees , OMG Firewall RTF , Jonathan Biggar , Zahid Ahmed Reply-to: "gene.jarboe" X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-MSMail-priority: Normal Polar Humenn and et al., Please see my comments inserted below. Gene -----Original Message----- From: Polar Humenn To: gene.jarboe Cc: Zahid Ahmed ; Jonathan Biggar ; OMG Firewall RTF ; Owen Rees ; Sastry Malladi ; interop@omg.org ; secsig@omg.org Date: Friday, May 07, 1999 9:20 AM Subject: Re: Issue 2634 masquerade (was Re: Bi-Directional GIOP: whichconnections may be used?) >On Fri, 7 May 1999, gene.jarboe wrote: > >> Zahid Ahmed and et al., >> >> I believe that the CORBA security needs to start discussing about >> the "Trusted Computing Base (TCB)" issues in addition to your points >> below. Even if your organization uses a "secure DNS to trust domain >> info," how does an organization protect itself from hackers/attackers >> or insiders having access to operating systems nodes both within or >> outside an organization? > >Discuss away Jene! What's on your mind? Having talked with CitiBank's security experts and other customers/ORB users, I have made the following observations: (1) CORBASec is extremely complicated and...yes, it is even hard to comprehend for the most knowledgeable of security aware people. (2) Security aware people are making & asking a lot of questions & comments about their "generic Trusted Computing Base (TCB)" and "trusted computing facilities", but NOT a lot is being said or written about their "operating system assumptions" or for that matter "how much security is does an organization really have using "generic commercial operating systems" today. It seems to beg the question, shouldn't the CORBA security community have written down somewhere: "what are these security TCB assumptions relative to an underlying architecture to made these security decisions about an organization's overall enterprise information security policy?" Yes, I know that you and others are security experts! :-)) And that you know a lot about the implementation details of CORBASec. But, we (security people) never talk or discuss much about Intranets/extranets/firewalls and the Internet what their underlying security assumptions are. Nor do we discuss it WRT what it is an organization is trying to secure! Questions like: (a) What is the TCB of your organization and is the organization already utilizing CORBA? (b) If so, how does that organization migrate from generic CORBA to CORBASec using various security protocols (e.g., SECIOP, SSL, DCE etc.) and heterogeneous operating systems and programming languages? (c) How does an organization better detect and protect their TCB using a heterogeneous CORBASec solution? (d) What are the vulnerabilites and risks associated with utilizing any distributed object computing base (DOC) (e.g., COM/DCOM, CORBA, Java RMI & Enterprise Java Beans (EJB))? (e) Is an organization's security any better with or without "DOC secure interoperability" when it is all say and done? The bottom line is what is it that an organization' is trying to protect and what is it that an organization' is trying detection when utilizing Information Systems (IS) today? From these questions, our security aware community can start architecting a good security solution. Wouldn't you agree? :-)) And yes, it comes down to an organization's risk management decision...how much are we willing to pay to protect/detect our IS? Now that is my 0.02 cents for Jishnu....Gene :-)) > >> It seems to me that early on within the CORBA Security >> specification, the CORBASec authors stated, if I remember >> correctly, >> that their security is only as good as the local operating system. >> Thus, if the bad people of this world have access to the local >> nodes' >> operating system, CORBASec still can be bypassed. Is this still >> true >> today? > >Yes, Gene, CORBA security is only as good as the local operating >> system. >There are many trust issues even with the concern of your hardware, >> such >as keyboards and monitors. You never know where Winn Swartau's >> Information >Warrior may be lurking about, much like McCarthy's communists :). > >Anyway, it's a cost/risk based decision. > >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 > > X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Fri, 7 May 1999 10:44:42 -0400 (EDT) From: Polar Humenn To: "gene.jarboe" cc: secsig@omg.org, interop@omg.org, Sastry Malladi , Owen Rees , OMG Firewall RTF , Jonathan Biggar , Zahid Ahmed Subject: Re: Issue 2634 masquerade (was Re: Bi-Directional GIOP: whichconnections may be used?) On Fri, 7 May 1999, gene.jarboe wrote: > Polar Humenn and et al., > > Having talked with CitiBank's security experts and other > customers/ORB > users, > I have made the following observations: > > (1) CORBASec is extremely complicated and...yes, it is even > hard > to comprehend for the most knowledgeable of security aware people. Yes, we already know that. There are lots of bells and whistles in the spec that maybe shouldn't be there because they are overly complicated and restrictive. > (2) Security aware people are making & asking a lot of questions > & comments about their "generic Trusted Computing Base (TCB)" and > "trusted computing facilities", but NOT a lot is being said or written > about their "operating system assumptions" or for that matter "how > much security is does an organization really have using "generic > commercial operating systems" today. It seems to beg the question, > shouldn't the CORBA security community have written down somewhere: > "what are these security TCB assumptions relative to an underlying > architecture to made these security decisions about an organization's > overall enterprise information security policy?" I believe there is some information in Appendix D, guidelines for a trustworthy system. Have you read that? How can it be better? Feel like writing a paper? > Yes, I know that you and others are security experts! :-)) And > that you know a lot about the implementation details of > CORBASec. But, > we (security people) never talk or discuss much about > Intranets/extranets/firewalls and the Internet what their underlying > security assumptions are. Nor do we discuss it WRT what it is an > organization is trying to secure! Every vertical domain has their own needs and their own shortcommings. How can one come up with a generic model to statisfy all? > Questions like: > (a) What is the TCB of your organization and is the organization > already utilizing CORBA? What is the purpose of this question? How many people even know what "TCB" even stands for? We cannot solve each organziation's problem of software, personnel, or equipment choices in general. > (b) If so, how does that organization migrate from generic CORBA to > CORBASec using various security protocols (e.g., SECIOP, SSL, DCE > etc.) and heterogeneous operating systems and programming languages? That also, is a function of the organization on how it wants to proceed in the most cost effective or inefficient manner as they choose. We cannot dictate how that can be done. > (c) How does an organization better detect and protect their TCB using > a heterogeneous CORBASec solution? This is what they pay security consultants for. > (d) What are the vulnerabilites and risks associated with utilizing > any distributed object computing base (DOC) (e.g., COM/DCOM, CORBA, > Java RMI & Enterprise Java Beans (EJB))? Oh com'on! This depends on the application, the configuration, and the enterprise(s) involved. If you get this one down Gene, you could sell a book to Addison Wesley or something. > (e) Is an organization's security any better with or without "DOC > secure interoperability" when it is all say and done? Answer first, Is is any better with CORBA when it is all said and done? > The bottom line is what is it that an organization' is trying to > protect and what is it that an organization' is trying detection when > utilizing Information Systems (IS) today? From these questions, our > security aware community can start architecting a good security > solution. Wouldn't you agree? :-)) Yes, but how can that be done in general for evey organization or interacting organizations. I contend that it cannot. > And yes, it comes down to an organization's risk management > decision...how much are we willing to pay to protect/detect our IS? Correct. Right now, security in form of CORBAsec is still more of a research project and not widely used. > Now that is my 0.02 cents for Jishnu....Gene :-)) Now, send some money my way Gene :) 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 From: "Martin Chapman" To: "Polar Humenn" , "Owen Rees" Cc: "Jonathan Biggar" , "Sastry Malladi" , "OMG Firewall RTF" , , Subject: RE: Issue 2634 masquerade (was Re: Bi-Directional GIOP: whichconnections may be used?) Date: Mon, 10 May 1999 17:34:24 +0100 X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Polar, The only way to get rid of BiDirGIOP now is to invoke the request for retirement procedure on it. I don't think that will get very far ;-) Martin. > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: 06 May 1999 17:59 > To: Owen Rees > Cc: Jonathan Biggar; Sastry Malladi; OMG Firewall RTF; > interop@omg.org; > secsig@omg.org > Subject: Re: Issue 2634 masquerade (was Re: Bi-Directional GIOP: > whichconnections may be used?) > > > On Thu, 6 May 1999, Owen Rees wrote: > > > My main concern is that Bi-Directional IIOP creates the > opportunity to > > undermine the partitioning of the network into enclaves separated > by > > firewalls. ORBs and applications will have to be much more careful > about > > the targets of invocations since the endpoint may be the other > side of the > > firewall compared to its apparent or assumed location. > > Or disregard BiDirGIOP all together and go with a bonefied CORBA > Security > architecture and kill off the security lame Java Sandbox, which > pretty > much started this mess. > > 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 > X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 10 May 1999 12:42:01 -0400 (EDT) From: Polar Humenn To: Martin Chapman cc: Owen Rees , Jonathan Biggar , Sastry Malladi , OMG Firewall RTF , interop@omg.org, secsig@omg.org Subject: RE: Issue 2634 masquerade (was Re: Bi-Directional GIOP: whichconnections may be used?) On Mon, 10 May 1999, Martin Chapman wrote: > Polar, > The only way to get rid of BiDirGIOP now is to invoke the request > for > retirement procedure on it. I don't think that will get very far ;-) Wouldn't try it in my lifetime! :) Ah, I didn't say get rid of it. I said just disregard it. There's quite alot of that done around here anyway. :^) See you in Tokyo. -Polar > Martin. > > > -----Original Message----- > > From: Polar Humenn [mailto:polar@adiron.com] > > Sent: 06 May 1999 17:59 > > To: Owen Rees > > Cc: Jonathan Biggar; Sastry Malladi; OMG Firewall RTF; > interop@omg.org; > > secsig@omg.org > > Subject: Re: Issue 2634 masquerade (was Re: Bi-Directional GIOP: > > whichconnections may be used?) > > > > > > On Thu, 6 May 1999, Owen Rees wrote: > > > > > My main concern is that Bi-Directional IIOP creates the > opportunity to > > > undermine the partitioning of the network into enclaves > separated by > > > firewalls. ORBs and applications will have to be much more > careful about > > > the targets of invocations since the endpoint may be the other > > side of the > > > firewall compared to its apparent or assumed location. > > > > Or disregard BiDirGIOP all together and go with a bonefied CORBA > Security > > architecture and kill off the security lame Java Sandbox, which > pretty > > much started this mess. > > > > 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 > > > ------------------------------------------------------------------- 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 Sender: jis@fpk.hp.com Date: Mon, 10 May 1999 14:02:45 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL To: Martin Chapman CC: Polar Humenn , Owen Rees , Jonathan Biggar , Sastry Malladi , OMG Firewall RTF , interop@omg.org, secsig@omg.org Subject: Re: Issue 2634 masquerade (was Re: Bi-Directional GIOP: whichconnections may be used?) References: <000601be9b02$f72cc9a0$0f01020a@dublin.iona.ie> Martin Chapman wrote: > > Polar, > The only way to get rid of BiDirGIOP now is to invoke the request > for > retirement procedure on it. I don't think that will get very far ;-) > > Martin. I think he meant, when in doubt, just say No,:-) i.e. don't use BiDiGIOP when the kind of security holes that it creates is considered not desirable for your particular application. The beauty of all this is that as long as you have a sufficient clientale for a particular, doohickey, no matter how broken it is for everyone else, it is worth making a buck off of the clientale that can live with it.:-) Jishnu. > > > -----Original Message----- > > From: Polar Humenn [mailto:polar@adiron.com] > > Sent: 06 May 1999 17:59 > > To: Owen Rees > > Cc: Jonathan Biggar; Sastry Malladi; OMG Firewall RTF; > interop@omg.org; > > secsig@omg.org > > Subject: Re: Issue 2634 masquerade (was Re: Bi-Directional GIOP: > > whichconnections may be used?) > > > > > > On Thu, 6 May 1999, Owen Rees wrote: > > > > > My main concern is that Bi-Directional IIOP creates the > opportunity to > > > undermine the partitioning of the network into enclaves > separated by > > > firewalls. ORBs and applications will have to be much more > careful about > > > the targets of invocations since the endpoint may be the other > > side of the > > > firewall compared to its apparent or assumed location. > > > > Or disregard BiDirGIOP all together and go with a bonefied CORBA > Security > > architecture and kill off the security lame Java Sandbox, which > pretty > > much started this mess. > > > > Cheers, > > -Polar -- 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. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 29 Nov 1999 13:58:59 -0500 (EST) From: Polar Humenn To: Martin Chapman cc: Paul Kyzivat , firewall-rtf@omg.org Subject: RE: Round 1 In-Reply-To: <002c01bf3a85$8fe25760$4d01020a@leo.dublin.iona.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: FV@e9`@>!! To: mchapman@iona.com, firewall-rtf@omg.org Subject: RE: Round 1 - issue 2634 Message-ID: <3322031223.943919869@localhost> In-Reply-To: <001701bf3a6e$650b0da0$4d01020a@leo.dublin.iona.ie> X-Mailer: Mulberry (Win32) [2.0.0b1, s/n P005-300802-002] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: XG#!!^Q-!!ZkSd9KSSd9 --On 29 November 1999 13:34 +0000 Martin Chapman wrote: > 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: The remark about masquerade at the end of 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: Refine the text to make more explicit. I am happy with the proposed replacement text. Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285