Issue 2867: Clarification is needed on the passing of credentials (firewall-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: Description: Clarification is needed on the passing of credentials. Section 4.7.3 states that "Since all proxies will have access to the IOR of the target object, and the certificate of the client, they can judge whether this client may use a pass-through connection or not." Section 4.12 states that "When a client establishes a normal connection to a target via a trusted proxy and uses a secure transport (e.g. IIOP/SSL), in order to achieve end-to-end authentication, the proxy will have to forward the client"s certificate/identity to the server." Section 4.12 implies that the ForwardedIdentity service context will only be used when using a secure transport, but section 4.7.3 implies that the client certificate will always be available. In fact, the ForwardedIdentity service context should only be used in the case of a NORMAL connection using a secure transport because those are the only conditions under which there is a notion of trust between a requestor and the recipient of that request. This means that the only mechanism upon which to base a decision of whether or not to allow a PASSTHRU connection is the source host address/port. Resolution: Revised Text: Actions taken: August 24, 1999: received issue Discussion: End of Annotations:===== From: "Niebuhr, Brian" To: "'firewall-rtf@omg.org'" Subject: Issue 6 Date: Tue, 24 Aug 1999 23:01:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: a06e967c6832368894db6ee3236195c4 Issue 6 Description: Clarification is needed on the passing of credentials. Section 4.7.3 states that "Since all proxies will have access to the IOR of the target object, and the certificate of the client, they can judge whether this client may use a pass-through connection or not." Section 4.12 states that "When a client establishes a normal connection to a target via a trusted proxy and uses a secure transport (e.g. IIOP/SSL), in order to achieve end-to-end authentication, the proxy will have to forward the client's certificate/identity to the server." Section 4.12 implies that the ForwardedIdentity service context will only be used when using a secure transport, but section 4.7.3 implies that the client certificate will always be available. In fact, the ForwardedIdentity service context should only be used in the case of a NORMAL connection using a secure transport because those are the only conditions under which there is a notion of trust between a requestor and the recipient of that request. This means that the only mechanism upon which to base a decision of whether or not to allow a PASSTHRU connection is the source host address/port. Proposed Solution: First, section 4.7.3 should be changed from, "Since all proxies will have access to the IOR of the target object, and the certificate of the client, they can judge whether this client may use a pass-through connection or not" to "Since all proxies will have access to the IOR of the target object, and the address/port pair of the requesting host, they can judge whether this client may use a pass-through connection or not." Second, either a secure method of authenticating the requestor of a PASSTHRU connection should be found, or a note should be made in the specification as to the insecurity of this means of authentication. Reply-To: From: "Martin Chapman" To: Subject: Issue 2867 Date: Wed, 1 Dec 1999 17:21:20 -0000 Message-ID: <001301bf3c20$7bccc2a0$4d01020a@leo.dublin.iona.ie> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" X-UIDL: iQO!!9UCe9U_"e9`X:e9 I'm at a loss on this on one. the only thing i can think of is to make it clear in 4.7.3 that we are talking about a secure connection (iiop over ssl) and hence the proxy will know the certificate (there is no other way to do this is there?) - but this is in the IIOP/SSL section so i'm grasping at straws. Also ForwardedIdentity is only really valid on a secure connection, and only then for NORMAL mode - but i think the text is clear enough on this. I propose a default resolution of close with no action, unless someone can provide any insights or suggestions. Issue 2867: Clarification is needed on the passing of credentials (firewall-rtf) Click here for this issue's archive. Nature: Uncategorized Issue Severity: Summary: Description: Clarification is needed on the passing of credentials. Section 4.7.3 states that "Since all proxies will have access to the IOR of the target object, and the certificate of the client, they can judge whether this client may use a pass-through connection or not." Section 4.12 states that "When a client establishes a normal connection to a target via a trusted proxy and uses a secure transport (e.g. IIOP/SSL), in order to achieve end-to-end authentication, the proxy will have to forward the client"s certificate/identity to the server." Section 4.12 implies that the ForwardedIdentity service context will only be used when using a secure transport, but section 4.7.3 implies that the client certificate will always be available. In fact, the ForwardedIdentity service context should only be used in the case of a NORMAL connection using a secure transport because those are the only conditions under which there is a notion of trust between a requestor and the recipient of that request. This means that the only mechanism upon which to base a decision of whether or not to allow a PASSTHRU connection is the source host address/port. Resolution: Revised Text: Actions taken: August 24, 1999: received issue Discussion: ---------------------------------------------------------------------- Martin Chapman ------------| email: mchapman@iona.com --| voice x2398 IONA Technologies ----------| ftp: ftp.iona.com -| tel: +353-1-6625255 The IONA Building ---------| http://www.iona.com| fax: +353-1-6625244 Shelbourne Road -| In the USA call: 1-800 orbix4u --------- Dublin 4, Ireland. ---------| ---------------- 1-800 6724948 --------- --------------------------------- "Making software work together (tm)" From: "Niebuhr, Brian" To: firewall-rtf@omg.org Subject: RE: Issue 2867 Date: Wed, 1 Dec 1999 11:43:11 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: J0_d9GG'e941 I'm at a loss on this on one. the only thing i can think of > is to make it clear in 4.7.3 that we are talking about a > secure connection (iiop over ssl) and hence the proxy will > know the certificate (there is no other way to do this is > there?) - but this is in the IIOP/SSL section so i'm > grasping at straws. This implies that in order to establish a PASSTHRU connection we must contact the GIOPProxy using IIOP/SSL to invoke new_target(). I am suggesting that this normally will not be the case; The reason behind that is if I am asking for a PASSTHRU connection, I probably don't trust the firewall and I may not trust its CA. (For example, let's say I am at company A attempting to contact a server at company B behind B's firewall. I may want to be cryptographically sure that I am talking to B's server and that my traffic is not being intercepted by their firewall. A second example might be if there is also a firewall on A's network. In that case, A's firewall will invoke new_target() on B's firewall, and the firewalls will almost certainly not trust each other's certificates, firewalls being the untrusting entities that they are.) Therefore, making an IIOP/SSL connection to the firewall to ask for a PASSTHRU connection doesn't make much sense (or may even not be possible). What this means is that it is possible (likely?) that a client will request a PASSTHRU connection simply using IIOP, in which case the certificate will not be available. This was the motivation behind the posting of the issue. > Also ForwardedIdentity is only really valid on a secure > connection, and only then for NORMAL mode - but i think the > text is clear enough on this. I agree that it should only be valid on a secure connection, but I disagree that the text is clear on this. Because section 4.7.3 stated we would always have the certificate of the client, I assumed when reading section 4.12 that FORWARDED_IDENTITY would always be present when requesting a PASSTHRU connection, whether the request came over a secure transport or not. Maybe I'm making more of an issue out of this than is really necessary. However, although I understand what is intended by the specification, what is said in 4.7.3 (proxy will always have the certificate of the client) contradicts what is implied in 4.12 (FORWARDED_IDENTITY is only passed over a secure transport). Brian _________________________ Brian Niebuhr Network Associates - NAI Labs 3060 Washington Rd. (Rt. 97) Glenwood, MD 21738 443-259-2349 bniebuhr@nai.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 1 Dec 1999 16:52:04 -0500 (EST) From: Polar Humenn To: Martin Chapman cc: firewall-rtf@omg.org Subject: Re: Issue 2867 In-Reply-To: <001301bf3c20$7bccc2a0$4d01020a@leo.dublin.iona.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 452!!SaQd9V<(!!!;`d9 I guess I would leave it as it is, as even if the first NORMAL hop was plain old IIOP, the "identity" that can be forwarded can be merely the IP address or DNS name of the client's machine. > Build 4.71.2173.0 > X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 > Importance: Normal > Status: O > X-Status: > X-Keywords: > X-UID: 10421 > > I'm at a loss on this on one. the only thing i can think of is to > make it > clear in 4.7.3 that we are talking about a secure connection (iiop > over ssl) > and hence the proxy will know the certificate (there is no other way > to do > this is there?) - but this is in the IIOP/SSL section so i'm > grasping at > straws. > Also ForwardedIdentity is only really valid on a secure connection, > and only > then for NORMAL mode - but i think the text is clear enough on this. > > > I propose a default resolution of close with no action, unless > someone can > provide any insights or suggestions. > > Issue 2867: Clarification is needed on the passing of credentials > (firewall-rtf) > Click here for this issue's archive. > Nature: Uncategorized Issue > Severity: > Summary: Description: Clarification is needed on the passing of > credentials. > Section 4.7.3 states that "Since all proxies will have access to the > IOR of > the target object, and the certificate of the client, they can judge > whether > this client may use a pass-through connection or not." Section 4.12 > states > that "When a client establishes a normal connection to a target via > a > trusted proxy and uses a secure transport (e.g. IIOP/SSL), in order > to > achieve end-to-end authentication, the proxy will have to forward > the > client"s certificate/identity to the server." Section 4.12 implies > that the > ForwardedIdentity service context will only be used when using a > secure > transport, but section 4.7.3 implies that the client certificate > will always > be available. In fact, the ForwardedIdentity service context should > only be > used in the case of a NORMAL connection using a secure transport > because > those are the only conditions under which there is a notion of trust > between > a requestor and the recipient of that request. This means that the > only > mechanism upon which to base a decision of whether or not to allow a > PASSTHRU connection is the source host address/port. > Resolution: > Revised Text: > Actions taken: > August 24, 1999: received issue > > Discussion: > > > ---------------------------------------------------------------------- > Martin Chapman ------------| email: mchapman@iona.com --| voice > x2398 > IONA Technologies ----------| ftp: ftp.iona.com -| tel: > +353-1-6625255 > The IONA Building ---------| http://www.iona.com| fax: > +353-1-6625244 > Shelbourne Road -| In the USA call: 1-800 orbix4u > --------- > Dubli ------------------------------------------------------------------- Polar Humenn Adiron, LLC Principal 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Thu, 02 Dec 1999 18:15:15 +0000 From: Owen Rees To: mchapman@iona.com, firewall-rtf@omg.org Subject: Re: Issue 2867 Message-ID: <3560678019.944158515@ews-proj-2.hpl.hp.com> In-Reply-To: <001301bf3c20$7bccc2a0$4d01020a@leo.dublin.iona.ie> Originator-Info: login-id=ore; server=ticb.hpl.hp.com X-Mailer: Mulberry (Win32) [1.4.3, s/n P005-300802-001] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: A_8e9T[ed9Uafd9_FMe9 --On 01 December 1999, 17:21 +0000 Martin Chapman wrote: > I'm at a loss on this on one. After reading the messages I am now totally confused about how PASSTHRU is supposed to work. I have a very basic question, but one that must be answered since it affects behaviour at opposite ends of a connection. When a client invokes "new_target(target, PASSTHRU)" does this (in the success case): (a) convert the connection on which the new_target request arrived to a pass through connection, or (b) establish a new listening point at the proxy to which the client must connect to get a pass through connection to the target. (or something else?) In case (a) the client can ignore the returned reference. The connection is open so the host:port data is irrelevant (but could be verified to be that of the proxy). The connection is PASSTHRU so the proxy neither observes nor modifies the data and therefore the target object key must be used. If the connection had already been converted to SSL, the proxy could look at the client certificate, but we then have the problem of dismantling the existing SSL session and creating a new one over the same TCP connection to the server (or next proxy) - I don't know SSL well enough to comment on this. In case (b) the GIOP proxy effectively includes a dynamically controlled TCP proxy. There is no direct link between the new_target request that may have been made over an SSL session with certificates available, and the TCP connect that arrives at the new listen point for relay to the server (or next proxy). It looks to me as if there is a race condition where the client has to beat the roving port scanner to the connect unless there is some other initial handshake over the new connection. Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285 From: "Niebuhr, Brian" To: firewall-rtf@omg.org Subject: RE: Issue 2867 Date: Thu, 2 Dec 1999 11:16:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: bUJe92#g!!*6Ie9/%Vd9 I got this message before I had a chance to send my response to your first post, so I'll try and put all of the information in this answer. I believe that your answer b) is the intended solution in the spec as it currently stands and I agree with you that this behavior is not correct (in addition to port-scanners, the firewall will probably want to be using ports to accept connections from more than 1 host at a time, again raising the race condition problem). This problem is what caused me to post my issue with PASSTHRU connections which is contained in the discussion of issue 2648: http://www.omg.org/issues/issue2648.txt In that discussion I propose a solution (solution 1 in my post in issue2648.txt) which you have presented here as answer a). I personally believe that this is the best solution, though you may have a point about the SSL renegotiation. In any case, I think if we can solve this problem then the issue you raised about the IOR returned by new_target() on a PASSTHRU request should be resolved. Brian > -----Original Message----- > From: Owen Rees [mailto:owen_rees@hp.com] > Sent: Thursday, December 02, 1999 1:15 PM > To: mchapman@iona.com; firewall-rtf@omg.org > Subject: Re: Issue 2867 > > > --On 01 December 1999, 17:21 +0000 Martin Chapman > wrote: > > > I'm at a loss on this on one. > > After reading the messages I am now totally confused about > how PASSTHRU is > supposed to work. I have a very basic question, but one that must be > answered since it affects behaviour at opposite ends of a > connection. > > When a client invokes "new_target(target, PASSTHRU)" does this (in > the > success case): > > (a) convert the connection on which the new_target request > arrived to a > pass through connection, or > > (b) establish a new listening point at the proxy to which the > client must > connect to get a pass through connection to the target. > > (or something else?) > > In case (a) the client can ignore the returned reference. The > connection is > open so the host:port data is irrelevant (but could be > verified to be that > of the proxy). The connection is PASSTHRU so the proxy > neither observes nor > modifies the data and therefore the target object key must be > used. If the > connection had already been converted to SSL, the proxy could > look at the > client certificate, but we then have the problem of dismantling the > existing SSL session and creating a new one over the same TCP > connection to > the server (or next proxy) - I don't know SSL well enough to > comment on > this. > > In case (b) the GIOP proxy effectively includes a dynamically > controlled > TCP proxy. There is no direct link between the new_target > request that may > have been made over an SSL session with certificates > available, and the TCP > connect that arrives at the new listen point for relay to the > server (or > next proxy). It looks to me as if there is a race condition where > the > client has to beat the roving port scanner to the connect > unless there is > some other initial handshake over the new connection. > > > Regards, > Owen Rees > Hewlett Packard Laboratories, Bristol, UK > tel: +44 117 312 9439 fax: +44 117 312 9285 > Reply-To: From: "Martin Chapman" To: "Niebuhr, Brian" , Subject: RE: Issue 2867 Date: Fri, 3 Dec 1999 12:58:53 -0000 Message-ID: <001001bf3d8e$26cbbd00$4d01020a@leo.dublin.iona.ie> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: > Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: /)pd9~hM!!Oc^d9QH?!! I don't see why we have to manadate either a) or b) - either are possible depending on original protocol used to the proxy and the mode - seems like a firewall implemnetation issue as far as I'm concerened. > -----Original Message----- > From: Niebuhr, Brian [mailto:Brian_Niebuhr@NAI.com] > Sent: 02 December 1999 19:17 > To: firewall-rtf@omg.org > Subject: RE: Issue 2867 > > > I got this message before I had a chance to send my response to your > first post, so I'll try and put all of the information in this > answer. > > I believe that your answer b) is the intended solution in the spec > as it currently stands and I agree with you that this behavior is > not correct (in addition to port-scanners, the firewall will > probably want to be using ports to accept connections from more than > 1 host at a time, again raising the race condition problem). This > problem is what caused me to post my issue with PASSTHRU connections > which is contained in the discussion of issue 2648: > http://www.omg.org/issues/issue2648.txt > > In that discussion I propose a solution (solution 1 in my post in > issue2648.txt) which you have presented here as answer a). I > personally believe that this is the best solution, though you may > have a point about the SSL renegotiation. > > In any case, I think if we can solve this problem then the issue > you raised about the IOR returned by new_target() on a PASSTHRU > request should be resolved. > > Brian > > > > -----Original Message----- > > From: Owen Rees [mailto:owen_rees@hp.com] > > Sent: Thursday, December 02, 1999 1:15 PM > > To: mchapman@iona.com; firewall-rtf@omg.org > > Subject: Re: Issue 2867 > > > > > > --On 01 December 1999, 17:21 +0000 Martin Chapman > > wrote: > > > > > I'm at a loss on this on one. > > > > After reading the messages I am now totally confused about > > how PASSTHRU is > > supposed to work. I have a very basic question, but one that must > be > > answered since it affects behaviour at opposite ends of a > connection. > > > > When a client invokes "new_target(target, PASSTHRU)" does this (in > the > > success case): > > > > (a) convert the connection on which the new_target request > > arrived to a > > pass through connection, or > > > > (b) establish a new listening point at the proxy to which the > > client must > > connect to get a pass through connection to the target. > > > > (or something else?) > > > > In case (a) the client can ignore the returned reference. The > > connection is > > open so the host:port data is irrelevant (but could be > > verified to be that > > of the proxy). The connection is PASSTHRU so the proxy > > neither observes nor > > modifies the data and therefore the target object key must be > > used. If the > > connection had already been converted to SSL, the proxy could > > look at the > > client certificate, but we then have the problem of dismantling > the > > existing SSL session and creating a new one over the same TCP > > connection to > > the server (or next proxy) - I don't know SSL well enough to > > comment on > > this. > > > > In case (b) the GIOP proxy effectively includes a dynamically > > controlled > > TCP proxy. There is no direct link between the new_target > > request that may > > have been made over an SSL session with certificates > > available, and the TCP > > connect that arrives at the new listen point for relay to the > > server (or > > next proxy). It looks to me as if there is a race condition where > the > > client has to beat the roving port scanner to the connect > > unless there is > > some other initial handshake over the new connection. > > > > > > Regards, > > Owen Rees > > Hewlett Packard Laboratories, Bristol, UK > > tel: +44 117 312 9439 fax: +44 117 312 9285 > > > Date: Mon, 06 Dec 1999 15:23:53 +0000 From: Owen Rees To: mchapman@iona.com, "Niebuhr, Brian" , firewall-rtf@omg.org Subject: RE: Issue 2867 Message-ID: <3895995629.944493833@ews-proj-2.hpl.hp.com> In-Reply-To: <001001bf3d8e$26cbbd00$4d01020a@leo.dublin.iona.ie> Originator-Info: login-id=ore; server=ticb.hpl.hp.com X-Mailer: Mulberry (Win32) [1.4.3, s/n P005-300802-001] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: ;*^!!E;#e9I17e9XgLe9 --On 03 December 1999, 12:58 +0000 Martin Chapman wrote: > I don't see why we have to manadate either a) or b) - either are possible > depending on original protocol used to the proxy and the mode - seems > like a firewall implemnetation issue as far as I'm concerened. > The options do not interoperate. We must pick one. Regards, Owen Rees Hewlett Packard Laboratories, Bristol, UK tel: +44 117 312 9439 fax: +44 117 312 9285