Issue 6313: Bidirectional Policy insufficient for persistent objects (firewall-traversal-ftf) Source: Adiron, LLC (Mr. Polar Humenn, polar(at)adiron.com) Nature: Uncategorized Issue Severity: Summary: The BidirectionalPolicy insufficient for persistent objects. The BidirectinoalExport Policy is a POA policy and it only has two values of ALLOW and DENY. If it is ALLOW, then a TAG_BI_DIR_GIOP componenet should be placed in the IOR. It is stated that the ORB must generate a random identifier when the POA is created. However, that will not work for persistent objects in which the BiDirectional Offer must remain constant. Also, there is no default specified if this policy is not placed on a POA, and no default for the RootPOA. Resolution: Revised Text: Actions taken: October 9, 2003: received issue Discussion: End of Annotations:===== uthentication-Warning: greene.case.syr.edu: polar owned process doing -bs Date: Thu, 9 Oct 2003 12:31:44 -0400 (EDT) From: Polar Humenn X-X-Sender: polar@greene.case.syr.edu To: issues@omg.org, firewall-traversal-ftf@omg.org Subject: Bidirectional Policy insufficient for persistent objects. The BidirectionalPolicy insufficient for persistent objects. The BidirectinoalExport Policy is a POA policy and it only has two values of ALLOW and DENY. If it is ALLOW, then a TAG_BI_DIR_GIOP componenet should be placed in the IOR. It is stated that the ORB must generate a random identifier when the POA is created. However, that will not work for persistent objects in which the BiDirectional Offer must remain constant. Also, there is no default specified if this policy is not placed on a POA, and no default for the RootPOA. -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Mon, 12 Apr 2004 14:41:53 -0400 (EDT) From: Polar Humenn To: "Bergersen, Rebecca" Cc: ckuo01@syr.edu, "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" , "Dave Stringer (E-mail)" , firewall-traversal-ftf@omg.org Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - resolution to 6313 This resolution is just wrong. It states: "Modify the text to indicate that random identifiers must be generated for transient objects, but that persistent objects must use an identifier that remains constant across sessions. In the strong identifier case, a different RSA Modulus and index is generated for each POA and is required for handling challenges. Since these numbers are not persistent across sessions, it is disallowed for POAs to have both a LifespanPolicy with a value of PERSISTENT and a BidirectionalExportPolicy with a strong BiDirId. That is, persistent POAs may only have a weak BiDirId type." So, what we have here in this resolution is the removal of the key functionality that allows Strong Identification for Persistent objects?!?!?! Are you kidding me? Persistent objects were pretty much the cause of the spoofing problem with BiDir in the first place! The fact that somebody had persitent objects behind a particular server and port means that YOU could say you served objects behind a particular server and port, and the server would start handing you requests. Same situation, only now, you can do it with just knowing the Weak BiDirId. Furthermore, there is nothing about RSA or public key mechanisms that prevents its use for persistent objects. The issue was about the specification stating that a new randomly generated identifier must be generated for each POA. Granted, it MAY be hard for the ORB to be able to know what RSA key it is going to generate for persitent objects and be able to redo that across shutting down of the POAs, ORB, etc., but it is certainly not impossible. -Polar On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > The second and final vote for the Firewall Traversal FTF has been posted at > ftp://ftp.omg.org/pub/firewall-traversal-ftf/Firewall_Traversal_FTF_Vote_2.htm. > > The resolutions are based on comments received from Tom, Jishnu, Dave, Joncheng, Polar and myself. > The vote will open at 12:00 PM (EDT) Monday 12 April and close at 17:00 PM (EDT) Wednesday 14 April, since the final report has a hard deadline of Thursday, 15 April. > > Vote Early! > > Regards, > Rebecca Bergersen > PRINCIPAL ARCHITECT, MIDDLEWARE STANDARDS > rebecca.bergersen@iona.com > ------------------------------------------------------- > IONA Technologies > 200 West Street Waltham, MA 02451 USA > Tel: (781) 902-8265 > Fax: (781) 902-8001 > ------------------------------------------------------- > Making Software Work Together TM > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution to 6313 Date: Mon, 12 Apr 2004 15:57:44 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PLEASE VOTE - Firewall FTF Vote 2 - resolution to 6313 Thread-Index: AcQgvlX/bhvyQjUESj+zQI7it03n7wACXkXg From: "Bergersen, Rebecca" To: "Polar Humenn" Cc: , "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" , "Dave Stringer (E-mail)" , , "Bergersen, Rebecca" X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i3CK0ana001161 A delegation model can be used when dealing with persistent POAs. It is very efficient in most ORBs to delegate processing to another object. Therefore, when a persistent POA is to be used for callback objects, a transient POA can be created which delegates its processing to the persistent POA. The transient POA participates in the full strong BiDir Challenge/Response protocol, if necessary, then delegates everything else to the persistent object. This model allows both strong and weak BiDir to be used with persistent objects. --Rebecca > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Monday, April 12, 2004 2:42 PM > To: Bergersen, Rebecca > Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave > Stringer (E-mail); firewall-traversal-ftf@omg.org > Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - resolution to 6313 > > > > This resolution is just wrong. It states: > > "Modify the text to indicate that random identifiers must be > generated for > transient objects, but that persistent objects must use an > identifier that > remains constant across sessions. In the strong identifier case, a > different RSA Modulus and index is generated for each POA and > is required > for handling challenges. Since these numbers are not > persistent across > sessions, it is disallowed for POAs to have both a > LifespanPolicy with a > value of PERSISTENT and a BidirectionalExportPolicy with a > strong BiDirId. > That is, persistent POAs may only have a weak BiDirId type." > > > So, what we have here in this resolution is the removal of the key > functionality that allows Strong Identification for Persistent > objects?!?!?! > > Are you kidding me? > > Persistent objects were pretty much the cause of the spoofing > problem with > BiDir in the first place! The fact that somebody had > persitent objects > behind a particular server and port means that YOU could say > you served > objects behind a particular server and port, and the server > would start > handing you requests. Same situation, only now, you can do it > with just > knowing the Weak BiDirId. > > Furthermore, there is nothing about RSA or public key mechanisms that > prevents its use for persistent objects. The issue was about the > specification stating that a new randomly generated identifier must be > generated for each POA. Granted, it MAY be hard for the ORB > to be able to > know what RSA key it is going to generate for persitent objects and be > able to redo that across shutting down of the POAs, ORB, > etc., but it is > certainly not impossible. > > -Polar > > > > > > > > > > > On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > > > The second and final vote for the Firewall Traversal FTF > has been posted at > > > ftp://ftp.omg.org/pub/firewall-traversal-ftf/Firewall_Traversa l_FTF_Vote_2.htm. > > The resolutions are based on comments received from Tom, Jishnu, Dave, Joncheng, Polar and myself. > The vote will open at 12:00 PM (EDT) Monday 12 April and close at 17:00 PM (EDT) Wednesday 14 April, since the final report has a hard deadline of Thursday, 15 April. > > Vote Early! > > Regards, > Rebecca Bergersen > PRINCIPAL ARCHITECT, MIDDLEWARE STANDARDS > rebecca.bergersen@iona.com > ------------------------------------------------------- > IONA Technologies > 200 West Street Waltham, MA 02451 USA > Tel: (781) 902-8265 > Fax: (781) 902-8001 > ------------------------------------------------------- > Making Software Work Together TM > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Mon, 12 Apr 2004 17:01:12 -0400 (EDT) From: Polar Humenn To: "Bergersen, Rebecca" Cc: ckuo01@syr.edu, "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" , "Dave Stringer (E-mail)" , firewall-traversal-ftf@omg.org Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution to 6313 All, I have to say to that is "huh??" I use a persistent POA and its persistent object references because I want to be able to contact the same object witout having to get new object references. Now, why would I want to create a transient POA and have to redistribute object references again? efficient? -Polar On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > A delegation model can be used when dealing with persistent POAs. It is > very efficient in most ORBs to delegate processing to another object. > Therefore, when a persistent POA is to be used for callback objects, a > transient POA can be created which delegates its processing to the > persistent POA. The transient POA participates in the full strong BiDir > Challenge/Response protocol, if necessary, then delegates everything > else to the persistent object. This model allows both strong and weak > BiDir to be used with persistent objects. > > --Rebecca > > > -----Original Message----- > > From: Polar Humenn [mailto:polar@adiron.com] > > Sent: Monday, April 12, 2004 2:42 PM > > To: Bergersen, Rebecca > > Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave > > Stringer (E-mail); firewall-traversal-ftf@omg.org > > Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - resolution to 6313 > > > > > > > > This resolution is just wrong. It states: > > > > "Modify the text to indicate that random identifiers must be > > generated for > > transient objects, but that persistent objects must use an > > identifier that > > remains constant across sessions. In the strong identifier case, a > > different RSA Modulus and index is generated for each POA and > > is required > > for handling challenges. Since these numbers are not > > persistent across > > sessions, it is disallowed for POAs to have both a > > LifespanPolicy with a > > value of PERSISTENT and a BidirectionalExportPolicy with a > > strong BiDirId. > > That is, persistent POAs may only have a weak BiDirId type." > > > > > > So, what we have here in this resolution is the removal of the key > > functionality that allows Strong Identification for Persistent > > objects?!?!?! > > > > Are you kidding me? > > > > Persistent objects were pretty much the cause of the spoofing > > problem with > > BiDir in the first place! The fact that somebody had > > persitent objects > > behind a particular server and port means that YOU could say > > you served > > objects behind a particular server and port, and the server > > would start > > handing you requests. Same situation, only now, you can do it > > with just > > knowing the Weak BiDirId. > > > > Furthermore, there is nothing about RSA or public key mechanisms that > > prevents its use for persistent objects. The issue was about the > > specification stating that a new randomly generated identifier must be > > generated for each POA. Granted, it MAY be hard for the ORB > > to be able to > > know what RSA key it is going to generate for persitent objects and be > > able to redo that across shutting down of the POAs, ORB, > > etc., but it is > > certainly not impossible. > > > > -Polar > > > > > > > > > > > > > > > > > > > > > > On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > > > > > The second and final vote for the Firewall Traversal FTF > > has been posted at > > > > > ftp://ftp.omg.org/pub/firewall-traversal-ftf/Firewall_Traversa > l_FTF_Vote_2.htm. > > > > The resolutions are based on comments received from Tom, Jishnu, Dave, Joncheng, Polar and myself. > > The vote will open at 12:00 PM (EDT) Monday 12 April and close at 17:00 PM (EDT) Wednesday 14 April, since the final report has a hard deadline of Thursday, 15 April. > > > > Vote Early! > > > > Regards, > > Rebecca Bergersen > > PRINCIPAL ARCHITECT, MIDDLEWARE STANDARDS > > rebecca.bergersen@iona.com > > ------------------------------------------------------- > > IONA Technologies > > 200 West Street Waltham, MA 02451 USA > > Tel: (781) 902-8265 > > Fax: (781) 902-8001 > > ------------------------------------------------------- > > Making Software Work Together TM > > > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Tue, 13 Apr 2004 10:27:53 -0400 (EDT) From: Polar Humenn To: "Bergersen, Rebecca" Cc: ckuo01@syr.edu, "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" , "Dave Stringer (E-mail)" , firewall-traversal-ftf@omg.org Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution to 6313 On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > I said that "delegation" was efficient and it is. > > You're asking why would you redistribute object references again. I > don't know where the "again" applies. You load your persistent object. The server already has the object reference for the persistent object. That's why it's a "persistent" object. > You create a transient POA. Its objects handle the BiDir protocol and > delegate the rest of the processing to the persistent object. You > distribute the transient object references to the server. There it is: "You distribute the tranient object ....". Now, why would I want to do that "again", since the server already has an object reference to the "persistent" object? > The persistent > object references are not distributed to the server. Since you have to > distribute object references to the server anyway, what difference does > it make if the references came from a transient POA or a persistent one? This seems, like a persistent object is merely a local orb issue. I assure you, it isn't. I've got systems out there that completely rely on the object reference they have as being persistent. > They still had to be communicated to the server. What am I missing? The fact that you don't have to "dstribute them again" everytime your system comes up or down, or you create or destroy a POA, etc. > My argument is simply that if you have persistent objects, using a > delegation model gives you the full BiDir Challenge/Response mechanism > and randomized BiDirIds and the problems of dealing with constants, etc. > is avoided. That's all I was trying to say. Your argument is one person's solution or work around that may not be desireable to every application designer/implementer. Still, back to the main point. There is NOTHING about RSA or any public key mechanism for that matter that prohibits its use for persistent object references. Cheers, -Polar > > --Rebecca > > > -----Original Message----- > > From: Polar Humenn [mailto:polar@adiron.com] > > Sent: Monday, April 12, 2004 5:01 PM > > To: Bergersen, Rebecca > > Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave > > Stringer (E-mail); firewall-traversal-ftf@omg.org > > Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution to 6313 > > > > > > > > All, I have to say to that is "huh??" > > > > I use a persistent POA and its persistent object references > > because I want > > to be able to contact the same object witout having to get new object > > references. > > > > Now, why would I want to create a transient POA and have to > > redistribute > > object references again? > > > > efficient? > > > > -Polar > > > > On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > > > > > A delegation model can be used when dealing with persistent > > POAs. It is > > > very efficient in most ORBs to delegate processing to > > another object. > > > Therefore, when a persistent POA is to be used for callback > > objects, a > > > transient POA can be created which delegates its processing to the > > > persistent POA. The transient POA participates in the full > > strong BiDir > > > Challenge/Response protocol, if necessary, then delegates everything > > > else to the persistent object. This model allows both > > strong and weak > > > BiDir to be used with persistent objects. > > > > > > --Rebecca > > > > > > > -----Original Message----- > > > > From: Polar Humenn [mailto:polar@adiron.com] > > > > Sent: Monday, April 12, 2004 2:42 PM > > > > To: Bergersen, Rebecca > > > > Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji > > (E-mail); Dave > > > > Stringer (E-mail); firewall-traversal-ftf@omg.org > > > > Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - > > resolution to 6313 > > > > > > > > > > > > > > > > This resolution is just wrong. It states: > > > > > > > > "Modify the text to indicate that random identifiers must be > > > > generated for > > > > transient objects, but that persistent objects must use an > > > > identifier that > > > > remains constant across sessions. In the strong > > identifier case, a > > > > different RSA Modulus and index is generated for each POA and > > > > is required > > > > for handling challenges. Since these numbers are not > > > > persistent across > > > > sessions, it is disallowed for POAs to have both a > > > > LifespanPolicy with a > > > > value of PERSISTENT and a BidirectionalExportPolicy with a > > > > strong BiDirId. > > > > That is, persistent POAs may only have a weak BiDirId type." > > > > > > > > > > > > So, what we have here in this resolution is the removal of the key > > > > functionality that allows Strong Identification for Persistent > > > > objects?!?!?! > > > > > > > > Are you kidding me? > > > > > > > > Persistent objects were pretty much the cause of the spoofing > > > > problem with > > > > BiDir in the first place! The fact that somebody had > > > > persitent objects > > > > behind a particular server and port means that YOU could say > > > > you served > > > > objects behind a particular server and port, and the server > > > > would start > > > > handing you requests. Same situation, only now, you can do it > > > > with just > > > > knowing the Weak BiDirId. > > > > > > > > Furthermore, there is nothing about RSA or public key > > mechanisms that > > > > prevents its use for persistent objects. The issue was about the > > > > specification stating that a new randomly generated > > identifier must be > > > > generated for each POA. Granted, it MAY be hard for the ORB > > > > to be able to > > > > know what RSA key it is going to generate for persitent > > objects and be > > > > able to redo that across shutting down of the POAs, ORB, > > > > etc., but it is > > > > certainly not impossible. > > > > > > > > -Polar > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > > > > > > > > > The second and final vote for the Firewall Traversal FTF > > > > has been posted at > > > > > > > > > ftp://ftp.omg.org/pub/firewall-traversal-ftf/Firewall_Traversa > > > l_FTF_Vote_2.htm. > > > > > > > > The resolutions are based on comments received from Tom, > > Jishnu, Dave, Joncheng, Polar and myself. > > > > The vote will open at 12:00 PM (EDT) Monday 12 April and > > close at 17:00 PM (EDT) Wednesday 14 April, since the final > > report has a hard deadline of Thursday, 15 April. > > > > > > > > Vote Early! > > > > > > > > Regards, > > > > Rebecca Bergersen > > > > PRINCIPAL ARCHITECT, MIDDLEWARE STANDARDS > > > > rebecca.bergersen@iona.com > > > > ------------------------------------------------------- > > > > IONA Technologies > > > > 200 West Street Waltham, MA 02451 USA > > > > Tel: (781) 902-8265 > > > > Fax: (781) 902-8001 > > > > ------------------------------------------------------- > > > > Making Software Work Together TM > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > Polar Humenn Adiron, LLC > > > mailto:polar@adiron.com 2-212 CST > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Tue, 13 Apr 2004 11:24:19 -0400 From: Joncheng Kuo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Polar Humenn CC: "Bergersen, Rebecca" , "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" , "Dave Stringer (E-mail)" , firewall-traversal-ftf@omg.org Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - resolution to 6313 X-Virus-Scanned: Symantec AntiVirus Scan Engine Polar Humenn wrote: There is NOTHING about RSA or any public key mechanism for that matter that prohibits its use for persistent object references. In other words, as long as a persistent BiDirId (and RSA key) can be used on a persistent POA with BidirectionalExportPolicy ALLOW, Issue 6313 can be resolved. On the other hand, we still need a way for the ORB to put a persistent BiDirId to such as POA. We can let the ORB to do it in its own way, or we can change the BidirectionalExportPolicy a bit to include such a BiDirId and RSA modulus. Besides, I found that there is no way for applications to decide whether a Weak or Strong BiDirId shall be used on a POA with BidirectionalExportPolicy ALLOW. I strongly believe that the BidirectionalExportPolicy and BidirectionalOfferPolicy, as they are stated in the spec, are inadequate for wrting portable applications. Many things are assumed by the ORB and applications have no control over them. Joncheng Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution to 6313 Date: Tue, 13 Apr 2004 14:43:03 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PLEASE VOTE - Firewall FTF Vote 2 - resolution to 6313 Thread-Index: AcQhZAXbbzBdd48jQU6M3/ccQec1tQAITyVw From: "Bergersen, Rebecca" To: "Polar Humenn" Cc: , "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" , "Dave Stringer (E-mail)" , , "Bergersen, Rebecca" X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i3DIjrna011541 Ah - I see. I was thinking that only the client loaded its persistent callback objects. It then communicated them to relevant servers. You have both client and server loading them. Okay. Now, forgive my lack of expertise in security protocols, but isn't the modulus or index that is sent to a server in the strong BiDir case something that is fixed only for the duration of client's session? How do you deal with the modulus and index that's associated with a persistent BiDirId? --Rebecca > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Tuesday, April 13, 2004 10:28 AM > To: Bergersen, Rebecca > Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave > Stringer (E-mail); firewall-traversal-ftf@omg.org > Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution to 6313 > > > On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > > > I said that "delegation" was efficient and it is. > > > > You're asking why would you redistribute object references again. I > > don't know where the "again" applies. You load your > persistent object. > > The server already has the object reference for the persistent object. > That's why it's a "persistent" object. > > > You create a transient POA. Its objects handle the BiDir > protocol and > > delegate the rest of the processing to the persistent object. You > > distribute the transient object references to the server. > > There it is: "You distribute the tranient object ....". > > Now, why would I want to do that "again", since the server > already has an > object reference to the "persistent" object? > > > The persistent > > object references are not distributed to the server. Since > you have to > > distribute object references to the server anyway, what > difference does > > it make if the references came from a transient POA or a > persistent one? > > This seems, like a persistent object is merely a local orb issue. > I assure you, it isn't. > > I've got systems out there that completely rely on the object > reference > they have as being persistent. > > > They still had to be communicated to the server. What am I missing? > > The fact that you don't have to "dstribute them again" everytime your > system comes up or down, or you create or destroy a POA, etc. > > > My argument is simply that if you have persistent objects, using a > > delegation model gives you the full BiDir > Challenge/Response mechanism > > and randomized BiDirIds and the problems of dealing with > constants, etc. > > is avoided. That's all I was trying to say. > > Your argument is one person's solution or work around that may not be > desireable to every application designer/implementer. > > Still, back to the main point. > > There is NOTHING about RSA or any public key mechanism for that matter > that prohibits its use for persistent object references. > > Cheers, > -Polar > > > > > > > --Rebecca > > > > > -----Original Message----- > > > From: Polar Humenn [mailto:polar@adiron.com] > > > Sent: Monday, April 12, 2004 5:01 PM > > > To: Bergersen, Rebecca > > > Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji > (E-mail); Dave > > > Stringer (E-mail); firewall-traversal-ftf@omg.org > > > Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - > resolution to 6313 > > > > > > > > > > > > All, I have to say to that is "huh??" > > > > > > I use a persistent POA and its persistent object references > > > because I want > > > to be able to contact the same object witout having to > get new object > > > references. > > > > > > Now, why would I want to create a transient POA and have to > > > redistribute > > > object references again? > > > > > > efficient? > > > > > > -Polar > > > > > > On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > > > > > > > A delegation model can be used when dealing with persistent > > > POAs. It is > > > > very efficient in most ORBs to delegate processing to > > > another object. > > > > Therefore, when a persistent POA is to be used for callback > > > objects, a > > > > transient POA can be created which delegates its > processing to the > > > > persistent POA. The transient POA participates in the full > > > strong BiDir > > > > Challenge/Response protocol, if necessary, then > delegates everything > > > > else to the persistent object. This model allows both > > > strong and weak > > > > BiDir to be used with persistent objects. > > > > > > > > --Rebecca > > > > > > > > > -----Original Message----- > > > > > From: Polar Humenn [mailto:polar@adiron.com] > > > > > Sent: Monday, April 12, 2004 2:42 PM > > > > > To: Bergersen, Rebecca > > > > > Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji > > > (E-mail); Dave > > > > > Stringer (E-mail); firewall-traversal-ftf@omg.org > > > > > Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - > > > resolution to 6313 > > > > > > > > > > > > > > > > > > > > This resolution is just wrong. It states: > > > > > > > > > > "Modify the text to indicate that random identifiers must be > > > > > generated for > > > > > transient objects, but that persistent objects must use an > > > > > identifier that > > > > > remains constant across sessions. In the strong > > > identifier case, a > > > > > different RSA Modulus and index is generated for each POA and > > > > > is required > > > > > for handling challenges. Since these numbers are not > > > > > persistent across > > > > > sessions, it is disallowed for POAs to have both a > > > > > LifespanPolicy with a > > > > > value of PERSISTENT and a BidirectionalExportPolicy with a > > > > > strong BiDirId. > > > > > That is, persistent POAs may only have a weak BiDirId type." > > > > > > > > > > > > > > > So, what we have here in this resolution is the > removal of the key > > > > > functionality that allows Strong Identification for Persistent > > > > > objects?!?!?! > > > > > > > > > > Are you kidding me? > > > > > > > > > > Persistent objects were pretty much the cause of the spoofing > > > > > problem with > > > > > BiDir in the first place! The fact that somebody had > > > > > persitent objects > > > > > behind a particular server and port means that YOU could say > > > > > you served > > > > > objects behind a particular server and port, and the server > > > > > would start > > > > > handing you requests. Same situation, only now, you can do it > > > > > with just > > > > > knowing the Weak BiDirId. > > > > > > > > > > Furthermore, there is nothing about RSA or public key > > > mechanisms that > > > > > prevents its use for persistent objects. The issue > was about the > > > > > specification stating that a new randomly generated > > > identifier must be > > > > > generated for each POA. Granted, it MAY be hard for the ORB > > > > > to be able to > > > > > know what RSA key it is going to generate for persitent > > > objects and be > > > > > able to redo that across shutting down of the POAs, ORB, > > > > > etc., but it is > > > > > certainly not impossible. > > > > > > > > > > -Polar > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > > > > > > > > > > > The second and final vote for the Firewall Traversal FTF > > > > > has been posted at > > > > > > > > > > > ftp://ftp.omg.org/pub/firewall-traversal-ftf/Firewall_Traversa > > > > l_FTF_Vote_2.htm. > > > > > > > > > > The resolutions are based on comments received from Tom, > > > Jishnu, Dave, Joncheng, Polar and myself. > > > > > The vote will open at 12:00 PM (EDT) Monday 12 April and > > > close at 17:00 PM (EDT) Wednesday 14 April, since the final > > > report has a hard deadline of Thursday, 15 April. > > > > > > > > > > Vote Early! > > > > > > > > > > Regards, > > > > > Rebecca Bergersen > > > > > PRINCIPAL ARCHITECT, MIDDLEWARE STANDARDS > > > > > rebecca.bergersen@iona.com > > > > > ------------------------------------------------------- > > > > > IONA Technologies > > > > > 200 West Street Waltham, MA 02451 USA > > > > > Tel: (781) 902-8265 > > > > > Fax: (781) 902-8001 > > > > > ------------------------------------------------------- > > > > > Making Software Work Together TM > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > Polar Humenn Adiron, LLC > > > > mailto:polar@adiron.com 2-212 CST > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > ------------------------------------------------------------------- > > > Polar Humenn Adiron, LLC > > > mailto:polar@adiron.com 2-212 CST > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com > Date: Tue, 13 Apr 2004 16:30:59 -0400 (EDT) From: Polar Humenn To: "Bergersen, Rebecca" Cc: ckuo01@syr.edu, "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" , "Dave Stringer (E-mail)" , firewall-traversal-ftf@omg.org Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution to 6313 On Tue, 13 Apr 2004, Bergersen, Rebecca wrote: > Ah - I see. I was thinking that only the client loaded its persistent callback objects. It then communicated them to relevant servers. You have both client and server loading them. Okay. > > Now, forgive my lack of expertise in security protocols, but isn't the > modulus or index that is sent to a server in the strong BiDir case > something that is fixed only for the duration of client's session? How > do you deal with the modulus and index that's associated with a > persistent BiDirId? It's a public key. Think of it as the same thing that basically resides within an X509 certificate. The "index" in which you talk about is merely the place in the bidir OFFER structure that the challange and response applies to. Since it seems the ORB doesn't have to challenge every strong offer, you have to know which one your talking about. -Polar > --Rebecca > > > -----Original Message----- > > From: Polar Humenn [mailto:polar@adiron.com] > > Sent: Tuesday, April 13, 2004 10:28 AM > > To: Bergersen, Rebecca > > Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave > > Stringer (E-mail); firewall-traversal-ftf@omg.org > > Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution to 6313 > > > > > > On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > > > > > I said that "delegation" was efficient and it is. > > > > > > You're asking why would you redistribute object references again. I > > > don't know where the "again" applies. You load your > > persistent object. > > > > The server already has the object reference for the persistent object. > > That's why it's a "persistent" object. > > > > > You create a transient POA. Its objects handle the BiDir > > protocol and > > > delegate the rest of the processing to the persistent object. You > > > distribute the transient object references to the server. > > > > There it is: "You distribute the tranient object ....". > > > > Now, why would I want to do that "again", since the server > > already has an > > object reference to the "persistent" object? > > > > > The persistent > > > object references are not distributed to the server. Since > > you have to > > > distribute object references to the server anyway, what > > difference does > > > it make if the references came from a transient POA or a > > persistent one? > > > > This seems, like a persistent object is merely a local orb issue. > > I assure you, it isn't. > > > > I've got systems out there that completely rely on the object > > reference > > they have as being persistent. > > > > > They still had to be communicated to the server. What am I missing? > > > > The fact that you don't have to "dstribute them again" everytime your > > system comes up or down, or you create or destroy a POA, etc. > > > > > My argument is simply that if you have persistent objects, using a > > > delegation model gives you the full BiDir > > Challenge/Response mechanism > > > and randomized BiDirIds and the problems of dealing with > > constants, etc. > > > is avoided. That's all I was trying to say. > > > > Your argument is one person's solution or work around that may not be > > desireable to every application designer/implementer. > > > > Still, back to the main point. > > > > There is NOTHING about RSA or any public key mechanism for that matter > > that prohibits its use for persistent object references. > > > > Cheers, > > -Polar > > > > > > > > > > > > --Rebecca > > > > > > > -----Original Message----- > > > > From: Polar Humenn [mailto:polar@adiron.com] > > > > Sent: Monday, April 12, 2004 5:01 PM > > > > To: Bergersen, Rebecca > > > > Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji > > (E-mail); Dave > > > > Stringer (E-mail); firewall-traversal-ftf@omg.org > > > > Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - > > resolution to 6313 > > > > > > > > > > > > > > > > All, I have to say to that is "huh??" > > > > > > > > I use a persistent POA and its persistent object references > > > > because I want > > > > to be able to contact the same object witout having to > > get new object > > > > references. > > > > > > > > Now, why would I want to create a transient POA and have to > > > > redistribute > > > > object references again? > > > > > > > > efficient? > > > > > > > > -Polar > > > > > > > > On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > > > > > > > > > A delegation model can be used when dealing with persistent > > > > POAs. It is > > > > > very efficient in most ORBs to delegate processing to > > > > another object. > > > > > Therefore, when a persistent POA is to be used for callback > > > > objects, a > > > > > transient POA can be created which delegates its > > processing to the > > > > > persistent POA. The transient POA participates in the full > > > > strong BiDir > > > > > Challenge/Response protocol, if necessary, then > > delegates everything > > > > > else to the persistent object. This model allows both > > > > strong and weak > > > > > BiDir to be used with persistent objects. > > > > > > > > > > --Rebecca > > > > > > > > > > > -----Original Message----- > > > > > > From: Polar Humenn [mailto:polar@adiron.com] > > > > > > Sent: Monday, April 12, 2004 2:42 PM > > > > > > To: Bergersen, Rebecca > > > > > > Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji > > > > (E-mail); Dave > > > > > > Stringer (E-mail); firewall-traversal-ftf@omg.org > > > > > > Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - > > > > resolution to 6313 > > > > > > > > > > > > > > > > > > > > > > > > This resolution is just wrong. It states: > > > > > > > > > > > > "Modify the text to indicate that random identifiers must be > > > > > > generated for > > > > > > transient objects, but that persistent objects must use an > > > > > > identifier that > > > > > > remains constant across sessions. In the strong > > > > identifier case, a > > > > > > different RSA Modulus and index is generated for each POA and > > > > > > is required > > > > > > for handling challenges. Since these numbers are not > > > > > > persistent across > > > > > > sessions, it is disallowed for POAs to have both a > > > > > > LifespanPolicy with a > > > > > > value of PERSISTENT and a BidirectionalExportPolicy with a > > > > > > strong BiDirId. > > > > > > That is, persistent POAs may only have a weak BiDirId type." > > > > > > > > > > > > > > > > > > So, what we have here in this resolution is the > > removal of the key > > > > > > functionality that allows Strong Identification for Persistent > > > > > > objects?!?!?! > > > > > > > > > > > > Are you kidding me? > > > > > > > > > > > > Persistent objects were pretty much the cause of the spoofing > > > > > > problem with > > > > > > BiDir in the first place! The fact that somebody had > > > > > > persitent objects > > > > > > behind a particular server and port means that YOU could say > > > > > > you served > > > > > > objects behind a particular server and port, and the server > > > > > > would start > > > > > > handing you requests. Same situation, only now, you can do it > > > > > > with just > > > > > > knowing the Weak BiDirId. > > > > > > > > > > > > Furthermore, there is nothing about RSA or public key > > > > mechanisms that > > > > > > prevents its use for persistent objects. The issue > > was about the > > > > > > specification stating that a new randomly generated > > > > identifier must be > > > > > > generated for each POA. Granted, it MAY be hard for the ORB > > > > > > to be able to > > > > > > know what RSA key it is going to generate for persitent > > > > objects and be > > > > > > able to redo that across shutting down of the POAs, ORB, > > > > > > etc., but it is > > > > > > certainly not impossible. > > > > > > > > > > > > -Polar > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > > > > > > > > > > > > > The second and final vote for the Firewall Traversal FTF > > > > > > has been posted at > > > > > > > > > > > > > ftp://ftp.omg.org/pub/firewall-traversal-ftf/Firewall_Traversa > > > > > l_FTF_Vote_2.htm. > > > > > > > > > > > > The resolutions are based on comments received from Tom, > > > > Jishnu, Dave, Joncheng, Polar and myself. > > > > > > The vote will open at 12:00 PM (EDT) Monday 12 April and > > > > close at 17:00 PM (EDT) Wednesday 14 April, since the final > > > > report has a hard deadline of Thursday, 15 April. > > > > > > > > > > > > Vote Early! > > > > > > > > > > > > Regards, > > > > > > Rebecca Bergersen > > > > > > PRINCIPAL ARCHITECT, MIDDLEWARE STANDARDS > > > > > > rebecca.bergersen@iona.com > > > > > > ------------------------------------------------------- > > > > > > IONA Technologies > > > > > > 200 West Street Waltham, MA 02451 USA > > > > > > Tel: (781) 902-8265 > > > > > > Fax: (781) 902-8001 > > > > > > ------------------------------------------------------- > > > > > > Making Software Work Together TM > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > Polar Humenn Adiron, LLC > > > > > mailto:polar@adiron.com 2-212 CST > > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > Polar Humenn Adiron, LLC > > > > mailto:polar@adiron.com 2-212 CST > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution to 6313 Date: Tue, 13 Apr 2004 17:06:42 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PLEASE VOTE - Firewall FTF Vote 2 - resolution to 6313 Thread-Index: AcQhlr+xmKjkYzeZQTiFdBQzlB6OYgAA9uBg From: "Bergersen, Rebecca" To: "Polar Humenn" Cc: , "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" , "Dave Stringer (E-mail)" , , "Bergersen, Rebecca" X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i3DL9Una013603 All right, so in the strong case there are really two critical pieces of information - the BiDirId and the modulus for that ID. Certainly the BiDirId has to be a constant for the persistent case. I guess you're saying that the modulus for that ID is constant also? And that the transmission of these constants back and forth in Offers and challenges and whatever doesn't cause the security issue you were concerned with regarding constants? --Rebecca > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Tuesday, April 13, 2004 4:31 PM > To: Bergersen, Rebecca > Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave > Stringer (E-mail); firewall-traversal-ftf@omg.org > Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution to 6313 > > > On Tue, 13 Apr 2004, Bergersen, Rebecca wrote: > > > Ah - I see. I was thinking that only the client loaded its > persistent callback objects. It then communicated them to > relevant servers. You have both client and server loading > them. Okay. > > > > Now, forgive my lack of expertise in security protocols, > but isn't the > > modulus or index that is sent to a server in the strong BiDir case > > something that is fixed only for the duration of client's > session? How > > do you deal with the modulus and index that's associated with a > > persistent BiDirId? > > It's a public key. Think of it as the same thing that > basically resides > within an X509 certificate. > > The "index" in which you talk about is merely the place in > the bidir OFFER > structure that the challange and response applies to. Since > it seems the > ORB doesn't have to challenge every strong offer, you have to > know which > one your talking about. > > -Polar > > > > > --Rebecca > > > > > -----Original Message----- > > > From: Polar Humenn [mailto:polar@adiron.com] > > > Sent: Tuesday, April 13, 2004 10:28 AM > > > To: Bergersen, Rebecca > > > Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji > (E-mail); Dave > > > Stringer (E-mail); firewall-traversal-ftf@omg.org > > > Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - > resolution to 6313 > > > > > > > > > On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > > > > > > > I said that "delegation" was efficient and it is. > > > > > > > > You're asking why would you redistribute object > references again. I > > > > don't know where the "again" applies. You load your > > > persistent object. > > > > > > The server already has the object reference for the > persistent object. > > > That's why it's a "persistent" object. > > > > > > > You create a transient POA. Its objects handle the BiDir > > > protocol and > > > > delegate the rest of the processing to the persistent > object. You > > > > distribute the transient object references to the server. > > > > > > There it is: "You distribute the tranient object ....". > > > > > > Now, why would I want to do that "again", since the server > > > already has an > > > object reference to the "persistent" object? > > > > > > > The persistent > > > > object references are not distributed to the server. Since > > > you have to > > > > distribute object references to the server anyway, what > > > difference does > > > > it make if the references came from a transient POA or a > > > persistent one? > > > > > > This seems, like a persistent object is merely a local orb issue. > > > I assure you, it isn't. > > > > > > I've got systems out there that completely rely on the object > > > reference > > > they have as being persistent. > > > > > > > They still had to be communicated to the server. What > am I missing? > > > > > > The fact that you don't have to "dstribute them again" > everytime your > > > system comes up or down, or you create or destroy a POA, etc. > > > > > > > My argument is simply that if you have persistent > objects, using a > > > > delegation model gives you the full BiDir > > > Challenge/Response mechanism > > > > and randomized BiDirIds and the problems of dealing with > > > constants, etc. > > > > is avoided. That's all I was trying to say. > > > > > > Your argument is one person's solution or work around > that may not be > > > desireable to every application designer/implementer. > > > > > > Still, back to the main point. > > > > > > There is NOTHING about RSA or any public key mechanism > for that matter > > > that prohibits its use for persistent object references. > > > > > > Cheers, > > > -Polar > > > > > > > > > > > > > > > > > --Rebecca > > > > > > > > > -----Original Message----- > > > > > From: Polar Humenn [mailto:polar@adiron.com] > > > > > Sent: Monday, April 12, 2004 5:01 PM > > > > > To: Bergersen, Rebecca > > > > > Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji > > > (E-mail); Dave > > > > > Stringer (E-mail); firewall-traversal-ftf@omg.org > > > > > Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - > > > resolution to 6313 > > > > > > > > > > > > > > > > > > > > All, I have to say to that is "huh??" > > > > > > > > > > I use a persistent POA and its persistent object references > > > > > because I want > > > > > to be able to contact the same object witout having to > > > get new object > > > > > references. > > > > > > > > > > Now, why would I want to create a transient POA and have to > > > > > redistribute > > > > > object references again? > > > > > > > > > > efficient? > > > > > > > > > > -Polar > > > > > > > > > > On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > > > > > > > > > > > A delegation model can be used when dealing with persistent > > > > > POAs. It is > > > > > > very efficient in most ORBs to delegate processing to > > > > > another object. > > > > > > Therefore, when a persistent POA is to be used for callback > > > > > objects, a > > > > > > transient POA can be created which delegates its > > > processing to the > > > > > > persistent POA. The transient POA participates in the full > > > > > strong BiDir > > > > > > Challenge/Response protocol, if necessary, then > > > delegates everything > > > > > > else to the persistent object. This model allows both > > > > > strong and weak > > > > > > BiDir to be used with persistent objects. > > > > > > > > > > > > --Rebecca > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Polar Humenn [mailto:polar@adiron.com] > > > > > > > Sent: Monday, April 12, 2004 2:42 PM > > > > > > > To: Bergersen, Rebecca > > > > > > > Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji > > > > > (E-mail); Dave > > > > > > > Stringer (E-mail); firewall-traversal-ftf@omg.org > > > > > > > Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - > > > > > resolution to 6313 > > > > > > > > > > > > > > > > > > > > > > > > > > > > This resolution is just wrong. It states: > > > > > > > > > > > > > > "Modify the text to indicate that random > identifiers must be > > > > > > > generated for > > > > > > > transient objects, but that persistent objects must use an > > > > > > > identifier that > > > > > > > remains constant across sessions. In the strong > > > > > identifier case, a > > > > > > > different RSA Modulus and index is generated for > each POA and > > > > > > > is required > > > > > > > for handling challenges. Since these numbers are not > > > > > > > persistent across > > > > > > > sessions, it is disallowed for POAs to have both a > > > > > > > LifespanPolicy with a > > > > > > > value of PERSISTENT and a BidirectionalExportPolicy with a > > > > > > > strong BiDirId. > > > > > > > That is, persistent POAs may only have a weak > BiDirId type." > > > > > > > > > > > > > > > > > > > > > So, what we have here in this resolution is the > > > removal of the key > > > > > > > functionality that allows Strong Identification > for Persistent > > > > > > > objects?!?!?! > > > > > > > > > > > > > > Are you kidding me? > > > > > > > > > > > > > > Persistent objects were pretty much the cause of > the spoofing > > > > > > > problem with > > > > > > > BiDir in the first place! The fact that somebody had > > > > > > > persitent objects > > > > > > > behind a particular server and port means that > YOU could say > > > > > > > you served > > > > > > > objects behind a particular server and port, and > the server > > > > > > > would start > > > > > > > handing you requests. Same situation, only now, > you can do it > > > > > > > with just > > > > > > > knowing the Weak BiDirId. > > > > > > > > > > > > > > Furthermore, there is nothing about RSA or public key > > > > > mechanisms that > > > > > > > prevents its use for persistent objects. The issue > > > was about the > > > > > > > specification stating that a new randomly generated > > > > > identifier must be > > > > > > > generated for each POA. Granted, it MAY be hard > for the ORB > > > > > > > to be able to > > > > > > > know what RSA key it is going to generate for persitent > > > > > objects and be > > > > > > > able to redo that across shutting down of the POAs, ORB, > > > > > > > etc., but it is > > > > > > > certainly not impossible. > > > > > > > > > > > > > > -Polar > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > > > > > > > > > > > > > > > The second and final vote for the Firewall Traversal FTF > > > > > > > has been posted at > > > > > > > > > > > > > > > ftp://ftp.omg.org/pub/firewall-traversal-ftf/Firewall_Traversa > > > > > l_FTF_Vote_2.htm. > > > > > > > > > > > > The resolutions are based on comments received from Tom, > > > > Jishnu, Dave, Joncheng, Polar and myself. > > > > > > The vote will open at 12:00 PM (EDT) Monday 12 April and > > > > close at 17:00 PM (EDT) Wednesday 14 April, since the final > > > > report has a hard deadline of Thursday, 15 April. > > > > > > > > > > > > Vote Early! > > > > > > > > > > > > Regards, > > > > > > Rebecca Bergersen > > > > > > PRINCIPAL ARCHITECT, MIDDLEWARE STANDARDS > > > > > > rebecca.bergersen@iona.com > > > > > > ------------------------------------------------------- > > > > > > IONA Technologies > > > > > > 200 West Street Waltham, MA 02451 USA > > > > > > Tel: (781) 902-8265 > > > > > > Fax: (781) 902-8001 > > > > > > ------------------------------------------------------- > > > > > > Making Software Work Together TM > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > Polar Humenn Adiron, LLC > > > > > mailto:polar@adiron.com 2-212 CST > > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > Polar Humenn Adiron, LLC > > > > mailto:polar@adiron.com 2-212 CST > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution to 6313 Date: Tue, 13 Apr 2004 19:16:15 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PLEASE VOTE - Firewall FTF Vote 2 - resolution to 6313 Thread-Index: AcQha3MxpmjP7KHIQ56AKOUreYFHNAAQfZNw From: "Bergersen, Rebecca" To: "Joncheng Kuo" , "Polar Humenn" Cc: "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" , "Dave Stringer (E-mail)" , , "Bergersen, Rebecca" X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i3DNJ5na014543 You could add the constant BiDirId and modulus to the export policy. If you're doing that, why not add a flag that indicates whether a strong or weak BiDirId is to be generated (when not specified in the two new fields)? --Rebecca > -----Original Message----- > From: Joncheng Kuo [mailto:ckuo01@syr.edu] > Sent: Tuesday, April 13, 2004 11:24 AM > To: Polar Humenn > Cc: Bergersen, Rebecca; Tom Rutt (E-mail); Jishnu Mukerji > (E-mail); Dave > Stringer (E-mail); firewall-traversal-ftf@omg.org > Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - resolution to 6313 > > > Polar Humenn wrote: > > >There is NOTHING about RSA or any public key mechanism for > that matter > >that prohibits its use for persistent object references. > > > In other words, as long as a persistent BiDirId (and RSA key) can be > used on a persistent POA with BidirectionalExportPolicy ALLOW, Issue > 6313 can be resolved. > > On the other hand, we still need a way for the ORB to put a > persistent > BiDirId to such as POA. We can let the ORB to do it in its > own way, or > we can change the BidirectionalExportPolicy a bit to include such a > BiDirId and RSA modulus. > > Besides, I found that there is no way for applications to > decide whether > a Weak or Strong BiDirId shall be used on a POA with > BidirectionalExportPolicy ALLOW. > > I strongly believe that the BidirectionalExportPolicy and > BidirectionalOfferPolicy, as they are stated in the spec, are > inadequate > for wrting portable applications. Many things are assumed by > the ORB and > applications have no control over them. > > Joncheng > > > > Date: Tue, 13 Apr 2004 21:59:29 -0400 From: Joncheng Kuo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: "Bergersen, Rebecca" CC: Polar Humenn , "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" , "Dave Stringer (E-mail)" , firewall-traversal-ftf@omg.org Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - resolution to 6313 X-Virus-Scanned: Symantec AntiVirus Scan Engine Bergersen, Rebecca wrote: You could add the constant BiDirId and modulus to the export policy. If you're doing that, why not add a flag that indicates whether a strong or weak BiDirId is to be generated (when not specified in the two new fields)? How about the following? typedef unsigned short BidirectionalExportPolicyValue; const BidirectionalExportPolicyValue ALLOW_WEAK = 0; const BidirectionalExportPolicyValue ALLOW_STRONG = 1; const BidirectionalExportPolicyValue DENY = 2; local interface BidirectionalExportPolicy : CORBA::Policy { readonly attribute BidirectionalExportPolicyValue value; readonly attribute BiDirId id; readonly attribute BiDirModulus modulus; }; .A BidirectionalExportPolicy can be applied to a POA on a client ORB using the PortableServer::POA::create_POA operation. If the BidirectionalExportPolicy value of the POA is ALLOW_WEAK, the client ORB is allowed to send to the server, in the BI_DIR_GIOP_OFFER IOP::ServiceContext of union type BiDirWeak, the BiDirId associated with the objects in that POA. In addition, when IORs are created for the objects in that POA, the BiDirId for that POA shall be placed in the TAG_BI_DIR_GIOP component of those IORs. In such case, if the id attribute of the BidirectionalExportPolicy is not null, this id will be used as the BiDirId of the POA. Otherwise, the ORB shall generate a BiDirId for the POA." "If the BidirectionalExportPolicy value of the POA is ALLOW_STRONG, it is the same as ALLOW_WEAK except that the client ORB shall use the union type BiDirStrong instead of BiDirWeak when the client ORB sends the BiDirId of the POA in the BI_DIR_GIOP_OFFER IOP::ServiceContext. In addition, if both the id and modulus attributes of the BidirectionalExportPolicy are not null, they will be used as the BiDirId and RSA modulus of the POA, respectively." I would also like to replace the last sentence of this paragraph with the following: "If the BidirectionalExportPolicy value of the POA is DENY, there is no BiDirId associated with the POA.. Joncheng --Rebecca -----Original Message----- From: Joncheng Kuo [mailto:ckuo01@syr.edu] Sent: Tuesday, April 13, 2004 11:24 AM To: Polar Humenn Cc: Bergersen, Rebecca; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave Stringer (E-mail); firewall-traversal-ftf@omg.org Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - resolution to 6313 Polar Humenn wrote: There is NOTHING about RSA or any public key mechanism for that matter that prohibits its use for persistent object references. In other words, as long as a persistent BiDirId (and RSA key) can be used on a persistent POA with BidirectionalExportPolicy ALLOW, Issue 6313 can be resolved. On the other hand, we still need a way for the ORB to put a persistent BiDirId to such as POA. We can let the ORB to do it in its own way, or we can change the BidirectionalExportPolicy a bit to include such a BiDirId and RSA modulus. Besides, I found that there is no way for applications to decide whether a Weak or Strong BiDirId shall be used on a POA with BidirectionalExportPolicy ALLOW. I strongly believe that the BidirectionalExportPolicy and BidirectionalOfferPolicy, as they are stated in the spec, are inadequate for wrting portable applications. Many things are assumed by the ORB and applications have no control over them. Joncheng Date: Tue, 13 Apr 2004 22:05:25 -0400 (EDT) From: Polar Humenn To: "Bergersen, Rebecca" Cc: ckuo01@syr.edu, "Tom Rutt (E-mail)" , "Jishnu Mukerji (E-mail)" , "Dave Stringer (E-mail)" , firewall-traversal-ftf@omg.org Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution to 6313 On Tue, 13 Apr 2004, Bergersen, Rebecca wrote: > All right, so in the strong case there are really two critical pieces of > information - the BiDirId and the modulus for that ID. Certainly the > BiDirId has to be a constant for the persistent case. I guess you're > saying that the modulus for that ID is constant also? Yep. > And that the transmission of these constants back and forth in Offers > and challenges and whatever doesn't cause the security issue you were > concerned with regarding constants? I was concerned about forcing the ORB to generate a new random number for a BiDirId for every call to create_POA, which didn't jive for Persistent Objects. Where you got the no strong offers on persistent POAs completely baffled me. -Polar > > --Rebecca > > > -----Original Message----- > > From: Polar Humenn [mailto:polar@adiron.com] > > Sent: Tuesday, April 13, 2004 4:31 PM > > To: Bergersen, Rebecca > > Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji (E-mail); Dave > > Stringer (E-mail); firewall-traversal-ftf@omg.org > > Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - resolution to 6313 > > > > > > On Tue, 13 Apr 2004, Bergersen, Rebecca wrote: > > > > > Ah - I see. I was thinking that only the client loaded its > > persistent callback objects. It then communicated them to > > relevant servers. You have both client and server loading > > them. Okay. > > > > > > Now, forgive my lack of expertise in security protocols, > > but isn't the > > > modulus or index that is sent to a server in the strong BiDir case > > > something that is fixed only for the duration of client's > > session? How > > > do you deal with the modulus and index that's associated with a > > > persistent BiDirId? > > > > It's a public key. Think of it as the same thing that > > basically resides > > within an X509 certificate. > > > > The "index" in which you talk about is merely the place in > > the bidir OFFER > > structure that the challange and response applies to. Since > > it seems the > > ORB doesn't have to challenge every strong offer, you have to > > know which > > one your talking about. > > > > -Polar > > > > > > > > > --Rebecca > > > > > > > -----Original Message----- > > > > From: Polar Humenn [mailto:polar@adiron.com] > > > > Sent: Tuesday, April 13, 2004 10:28 AM > > > > To: Bergersen, Rebecca > > > > Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji > > (E-mail); Dave > > > > Stringer (E-mail); firewall-traversal-ftf@omg.org > > > > Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - > > resolution to 6313 > > > > > > > > > > > > On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > > > > > > > > > I said that "delegation" was efficient and it is. > > > > > > > > > > You're asking why would you redistribute object > > references again. I > > > > > don't know where the "again" applies. You load your > > > > persistent object. > > > > > > > > The server already has the object reference for the > > persistent object. > > > > That's why it's a "persistent" object. > > > > > > > > > You create a transient POA. Its objects handle the BiDir > > > > protocol and > > > > > delegate the rest of the processing to the persistent > > object. You > > > > > distribute the transient object references to the server. > > > > > > > > There it is: "You distribute the tranient object ....". > > > > > > > > Now, why would I want to do that "again", since the server > > > > already has an > > > > object reference to the "persistent" object? > > > > > > > > > The persistent > > > > > object references are not distributed to the server. Since > > > > you have to > > > > > distribute object references to the server anyway, what > > > > difference does > > > > > it make if the references came from a transient POA or a > > > > persistent one? > > > > > > > > This seems, like a persistent object is merely a local orb issue. > > > > I assure you, it isn't. > > > > > > > > I've got systems out there that completely rely on the object > > > > reference > > > > they have as being persistent. > > > > > > > > > They still had to be communicated to the server. What > > am I missing? > > > > > > > > The fact that you don't have to "dstribute them again" > > everytime your > > > > system comes up or down, or you create or destroy a POA, etc. > > > > > > > > > My argument is simply that if you have persistent > > objects, using a > > > > > delegation model gives you the full BiDir > > > > Challenge/Response mechanism > > > > > and randomized BiDirIds and the problems of dealing with > > > > constants, etc. > > > > > is avoided. That's all I was trying to say. > > > > > > > > Your argument is one person's solution or work around > > that may not be > > > > desireable to every application designer/implementer. > > > > > > > > Still, back to the main point. > > > > > > > > There is NOTHING about RSA or any public key mechanism > > for that matter > > > > that prohibits its use for persistent object references. > > > > > > > > Cheers, > > > > -Polar > > > > > > > > > > > > > > > > > > > > > > --Rebecca > > > > > > > > > > > -----Original Message----- > > > > > > From: Polar Humenn [mailto:polar@adiron.com] > > > > > > Sent: Monday, April 12, 2004 5:01 PM > > > > > > To: Bergersen, Rebecca > > > > > > Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji > > > > (E-mail); Dave > > > > > > Stringer (E-mail); firewall-traversal-ftf@omg.org > > > > > > Subject: RE: PLEASE VOTE - Firewall FTF Vote 2 - > > > > resolution to 6313 > > > > > > > > > > > > > > > > > > > > > > > > All, I have to say to that is "huh??" > > > > > > > > > > > > I use a persistent POA and its persistent object references > > > > > > because I want > > > > > > to be able to contact the same object witout having to > > > > get new object > > > > > > references. > > > > > > > > > > > > Now, why would I want to create a transient POA and have to > > > > > > redistribute > > > > > > object references again? > > > > > > > > > > > > efficient? > > > > > > > > > > > > -Polar > > > > > > > > > > > > On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > > > > > > > > > > > > > A delegation model can be used when dealing with persistent > > > > > > POAs. It is > > > > > > > very efficient in most ORBs to delegate processing to > > > > > > another object. > > > > > > > Therefore, when a persistent POA is to be used for callback > > > > > > objects, a > > > > > > > transient POA can be created which delegates its > > > > processing to the > > > > > > > persistent POA. The transient POA participates in the full > > > > > > strong BiDir > > > > > > > Challenge/Response protocol, if necessary, then > > > > delegates everything > > > > > > > else to the persistent object. This model allows both > > > > > > strong and weak > > > > > > > BiDir to be used with persistent objects. > > > > > > > > > > > > > > --Rebecca > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Polar Humenn [mailto:polar@adiron.com] > > > > > > > > Sent: Monday, April 12, 2004 2:42 PM > > > > > > > > To: Bergersen, Rebecca > > > > > > > > Cc: ckuo01@syr.edu; Tom Rutt (E-mail); Jishnu Mukerji > > > > > > (E-mail); Dave > > > > > > > > Stringer (E-mail); firewall-traversal-ftf@omg.org > > > > > > > > Subject: Re: PLEASE VOTE - Firewall FTF Vote 2 - > > > > > > resolution to 6313 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This resolution is just wrong. It states: > > > > > > > > > > > > > > > > "Modify the text to indicate that random > > identifiers must be > > > > > > > > generated for > > > > > > > > transient objects, but that persistent objects must use an > > > > > > > > identifier that > > > > > > > > remains constant across sessions. In the strong > > > > > > identifier case, a > > > > > > > > different RSA Modulus and index is generated for > > each POA and > > > > > > > > is required > > > > > > > > for handling challenges. Since these numbers are not > > > > > > > > persistent across > > > > > > > > sessions, it is disallowed for POAs to have both a > > > > > > > > LifespanPolicy with a > > > > > > > > value of PERSISTENT and a BidirectionalExportPolicy with a > > > > > > > > strong BiDirId. > > > > > > > > That is, persistent POAs may only have a weak > > BiDirId type." > > > > > > > > > > > > > > > > > > > > > > > > So, what we have here in this resolution is the > > > > removal of the key > > > > > > > > functionality that allows Strong Identification > > for Persistent > > > > > > > > objects?!?!?! > > > > > > > > > > > > > > > > Are you kidding me? > > > > > > > > > > > > > > > > Persistent objects were pretty much the cause of > > the spoofing > > > > > > > > problem with > > > > > > > > BiDir in the first place! The fact that somebody had > > > > > > > > persitent objects > > > > > > > > behind a particular server and port means that > > YOU could say > > > > > > > > you served > > > > > > > > objects behind a particular server and port, and > > the server > > > > > > > > would start > > > > > > > > handing you requests. Same situation, only now, > > you can do it > > > > > > > > with just > > > > > > > > knowing the Weak BiDirId. > > > > > > > > > > > > > > > > Furthermore, there is nothing about RSA or public key > > > > > > mechanisms that > > > > > > > > prevents its use for persistent objects. The issue > > > > was about the > > > > > > > > specification stating that a new randomly generated > > > > > > identifier must be > > > > > > > > generated for each POA. Granted, it MAY be hard > > for the ORB > > > > > > > > to be able to > > > > > > > > know what RSA key it is going to generate for persitent > > > > > > objects and be > > > > > > > > able to redo that across shutting down of the POAs, ORB, > > > > > > > > etc., but it is > > > > > > > > certainly not impossible. > > > > > > > > > > > > > > > > -Polar > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, 12 Apr 2004, Bergersen, Rebecca wrote: > > > > > > > > > > > > > > > > > The second and final vote for the Firewall Traversal FTF > > > > > > > > has been posted at > > > > > > > > > > > > > > > > > > ftp://ftp.omg.org/pub/firewall-traversal-ftf/Firewall_Traversa > > > > > > l_FTF_Vote_2.htm. > > > > > > > > > > > > > > The resolutions are based on comments received from Tom, > > > > > Jishnu, Dave, Joncheng, Polar and myself. > > > > > > > The vote will open at 12:00 PM (EDT) Monday 12 April and > > > > > close at 17:00 PM (EDT) Wednesday 14 April, since the final > > > > > report has a hard deadline of Thursday, 15 April. > > > > > > > > > > > > > > Vote Early! > > > > > > > > > > > > > > Regards, > > > > > > > Rebecca Bergersen > > > > > > > PRINCIPAL ARCHITECT, MIDDLEWARE STANDARDS > > > > > > > rebecca.bergersen@iona.com > > > > > > > ------------------------------------------------------- > > > > > > > IONA Technologies > > > > > > > 200 West Street Waltham, MA 02451 USA > > > > > > > Tel: (781) 902-8265 > > > > > > > Fax: (781) 902-8001 > > > > > > > ------------------------------------------------------- > > > > > > > Making Software Work Together TM > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > > Polar Humenn Adiron, LLC > > > > > > mailto:polar@adiron.com 2-212 CST > > > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > Polar Humenn Adiron, LLC > > > > > mailto:polar@adiron.com 2-212 CST > > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > Polar Humenn Adiron, LLC > > > mailto:polar@adiron.com 2-212 CST > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com