Issue 2958: Security: Need to complete SecurityReplaceable (sec-rev) Source: Syracuse University (Dr. Polar Humenn, polar(at)adiron.com) Nature: Uncategorized Issue Severity: Summary: The Security Replaceablity interfaces are deficient in the aspect of creating the correct components for the IIOP profile of the IOR for the specified credentials. The Vault::init_security_context, takes a parameter, mech_data, which is the data component of the tagged component that was selected by the ORB from the IOR for which the mechanism that was used in starting the secure association. However, analogously on the accepting side, there is no way to create a tagged component for use in the IOR! Adding functionality to the vault will complete the security replaceablity and fill this hole. I suggest to *add* the following definitions to Security Replaceable. #include <IOP.idl> typedef sequence<IOP:TaggedComponent> TaggedComponentList; interface Vault { TaggedComponentList create_iiop_components( in SecurityLevel2::CredentialsList creds_list ); }; The Vault produces the correct IOP tagged components for the set of credentials specified that will be placed in the IIOP profile. There is no definite 1 to 1 correlation between the credentials in the given list and the tagged components generated. The vault may determine that some credentials are redundant, irrelevant, or take precedence over other credentials. Resolution: Revised Text: Action: Close Issue 2958 3044 3047 About not being able to get IOR components for supported security mechanisms: [Add the following end of the Vault section. Add on page 15-173 before the "The Security Context Object" header.] create_ior_components This operation is called to create a set of security related TaggedComponents that indicate the security mechanisms supported by the Vault and the given set of Credentials objects. IOP::TaggedComponentList create_ior_components( in SecurityLevel2::CredentialsList creds_list ); Parameters creds_list This argument lists the credentials that are to be considered in creating the Tagged Components. Return Value This operation returns the Tagged Components. Add the following to the Consolidate IDL Appendix A.7. Security Replaceable Service Interfaces, add: #include <IOP.idl> and in the definition of the Vault, add: IOP::TaggedComponentList create_ior_components( in SecurityLevel2::CredentialsList creds_list ); Actions taken: October 26, 1999: received issue March 10, 2000: closed issue Discussion: End of Annotations:===== X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 26 Oct 1999 12:52:20 -0400 (EDT) From: Polar Humenn To: issues@omg.org, secrev@omg.org Subject: Security: Need to complete SecurityReplaceable Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: !5De9o$$!!/01e94[2e9 Document: Security 1.5, of course! Severity: Critical, naturally. Description: The Security Replaceablity interfaces are deficient in the aspect of creating the correct components for the IIOP profile of the IOR for the specified credentials. The Vault::init_security_context, takes a parameter, mech_data, which is the data component of the tagged component that was selected by the ORB from the IOR for which the mechanism that was used in starting the secure association. However, analogously on the accepting side, there is no way to create a tagged component for use in the IOR! Adding functionality to the vault will complete the security replaceablity and fill this hole. I suggest to *add* the following definitions to Security Replaceable. #include typedef sequence TaggedComponentList; interface Vault { TaggedComponentList create_iiop_components( in SecurityLevel2::CredentialsList creds_list ); }; The Vault produces the correct IOP tagged components for the set of credentials specified that will be placed in the IIOP profile. There is no definite 1 to 1 correlation between the credentials in the given list and the tagged components generated. The vault may determine that some credentials are redundant, irrelevant, or take precedence over other credentials. ==== This addition will complete the SecurityReplacable Vault interface so that it can truly be replaceable within a SECIOP framework. Regards, -Polar ------------------------------------------------------------------- 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 Sender: jis@fpk.hp.com Message-ID: <3815F150.B8BC972C@fpk.hp.com> Date: Tue, 26 Oct 1999 14:22:08 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: Polar Humenn CC: issues@omg.org, secrev@omg.org Subject: Re: Security: Need to complete SecurityReplaceable References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 62ed9eYL!!p~-e96G@e9 Polar Humenn wrote: > > Document: Security 1.5, of course! > Severity: Critical, naturally. > Description: > > The Security Replaceablity interfaces are deficient in the aspect of > creating the correct components for the IIOP profile of the IOR for > the > specified credentials. > > The Vault::init_security_context, takes a parameter, mech_data, > which is > the data component of the tagged component that was selected by the > ORB > from the IOR for which the mechanism that was used in starting the > secure > association. > > However, analogously on the accepting side, there is no way to > create a > tagged component for use in the IOR! Adding functionality to the > vault > will complete the security replaceablity and fill this hole. > > I suggest to *add* the following definitions to Security > Replaceable. > > #include > > typedef sequence TaggedComponentList; > > interface Vault { > TaggedComponentList create_iiop_components( > in SecurityLevel2::CredentialsList creds_list > ); > }; > > The Vault produces the correct IOP tagged components for the set of > credentials specified that will be placed in the IIOP profile. > > There is no definite 1 to 1 correlation between the credentials in > the > given list and the tagged components generated. The vault may > determine > that some credentials are redundant, irrelevant, or take precedence > over > other credentials. > > ==== > > This addition will complete the SecurityReplacable Vault interface > so that > it can truly be replaceable within a SECIOP framework. Just a minor suggestion. Change the name of the operation to "create_ior_components", since the tagged components thata re being created are IOR components that may potentially be used someday in an IOR that does specify IIOP/ aka GIOP over TCPIP as the base protocol. There is no reason to restrict this general vault mechanism to IIOP forever. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 26 Oct 1999 14:40:29 -0400 (EDT) From: Polar Humenn To: Jishnu Mukerji cc: issues@omg.org, secrev@omg.org Subject: Re: Security: Need to complete SecurityReplaceable In-Reply-To: <3815F150.B8BC972C@fpk.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: HTk!!P=D!!U^F!!0=c!! On Tue, 26 Oct 1999, Jishnu Mukerji wrote: > Just a minor suggestion. Change the name of the operation to > "create_ior_components", since the tagged components thata re being > created are > IOR components that may potentially be used someday in an IOR that > does specify > IIOP/ aka GIOP over TCPIP as the base protocol. There is no reason > to restrict > this general vault mechanism to IIOP forever. That would be fine, but what will constitute them being lifted from the IIOP profile in the future? I kinda thought it would be feasible, so that the vault may be able to be extended for a future protocol. However, a better way probably just occurred to me. Whould it be better to have something like this, then? typedef sequence TaggedComponentList; interface Vault { TaggedComponentList create_ior_components( in IOP::ProfileId profile_tag, in Security::CredentialsList creds_list ); }; Now that I think about it, this is probably the way to go, since profiles are *suppose* to (at last I heard, which abeit, was over year ago since I looked into it), completely independant. Thanks for the feedback. It's appreciated that someone is watching. Cheers, -Polar ------------------------------------------------------------------- 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 From: "Ryan Eberhard" To: "Polar Humenn" , , Subject: RE: Security: Need to complete SecurityReplaceable Date: Tue, 26 Oct 1999 14:38:45 -0400 Message-ID: <007601bf1fe1$55c575d0$a92f0118@ztglw.carneg1.pa.home.com> 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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ]BO!!8#Td9DTOe9DM3e9 Polar, For my part, this interface looks good. Have we addressed the matching issue (it may not have a number) of how the ORB determines that the security service has a new IOR for the target object? Ryan > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Tuesday, October 26, 1999 12:52 PM > To: issues@omg.org; secrev@omg.org > Subject: Security: Need to complete SecurityReplaceable > > > > Document: Security 1.5, of course! > Severity: Critical, naturally. > Description: > > The Security Replaceablity interfaces are deficient in the aspect of > creating the correct components for the IIOP profile of the IOR for > the > specified credentials. > > The Vault::init_security_context, takes a parameter, mech_data, > which is > the data component of the tagged component that was selected by the > ORB > from the IOR for which the mechanism that was used in starting the > secure > association. > > However, analogously on the accepting side, there is no way to > create a > tagged component for use in the IOR! Adding functionality to the > vault > will complete the security replaceablity and fill this hole. > > I suggest to *add* the following definitions to Security > Replaceable. > > #include > > typedef sequence TaggedComponentList; > > interface Vault { > TaggedComponentList create_iiop_components( > in SecurityLevel2::CredentialsList creds_list > ); > }; > > The Vault produces the correct IOP tagged components for the set of > credentials specified that will be placed in the IIOP profile. > > There is no definite 1 to 1 correlation between the credentials in > the > given list and the tagged components generated. The vault may > determine > that some credentials are redundant, irrelevant, or take precedence > over > other credentials. > > ==== > > This addition will complete the SecurityReplacable Vault interface > so that > it can truly be replaceable within a SECIOP framework. > > Regards, > -Polar > > ------------------------------------------------------------------- > 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 > X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 26 Oct 1999 16:03:04 -0400 (EDT) From: Polar Humenn To: Ryan Eberhard cc: issues@omg.org, secrev@omg.org Subject: RE: Security: Need to complete SecurityReplaceable In-Reply-To: <007601bf1fe1$55c575d0$a92f0118@ztglw.carneg1.pa.home.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: iEP!!5NR!!">~!!*\Me9 On Tue, 26 Oct 1999, Ryan Eberhard wrote: > Polar, > > For my part, this interface looks good. > > Have we addressed the matching issue (it may not have a number) of > how the > ORB determines that the security service has a new IOR for the > target > object? Ryan, Could you explain further, what you mean by "new" IOR? Cheers, -Polar ------------------------------------------------------------------- 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 Sender: jis@fpk.hp.com Message-ID: <381609CF.AFD848D@fpk.hp.com> Date: Tue, 26 Oct 1999 16:06:39 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: Polar Humenn Cc: secrev@omg.org Subject: Re: Security: Need to complete SecurityReplaceable References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: L4I!!JKad9P+V!!l#Oe9 Polar Humenn wrote: > > On Tue, 26 Oct 1999, Jishnu Mukerji wrote: > > > Just a minor suggestion. Change the name of the operation to > > "create_ior_components", since the tagged components thata re > being created are > > IOR components that may potentially be used someday in an IOR that > does specify > > IIOP/ aka GIOP over TCPIP as the base protocol. There is no reason > to restrict > > this general vault mechanism to IIOP forever. > > That would be fine, but what will constitute them being lifted from > the > IIOP profile in the future? > > I kinda thought it would be feasible, so that the vault may be able > to be > extended for a future protocol. However, a better way probably just > occurred to me. Whould it be better to have something like this, > then? > > typedef sequence TaggedComponentList; > > interface Vault { > TaggedComponentList create_ior_components( > in IOP::ProfileId profile_tag, > in Security::CredentialsList creds_list > ); > }; > > Now that I think about it, this is probably the way to go, since > profiles > are *suppose* to (at last I heard, which abeit, was over year ago > since I > looked into it), completely independant. Yes, I think so too, and Yes. > Thanks for the feedback. It's appreciated that someone is watching. You're welcome. I better do my penance now since I am only triple booked for the timeslot in which Security RTF meets in Cambridge.:-( Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. From: "Ryan Eberhard" To: "Polar Humenn" Cc: , Subject: RE: Security: Need to complete SecurityReplaceable Date: Tue, 26 Oct 1999 16:11:47 -0400 Message-ID: <007e01bf1fee$5506a6c0$a92f0118@ztglw.carneg1.pa.home.com> 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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" X-UIDL: UnCe9f7B!!!^5e9p_G!! I should say "updated", i.e. with the SECIOP specific profiles. It is "new" in the sense that it is different from the IOR that the ORB would have generated by default. Specifically, I'm thinking of this problem from the viewpoint of a third-party trying to integrate an implementation of the security service into an ORB. Ryan > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Tuesday, October 26, 1999 4:03 PM > To: Ryan Eberhard > Cc: issues@omg.org; secrev@omg.org > Subject: RE: Security: Need to complete SecurityReplaceable > > > On Tue, 26 Oct 1999, Ryan Eberhard wrote: > > > Polar, > > > > For my part, this interface looks good. > > > > Have we addressed the matching issue (it may not have a number) > of how the > > ORB determines that the security service has a new IOR for the > target > > object? > > Ryan, > > Could you explain further, what you mean by "new" IOR? > > Cheers, > -Polar > > ------------------------------------------------------------------- > 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 > Sender: jis@fpk.hp.com Message-ID: <38160CC9.5D924969@fpk.hp.com> Date: Tue, 26 Oct 1999 16:19:21 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: Ryan Eberhard CC: Polar Humenn , secrev@omg.org Subject: Re: Security: Need to complete SecurityReplaceable References: <007601bf1fe1$55c575d0$a92f0118@ztglw.carneg1.pa.home.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: [K-e9U%6!!:2G!!I/?e9 Ryan Eberhard wrote: > > Polar, > > For my part, this interface looks good. > > Have we addressed the matching issue (it may not have a number) of > how the > ORB determines that the security service has a new IOR for the > target > object? > > Ryan Isn't this where the IOR interceptor comes in? There is quite a bit of interesting discussion going on in the Interceptor submitters list on this subject, specifically, what the frequency of call to the IOR interceptor should be, and such. You will see the current state of the document as soon as it gets on the server. Essentially what happens is that the Security Service plants an IOR interceptor. This interceptor is called by the ORB/POA to gather information on what goes in the IOR, This interceptor is the one that presumably calls this Vault operation that Polar is positing to put together the info that it needs to invoke the add_ocmponent operation of the IORInfo object. Did I get it about right Polar? Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. From: "Ryan Eberhard" To: Cc: "Polar Humenn" , Subject: RE: Security: Need to complete SecurityReplaceable Date: Tue, 26 Oct 1999 16:21:53 -0400 Message-ID: <007f01bf1fef$bdbabd40$a92f0118@ztglw.carneg1.pa.home.com> 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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <38160CC9.5D924969@fpk.hp.com> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 5\a!!HjG!!])Sd9o+Fe9 Thanks, this is what I am looking for. > -----Original Message----- > From: jis@fpk.hp.com [mailto:jis@fpk.hp.com] > Sent: Tuesday, October 26, 1999 4:19 PM > To: Ryan Eberhard > Cc: Polar Humenn; secrev@omg.org > Subject: Re: Security: Need to complete SecurityReplaceable > > > Ryan Eberhard wrote: > > > > Polar, > > > > For my part, this interface looks good. > > > > Have we addressed the matching issue (it may not have a number) > of how the > > ORB determines that the security service has a new IOR for the > target > > object? > > > > Ryan > > Isn't this where the IOR interceptor comes in? There is quite a bit > of > interesting discussion going on in the Interceptor submitters list > on this > subject, specifically, what the frequency of call to the IOR > interceptor should > be, and such. You will see the current state of the document as > soon as it gets > on the server. > > Essentially what happens is that the Security Service plants an > IOR interceptor. > This interceptor is called by the ORB/POA to gather information > on what goes in > the IOR, This interceptor is the one that presumably calls this > Vault operation > that Polar is positing to put together the info that it needs to > invoke the > add_ocmponent operation of the IORInfo object. Did I get it about > right Polar? > > Jishnu. > -- > Jishnu Mukerji > Systems Architect > > Email: jis@fpk.hp.com Hewlett-Packard EIAL, > Tel: +1 973 443 7528 300 Campus Drive, 2E-62, > Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. > X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 26 Oct 1999 16:34:02 -0400 (EDT) From: Polar Humenn To: Ryan Eberhard cc: secrev@omg.org, issues@omg.org Subject: RE: Security: Need to complete SecurityReplaceable In-Reply-To: <007e01bf1fee$5506a6c0$a92f0118@ztglw.carneg1.pa.home.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ~g]!!cUp!!-XT!!<-:e9 Well it is outlined what the components are that are supposed to be understood by SECIOP, namely, KerberosV5, SPKM1, SPKM2, and the Sesame stuff. Those match up to mechanisms in the following way: The tag for Kerberos is 17. Therefore, "mechanism" on the user side, is "17", or "17,..", if there are any specified crypto profiles. This information comes out of the IOR component for the known mechanisms via the crypto profile. So therefore, there is a way to correlate them. Now I do admit we have a hard time with TAG_GENERIC_SEC_MECH, which is labed by tag 22 and an OID. For that we do a constructed version of "22:" where oidhex is the hex string representing the ASN1 encoded byte string of an ObjectIndentifer (OID) which is in that IOR component. (Although this could be better specified, of which I'm sure we will get to in CSIv2 :). A hex string is good enough without resorting to an OID string parser of various forms "iso(1) member-body(2).. " ... "{ 1 2 11435 11 2 }", "1.2.114345.22.1", etc. It serves enough to distinguish mechanisms based solely on the TAG_GENERIC_SEC_MECH component. Is this what you are getting at? -Polar On Tue, 26 Oct 1999, Ryan Eberhard wrote: > I should say "updated", i.e. with the SECIOP specific profiles. It is "new" > in the sense that it is different from the IOR that the ORB would have > generated by default. Specifically, I'm thinking of this problem from the > viewpoint of a third-party trying to integrate an implementation of the > security service into an ORB. > > Ryan > > > -----Original Message----- > > From: Polar Humenn [mailto:polar@adiron.com] > > Sent: Tuesday, October 26, 1999 4:03 PM > > To: Ryan Eberhard > > Cc: issues@omg.org; secrev@omg.org > > Subject: RE: Security: Need to complete SecurityReplaceable > > > > > > On Tue, 26 Oct 1999, Ryan Eberhard wrote: > > > > > Polar, > > > > > > For my part, this interface looks good. > > > > > > Have we addressed the matching issue (it may not have a number) > > of how the > > > ORB determines that the security service has a new IOR for the target > > > object? > > > > Ryan, > > > > Could you explain further, what you mean by "new" IOR? > > > > Cheers, > > -Polar > > > > ------------------------------------------------------------------- > > 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 > > > ------------------------------------------------------------------- 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 X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 26 Oct 1999 16:48:27 -0400 (EDT) From: Polar Humenn To: Jishnu Mukerji cc: Ryan Eberhard , secrev@omg.org Subject: Re: Security: Need to complete SecurityReplaceable In-Reply-To: <38160CC9.5D924969@fpk.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: lI/e9BnL!!10id9iHNe9 On Tue, 26 Oct 1999, Jishnu Mukerji wrote: > Ryan Eberhard wrote: > > > > Polar, > > > > For my part, this interface looks good. > > > > Have we addressed the matching issue (it may not have a number) of > how the > > ORB determines that the security service has a new IOR for the > target > > object? > > > > Ryan > Isn't this where the IOR interceptor comes in? There is quite a bit > of > interesting discussion going on in the Interceptor submitters list > on this > subject, specifically, what the frequency of call to the IOR > interceptor should > be, and such. You will see the current state of the document as soon > as it gets > on the server. > > Essentially what happens is that the Security Service plants an IOR > interceptor. > This interceptor is called by the ORB/POA to gather information on > what goes in > the IOR, This interceptor is the one that presumably calls this > Vault operation > that Polar is positing to put together the info that it needs to > invoke the > add_ocmponent operation of the IORInfo object. Did I get it about > right Polar? Yeah something like that of the sort, I would suppose. I had imagined this sort of thing to be propritary as well. As long as we can get at it at the transport level, or low down, that'll be fine, I guess. ------------------------------------------------------------------- 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 From: "Ryan Eberhard" To: "Polar Humenn" , "Jishnu Mukerji" Cc: Subject: RE: Security: Need to complete SecurityReplaceable Date: Tue, 26 Oct 1999 17:01:04 -0400 Message-ID: <008301bf1ff5$378031a0$a92f0118@ztglw.carneg1.pa.home.com> 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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" X-UIDL: OFUd9jAEe9QB-e9O`%"! Polar, This is exactly the sort of thing that should be standardized, because without hooks like these, ORB vendors won't know what is required of them to support external security services and security vendors can't rely on being able to integrate into distinct ORB's in a uniform way (the current situation). Without these types of hooks, security still won't be fully replaceable, and it is hard to see the competitive advantage/distincition in how ORB's determine that updated IOR profiles are available. Ryan > -----Original Message----- > From: Polar Humenn [mailto:polar@adiron.com] > Sent: Tuesday, October 26, 1999 4:48 PM > To: Jishnu Mukerji > Cc: Ryan Eberhard; secrev@omg.org > Subject: Re: Security: Need to complete SecurityReplaceable > > > On Tue, 26 Oct 1999, Jishnu Mukerji wrote: > > > Ryan Eberhard wrote: > > > > > > Polar, > > > > > > For my part, this interface looks good. > > > > > > Have we addressed the matching issue (it may not have a > number) of how the > > > ORB determines that the security service has a new IOR for the > target > > > object? > > > > > > Ryan > > Isn't this where the IOR interceptor comes in? There is quite a > bit of > > interesting discussion going on in the Interceptor submitters > list on this > > subject, specifically, what the frequency of call to the IOR > interceptor should > > be, and such. You will see the current state of the document as > soon as it gets > > on the server. > > > > Essentially what happens is that the Security Service plants an > IOR interceptor. > > This interceptor is called by the ORB/POA to gather information > on what goes in > > the IOR, This interceptor is the one that presumably calls this > Vault operation > > that Polar is positing to put together the info that it needs > to invoke the > > add_ocmponent operation of the IORInfo object. Did I get it > about right Polar? > > Yeah something like that of the sort, I would suppose. > I had imagined this sort of thing to be propritary as well. As long > as we > can get at it at the transport level, or low down, that'll be fine, > I > guess. > > ------------------------------------------------------------------- > 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 > Sender: jis@fpk.hp.com Message-ID: <381616BE.A7FE5A08@fpk.hp.com> Date: Tue, 26 Oct 1999 17:01:50 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: Polar Humenn Cc: Ryan Eberhard , secrev@omg.org Subject: Re: Security: Need to complete SecurityReplaceable References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ^4A!!n^c!!aTld9jS0e9 Polar Humenn wrote: > > On Tue, 26 Oct 1999, Jishnu Mukerji wrote: > > > Ryan Eberhard wrote: > > > > > > Polar, > > > > > > For my part, this interface looks good. > > > > > > Have we addressed the matching issue (it may not have a number) > of how the > > > ORB determines that the security service has a new IOR for the > target > > > object? > > > > > > Ryan > > Isn't this where the IOR interceptor comes in? There is quite a > bit of > > interesting discussion going on in the Interceptor submitters list > on this > > subject, specifically, what the frequency of call to the IOR > interceptor should > > be, and such. You will see the current state of the document as > soon as it gets > > on the server. > > > > Essentially what happens is that the Security Service plants an > IOR interceptor. > > This interceptor is called by the ORB/POA to gather information on > what goes in > > the IOR, This interceptor is the one that presumably calls this > Vault operation > > that Polar is positing to put together the info that it needs to > invoke the > > add_ocmponent operation of the IORInfo object. Did I get it about > right Polar? > > Yeah something like that of the sort, I would suppose. > I had imagined this sort of thing to be propritary as well. As long > as we > can get at it at the transport level, or low down, that'll be fine, > I > guess. Yup, that is always an option. I presumed that Ryan was asking the question with reference to a standard way for the ORB to get this info. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 26 Oct 1999 17:20:36 -0400 (EDT) From: Polar Humenn To: Ryan Eberhard cc: Jishnu Mukerji , secrev@omg.org Subject: RE: Security: Need to complete SecurityReplaceable In-Reply-To: <008301bf1ff5$378031a0$a92f0118@ztglw.carneg1.pa.home.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Polar, > > This is exactly the sort of thing that should be standardized, > because > without hooks like these, ORB vendors won't know what is required of > them to > support external security services and security vendors can't rely > on being > able to integrate into distinct ORB's in a uniform way (the current > situation). > > Without these types of hooks, security still won't be fully > replaceable, and > it is hard to see the competitive advantage/distincition in how > ORB's > determine that updated IOR profiles are available. > > Ryan > > > -----Original Message----- > > From: Polar Humenn [mailto:polar@adiron.com] > > Sent: Tuesday, October 26, 1999 4:48 PM > > To: Jishnu Mukerji > > Cc: Ryan Eberhard; secrev@omg.org > > Subject: Re: Security: Need to complete SecurityReplaceable > > > > > > On Tue, 26 Oct 1999, Jishnu Mukerji wrote: > > > > > Ryan Eberhard wrote: > > > > > > > > Polar, > > > > > > > > For my part, this interface looks good. > > > > > > > > Have we addressed the matching issue (it may not have a > > number) of how the > > > > ORB determines that the security service has a new IOR for the > target > > > > object? > > > > > > > > Ryan > > > Isn't this where the IOR interceptor comes in? There is quite a > bit of > > > interesting discussion going on in the Interceptor submitters > > list on this > > > subject, specifically, what the frequency of call to the IOR > > interceptor should > > > be, and such. You will see the current state of the document as > > soon as it gets > > > on the server. > > > > > > Essentially what happens is that the Security Service plants an > > IOR interceptor. > > > This interceptor is called by the ORB/POA to gather information > > on what goes in > > > the IOR, This interceptor is the one that presumably calls this > > Vault operation > > > that Polar is positing to put together the info that it needs > > to invoke the > > > add_ocmponent operation of the IORInfo object. Did I get it > > about right Polar? > > > > Yeah something like that of the sort, I would suppose. > > I had imagined this sort of thing to be propritary as well. As > long as we > > can get at it at the transport level, or low down, that'll be > fine, I > > guess. > > > > > ------------------------------------------------------------------- > > 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 > > > ------------------------------------------------------------------- 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: Tue, 26 Oct 1999 20:47:05 -0400 From: Bob Kukura Organization: IONA Technologies X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn CC: Ryan Eberhard , Jishnu Mukerji , secrev@omg.org Subject: Re: Security: Need to complete SecurityReplaceable References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 6[(!!L5J!!lgK!!phKd9 I agree 100% with Polar here, particularly regarding replaceability at the vault level. -Bob Polar Humenn wrote: > > Ryan, > > For security to be a "fully" replaceable security service AND > interoperable, you will need access to the transport. That is such a > can > of worms, and hardly practical for some ORBs. > > I believe, Security will be available to ORBs that give the > interfaces > necessary to give you acess to the transport layer. However, I don't > expect any of those interfaces to be the same between ORBs due to > different underlying architectures. > > So, an IOR interceptor may be easy enough, but there is enough out > there > to stop "fully" replaceable security services. > > It's not bad, just some glue code must be written for each orb that > yeilds > those interfaces. I don't see that as all that bad. > > Even better would be ORBs that would give you a SECIOP finite state > machine and a way to register vaults in it. Then you got all the > replaceability interfaces you need, without harming ORB internal > architectures and possiblities for optimizations. > > Cheers, > -Polar > > On Tue, 26 Oct 1999, Ryan Eberhard wrote: > > > Polar, > > > > This is exactly the sort of thing that should be standardized, > because > > without hooks like these, ORB vendors won't know what is required > of them to > > support external security services and security vendors can't rely > on being > > able to integrate into distinct ORB's in a uniform way (the > current > > situation). > > > > Without these types of hooks, security still won't be fully > replaceable, and > > it is hard to see the competitive advantage/distincition in how > ORB's > > determine that updated IOR profiles are available. > > > > Ryan > > > > > -----Original Message----- > > > From: Polar Humenn [mailto:polar@adiron.com] > > > Sent: Tuesday, October 26, 1999 4:48 PM > > > To: Jishnu Mukerji > > > Cc: Ryan Eberhard; secrev@omg.org > > > Subject: Re: Security: Need to complete SecurityReplaceable > > > > > > > > > On Tue, 26 Oct 1999, Jishnu Mukerji wrote: > > > > > > > Ryan Eberhard wrote: > > > > > > > > > > Polar, > > > > > > > > > > For my part, this interface looks good. > > > > > > > > > > Have we addressed the matching issue (it may not have a > > > number) of how the > > > > > ORB determines that the security service has a new IOR for > the target > > > > > object? > > > > > > > > > > Ryan > > > > Isn't this where the IOR interceptor comes in? There is quite > a bit of > > > > interesting discussion going on in the Interceptor submitters > > > list on this > > > > subject, specifically, what the frequency of call to the IOR > > > interceptor should > > > > be, and such. You will see the current state of the document > as > > > soon as it gets > > > > on the server. > > > > > > > > Essentially what happens is that the Security Service plants > an > > > IOR interceptor. > > > > This interceptor is called by the ORB/POA to gather > information > > > on what goes in > > > > the IOR, This interceptor is the one that presumably calls > this > > > Vault operation > > > > that Polar is positing to put together the info that it needs > > > to invoke the > > > > add_ocmponent operation of the IORInfo object. Did I get it > > > about right Polar? > > > > > > Yeah something like that of the sort, I would suppose. > > > I had imagined this sort of thing to be propritary as well. As > long as we > > > can get at it at the transport level, or low down, that'll be > fine, I > > > guess. > > > > > > > ------------------------------------------------------------------- > > > 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 > > > > > > > ------------------------------------------------------------------- > 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 X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 28 Oct 1999 09:58:12 -0400 (EDT) From: Polar Humenn To: secrev@omg.org Subject: Re: Security: Need to complete SecurityReplaceable (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Q,2!!DIm!!]1De9T^Ge9 Does anybody have an objections to creating and voting on a resolution on the following previously submitted issue? To refresh your memory some of the thread and proposed interface is below. -Polar ------------------------------------------------------------------- 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 ---------- Forwarded message ---------- Date: Tue, 26 Oct 1999 14:40:29 -0400 (EDT) From: Polar Humenn To: Jishnu Mukerji Cc: issues@omg.org, secrev@omg.org Subject: Re: Security: Need to complete SecurityReplaceable On Tue, 26 Oct 1999, Jishnu Mukerji wrote: > Just a minor suggestion. Change the name of the operation to > "create_ior_components", since the tagged components thata re being > created are > IOR components that may potentially be used someday in an IOR that > does specify > IIOP/ aka GIOP over TCPIP as the base protocol. There is no reason > to restrict > this general vault mechanism to IIOP forever. That would be fine, but what will constitute them being lifted from the IIOP profile in the future? I kinda thought it would be feasible, so that the vault may be able to be extended for a future protocol. However, a better way probably just occurred to me. Whould it be better to have something like this, then? typedef sequence TaggedComponentList; interface Vault { TaggedComponentList create_ior_components( in IOP::ProfileId profile_tag, in Security::CredentialsList creds_list ); }; Now that I think about it, this is probably the way to go, since profiles are *suppose* to (at last I heard, which abeit, was over year ago since I looked into it), completely independant. Thanks for the feedback. It's appreciated that someone is watching. Cheers, -Polar ------------------------------------------------------------------- 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