Issue 2068: Tagged Component interactions (interop) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: The Tagged Components TAG_SSL_SEC_TRANS and TAG_IIOP_ALTERNATE_ADDRESS both allow an IIOP profile to have an extra port in the IOR. The words around SSL_SEC_TRANS say something like "to be used instead of the one in the profile proper". Whereas the words around ALTERNATE_ADDRESS are deliberately (?) vague. So what should a client-side ORB do with one of these? It could view the IOR as broken, it could treat the ALTERNATE_ADDRESS component as invalid or it could treat the port in the ALTERNATE_ ADDRESS component as either for TCP connection requests >or< for SSL connection requests. It could even look for a second SSL_SEC_TRANS component. Resolution: resolved, see above Revised Text: Actions taken: October 9, 1998: received issue March 8, 1999: closed issue Discussion: Discussion brought out the view that it has very clearly specified behavior which consists of one of the following at the behest of the client ORB that is trying to establish a session: (i) It decides that it wants to use SSL and proceeds to use the info from TAG_IIOP_SEC_TRANS, or (ii) It decides to use TAG_IIOP_ALTERNATE_ADDRESS, and then SSL is completely out of the picture. Once this choice is made the behavior is perfectly well specified. End of Annotations:===== Return-Path: Date: Fri, 09 Oct 1998 17:58:18 +0100 From: Dave Stringer To: interop@omg.org, issues@omg.org Subject: Tagged Component interactions Tom I guess we're onto Interop 2.4 RTF now so this might be an issue for that but I'm not sure what text we're working from just now. The Tagged Components TAG_SSL_SEC_TRANS and TAG_IIOP_ALTERNATE_ADDRESS both allow an IIOP profile to have an extra port in the IOR. The words around SSL_SEC_TRANS say something like "to be used instead of the one in the profile proper". Whereas the words around ALTERNATE_ADDRESS are deliberately (?) vague. So what should a client-side ORB do with one of these? It could view the IOR as broken, it could treat the ALTERNATE_ADDRESS component as invalid or it could treat the port in the ALTERNATE_ ADDRESS component as either for TCP connection requests >or< for SSL connection requests. It could even look for a second SSL_SEC_TRANS component. If the Messaging spec's changes to IIOP 1.2 are folded in then there is also the TAG_MESSAGE_ROUTERS component. If this is present in an IOR along with an SSL_SEC_TRANS, is an ORB allowed to send the data onto a router? If MESSAGE_ROUTERS coexists with an ALTENATE_ADDRESS are there any rules at all? Cheers, Dave Return-Path: Sender: jis@fpk.hp.com Date: Fri, 09 Oct 1998 13:38:12 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: Dave Stringer Cc: interop@omg.org Subject: Re: Tagged Component interactions References: <361E40AA.8B4B8324@nortel.com> Dave Stringer wrote: > I guess we're onto Interop 2.4 RTF now so this might be an issue > for that but I'm not sure what text we're working from just now. The final CORBA Core 2.3 Chapter 15 GIOP is ptc/98-08-13 and Chapter 13 Interop Architecture is ptc/98-08-16. Jishnu -- Jishnu Mukerji Systems Architect Advanced Development Enterprise Internet Solution Center Enterprise Systems Group Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Return-Path: Date: Fri, 09 Oct 1998 14:33:53 -0700 From: Sastry Malladi Organization: Oracle To: Dave Stringer CC: interop@omg.org, issues@omg.org Subject: Re: Tagged Component interactions References: <361E40AA.8B4B8324@nortel.com> Dave Stringer wrote: > > Tom > > I guess we're onto Interop 2.4 RTF now so this might be an issue > for that but I'm not sure what text we're working from just now. > > The Tagged Components TAG_SSL_SEC_TRANS and > TAG_IIOP_ALTERNATE_ADDRESS > both allow an IIOP profile to have an extra port in the IOR. The > words around SSL_SEC_TRANS say something like "to be used instead > of the one in the profile proper". Whereas the words around > ALTERNATE_ADDRESS are deliberately (?) vague. Well, even the usage of TAG_SSL_SEC_TRANS is not very clear from the spec. I discussed this with several ORB vendors last year and I guess it didn't make it to the RTF. Here is the main issue ? What if the object implementation want's to support both secure and non-secure (i.e, SSL and plain IIOP) invocations ? How does the client ORB know what is supported by the server and what is mandatory. Even with SSL, what association options are mandatory, what are supported. This is all contained in the SSL tagged component, but is not explained as to how that information should be interpretted. As a result, different vendors have implemented it in different ways and we have serious interoperability problems. The following is what I came up with to clarify things, and perhaps should be added to the spec. Any comments ? There are three possible modes that an object can support with respect to method invocations. They are secure only, non-secure only, and secure and non-secure modes respectively. These modes translate to IIOP only, IIOP over SSL only, and both IIOP and IIOP over SSL. The following discusses the profile layout for these three cases within an IOR. Please note that only IIOP profiles are discussed here. This does not rule out other profiles in IOR. They are vendor specific and will be ignored by foreign ORBs. Also note that all cases discussed will use IIOP 1.1 profile body. For reference: -------------- struct ProfileBody_1.1 { Version iiop_version; string host; unsigned short port; sequence object_key; sequence components; } TAG_SSL_SEC_TRANS: struct SSL { AssociationOptions target_supports; AssociationOptions target_requires; unsigned short port; } case 1: Object wants to support non-secure invocations only: There will NOT be any SSL component tag in the IIOP profile body. (If there are no other components present, then the sequence length of components will be zero). Object/server listens on the port # specified in IIOP profile body. If user has set invocation security features other than NoPtotection, then the client ORB should throw an exception(CORBA::IMPL_LIMIT) in this case. case 2: Object supports secure invocations only: There will be SSL component tag present in the profile body. The port number in the profile body itself will be invalid and no one will be listening on that port. So, how do the invoking clients find that out? They first need to see if SSL component tag is present. If present, then they need to check 'target_requires' value. If target_requires contains one of 'IntegrityAndConfidentiality', 'EstablishTrustInClient' then the client shouldn't use the port # in the profile body and treat the port in the profile body as invalid. If it ignores this information and tries to connect to that port, it will get a connection error. For this case, the 'target_requires' field should contain one of those two above values, depending on what is required. The client uses the port # in SSL component tag to connect to the server. What if a client doesn't know how to interpret SSL component tag It will try connecting to the port # in the profile body, ignoring the SSL component tag and will get a connection error. case 3: Object supports both secure and non-secure invocations: There will be SSL component tag present in the profile body and both the port numbers (i.e., one in profile body and one in component tag) are valid. 'taget_requires' contains nothing and target_supports contains 'NoProtection' and one of 'TrustInClient' and 'IntegrityAndConfidentiality' depending upon what is supported. Now the client may use either port depending on what the user has selected. What is described above is only how the client ORB finds out what the server supports. However, what the client actually uses to connect to depends upon what the user has selected. If what the user has selected does not match with what the target supports, the client ORB should throw either CORBA::NO_PERMISSION or CORBA::IMPL_LIMIT exception depending upon the case. User has an API available to him/her (we understand this API differs from vendor to vendor, although we tried to follow CORBA security API as much as possible at Oracle) through which he/she can set the security features (i.e, NoProtection, Confidentiality, TrustInTarget, etc.) and credentials (certificates) before invocation. In all the above cases, there will only be ONE IIOP 1.1 profile present in the IOR. Sastry > > So what should a client-side ORB do with one of these? It could > view the IOR as broken, it could treat the ALTERNATE_ADDRESS > component as invalid or it could treat the port in the ALTERNATE_ > ADDRESS component as either for TCP connection requests >or< for > SSL connection requests. It could even look for a second > SSL_SEC_TRANS component. > > If the Messaging spec's changes to IIOP 1.2 are folded in then > there is also the TAG_MESSAGE_ROUTERS component. If this is > present in an IOR along with an SSL_SEC_TRANS, is an ORB allowed > to send the data onto a router? If MESSAGE_ROUTERS coexists > with an ALTENATE_ADDRESS are there any rules at all? > > Cheers, > Dave Return-Path: Date: Sun, 11 Oct 1998 13:38:25 +0100 From: Dave Stringer To: Sastry Malladi CC: "Stringer, Dave (D.R.) [EXCHANGE:HAL02:HM20-I:BNR]" , interop@omg.org, jgoldberg@inprise.com Subject: Issue # 2068 - Re: Tagged Component interactions References: <361E40AA.8B4B8324@nortel.com> <361E8141.4008DA02@us.oracle.com> As we're not supposed to have discussion on issues@ I'm recapping the thread thus far with some added remarks. (My fault for sending the one message to both lists at the outset). Jon, shouldn't the TAG_MESSAGE_ROUTERS, which in the Measaging submission is in module MessageRouting, appear in the IOR section of IIOP (as do the Security Tags) ? Bob Kukura wrote: > > Jishnu & Dave, > > These documents don't have the 2.3a revisions applied yet, do they? > The > copy of 98-08-13 I just pulled down from the OMG server still has > service_context first in the RequestHeader_1_2 and ReplyHeader_1_2 > stucts, for instance. > > -Bob > > Jishnu Mukerji wrote: > > > > Dave Stringer wrote: > > > > > I guess we're onto Interop 2.4 RTF now so this might be an issue > > > for that but I'm not sure what text we're working from just now. > > > > The final CORBA Core 2.3 Chapter 15 GIOP is ptc/98-08-13 and > Chapter 13 > > Interop Architecture is ptc/98-08-16. > > > > > > Jishnu Sastry Malladi wrote: > > Dave Stringer wrote: > > > > Tom > > > > I guess we're onto Interop 2.4 RTF now so this might be an issue > > for that but I'm not sure what text we're working from just now. > > > > The Tagged Components TAG_SSL_SEC_TRANS and > TAG_IIOP_ALTERNATE_ADDRESS > > both allow an IIOP profile to have an extra port in the IOR. The > > words around SSL_SEC_TRANS say something like "to be used instead > > of the one in the profile proper". Whereas the words around > > ALTERNATE_ADDRESS are deliberately (?) vague. > > Well, even the usage of TAG_SSL_SEC_TRANS is not very clear from the > spec. I discussed this with several ORB vendors last year and I > guess it > didn't make it to the > RTF. Here is the main issue ? What if the object implementation > want's > to support both secure and non-secure (i.e, SSL and plain IIOP) > invocations ? How does the client ORB know what is supported by the > server and what is mandatory. Even with > SSL, what association options are mandatory, what are > supported. This is > all contained in the SSL tagged component, but is not explained as > to > how that information should be interpretted. As a result, different > vendors have implemented it in different ways and we have serious > interoperability problems. > I'd like to keep what I see as two issues separate. The relationship between the two ports in the IOR (the issue I raised). Secondly, the interpretation of association options is described in Security 1.2, 15.6.6. If these are ambiguity in the context of SSL then that would be a security RTF issue. In itself, I think that the TAG_SSL_SEC_TRANS has clear (if less than user friendly) semantics. The relevant text from Security 1.2, section 15.14 is: |" The port field contains the port number to be used instead of the port | defined in the accompanying IIOP profile body, if SSL is selected by the | client. It contains the TCP/IP port number (at the specified host) where | the target agent is listening for connection requests. The agent must be | ready to process IIOP messages on connections accepted at this port.| | | As with the other secure interoperability options, if the client invokes | the target without the appropriate level of security (e.g., if the client | is not secure and simply invokes the target ignoring all security TAGs in | the profile) the target shall raise the CORBA::NO_PERMISSION exception. " The first para quoted appears to allow flexibility: use the SSL port if SSL is selected by the client. But even if the client can select via a policy or some proprietary mechanism the server-side ORB cannot distinguish such a client selecting to not use the SSL port from one that was built pre-SSL and just didn't understand the TAG. The second para then defines the correct server behaviour: Assuming that the TAG_SSL_SEC_TRANS has been ignored (which the server side must assume), the server-side ORB must reply with NO_PERMISSION. Since that ORB created the reference it is capable of knowing which ObjectKeys relate to objects that assume interaction over SSL. This means that a single object reference cannot support interaction over both IIOP and IIOP-over-SSL. To do that you would need to create two references on the same Servant and manage which is for which transport in the application (not very pleasant perhaps). > The following is what I came up with to clarify things, and perhaps > should be added to the spec. Any comments ? > > There are three possible modes that an object can support with > respect > to > method invocations. They are secure only, non-secure only, and > secure > and non-secure modes respectively. These modes translate to IIOP > only, > IIOP over SSL only, and both IIOP and IIOP over SSL. The following > discusses the profile layout for these three cases within an > IOR. Please > note that only IIOP profiles are discussed here. This does not rule > out > other profiles in IOR. They are vendor specific and will be ignored > by > foreign ORBs. Also note that all cases discussed will use IIOP 1.1 > profile body. > > For reference: > -------------- > struct ProfileBody_1.1 > { > Version iiop_version; > string host; > unsigned short port; > sequence object_key; > > sequence components; > } > > TAG_SSL_SEC_TRANS: > struct SSL > { > AssociationOptions target_supports; > AssociationOptions target_requires; > unsigned short port; > } > > case 1: Object wants to support non-secure invocations only: > There will NOT be any SSL component tag in the IIOP profile > body. (If there are no other components present, then the > sequence length of components will be zero). > Object/server listens on the port # > specified in IIOP profile body. If user has set invocation > security features other than NoPtotection, then the client > ORB > should throw an exception(CORBA::IMPL_LIMIT) in this > case. > > case 2: Object supports secure invocations only: There will be SSL > component tag present in the profile body. > The port number in the profile body itself will be invalid > and > no one will be listening on that port. I think an SSL enabled ORB must still listen on this port, accept connections and then reply with NO_PERMISSION should a client try to invoke an object intended to be SSL only. Otherwise, old generation clients get a TCP level failure and can't give the application the proper exception. > So, how do the > invoking clients find that out? They first need to see if > SSL > component tag is present. If present, then they need to > check > 'target_requires' value. If target_requires contains > one of 'IntegrityAndConfidentiality', > 'EstablishTrustInClient' then the client shouldn't use the > port > # in the profile body and treat the port in the profile > body as > invalid. If it ignores this information and tries to > connect to > that port, it will get a connection error. For this > case, the 'target_requires' field should > contain one of those two above values, depending on what is > required. The client uses the port # in SSL component tag > to > connect to the server. What if a client doesn't know how to > interpret SSL component > tag It will try connecting to the port # in the profile > body, > ignoring the SSL component tag and will get a connection > error. > > > case 3: Object supports both secure and non-secure invocations: > There > will be SSL component tag present in the profile body and > both > the port numbers (i.e., one in profile body and one in > component tag) are valid. 'taget_requires' contains > nothing > and target_supports contains 'NoProtection' and one of > 'TrustInClient' and 'IntegrityAndConfidentiality' depending > upon > what is supported. Now the client may use either port > depending on > what the user has selected. > using a particular set of AssociationOptions to indicate that the > server is not adverse to accepting connection on the IIOP port is very > messy. With feature interactions between Messaging, Real-time and Fault Tolerance to consider in the future, I don't think complicating the SSL story will help. If the ability to use either port is to be sought then a cleaner information model for an IOR is what's needed not a messier > one. > > What is described above is only how the client ORB finds out what > the > server supports. However, what the client actually uses to connect > to > depends > upon what the user has selected. If what the user has selected does > not > match with what the target supports, the client ORB should throw > either > CORBA::NO_PERMISSION or CORBA::IMPL_LIMIT exception depending upon > the > case. User has an API available to him/her (we understand this API > differs > from vendor to vendor, although we tried to follow CORBA security > API > as > much as possible at Oracle) through which he/she can set the > security > features (i.e, NoProtection, Confidentiality, TrustInTarget, etc.) > and > credentials (certificates) before invocation. In all the above > cases, > there will only be ONE IIOP 1.1 profile present in the IOR. > > Sastry > > > > > So what should a client-side ORB do with one of these? It could > > view the IOR as broken, it could treat the ALTERNATE_ADDRESS > > component as invalid or it could treat the port in the ALTERNATE_ > > ADDRESS component as either for TCP connection requests >or< for > > SSL connection requests. It could even look for a second > > SSL_SEC_TRANS component. > > > > If the Messaging spec's changes to IIOP 1.2 are folded in then > > there is also the TAG_MESSAGE_ROUTERS component. If this is > > present in an IOR along with an SSL_SEC_TRANS, is an ORB allowed > > to send the data onto a router? If MESSAGE_ROUTERS coexists > > with an ALTENATE_ADDRESS are there any rules at all? > > > > Cheers, > > Dave Return-Path: Sender: jis@fpk.hp.com Date: Mon, 12 Oct 1998 10:16:29 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: Dave Stringer Cc: Sastry Malladi , interop@omg.org, jgoldberg@inprise.com Subject: Re: Issue # 2068 - Re: Tagged Component interactions References: <361E40AA.8B4B8324@nortel.com> <361E8141.4008DA02@us.oracle.com> <3620A6C1.4487E0AE@nortel.com> Dave Stringer wrote: > > As we're not supposed to have discussion on issues@ I'm recapping > the > thread thus far with some added remarks. (My fault for sending the > one > message to both lists at the outset). > > Jon, > shouldn't the TAG_MESSAGE_ROUTERS, which in the Measaging > submission is in module MessageRouting, appear in the IOR section of > IIOP > (as do the Security Tags) ? Core Revision 2.3 or 2.3a edits *do not include* changes from the Messaging stuff (well, except a few select pieces, which were explicitly added by the RTFs). The whole thing will get incorporated at some point after the 2.3a edits are done. Stay tuned. Jishnu. -- Jishnu Mukerji Systems Architect Advanced Development Enterprise Internet Solution Center Enterprise Systems Group Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Return-Path: Date: Mon, 12 Oct 1998 23:16:51 -0700 From: Sastry Malladi Organization: Oracle To: Dave Stringer CC: "Stringer, Dave (D.R.) [EXCHANGE:HAL02:HM20-I:BNR]" , interop@omg.org, jgoldberg@inprise.com, smalladi@us.oracle.com Subject: Re: Issue # 2068 - Re: Tagged Component interactions References: <361E40AA.8B4B8324@nortel.com> <361E8141.4008DA02@us.oracle.com> <3620A6C1.4487E0AE@nortel.com> Dave Stringer wrote: > As we're not supposed to have discussion on issues@ I'm recapping the > thread thus far with some added remarks. (My fault for sending the one > message to both lists at the outset). Sorry, I inadvertently replied to the original mail without realizing it is going to issues. I apologize. > > > Jon, > shouldn't the TAG_MESSAGE_ROUTERS, which in the Measaging > submission is in module MessageRouting, appear in the IOR section of > IIOP > (as do the Security Tags) ? > > Bob Kukura wrote: > > > > Jishnu & Dave, > > > > These documents don't have the 2.3a revisions applied yet, do they? The > > copy of 98-08-13 I just pulled down from the OMG server still has > > service_context first in the RequestHeader_1_2 and ReplyHeader_1_2 > > stucts, for instance. > > > > -Bob > > > > Jishnu Mukerji wrote: > > > > > > Dave Stringer wrote: > > > > > > > I guess we're onto Interop 2.4 RTF now so this might be an issue > > > > for that but I'm not sure what text we're working from just now. > > > > > > The final CORBA Core 2.3 Chapter 15 GIOP is ptc/98-08-13 and Chapter 13 > > > Interop Architecture is ptc/98-08-16. > > > > > > > > > Jishnu > > Sastry Malladi wrote: > > > > Dave Stringer wrote: > > > > > > Tom > > > > > > I guess we're onto Interop 2.4 RTF now so this might be an issue > > > for that but I'm not sure what text we're working from just now. > > > > > > The Tagged Components TAG_SSL_SEC_TRANS and TAG_IIOP_ALTERNATE_ADDRESS > > > both allow an IIOP profile to have an extra port in the IOR. The > > > words around SSL_SEC_TRANS say something like "to be used instead > > > of the one in the profile proper". Whereas the words around > > > ALTERNATE_ADDRESS are deliberately (?) vague. > > > > Well, even the usage of TAG_SSL_SEC_TRANS is not very clear from the > > spec. I discussed this with several ORB vendors last year and I guess it > > didn't make it to the > > RTF. Here is the main issue ? What if the object implementation want's > > to support both secure and non-secure (i.e, SSL and plain IIOP) > > invocations ? How does the client ORB know what is supported by the > > server and what is mandatory. Even with > > SSL, what association options are mandatory, what are supported. This is > > all contained in the SSL tagged component, but is not explained as to > > how that information should be interpretted. As a result, different > > vendors have implemented it in different ways and we have serious > > interoperability problems. > > > I'd like to keep what I see as two issues separate. The relationship > between the two ports in the IOR (the issue I raised). Secondly, the > interpretation of association options is described in Security 1.2, > 15.6.6. If these are ambiguity in the context of SSL then that would > be a security RTF issue. > > In itself, I think that the TAG_SSL_SEC_TRANS has clear (if less than > user friendly) semantics. > > The relevant text from Security 1.2, section 15.14 is: > > |" The port field contains the port number to be used instead of the > port > | defined in the accompanying IIOP profile body, if SSL is selected by > the > | client. It contains the TCP/IP port number (at the specified host) > where > | the target agent is listening for connection requests. The agent must > be > | ready to process IIOP messages on connections accepted at this port.| > | > | As with the other secure interoperability options, if the client > invokes > | the target without the appropriate level of security (e.g., if the > client > | is not secure and simply invokes the target ignoring all security TAGs > in > | the profile) the target shall raise the CORBA::NO_PERMISSION > exception. " > > The first para quoted appears to allow flexibility: use the SSL port if > SSL is selected by the client. But even if the client can select via a > policy or some proprietary mechanism the server-side ORB cannot > distinguish > such a client selecting to not use the SSL port from one that was built > pre-SSL and just didn't understand the TAG. Well, this is where association options in the accompanying component tag come into play. If the server also has'noProtection' as part of the "target_supports" field, then the client may choose to select either mechanism, i.,e, secure port or non-secure port. The way to do that, doesn't have to be proprietary either. The CORBA SEC defines IDL/APIS to set these options in the security current. My intention of the note was that, whatever the right interpretation is, it is not clear from the spec. As a matter of fact, we implemented the way you pointed out. But the some ORB vendors with whom we are trying to interoperate implemented the way I was interpreting the spec. So there are interoperability problems. > > > The second para then defines the correct server behaviour: Assuming that > the TAG_SSL_SEC_TRANS has been ignored (which the server side must > assume), > the server-side ORB must reply with NO_PERMISSION. Since that ORB > created the reference it is capable of knowing which ObjectKeys relate > to objects that assume interaction over SSL. > > This means that a single object reference cannot support interaction > over > both IIOP and IIOP-over-SSL. To do that you would need to create two > references on the same Servant and manage which is for which transport > in the application (not very pleasant perhaps). The whole purpose of my clarification was to avoid creating two different references for the same object. It's just a different interpretation from the same spec. > > > > The following is what I came up with to clarify things, and perhaps > > should be added to the spec. Any comments ? > > > > There are three possible modes that an object can support with respect > > to > > method invocations. They are secure only, non-secure only, and secure > > and non-secure modes respectively. These modes translate to IIOP only, > > IIOP over SSL only, and both IIOP and IIOP over SSL. The following > > discusses the profile layout for these three cases within an IOR. Please > > note that only IIOP profiles are discussed here. This does not rule out > > other profiles in IOR. They are vendor specific and will be ignored by > > foreign ORBs. Also note that all cases discussed will use IIOP 1.1 > > profile body. > > > > For reference: > > -------------- > > struct ProfileBody_1.1 > > { > > Version iiop_version; > > string host; > > unsigned short port; > > sequence object_key; > > > > sequence components; > > } > > > > TAG_SSL_SEC_TRANS: > > struct SSL > > { > > AssociationOptions target_supports; > > AssociationOptions target_requires; > > unsigned short port; > > } > > > > case 1: Object wants to support non-secure invocations only: > > There will NOT be any SSL component tag in the IIOP profile > > body. (If there are no other components present, then the > > sequence length of components will be zero). > > Object/server listens on the port # > > specified in IIOP profile body. If user has set invocation > > security features other than NoPtotection, then the client ORB > > should throw an exception(CORBA::IMPL_LIMIT) in this case. > > > > case 2: Object supports secure invocations only: There will be SSL > > component tag present in the profile body. > > The port number in the profile body itself will be invalid and > > no one will be listening on that port. > I think an SSL enabled ORB must still listen on this port, accept > connections and then reply with NO_PERMISSION should a client try to > invoke an object intended to be SSL only. Otherwise, old generation > clients > get a TCP level failure and can't give the application the proper > exception. > > So, how do the > > invoking clients find that out? They first need to see if SSL > > component tag is present. If present, then they need to check > > 'target_requires' value. If target_requires contains > > one of 'IntegrityAndConfidentiality', > > 'EstablishTrustInClient' then the client shouldn't use the port > > # in the profile body and treat the port in the profile body as > > invalid. If it ignores this information and tries to connect to > > that port, it will get a connection error. For this > > case, the 'target_requires' field should > > contain one of those two above values, depending on what is > > required. The client uses the port # in SSL component tag to > > connect to the server. What if a client doesn't know how to > > interpret SSL component > > tag It will try connecting to the port # in the profile body, > > ignoring the SSL component tag and will get a connection error. > > > > > > case 3: Object supports both secure and non-secure invocations: There > > will be SSL component tag present in the profile body and both > > the port numbers (i.e., one in profile body and one in > > component tag) are valid. 'taget_requires' contains nothing > > and target_supports contains 'NoProtection' and one of > > 'TrustInClient' and 'IntegrityAndConfidentiality' depending upon > > what is supported. Now the client may use either port depending on > > what the user has selected. > > > using a particular set of AssociationOptions to indicate that the server > is not adverse to accepting connection on the IIOP port is very messy. > With feature interactions between Messaging, Real-time and Fault > Tolerance > to consider in the future, I don't think complicating the SSL story > will help. If the ability to use either port is to be sought then a > cleaner information model for an IOR is what's needed not a messier one. > > > > > What is described above is only how the client ORB finds out what the > > server supports. However, what the client actually uses to connect to > > depends > > upon what the user has selected. If what the user has selected does not > > match with what the target supports, the client ORB should throw either > > CORBA::NO_PERMISSION or CORBA::IMPL_LIMIT exception depending upon the > > case. User has an API available to him/her (we understand this API > > differs > > from vendor to vendor, although we tried to follow CORBA security API > > as > > much as possible at Oracle) through which he/she can set the security > > features (i.e, NoProtection, Confidentiality, TrustInTarget, etc.) and > > credentials (certificates) before invocation. In all the above cases, > > there will only be ONE IIOP 1.1 profile present in the IOR. > > > > Sastry > > > > > > > > So what should a client-side ORB do with one of these? It could > > > view the IOR as broken, it could treat the ALTERNATE_ADDRESS > > > component as invalid or it could treat the port in the ALTERNATE_ > > > ADDRESS component as either for TCP connection requests >or< for > > > SSL connection requests. It could even look for a second > > > SSL_SEC_TRANS component. > > > > > > If the Messaging spec's changes to IIOP 1.2 are folded in then > > > there is also the TAG_MESSAGE_ROUTERS component. If this is > > > present in an IOR along with an SSL_SEC_TRANS, is an ORB allowed > > > to send the data onto a router? If MESSAGE_ROUTERS coexists > > > with an ALTENATE_ADDRESS are there any rules at all? > > > > > > Cheers, > > > Dave Return-Path: Date: Mon, 12 Oct 1998 13:56:44 -0700 From: "Jon Goldberg" Reply-To: goldberg@inprise.com X-Accept-Language: en To: Dave Stringer CC: Sastry Malladi , interop@omg.org Subject: Re: Issue # 2068 - Re: Tagged Component interactions References: <361E40AA.8B4B8324@nortel.com> <361E8141.4008DA02@us.oracle.com> <3620A6C1.4487E0AE@nortel.com> Dave Stringer wrote: > > As we're not supposed to have discussion on issues@ I'm recapping > the > thread thus far with some added remarks. (My fault for sending the > one > message to both lists at the outset). > > Jon, > shouldn't the TAG_MESSAGE_ROUTERS, which in the Measaging > submission is in module MessageRouting, appear in the IOR section of > IIOP > (as do the Security Tags) ? Since Messaging is not part of CORBA2.3, none of those additions have been incorparated as have the Security tags. Assuming Messaging is part of CORBA 3.0, the tags should be added. > > > If the Messaging spec's changes to IIOP 1.2 are folded in then > > > there is also the TAG_MESSAGE_ROUTERS component. If this is > > > present in an IOR along with an SSL_SEC_TRANS, is an ORB allowed > > > to send the data onto a router? If MESSAGE_ROUTERS coexists > > > with an ALTENATE_ADDRESS are there any rules at all? > > > An interop RTF adopted some of the GIOP changes that had initially beed discussed as part of the messaging submission, so those are part of IIOP 1.2. Since the messaging-specific changes (e.g. any reference to Routing) are not part of IIOP 1.2, the questions you are asking above is not yet addressable in the spec. Regardless, I would say that the TAG_MESSAGE_ROUTERS component has no impact on the SSL_SEC_TRANS component. If a client decides to use routing, it will be directly contacting the Router using the Router's IOR (within the context of the client's interaction with the Router, not the real target). The target router uses the security information in the target's IOR. The same thing goes for IIOP_ALTERNATE_ADDRESS. I agree that something would need to be changed for this component to indicate SSL-specific information (because currently it is only used to specify alternate IIOP/TCP addressing), but don't think there is any conflict where messaging is concerned. take care, Jon Date: Tue, 23 Feb 1999 11:15:44 +1000 (EST) From: Michi Henning To: Tom Rutt cc: interop@omg.org Subject: Re: Interop 2.4 RTF Vote 1 Organization: Triodia Technologies Content-ID: On Fri, 19 Feb 1999, Tom Rutt wrote: > zPlease vote on the attached proposed issue resolutions for Interop RTF 2.4, by > 5:00 PM EST, February 26, 1999. DSTC votes as follows: YES to 543, 1129, 1653, 1948, 1975, 1982, 2045, 2315, 2324, 2333. YES with option (c) to 1968. NO to 2068 and 2338 (2338 with a friendly amendment) 2068 rationale: > Resolution: Add clarification note stating use of both components is not > understood > Proposed Revised Text: Add a note after the definition of TAG_IIOP_ALTERNATE_ADDRESSS: > " > Note: The use of a TAG_IIOP_ALTERNATE_ADDRESS component together with a > TAG_SSL_SEC_TRANS component in the same IOR profile is for further study. To paraphrase: "We have no idea what this stuff actually means but we are confident we'll figure it out eventually." I don't think there is room in a specification for such words (blunt or not). 2338 rationale: > For GIOP 1.2 only the operation name "_non_existent" shall be used. ^^^^^^^^^^^^^^^^ I have no problem with the proposed resolution, but I suggest to change the wording of the above to "For GIOP 1.2 and later versions". Otherwise, we have to endlessly go back and patch this phrase as the protocol evolves. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Cc: interop@omg.org Date: Tue, 23 Feb 1999 09:47:21 -0500 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies - Bell Labs To: Michi Henning Original-CC: interop@omg.org Subject: Re: Intent of "for further study" References: Michi Henning wrote: > > On Fri, 19 Feb 1999, Tom Rutt wrote: > > > zPlease vote on the attached proposed issue resolutions for > Interop RTF 2.4, by > > 5:00 PM EST, February 26, 1999. > > DSTC votes as follows: > > YES to 543, 1129, 1653, 1948, 1975, 1982, 2045, 2315, 2324, 2333. > > YES with option (c) to 1968. > > NO to 2068 and 2338 (2338 with a friendly amendment) > > 2068 rationale: > > > Resolution: Add clarification note stating use of both components > is not > > understood > > Proposed Revised Text: Add a note after the definition of > TAG_IIOP_ALTERNATE_ADDRESSS: > > " > > Note: The use of a TAG_IIOP_ALTERNATE_ADDRESS component together > with a > > TAG_SSL_SEC_TRANS component in the same IOR profile is for further > study. > > To paraphrase: > > "We have no idea what this stuff actually means but we are > confident we'll figure it out eventually." > > I don't think there is room in a specification for such words (blunt > or not). > What the intention of the phrase is is that the two components were not designed to work together in the same IOR. Anyone who uses both is outside the design intentions of the protocol. I am sorry, but in the standards world "for further study" usually means "don't try it" or "let the tryer beware". Tom Rutt Interop RTF chair > Cheers, > > > Michi. > -- > Michi Henning +61 7 3236 1633 > Triodia Technologies +61 4 1118 2700 (mobile) > PO Box 372 +61 7 3211 0047 (fax) > Annerley 4103 michi@triodia.com > AUSTRALIA > http://www.triodia.com/staff/michi-henning.html -- ---------------------------------------------------------------- Tom Rutt Tel: +1 732 949 7862 Lucent Technologies - Bell Laboratories Fax: +1 732 949 1196 Rm 4L-336, 101 Crawford Corner Rd eail: terutt@lucent.com Holmdel NJ, 07733 ---------------------------------------------- Date: Wed, 24 Feb 1999 09:18:33 +1000 (EST) From: Michi Henning To: Tom Rutt cc: interop@omg.org Subject: Re: Intent of "for further study" Organization: Triodia Technologies On Tue, 23 Feb 1999, Tom Rutt wrote: > I accept your rewording. Please have your ballot require this > change so others can react to it. OK, here we go... ;-) DSTC votes yes on 2068 with the friendly amendment that the text be changed to: Note: The use of a TAG_IIOP_ALTERNATE_ADDRESS component together with a TAG_SSL_SEC_TRANS component in the same IOR profile currently has unspecified behavior; its use is therefore implementation- dependent. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Cc: Michi Henning , interop@omg.org Date: Wed, 24 Feb 1999 12:52:42 -0500 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies - Bell Labs To: Bob Kukura Original-CC: Michi Henning , interop@omg.org Subject: Re: Intent of "for further study" References: <36D333C8.1046A656@iona.com> Bob Kukura wrote: > > I haven't had a chance to send my votes yet, but I plan to vote NO > on > this one. But I haven't seen any discussion reflecting my view on > this. > > Simply put, the IIOP protocol uses the address in the profile body, > and > any additional addresses in TAG_IIOP_ALTERNATE_ADDRESS components. > The > IIOP/SSL protocol uses the port from the TAG_SSL_SEC_TRANS component > with the host from the profile body. The IIOP/SSL protocol does not > know anything about the TAG_IIOP_ALTERNATE_ADDRESS component, and > there > is no ambiguity at all - it simply cannot use it. then what is wrong with Michi's rewording? Note: The use of a TAG_IIOP_ALTERNATE_ADDRESS component together with a TAG_SSL_SEC_TRANS component in the same IOR profile currently has unspecified behavior; its use is therefore implementation- dependent. Are you suggesting there is more to it than this. Does this need to be addressed by the security RTF? > > It is unfortunate that there is currently no way to specify multiple > hosts for IIOP/SSL, but that should be addressed by replacing the > TAG_SSL_SEC_TRANS component with one that includes either a host as > well > as a port, or a list of TCP/IP addresses. My only question is > whether > this should be done by the Security RTF or the Interop RTF. > > -Bob > -- ---------------------------------------------------------------- Tom Rutt Tel: +1 732 949 7862 Lucent Technologies - Bell Laboratories Fax: +1 732 949 1196 Rm 4L-336, 101 Crawford Corner Rd eail: terutt@lucent.com Holmdel NJ, 07733 ---------------------------------------------- Sender: jon@floorboard.com Date: Wed, 24 Feb 1999 11:27:36 -0800 From: Jonathan Biggar X-Accept-Language: en To: terutt@lucent.com CC: Bob Kukura , Michi Henning , interop@omg.org Subject: Re: Intent of "for further study" References: <36D333C8.1046A656@iona.com> <36D43C6A.4568DDC3@lucent.com> Tom Rutt wrote: > > Bob Kukura wrote: > > > > I haven't had a chance to send my votes yet, but I plan to vote NO > on > > this one. But I haven't seen any discussion reflecting my view on > this. > > > > Simply put, the IIOP protocol uses the address in the profile > body, and > > any additional addresses in TAG_IIOP_ALTERNATE_ADDRESS > components. The > > IIOP/SSL protocol uses the port from the TAG_SSL_SEC_TRANS > component > > with the host from the profile body. The IIOP/SSL protocol does > not > > know anything about the TAG_IIOP_ALTERNATE_ADDRESS component, and > there > > is no ambiguity at all - it simply cannot use it. > > then what is wrong with Michi's rewording? > > Note: The use of a TAG_IIOP_ALTERNATE_ADDRESS component together > with a > TAG_SSL_SEC_TRANS component in the same IOR profile currently > has unspecified behavior; its use is therefore implementation- > dependent. > > Are you suggesting there is more to it than this. Does this need > to be addressed by the security RTF? I think what Bob is saying is that there is no ambiguity. IIOP/SSL uses the port in TAG_SSL_SEC_TRANS, and IIOP/GIOP uses the addresses in the IIOP profile as well as the ones in TAG_IIOP_ALTERNATE_ADDRESS. The standards are already clear and there is no undefined behavior possible. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Wed, 24 Feb 1999 14:49:50 -0500 From: Jishnu Mukerji Reply-To: jis@fpk.hp.com Organization: Hewlett-Packard New Jersey Laboratories To: terutt@lucent.com CC: Bob Kukura , Michi Henning , interop@omg.org Subject: Re: Intent of "for further study" References: <36D333C8.1046A656@iona.com> <36D43C6A.4568DDC3@lucent.com> Tom Rutt wrote: > Bob Kukura wrote: > > > > I haven't had a chance to send my votes yet, but I plan to vote NO > on > > this one. But I haven't seen any discussion reflecting my view on > this. > > > > Simply put, the IIOP protocol uses the address in the profile > body, and > > any additional addresses in TAG_IIOP_ALTERNATE_ADDRESS > components. The > > IIOP/SSL protocol uses the port from the TAG_SSL_SEC_TRANS > component > > with the host from the profile body. The IIOP/SSL protocol does > not > > know anything about the TAG_IIOP_ALTERNATE_ADDRESS component, and > there > > is no ambiguity at all - it simply cannot use it. > > then what is wrong with Michi's rewording? > > Note: The use of a TAG_IIOP_ALTERNATE_ADDRESS component together > with a > TAG_SSL_SEC_TRANS component in the same IOR profile currently > has unspecified behavior; its use is therefore implementation- > dependent. Actually, methinks it has very clearly specified behavior which consists of one of the following at the behest of the client ORB that is trying to establish a session: (i) It decides that it wants to use SSL and proceeds to use the info from TAG_IIOP_SEC_TRANS, or (ii) It decides to use TAG_IIOP_ALTERNATE_ADDRESS, and then SSL is completely out of the picture. Once this choice is made the behavior is perfectly well specified. Wording to this effect would be moire preferable than what Michi has proposed. There are no other possibilities. So to say that the behavior is unspecified is a tad too permissive. > Are you suggesting there is more to it than this. Does this need > to be addressed by the security RTF? I don't think the issue that we are voting on needs to be addressed in SecRTF. But Bob could raise the para excerpted from his message below as a separate issue and hand to the SecRTF. That should certainly not be addressed in Interop RTF, and making that change will require upping the minor version number of GIOP. > > It is unfortunate that there is currently no way to specify multiple > > hosts for IIOP/SSL, but that should be addressed by replacing the > > TAG_SSL_SEC_TRANS component with one that includes either a host as well > > as a port, or a list of TCP/IP addresses. My only question is whether > > this should be done by the Security RTF or the Interop RTF. > > > > -Bob > > > > -- > ---------------------------------------------------------------- > Tom Rutt Tel: +1 732 949 7862 > Lucent Technologies - Bell Laboratories Fax: +1 732 949 1196 > Rm 4L-336, 101 Crawford Corner Rd eail: terutt@lucent.com > Holmdel NJ, 07733 ---------------------------------------------- Date: Thu, 25 Feb 1999 06:50:34 +1000 (EST) From: Michi Henning To: Jishnu Mukerji cc: terutt@lucent.com, Bob Kukura , interop@omg.org Subject: Re: Intent of "for further study" Organization: Triodia Technologies On Wed, 24 Feb 1999, Jishnu Mukerji wrote: > Actually, methinks it has very clearly specified behavior which consists of > one of the following at the behest of the client ORB that is trying to > establish a session: > > (i) It decides that it wants to use SSL and proceeds to use the info from > TAG_IIOP_SEC_TRANS, or > > (ii) It decides to use TAG_IIOP_ALTERNATE_ADDRESS, and then SSL is completely > out of the picture. > > Once this choice is made the behavior is perfectly well specified. Wording to > this effect would be moire preferable than what Michi has proposed. I agree with you Jishnu. Seeing that the behavior actually *is* defined, I suggest to vote NO on this resolution and to place words into the spec that accurately describe the behavior. DSTC changes its vote to NO until we've sorted out what *really* should be happening ;-) Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Date: Wed, 24 Feb 1999 16:21:59 -0500 From: Bob Kukura Organization: IONA Technologies X-Accept-Language: en To: jis@fpk.hp.com CC: terutt@lucent.com, Michi Henning , interop@omg.org Subject: Re: Intent of "for further study" References: <36D333C8.1046A656@iona.com> <36D43C6A.4568DDC3@lucent.com> <36D457DE.DF90C16B@fpk.hp.com> Thanks, Jon, Jishnu, Michi, and Tom for following up on this. I've been traveling the past couple of days and have only been intermittently connected. Jishnu Mukerji wrote: > > Tom Rutt wrote: > > > Bob Kukura wrote: > > > > > > I haven't had a chance to send my votes yet, but I plan to vote > NO on > > > this one. But I haven't seen any discussion reflecting my view > on this. > > > > > > Simply put, the IIOP protocol uses the address in the profile > body, and > > > any additional addresses in TAG_IIOP_ALTERNATE_ADDRESS > components. The > > > IIOP/SSL protocol uses the port from the TAG_SSL_SEC_TRANS > component > > > with the host from the profile body. The IIOP/SSL protocol does > not > > > know anything about the TAG_IIOP_ALTERNATE_ADDRESS component, > and there > > > is no ambiguity at all - it simply cannot use it. > > > > then what is wrong with Michi's rewording? > > > > Note: The use of a TAG_IIOP_ALTERNATE_ADDRESS component together > with a > > TAG_SSL_SEC_TRANS component in the same IOR profile > currently > > has unspecified behavior; its use is therefore > implementation- > > dependent. > > Actually, methinks it has very clearly specified behavior which > consists of > one of the following at the behest of the client ORB that is trying > to > establish a session: As Jon correctly assumed, this is exacly my point. It ain't broken, so don't fix it. > > (i) It decides that it wants to use SSL and proceeds to use the info > from > TAG_IIOP_SEC_TRANS, or > > (ii) It decides to use TAG_IIOP_ALTERNATE_ADDRESS, and then SSL is > completely > out of the picture. > > Once this choice is made the behavior is perfectly well > specified. Wording to > this effect would be moire preferable than what Michi has proposed. > > There are no other possibilities. So to say that the behavior is > unspecified > is a tad too permissive. > > > Are you suggesting there is more to it than this. Does this need > > to be addressed by the security RTF? > > I don't think the issue that we are voting on needs to be addressed > in SecRTF. > But Bob could raise the para excerpted from his message below as a > separate > issue and hand to the SecRTF. That should certainly not be addressed > in > Interop RTF, and making that change will require upping the minor > version > number of GIOP. Jishnu, did you mean to say "... will not require upping ..."? I would not think that revving SSL by adding a new alternative component should require upping GIOP's version. But then again, I've never believed that components are actually "droppable" in practice, so I don't worry too much about new components getting dropped by existing ORBs. -Bob > > > > It is unfortunate that there is currently no way to specify > multiple > > > hosts for IIOP/SSL, but that should be addressed by replacing > the > > > TAG_SSL_SEC_TRANS component with one that includes either a host > as well > > > as a port, or a list of TCP/IP addresses. My only question is > whether > > > this should be done by the Security RTF or the Interop RTF. > > > > > > -Bob > > > > > > > -- > > ---------------------------------------------------------------- > > Tom Rutt Tel: +1 732 949 7862 > > Lucent Technologies - Bell Laboratories Fax: +1 732 949 1196 > > Rm 4L-336, 101 Crawford Corner Rd eail: terutt@lucent.com > > Holmdel NJ, 07733 ---------------------------------------------- Cc: Jishnu Mukerji , Bob Kukura , interop@omg.org Date: Wed, 24 Feb 1999 16:17:09 -0500 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies - Bell Labs To: Michi Henning Original-CC: Jishnu Mukerji , Bob Kukura , interop@omg.org Subject: Re: Intent of "for further study" References: Michi Henning wrote: > > On Wed, 24 Feb 1999, Jishnu Mukerji wrote: > > > Actually, methinks it has very clearly specified behavior which > consists of > > one of the following at the behest of the client ORB that is > trying to > > establish a session: > > > > (i) It decides that it wants to use SSL and proceeds to use the > info from > > TAG_IIOP_SEC_TRANS, or > > > > (ii) It decides to use TAG_IIOP_ALTERNATE_ADDRESS, and then SSL is > completely > > out of the picture. > > > > Once this choice is made the behavior is perfectly well > specified. Wording to > > this effect would be moire preferable than what Michi has > proposed. > > I agree with you Jishnu. Seeing that the behavior actually *is* > defined, > I suggest to vote NO on this resolution and to place words into the > spec > that accurately describe the behavior. DSTC changes its vote to NO > until > we've sorted out what *really* should be happening ;-) > > Cheers, > > > Michi. > -- I also now change my vote on this issue proposed resolution to NO. > Sorry Dave, but there does not seem to be a real problem here. Since this issue will likely fail, If anyone wants to propose another proposed solution for a second vote, let me know, otherwise I would like to close the issue with no change if it fails in this round. Jishnu, do you propose we need a clarification or not? -- ---------------------------------------------------------------- Tom Rutt Tel: +1 732 949 7862 Lucent Technologies - Bell Laboratories Fax: +1 732 949 1196 Rm 4L-336, 101 Crawford Corner Rd eail: terutt@lucent.com Holmdel NJ, 07733 ---------------------------------------------- Date: Fri, 26 Feb 1999 13:37:28 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Core RTF 2.4 Vote 4 To: jis@fpk.hp.com Cc: orb_revision@omg.org Content-MD5: D4Lqd4/m5H/3zAqy5VAnhQ== Sun votes as follows on Core RTF 2.4 vote 4: NO on issues 616, 2308. YES on issues 2308, 2314, 2343, 2436, 2454. NO on 1665 (if it's still part of vote 4) since there has not been enough time to evaluate Paul's proposal from 2/25.