Issue 7308: Firewall Issue: Response to failed BiDir challenge is unclear (firewall-traversal-ftf) Source: (Ms. Rebecca Bergersen, becky(at)bergersen.org) Nature: Uncategorized Issue Severity: Summary: PROBLEM: The actions that result from the failure of a BiDir challenge are unclear. RECOMMENDATION: The client has proven itself untrustworthy. A BI_DIR_GIOP_RESPONSE containing a STRONG_FAILED result is returned to the client and all bi-directional connections to the client are closed. Resolution: Revised Text: Actions taken: May 6, 2004: received issue Discussion: End of Annotations:===== ubject: Firewall Issue: Response to failed BiDir challenge is unclear Date: Thu, 6 May 2004 15:58:42 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall Issue: Response to failed BiDir challenge is unclear Thread-Index: AcQzpJ9lWrGKEICuSNqgwzt94jVqZA== From: "Bergersen, Rebecca" To: , Cc: "Bergersen, Rebecca" PROBLEM: The actions that result from the failure of a BiDir challenge are unclear. RECOMMENDATION: The client has proven itself untrustworthy. A BI_DIR_GIOP_RESPONSE containing a STRONG_FAILED result is returned to the client and all bi-directional connections to the client are closed. Respectfully, 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 Date: Thu, 6 May 2004 17:09:05 -0400 (EDT) From: Polar Humenn To: "Bergersen, Rebecca" Cc: issues@omg.org, firewall-traversal-ftf@omg.org Subject: Re: Firewall Issue: Response to failed BiDir challenge is unclear On Thu, 6 May 2004, Bergersen, Rebecca wrote: > PROBLEM: > The actions that result from the failure of a BiDir challenge are unclear. > > RECOMMENDATION: > The client has proven itself untrustworthy. A BI_DIR_GIOP_RESPONSE > containing a STRONG_FAILED result is returned to the client and all > bi-directional connections to the client are closed. If the client has *proven* itself untrustworthy, why bother sending it back anything at all? You might end up sending a GIOP Reply to this untrustworthy client. Why not just drop this *untrustworthy* connection? -Polar > Respectfully, > 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: Thu, 06 May 2004 19:17:01 -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: Brian_Niebuhr@NAI.com, firewall-traversal-ftf@omg.org Subject: Re: Firewall Issue: Response to failed BiDir challenge is unclear X-Virus-Scanned: Symantec AntiVirus Scan Engine Bergersen, Rebecca wrote: PROBLEM: The actions that result from the failure of a BiDir challenge are unclear. RECOMMENDATION: The client has proven itself untrustworthy. A BI_DIR_GIOP_RESPONSE containing a STRONG_FAILED result is returned to the client and all bi-directional connections to the client are closed. First of all, how can you close all other bi-directional connections to the same client due to a STRONG_FAILED in one connection? Secondly, there are reasons for STRONG_FAILED other than a malicious client. For example, one of the security keys used for challenge/response could expire. Lastly, your recommendation opens a door for future denial-of-service attack. Consider an application server that has an ORB shared by many client applications. If a client application is allowed to specify its own BiDirId and response for challenge (not allowed in the current spec), any of these client applications can bring down *all* bi-directional connections by giving a bad response. Joncheng Respectfully, 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 Subject: RE: Firewall Issue: Response to failed BiDir challenge is unclear Date: Fri, 7 May 2004 11:15:26 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall Issue: Response to failed BiDir challenge is unclear Thread-Index: AcQzwDtMRSk6YW9+Rl6YpXZqBoIOmAAhVhPA From: "Bergersen, Rebecca" To: "Joncheng Kuo" Cc: , My understanding is that the challenge and consequent inference of trustworthiness isn't so much to the connection as to the client itself. If a challenge fails, it is the client that is deemed untrustworthy. That would imply that all (BiDir) connections to that client should be closed. --Rebecca -----Original Message----- From: Joncheng Kuo [mailto:ckuo01@syr.edu] Sent: Thursday, May 06, 2004 7:17 PM To: Bergersen, Rebecca Cc: Brian_Niebuhr@NAI.com; firewall-traversal-ftf@omg.org Subject: Re: Firewall Issue: Response to failed BiDir challenge is unclear Bergersen, Rebecca wrote: PROBLEM: The actions that result from the failure of a BiDir challenge are unclear. RECOMMENDATION: The client has proven itself untrustworthy. A BI_DIR_GIOP_RESPONSE containing a STRONG_FAILED result is returned to the client and all bi-directional connections to the client are closed. First of all, how can you close all other bi-directional connections to the same client due to a STRONG_FAILED in one connection? Secondly, there are reasons for STRONG_FAILED other than a malicious client. For example, one of the security keys used for challenge/response could expire. Lastly, your recommendation opens a door for future denial-of-service attack. Consider an application server that has an ORB shared by many client applications. If a client application is allowed to specify its own BiDirId and response for challenge (not allowed in the current spec), any of these client applications can bring down *all* bi-directional connections by giving a bad response. Joncheng Respectfully, 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 Subject: RE: Firewall Issue: Response to failed BiDir challenge is unclear Date: Fri, 7 May 2004 11:26:07 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall Issue: Response to failed BiDir challenge is unclear Thread-Index: AcQzwDtMRSk6YW9+Rl6YpXZqBoIOmAAhh3Ag From: "Bergersen, Rebecca" To: "Joncheng Kuo" Cc: , I didn't read your last paragraph completely before sending my last response. You say "If a client application is allowed to specify its own BiDirId and response for challenge (not allowed in the current spec), any of these client applications can bring down *all* bi-directional connections by giving a bad response." My reading of the spec is that the client *does* generate its own BiDirId. It's the POA on the client (connection Initiator) side that generates and sets the BiDirId for its servants. And I'm saying that the connections to the offending client should be shut down, not all clients. If you put something in the middle that fails a challenge, then that middle entity is untrustworthy, regardless of the reason for the failure. That's the point of the challenge, isn't it? To determine trustworthiness? Of course, if the server thinks something is untrustworthy, it should not deal with it, at least in a BiDir situation. --Rebecca -----Original Message----- From: Joncheng Kuo [mailto:ckuo01@syr.edu] Sent: Thursday, May 06, 2004 7:17 PM To: Bergersen, Rebecca Cc: Brian_Niebuhr@NAI.com; firewall-traversal-ftf@omg.org Subject: Re: Firewall Issue: Response to failed BiDir challenge is unclear Bergersen, Rebecca wrote: PROBLEM: The actions that result from the failure of a BiDir challenge are unclear. RECOMMENDATION: The client has proven itself untrustworthy. A BI_DIR_GIOP_RESPONSE containing a STRONG_FAILED result is returned to the client and all bi-directional connections to the client are closed. First of all, how can you close all other bi-directional connections to the same client due to a STRONG_FAILED in one connection? Secondly, there are reasons for STRONG_FAILED other than a malicious client. For example, one of the security keys used for challenge/response could expire. Lastly, your recommendation opens a door for future denial-of-service attack. Consider an application server that has an ORB shared by many client applications. If a client application is allowed to specify its own BiDirId and response for challenge (not allowed in the current spec), any of these client applications can bring down *all* bi-directional connections by giving a bad response. Joncheng Respectfully, 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 Date: Fri, 7 May 2004 11:33:44 -0400 (EDT) From: Polar Humenn To: "Bergersen, Rebecca" Cc: Joncheng Kuo , Brian_Niebuhr@NAI.com, firewall-traversal-ftf@omg.org Subject: RE: Firewall Issue: Response to failed BiDir challenge is unclear On Fri, 7 May 2004, Bergersen, Rebecca wrote: > My understanding is that the challenge and consequent inference of > trustworthiness isn't so much to the connection as to the client itself. > If a challenge fails, it is the client that is deemed untrustworthy. > That would imply that all (BiDir) connections to that client should be > closed. All? So, say have many separate connections from the same "initiator" using the same BiDirID. Asside from the problem of trying to figure out which connection to send a request in, let's say the last StrongOffer for the same BiDirID fails. Now, you say, that I must look through all my connections in the ORB to see if that BiDirId is in use, and drop all of those connections? -Polar > > --Rebecca > > -----Original Message----- > From: Joncheng Kuo [mailto:ckuo01@syr.edu] > Sent: Thursday, May 06, 2004 7:17 PM > To: Bergersen, Rebecca > Cc: Brian_Niebuhr@NAI.com; firewall-traversal-ftf@omg.org > Subject: Re: Firewall Issue: Response to failed BiDir challenge is unclear > > > Bergersen, Rebecca wrote: > > > PROBLEM: > The actions that result from the failure of a BiDir challenge are unclear. > > RECOMMENDATION: > The client has proven itself untrustworthy. A BI_DIR_GIOP_RESPONSE containing a STRONG_FAILED result is returned to the client and all bi-directional connections to the client are closed. > > First of all, how can you close all other bi-directional connections to the same client due to a STRONG_FAILED in one connection? > > Secondly, there are reasons for STRONG_FAILED other than a malicious client. For example, one of the security keys used for challenge/response could expire. > > Lastly, your recommendation opens a door for future denial-of-service attack. Consider an application server that has an ORB shared by many client applications. If a client application is allowed to specify its own BiDirId and response for challenge (not allowed in the current spec), any of these client applications can bring down *all* bi-directional connections by giving a bad response. > > Joncheng > > > > Respectfully, > > 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: Fri, 7 May 2004 12:45:47 -0400 (EDT) From: Polar Humenn To: "Bergersen, Rebecca" Cc: firewall-traversal-ftf@omg.org Subject: RE: Firewall Issue: Response to failed BiDir challenge is unclear On Fri, 7 May 2004, Bergersen, Rebecca wrote: > So what is your conclusion? (I'm not sure how to interpret "Oh, well." > ;-) To me it means a stoic acceptance.) I mean, it's bad for GIOP and bad for CORBA, and there's nothing I can really do about it. -Polar > --Rebecca > > > -----Original Message----- > > From: Polar Humenn [mailto:polar@adiron.com] > > Sent: Friday, May 07, 2004 11:45 AM > > To: firewall-traversal-ftf@omg.org > > Subject: RE: Firewall Issue: Response to failed BiDir challenge is > > unclear > > > > > > On Fri, 7 May 2004, Bergersen, Rebecca wrote: > > > > > offending client should be shut down, not all clients. If you put > > > something in the middle that fails a challenge, then that > > middle entity > > > is untrustworthy, regardless of the reason for the failure. > > That's the > > > point of the challenge, isn't it? To determine trustworthiness? Of > > > course, if the server thinks something is untrustworthy, it > > should not > > > deal with it, at least in a BiDir situation. > > > > Trustworthiness may have been the intent. > > > > However, the only thing that is implied by the solution is > > that the client > > is merely in posession of the corresponding component of an > > RSA key pair. > > > > That could be one of many many clients. > > > > Trustworthiness would be implied the client keeps his RSA key > > a secret, > > and doen't give it out to anybody, or it doesn't get compromised in > > anyway. > > > > That's what we have PKI for, so that third parties can vouch for the > > sanctity of keys. > > > > Now, you could implement a trusted key data base, or an untrusted key > > database on your server. > > > > However, that's where the StrongFailed case comes in, where > > you might have > > potentially many valid keys, but one is sitting on your > > untrusted list. > > > > Perhaps you should just accept it, and then don't send anything to it. > > > > If that were the case, then you really don't need to ACK anything. > > > > However, if you don't ACK anything, you might screw up the client > > application because it will be waiting around for its callback. > > > > Oh well. > > > > -Polar > > > > > > > > > > --Rebecca > > > > > > > > > -----Original Message----- > > > From: Joncheng Kuo [mailto:ckuo01@syr.edu] > > > Sent: Thursday, May 06, 2004 7:17 PM > > > To: Bergersen, Rebecca > > > Cc: Brian_Niebuhr@NAI.com; firewall-traversal-ftf@omg.org > > > Subject: Re: Firewall Issue: Response to failed BiDir > > challenge is unclear > > > > > > > > > Bergersen, Rebecca wrote: > > > > > > > > > PROBLEM: > > > The actions that result from the failure of a BiDir > > challenge are unclear. > > > > > > RECOMMENDATION: > > > The client has proven itself untrustworthy. A > > BI_DIR_GIOP_RESPONSE containing a STRONG_FAILED result is > > returned to the client and all bi-directional connections to > > the client are closed. > > > > > > First of all, how can you close all other bi-directional > > connections to the same client due to a STRONG_FAILED in one > > connection? > > > > > > Secondly, there are reasons for STRONG_FAILED other than a > > malicious client. For example, one of the security keys used > > for challenge/response could expire. > > > > > > Lastly, your recommendation opens a door for future > > denial-of-service attack. Consider an application server that > > has an ORB shared by many client applications. If a client > > application is allowed to specify its own BiDirId and > > response for challenge (not allowed in the current spec), any > > of these client applications can bring down *all* > > bi-directional connections by giving a bad response. > > > > > > Joncheng > > > > > > > > > > > > Respectfully, > > > > > > 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 Subject: RE: Firewall Issue: Response to failed BiDir challenge is unclear Date: Fri, 7 May 2004 15:04:13 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall Issue: Response to failed BiDir challenge is unclear Thread-Index: AcQ0SLXyDAe4LtzBS7iHBoN+Vt3NVAAHOX1A From: "Bergersen, Rebecca" To: "Polar Humenn" Cc: "Joncheng Kuo" , , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i47JAgFh019535 I was actually being a bit more inclusive. I meant all BiDir connections to that connection initiator, not just those carrying the offending BiDirID (though in most cases all connections and those containing that BiDirId is probably the same set.) After all, it is the client that been proven untrustworthy, not the individual connection. --Rebecca > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Friday, May 07, 2004 11:34 AM > To: Bergersen, Rebecca > Cc: Joncheng Kuo; Brian_Niebuhr@NAI.com; > firewall-traversal-ftf@omg.org > Subject: RE: Firewall Issue: Response to failed BiDir challenge is > unclear > > > On Fri, 7 May 2004, Bergersen, Rebecca wrote: > > > My understanding is that the challenge and consequent inference of > > trustworthiness isn't so much to the connection as to the > client itself. > > If a challenge fails, it is the client that is deemed untrustworthy. > > That would imply that all (BiDir) connections to that > client should be > > closed. > > All? > > So, say have many separate connections from the same > "initiator" using the > same BiDirID. Asside from the problem of trying to figure out which > connection to send a request in, let's say the last > StrongOffer for the > same BiDirID fails. > > Now, you say, that I must look through all my connections in > the ORB to > see if that BiDirId is in use, and drop all of those connections? > > > -Polar > > > > > > > --Rebecca > > > > -----Original Message----- > > From: Joncheng Kuo [mailto:ckuo01@syr.edu] > > Sent: Thursday, May 06, 2004 7:17 PM > > To: Bergersen, Rebecca > > Cc: Brian_Niebuhr@NAI.com; firewall-traversal-ftf@omg.org > > Subject: Re: Firewall Issue: Response to failed BiDir > challenge is unclear > > > > > > Bergersen, Rebecca wrote: > > > > > > PROBLEM: > > The actions that result from the failure of a BiDir > challenge are unclear. > > > > RECOMMENDATION: > > The client has proven itself untrustworthy. A > BI_DIR_GIOP_RESPONSE containing a STRONG_FAILED result is > returned to the client and all bi-directional connections to > the client are closed. > > > > First of all, how can you close all other bi-directional > connections to the same client due to a STRONG_FAILED in one > connection? > > > > Secondly, there are reasons for STRONG_FAILED other than a > malicious client. For example, one of the security keys used > for challenge/response could expire. > > > > Lastly, your recommendation opens a door for future > denial-of-service attack. Consider an application server that > has an ORB shared by many client applications. If a client > application is allowed to specify its own BiDirId and > response for challenge (not allowed in the current spec), any > of these client applications can bring down *all* > bi-directional connections by giving a bad response. > > > > Joncheng > > > > > > > > Respectfully, > > > > 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: Firewall Issue: Response to failed BiDir challenge is unclear Date: Fri, 7 May 2004 11:51:49 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall Issue: Response to failed BiDir challenge is unclear Thread-Index: AcQzrmMYLgORqqLOTK2eR3CVH5gNmwAnFA0w From: "Bergersen, Rebecca" To: "Polar Humenn" Cc: , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i4AAe1Fh024690 I think it's better to return a STRONG_FAILED response before dropping the connection. That gives the application a reason, whereas the application doesn't know how to interpret just dropping the connection and might try starting it again and going through the protocol with the same result and retry again, etc. If it gets a STRONG_FAILED back it should know not to retry until it has at least fixed the problem that it now knows about. --Rebecca > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Thursday, May 06, 2004 5:09 PM > To: Bergersen, Rebecca > Cc: issues@omg.org; firewall-traversal-ftf@omg.org > Subject: Re: Firewall Issue: Response to failed BiDir challenge is > unclear > > > On Thu, 6 May 2004, Bergersen, Rebecca wrote: > > > PROBLEM: > > The actions that result from the failure of a BiDir > challenge are unclear. > > > > RECOMMENDATION: > > The client has proven itself untrustworthy. A BI_DIR_GIOP_RESPONSE > > containing a STRONG_FAILED result is returned to the client and all > > bi-directional connections to the client are closed. > > If the client has *proven* itself untrustworthy, why bother sending it > back anything at all? You might end up sending a GIOP Reply to this > untrustworthy client. > > Why not just drop this *untrustworthy* connection? > > -Polar > > > > > > Respectfully, > > 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: Firewall Issue: Response to failed BiDir challenge is unclear Date: Fri, 7 May 2004 11:57:30 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall Issue: Response to failed BiDir challenge is unclear Thread-Index: AcQ0SmJ7h+lD4pvYSlSRuJ320pewiQAAU22A From: "Bergersen, Rebecca" To: "Polar Humenn" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i4A9hQFh024247 So what is your conclusion? (I'm not sure how to interpret "Oh, well." ;-) To me it means a stoic acceptance.) --Rebecca > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Friday, May 07, 2004 11:45 AM > To: firewall-traversal-ftf@omg.org > Subject: RE: Firewall Issue: Response to failed BiDir challenge is > unclear > > > On Fri, 7 May 2004, Bergersen, Rebecca wrote: > > > offending client should be shut down, not all clients. If you put > > something in the middle that fails a challenge, then that > middle entity > > is untrustworthy, regardless of the reason for the failure. > That's the > > point of the challenge, isn't it? To determine trustworthiness? Of > > course, if the server thinks something is untrustworthy, it > should not > > deal with it, at least in a BiDir situation. > > Trustworthiness may have been the intent. > > However, the only thing that is implied by the solution is > that the client > is merely in posession of the corresponding component of an > RSA key pair. > > That could be one of many many clients. > > Trustworthiness would be implied the client keeps his RSA key > a secret, > and doen't give it out to anybody, or it doesn't get compromised in > anyway. > > That's what we have PKI for, so that third parties can vouch for the > sanctity of keys. > > Now, you could implement a trusted key data base, or an untrusted key > database on your server. > > However, that's where the StrongFailed case comes in, where > you might have > potentially many valid keys, but one is sitting on your > untrusted list. > > Perhaps you should just accept it, and then don't send anything to it. > > If that were the case, then you really don't need to ACK anything. > > However, if you don't ACK anything, you might screw up the client > application because it will be waiting around for its callback. > > Oh well. > > -Polar > > > > > > --Rebecca > > > > > > -----Original Message----- > > From: Joncheng Kuo [mailto:ckuo01@syr.edu] > > Sent: Thursday, May 06, 2004 7:17 PM > > To: Bergersen, Rebecca > > Cc: Brian_Niebuhr@NAI.com; firewall-traversal-ftf@omg.org > > Subject: Re: Firewall Issue: Response to failed BiDir > challenge is unclear > > > > > > Bergersen, Rebecca wrote: > > > > > > PROBLEM: > > The actions that result from the failure of a BiDir > challenge are unclear. > > > > RECOMMENDATION: > > The client has proven itself untrustworthy. A > BI_DIR_GIOP_RESPONSE containing a STRONG_FAILED result is > returned to the client and all bi-directional connections to > the client are closed. > > > > First of all, how can you close all other bi-directional > connections to the same client due to a STRONG_FAILED in one > connection? > > > > Secondly, there are reasons for STRONG_FAILED other than a > malicious client. For example, one of the security keys used > for challenge/response could expire. > > > > Lastly, your recommendation opens a door for future > denial-of-service attack. Consider an application server that > has an ORB shared by many client applications. If a client > application is allowed to specify its own BiDirId and > response for challenge (not allowed in the current spec), any > of these client applications can bring down *all* > bi-directional connections by giving a bad response. > > > > Joncheng > > > > > > > > Respectfully, > > > > 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, 10 May 2004 11:42:10 -0400 From: Joncheng Kuo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: Brian_Niebuhr@NAI.com CC: Rebecca.Bergersen@iona.com, firewall-traversal-ftf@omg.org Subject: Re: Firewall Issue: Response to failed BiDir challenge is unclear Comments inline. Brian_Niebuhr@NAI.com wrote: [BNIEBUHR] Keys don't expire in this environment. You'll notice that we're not passing around certificates with date information in them. The reason for this is that the keys are not expected to last long - and certainly not longer than a normal expiration period. As the discussions on bidir progressed we realized that bidir is really most appropriate for transient objects. While one could use bidir for persisent objects, it was not likely to happen often for a number of reasons; Most important was that persistent objects are usually hosted on servers that have a public address and can receive incoming connections - therefore using bidir to reach those objects was not necessary. We used this same argument for the key length - the key length is (I think - I didn't look it up) 512 bits, which is not a strong key. We decided that it was more important that the key generation and transmission process be more efficient than to have big keys, because keys shouldn't last that long. I agree with your particular use of bidir, which might be what the bidir spec was called for. If that is the case, the bidir spec shall state its limitations explicitely. [BNIEBUHR] One other note on key expiration: you'll notice that a client can effectively expire a key any time it wants to. Since the client generates the key, and the client makes offers using that key, the client effectively exprires a key by not making any more bidir offers using that key. The effect is that any objects that used that key in the generation of a bidir id can no longer be used bidirectionally. Not quite. Even when the client expires a key and sends no more BiDirId associated with the key, the established bidirectional connections can still be used for that BiDirId. The client should probably shutdown the POA associated with that BiDirId. Joncheng Lastly, your recommendation opens a door for future denial-of-service attack. Consider an application server that has an ORB shared by many client applications. If a client application is allowed to specify its own BiDirId and response for challenge (not allowed in the current spec), any of these client applications can bring down *all* bi-directional connections by giving a bad response. [BNIEBUHR] Client applications shouldn't be allowed to specify their own bidirid. The intent is for the ORB to generate and manage the BidirIds. If an ORB allows client applications to begin specifying the BidirIds and implementing the challenge/response algorithm, then that ORB needs to handle the consequences of additional security vulnerabilities. Joncheng Date: Mon, 10 May 2004 11:55:34 -0400 From: Joncheng Kuo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en To: Brian_Niebuhr@NAI.com CC: polar@adiron.com, Rebecca.Bergersen@iona.com, firewall-traversal-ftf@omg.org Subject: Re: Firewall Issue: Response to failed BiDir challenge is unclear Brian_Niebuhr@NAI.com wrote: From: Polar Humenn [mailto:polar@adiron.com] Now, you say, that I must look through all my connections in the ORB to see if that BiDirId is in use, and drop all of those connections? I don't think that's too much to ask. In fact, I think this is the best solution to the problem that I've heard. Remember that a STRONG_FAILED only occurs when a client was unable to complete the challenge/response protocol. This only occurs in the case where a client is malicious or faulty, which is going to be a very, very small percentage of all connections. Therefore, doing a little extra work when the challenge/response fails makes sense. Checking bidirids is probably the easiest way to locate other potential connections to the client. It may not catch all of the connections, but at least any known bad connections can be closed. Sounds like a wonderful and secure approach. However, if that is ever implemented, a malicious client can spoof other clients' strong BiDirIds and shutdown a server's bidirectional connections to those clients if the malicious client can get the BiDirIds of those clients. Because BiDirIds are always in clear, it's not too hard to conduct this type of DoS attack. Joncheng Brian