Issue 4167: Stateful boolean causes all CSI mechanisms to operate the same way. (corba-rtf) Source: Syracuse University (Dr. Polar Humenn, polar(at)adiron.com) Nature: Uncategorized Issue Severity: Summary: The stateful boolean of the CSIIOP::CompoundSecMech forces all CSI mechanisms to behave the same way with respect to state retention. This is problematic and makes mechanisms parametric on the POA they are supporting. The retention of state is actually a function of an established transport, not a POA. Discussion: In the architecture (OMA) POA's are the 'owners' of object references. Therefore, the state retention boolean must be set there, as there is only one CompundSecMecList per object reference. You may have cases where multiple CSI mechanisms must support one POA. These mechanisms may span POA's as they may be defaults for many POA's. If state retention is parameterized on the particular mechanism, then negotiating the state retention for each mechanism becomes easier to handle, as the state retention algorithm is mechanism specific. Therefore, that mechanism may operate independently of knowing the POA. This makes the TSS mechanisms to be able to work independently of the POA policy. Also, for another reason, CSI state retention is based on the established transport, which has nothing to do with a POA, therefore it is part of the CSI mechanism over which the transport it is working. I think the purpose for the "stateful" boolean was ill conceived. It was thought of by some as a deficiency in your implementation and you needed to provide a single boolean so one could RED FLAG a security service "inferior" in some sense. The fact is that state retention can be inefficient in some cases. State retention is actually parameter that is a function of the mechanism over a particular transport mechanism. One may want to use mechanisms that retain their state where one makes lots of invocations over a single transport (long live connections). (State retention is a function of transport). Short lived connections need not incur the overhead. Proposed Solution: Move the stateful field, as follows: module CSIIOP { // type used in the body of a TAG_CSI_SEC_MECH_LIST component to describe a // compound mechanism struct CompoundSecMech { AssociationOptions target_requires; IOP::TaggedComponent transport_mech; AS_ContextSec as_context_mech; SAS_ContextSec sas_context_mech; boolean stateful; }; // type corresponding to the body of a TAG_CSI_SEC_MECH_LIST component struct CompoundSecMechList { sequence <CompoundSecMech> mechanism_list; }; }; Resolution: CLOSE NO CHANGE Revised Text: Actions taken: January 22, 2001: received issue December 11, 2002: closed issue Discussion: For the reasons brought forth in this issue, this resolution moves the "stateful" field into the CompoundSecMech structure. It also takes care of an "anonymous" sequence contained in the CompoundSecMechList structure. The proposed change is backward incompatible and contrary to the intent of the original submission. End of Annotations:===== X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 22 Jan 2001 10:12:37 -0500 (EST) From: Polar Humenn To: issues@omg.org, csiv2-ftf@omg.org Subject: CSIv2 Issue Polar-4: Stateful boolean causes all CSI mechanisms to operate the same way. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: /;>!!H$4e9#bBe9d9k!! Issue Polar-4: Subject: Stateful boolean causes all CSI mechanisms to operate the same way. Document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-0117011.pdf Summary: The stateful boolean of the CSIIOP::CompoundSecMech forces all CSI mechanisms to behave the same way with respect to state retention. This is problematic and makes mechanisms parametric on the POA they are supporting. The retention of state is actually a function of an established transport, not a POA. Discussion: In the architecture (OMA) POA's are the 'owners' of object references. Therefore, the state retention boolean must be set there, as there is only one CompundSecMecList per object reference. You may have cases where multiple CSI mechanisms must support one POA. These mechanisms may span POA's as they may be defaults for many POA's. If state retention is parameterized on the particular mechanism, then negotiating the state retention for each mechanism becomes easier to handle, as the state retention algorithm is mechanism specific. Therefore, that mechanism may operate independently of knowing the POA. This makes the TSS mechanisms to be able to work independently of the POA policy. Also, for another reason, CSI state retention is based on the established transport, which has nothing to do with a POA, therefore it is part of the CSI mechanism over which the transport it is working. I think the purpose for the "stateful" boolean was ill conceived. It was thought of by some as a deficiency in your implementation and you needed to provide a single boolean so one could RED FLAG a security service "inferior" in some sense. The fact is that state retention can be inefficient in some cases. State retention is actually parameter that is a function of the mechanism over a particular transport mechanism. One may want to use mechanisms that retain their state where one makes lots of invocations over a single transport (long live connections). (State retention is a function of transport). Short lived connections need not incur the overhead. Proposed Solution: Move the stateful field, as follows: module CSIIOP { // type used in the body of a TAG_CSI_SEC_MECH_LIST component to describe a // compound mechanism struct CompoundSecMech { AssociationOptions target_requires; IOP::TaggedComponent transport_mech; AS_ContextSec as_context_mech; SAS_ContextSec sas_context_mech; boolean stateful; }; // type corresponding to the body of a TAG_CSI_SEC_MECH_LIST component struct CompoundSecMechList { sequence mechanism_list; }; }; Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Mon, 22 Jan 2001 11:58:57 -0500 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn CC: issues@omg.org, csiv2-ftf@omg.org Subject: Re: CSIv2 Issue Polar-4: Stateful boolean causes all CSI mechanisms tooperate the same way. References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: $<\d9=I\d9G)`!!_4!!! Polar Humenn wrote: > > Issue Polar-4: > Subject: Stateful boolean causes all CSI mechanisms to operate the same way. > Document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-0117011.pdf > Summary: > > The stateful boolean of the CSIIOP::CompoundSecMech forces all CSI > mechanisms to behave the same way with respect to state retention. This is > problematic and makes mechanisms parametric on the POA they are > supporting. The retention of state is actually a function of an > established transport, not a POA. > > Discussion: > > In the architecture (OMA) POA's are the 'owners' of object references. > Therefore, the state retention boolean must be set there, as there is only > one CompundSecMecList per object reference. > > You may have cases where multiple CSI mechanisms must support one POA. > > These mechanisms may span POA's as they may be defaults for many POA's. If > state retention is parameterized on the particular mechanism, then > negotiating the state retention for each mechanism becomes easier to > handle, as the state retention algorithm is mechanism specific. Therefore, > that mechanism may operate independently of knowing the POA. > > This makes the TSS mechanisms to be able to work independently of the POA > policy. > > Also, for another reason, CSI state retention is based on the established > transport, which has nothing to do with a POA, therefore it is part of the > CSI mechanism over which the transport it is working. > > I think the purpose for the "stateful" boolean was ill conceived. It was > thought of by some as a deficiency in your implementation and you needed > to provide a single boolean so one could RED FLAG a security service > "inferior" in some sense. This in not the reason the "stateful" boolean was created. It was created to support a client optimization, or in deference to client resources, such that a client could know when not to go to the extra overhead of setting up a stateful context when it knows the target is stateless. This does not mean that it could never be useful for a target to vary with respect to its statefulness on a mechanism by mechanism basis. In which case the same optimization could be applied (wrt each mechanism). However, doing so would be functionality above and beyond that defined by the adopted submission. > > The fact is that state retention can be inefficient in some > cases. State > retention is actually parameter that is a function of the mechanism > over a > particular transport mechanism. One may want to use mechanisms that > retain > their state where one makes lots of invocations over a single > transport > (long live connections). (State retention is a function of > transport). > Short lived connections need not incur the overhead. Can you give us an example using required CSIv2 mechanisms where such "inefficiency" would occur? > > Proposed Solution: > > Move the stateful field, as follows: > > module CSIIOP { > // type used in the body of a TAG_CSI_SEC_MECH_LIST component to > describe a > // compound mechanism > > struct CompoundSecMech { > AssociationOptions target_requires; > IOP::TaggedComponent transport_mech; > AS_ContextSec as_context_mech; > SAS_ContextSec sas_context_mech; > boolean stateful; > }; > > // type corresponding to the body of a TAG_CSI_SEC_MECH_LIST > component > > struct CompoundSecMechList { > sequence mechanism_list; > }; > > }; > > Cheers, > -Polar > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 22 Jan 2001 12:48:51 -0500 (EST) From: Polar Humenn To: Ron Monzillo cc: issues@omg.org, csiv2-ftf@omg.org Subject: Re: CSIv2 Issue Polar-4: Stateful boolean causes all CSI mechanisms tooperate the same way. In-Reply-To: <3A6C66D1.4050B831@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: n)n!!d*\d9X]9!!KR(e9 Ron, et al, Comments below. On Mon, 22 Jan 2001, Ron Monzillo wrote: > > > Polar Humenn wrote: > > > > Issue Polar-4: > > Subject: Stateful boolean causes all CSI mechanisms to operate the > same way. > > Document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-0117011.pdf > > Summary: > > > > The stateful boolean of the CSIIOP::CompoundSecMech forces all CSI > > mechanisms to behave the same way with respect to state > retention. This is > > problematic and makes mechanisms parametric on the POA they are > > supporting. The retention of state is actually a function of an > > established transport, not a POA. > > > > Discussion: > > > > In the architecture (OMA) POA's are the 'owners' of object > references. > > Therefore, the state retention boolean must be set there, as there > is only > > one CompundSecMecList per object reference. > > > > You may have cases where multiple CSI mechanisms must support one > POA. > > > > These mechanisms may span POA's as they may be defaults for many > POA's. If > > state retention is parameterized on the particular mechanism, then > > negotiating the state retention for each mechanism becomes easier > to > > handle, as the state retention algorithm is mechanism > specific. Therefore, > > that mechanism may operate independently of knowing the POA. > > > > This makes the TSS mechanisms to be able to work independently of > the POA > > policy. > > > > Also, for another reason, CSI state retention is based on the > established > > transport, which has nothing to do with a POA, therefore it is > part of the > > CSI mechanism over which the transport it is working. > > > > I think the purpose for the "stateful" boolean was ill > conceived. It was > > thought of by some as a deficiency in your implementation and you > needed > > to provide a single boolean so one could RED FLAG a security > service > > "inferior" in some sense. > > This in not the reason the "stateful" boolean was created. It was > created to support a client optimization, or in deference to client > resources, such that a client could know when not to go to the extra > overhead of setting up a stateful context when it knows the target > is > stateless. Okay. so we agree that we have "extra" overhead on the Client side. Exactly my point. There is also some overhead incurred on the server. See below. > This does not mean that it could never be useful for a target to vary > with respect to its statefulness on a mechanism by mechanism basis. In > which case the same optimization could be applied (wrt each mechanism). > However, doing so would be functionality above and beyond that defined > by the adopted submission. I merely raised it as an issue such that I think is a problem with the "adopted" submission, based on implementation experience, and my reasons are below. > > The fact is that state retention can be inefficient in some cases. State > > retention is actually parameter that is a function of the mechanism over a > > particular transport mechanism. One may want to use mechanisms that retain > > their state where one makes lots of invocations over a single transport > > (long live connections). (State retention is a function of transport). > > Short lived connections need not incur the overhead. > > Can you give us an example using required CSIv2 mechanisms where such > "inefficiency" would occur? Okay, I am a server. I may have a mechanism that requires fairly extensive authorization validation, and retaining state over the transport for invocations on many objects by that client will be beneficial to BOTH the client and server, should the client choose to use it. I expect connections from clients using this mechanism to be fairly long lived. I think everyone is agreed on this point. One thing that I want you to note is this: A CSI mechanism is not *exclusively* tied to the object. That mechanism can show up in many IORs and a smart client can figure out when it has a match on host/port/CSImechanism for reuse, even on different objects. Now, I may also have a CSI mechanism that does not require such lengthy authorization, and quite possibly a different transport, associated with the same objects (both in the CompoundSecMechList). I plan on getting many invocations from many different clients using this mechanism, but I'm going to close the connection after each one, for availability of the servers resources. However, since my "stateful" boolean at the top of the CompoundSecMech must say "stateful" to support the above arduous mechanism, the "eager to optimize" client keeps sending me client_context_ids that I have to deny. The client must manage this. Not realizing that the connection is going to be shut down after the reply, he incurs the overhead you speak of for no good reason. Therefore, the "eager to optimize" client turns out NOT to optimized. If the "stateful" boolean where associated with each CSI mechanism and not the object, this scenario can be avoided. The basic cruxt is the FUNDEMENTAL architecture difference. The CSI mechanism is not exclusively tied to the object, where as the "stateful" attribute currently is. I believe this is a fundamental flaw in the CSIv2 Architecture. On the server side, trying to implement "stateful" and "stateless" over a single mechanism is a possibility in the same server because that attribute would have to be associated the the POAs and not the mechanisms themselves. Using the same mechanism implementation for many objects within a server is beneficial. Having to determine the POA of each request, to figure out whether the policy is stateful or not, is an inefficient burden on the server. That is because while processing the mechanism, the mechanism has to operate in two different modes simultaneously, retaining state and not retaining state, which depends on the object (or POA) for which it is getting the request. Cheers, -Polar > > > > Proposed Solution: > > > > Move the stateful field, as follows: > > > > module CSIIOP { > > // type used in the body of a TAG_CSI_SEC_MECH_LIST component > > to describe a > > // compound mechanism > > > > struct CompoundSecMech { > > AssociationOptions target_requires; > > IOP::TaggedComponent transport_mech; > > AS_ContextSec as_context_mech; > > SAS_ContextSec sas_context_mech; > > boolean stateful; > > }; > > > > // type corresponding to the body of a TAG_CSI_SEC_MECH_LIST > > component > > > > struct CompoundSecMechList { > > sequence mechanism_list; > > }; > > > > }; > > > > Cheers, > > -Polar > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Mon, 22 Jan 2001 16:42:57 -0500 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn CC: issues@omg.org, csiv2-ftf@omg.org Subject: Re: CSIv2 Issue Polar-4: Stateful boolean causes all CSI mechanismstooperate the same way. References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: <`De9nme!!=!5e9M7&e9 This is an interesting thread, I inserted some comments below. I would like to direct my attention to (i.e prioritize) the GSSUP related issues, as unlike Polar, I cannot give so many things a careful consideration at once. Polar Humenn wrote: > > Ron, et al, > > Comments below. > > On Mon, 22 Jan 2001, Ron Monzillo wrote: > > > > > > > Polar Humenn wrote: > > > > > > Issue Polar-4: > > > Subject: Stateful boolean causes all CSI mechanisms to operate the same way. > > > Document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-0117011.pdf > > > Summary: > > > > > > The stateful boolean of the CSIIOP::CompoundSecMech forces all CSI > > > mechanisms to behave the same way with respect to state retention. This is > > > problematic and makes mechanisms parametric on the POA they are > > > supporting. The retention of state is actually a function of an > > > established transport, not a POA. > > > > > > Discussion: > > > > > > In the architecture (OMA) POA's are the 'owners' of object references. > > > Therefore, the state retention boolean must be set there, as there is only > > > one CompundSecMecList per object reference. > > > > > > You may have cases where multiple CSI mechanisms must support one POA. > > > > > > These mechanisms may span POA's as they may be defaults for many POA's. If > > > state retention is parameterized on the particular mechanism, then > > > negotiating the state retention for each mechanism becomes easier to > > > handle, as the state retention algorithm is mechanism specific. Therefore, > > > that mechanism may operate independently of knowing the POA. > > > > > > This makes the TSS mechanisms to be able to work independently of the POA > > > policy. > > > > > > Also, for another reason, CSI state retention is based on the established > > > transport, which has nothing to do with a POA, therefore it is part of the > > > CSI mechanism over which the transport it is working. > > > > > > I think the purpose for the "stateful" boolean was ill conceived. It was > > > thought of by some as a deficiency in your implementation and you needed > > > to provide a single boolean so one could RED FLAG a security service > > > "inferior" in some sense. > > > > This in not the reason the "stateful" boolean was created. It was > > created to support a client optimization, or in deference to client > > resources, such that a client could know when not to go to the extra > > overhead of setting up a stateful context when it knows the target is > > stateless. > > Okay. so we agree that we have "extra" overhead on the Client side. > Exactly my point. There is also some overhead incurred on the server. See > below. > > > This does not mean that it could never be useful for a target to vary > > with respect to its statefulness on a mechanism by mechanism basis. In > > which case the same optimization could be applied (wrt each mechanism). > > However, doing so would be functionality above and beyond that defined > > by the adopted submission. > > I merely raised it as an issue such that I think is a problem with the > "adopted" submission, based on implementation experience, and my reasons > are below. > > > > The fact is that state retention can be inefficient in some cases. State > > > retention is actually parameter that is a function of the mechanism over a > > > particular transport mechanism. One may want to use mechanisms that retain > > > their state where one makes lots of invocations over a single transport > > > (long live connections). (State retention is a function of transport). > > > Short lived connections need not incur the overhead. > > > > Can you give us an example using required CSIv2 mechanisms where such > > "inefficiency" would occur? > > Okay, > > I am a server. > > I may have a mechanism that requires fairly extensive authorization > validation, and retaining state over the transport for invocations on many > objects by that client will be beneficial to BOTH the client and server, > should the client choose to use it. I expect connections from clients > using this mechanism to be fairly long lived. > > I think everyone is agreed on this point. > > One thing that I want you to note is this: > > A CSI mechanism is not *exclusively* tied to the object. That mechanism > can show up in many IORs and a smart client can figure out when it has a > match on host/port/CSImechanism for reuse, even on different objects. > > Now, I may also have a CSI mechanism that does not require such lengthy > authorization, and quite possibly a different transport, associated with > the same objects (both in the CompoundSecMechList). I plan on getting many > invocations from many different clients using this mechanism, but I'm > going to close the connection after each one, for availability of the > servers resources. > > However, since my "stateful" boolean at the top of the CompoundSecMech > must say "stateful" to support the above arduous mechanism, the "eager to > optimize" client keeps sending me client_context_ids that I have to deny. > The client must manage this. Not realizing that the connection is going to > be shut down after the reply, he incurs the overhead you speak of for no > good reason. > > Therefore, the "eager to optimize" client turns out NOT to optimized. > > If the "stateful" boolean where associated with each CSI mechanism and not > the object, this scenario can be avoided. > > The basic cruxt is the FUNDEMENTAL architecture difference. The CSI > mechanism is not exclusively tied to the object, where as the "stateful" > attribute currently is. > > I believe this is a fundamental flaw in the CSIv2 Architecture. > That seems a little overboard. The Stateless bit is for optimization purposes. As stated in para 96, a stateful TSS can respond statelessly (to a stateful request) as long as it has no existing matching context. It is true that the IOR schema is not rich enough to optimize the client's behavior on a per mechanism basis. When a stateful request is negotiated down to stateless, a stateful client has enough information to modify its state such that it does not in the future act statefully using that Mechanism. This perhaps is not ideal, as it is not optimized for a case where the target supports more than one mechanism, some of which are stateful and some are not. My first thought was that if you want to do what you are suggesting, then maybe you could put multiple profiles in your IORs. I don't think this will be workable, as you may wind up inteferring with other uses of multiple profiles (i.e fault tolearance) and you may not like the overhead of duplicating a profile, mostly to change a bit. My second thought was that if context_id scopes are defined by transport layer session (as defined in para 88), then perhaps you are right; i.e this change should be made. My third thought was that moving this bit down such that it can influence individual mechanisms, may create some complexity in the interpretation of requests made against multiple mechanism IOR's where there are two or more mechanisms which are identical in their transport definition, but differ in their statefulness (and other layer definitions). I think this would conflict with para 88, in that it would be possible to indicate that a context_id scope does not apply to all the connections on a single transport session (one mechanims being stateful, another not). > On the server side, trying to implement "stateful" and "stateless" over a > single mechanism is a possibility in the same server because that > attribute would have to be associated the the POAs and not the mechanisms > themselves. > > Using the same mechanism implementation for many objects within a server > is beneficial. Having to determine the POA of each request, to figure out > whether the policy is stateful or not, is an inefficient burden on the > server. That is because while processing the mechanism, the mechanism has > to operate in two different modes simultaneously, retaining state and not > retaining state, which depends on the object (or POA) for which it is > getting the request. I don't get this. If you want mechanism specific client side optimization policy to be included in mechanisms, then what you are talking about are mechanisms whose definition includes whether or not they support stateful clients. Please respond if you choose, but I won't be getting back to this for a little while. I think I will be away from work for most of Wednesday. I may be able to call in. I intend to comment on GSSUP (tonight), and review the module reorganization proposed by Polar (tomorrow). On the latter, I did a quick review of what he did and looked very good. Ron > > Cheers, > -Polar > > > > > > > Proposed Solution: > > > > > > Move the stateful field, as follows: > > > > > > module CSIIOP { > > > // type used in the body of a TAG_CSI_SEC_MECH_LIST > component to describe a > > > // compound mechanism > > > > > > struct CompoundSecMech { > > > AssociationOptions target_requires; > > > IOP::TaggedComponent transport_mech; > > > AS_ContextSec as_context_mech; > > > SAS_ContextSec sas_context_mech; > > > boolean stateful; > > > }; > > > > > > // type corresponding to the body of a TAG_CSI_SEC_MECH_LIST > component > > > > > > struct CompoundSecMechList { > > > sequence mechanism_list; > > > }; > > > > > > }; > > > > > > Cheers, > > > -Polar > > > > > > > ------------------------------------------------------------------- > > > Polar Humenn Adiron, LLC > > > mailto:polar@adiron.com 2-212 CST > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > Fax: 315-443-4745 http://www.adiron.com > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 22 Jan 2001 17:38:57 -0500 (EST) From: Polar Humenn To: Ron Monzillo cc: issues@omg.org, csiv2-ftf@omg.org Subject: Re: CSIv2 Issue Polar-4: Stateful boolean causes all CSI mechanismstooperate the same way. In-Reply-To: <3A6CA961.B07B34D5@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: %Gfd9P;7!!4h1e9mE5!! Ron, et al, Comments below: On Mon, 22 Jan 2001, Ron Monzillo wrote: > This is an interesting thread, I inserted some comments below. > > I would like to direct my attention to (i.e prioritize) the GSSUP > related issues, as unlike Polar, I cannot give so many things a > careful consideration at once. > > Polar Humenn wrote: > > > > Ron, et al, > > > > Comments below. > > > > On Mon, 22 Jan 2001, Ron Monzillo wrote: > > > > > > > > > > > Polar Humenn wrote: > > > > > > > > Issue Polar-4: > > > > Subject: Stateful boolean causes all CSI mechanisms to operate > the same way. > > > > Document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-0117011.pdf > > > > Summary: > > > > > > > > The stateful boolean of the CSIIOP::CompoundSecMech forces all > CSI > > > > mechanisms to behave the same way with respect to state > retention. This is > > > > problematic and makes mechanisms parametric on the POA they > are > > > > supporting. The retention of state is actually a function of > an > > > > established transport, not a POA. > > > > > > > > Discussion: > > > > > > > > In the architecture (OMA) POA's are the 'owners' of object > references. > > > > Therefore, the state retention boolean must be set there, as > there is only > > > > one CompundSecMecList per object reference. > > > > > > > > You may have cases where multiple CSI mechanisms must support > one POA. > > > > > > > > These mechanisms may span POA's as they may be defaults for > many POA's. If > > > > state retention is parameterized on the particular mechanism, > then > > > > negotiating the state retention for each mechanism becomes > easier to > > > > handle, as the state retention algorithm is mechanism > specific. Therefore, > > > > that mechanism may operate independently of knowing the POA. > > > > > > > > This makes the TSS mechanisms to be able to work independently > of the POA > > > > policy. > > > > > > > > Also, for another reason, CSI state retention is based on the > established > > > > transport, which has nothing to do with a POA, therefore it is > part of the > > > > CSI mechanism over which the transport it is working. > > > > > > > > I think the purpose for the "stateful" boolean was ill > conceived. It was > > > > thought of by some as a deficiency in your implementation and > you needed > > > > to provide a single boolean so one could RED FLAG a security > service > > > > "inferior" in some sense. > > > > > > This in not the reason the "stateful" boolean was created. It > was > > > created to support a client optimization, or in deference to > client > > > resources, such that a client could know when not to go to the > extra > > > overhead of setting up a stateful context when it knows the > target is > > > stateless. > > > > Okay. so we agree that we have "extra" overhead on the Client > side. > > Exactly my point. There is also some overhead incurred on the > server. See > > below. > > > > > This does not mean that it could never be useful for a target to > vary > > > with respect to its statefulness on a mechanism by mechanism > basis. In > > > which case the same optimization could be applied (wrt each > mechanism). > > > However, doing so would be functionality above and beyond that > defined > > > by the adopted submission. > > > > I merely raised it as an issue such that I think is a problem with > the > > "adopted" submission, based on implementation experience, and my > reasons > > are below. > > > > > > The fact is that state retention can be inefficient in some > cases. State > > > > retention is actually parameter that is a function of the > mechanism over a > > > > particular transport mechanism. One may want to use mechanisms > that retain > > > > their state where one makes lots of invocations over a single > transport > > > > (long live connections). (State retention is a function of > transport). > > > > Short lived connections need not incur the overhead. > > > > > > Can you give us an example using required CSIv2 mechanisms where > such > > > "inefficiency" would occur? > > > > Okay, > > > > I am a server. > > > > I may have a mechanism that requires fairly extensive > authorization > > validation, and retaining state over the transport for invocations > on many > > objects by that client will be beneficial to BOTH the client and > server, > > should the client choose to use it. I expect connections from > clients > > using this mechanism to be fairly long lived. > > > > I think everyone is agreed on this point. > > > > One thing that I want you to note is this: > > > > A CSI mechanism is not *exclusively* tied to the object. That > mechanism > > can show up in many IORs and a smart client can figure out when it > has a > > match on host/port/CSImechanism for reuse, even on different > objects. > > > > Now, I may also have a CSI mechanism that does not require such > lengthy > > authorization, and quite possibly a different transport, > associated with > > the same objects (both in the CompoundSecMechList). I plan on > getting many > > invocations from many different clients using this mechanism, but > I'm > > going to close the connection after each one, for availability of > the > > servers resources. > > > > However, since my "stateful" boolean at the top of the > CompoundSecMech > > must say "stateful" to support the above arduous mechanism, the > "eager to > > optimize" client keeps sending me client_context_ids that I have > to deny. > > The client must manage this. Not realizing that the connection is > going to > > be shut down after the reply, he incurs the overhead you speak of > for no > > good reason. > > > > Therefore, the "eager to optimize" client turns out NOT to > optimized. > > > > If the "stateful" boolean where associated with each CSI mechanism > and not > > the object, this scenario can be avoided. > > > > The basic cruxt is the FUNDEMENTAL architecture difference. The > CSI > > mechanism is not exclusively tied to the object, where as the > "stateful" > > attribute currently is. > > > > I believe this is a fundamental flaw in the CSIv2 Architecture. > > > > That seems a little overboard. Not really. the "stateless" bit is for optimization, but it is tied to the object, not the mechanism. I really do think this is fundemental. > The Stateless bit is for optimization > purposes. As stated in para 96, a stateful TSS can respond > statelessly > (to a stateful request) as long as it has no existing matching > context. > It is true that the IOR schema is not rich enough to optimize the > client's behavior on a per mechanism basis. When a stateful request > is > negotiated down to stateless, a stateful client has enough > information > to modify its state such that it does not in the future act > statefully > using that Mechanism. That means the Client has to negotiate at the outset regardless of whether the mechanism supports stateless or not. Hmmmm, we keep talking about the mechanism supporting state, not the object. > This perhaps is not ideal, as it is not optimized for a case where the > target supports more than one mechanism, some of which are stateful and > some are not. True, that is the point I am trying to rectify. > My first thought was that if you want to do what you are suggesting, > then maybe you could put multiple profiles in your IORs. I don't > think > this will be workable, as you may wind up interfering with other > uses > of multiple profiles (i.e fault tolerance) and you may not like the > overhead of duplicating a profile, mostly to change a bit. Agreed. > My second thought was that if context_id scopes are defined by transport > layer session (as defined in para 88), then perhaps you are right; i.e > this change should be made. I think I am. :-) > My third thought was that moving this bit down such that it can > influence individual mechanisms, may create some complexity in the > interpretation of requests made against multiple mechanism IOR's > where > there are two or more mechanisms which are identical in their > transport > definition, but differ in their statefulness (and other layer > definitions). I think this would conflict with para 88, in that it > would > be possible to indicate that a context_id scope does not apply to > all > the connections on a single transport session (one mechanims being > stateful, another not). I don't think so. para 88 of csiv2-0117011.pdf says: Each transport layer session defines a context identifier number scope. The CSS selects context identifiers for use within a scope. The client_context_id scope is per transport session *regardless* of the CSI mechanism used on the session. The client_context_id refers to a particular *security context*, which matches one of possibly many CSI mechanisms. The ability of the CSI mechanism to handle state is orthogonal to this argument. The case you state above is only interesting if every component of two CSI mechanisms are the same and the client would up generate the same CSI security context for each. One mechanism claims it retains state, and the other doesn't. A stateless client can still choose the mechanism if it says it retains state, and use it without retaining state. And, even if the client wants to retain state, a client can still choose the mechanism if it says it doesn't retain state, and process it "statelessly". > > On the server side, trying to implement "stateful" and "stateless" over a > > single mechanism is a possibility in the same server because that > > attribute would have to be associated the the POAs and not the mechanisms > > themselves. > > > > Using the same mechanism implementation for many objects within a server > > is beneficial. Having to determine the POA of each request, to figure out > > whether the policy is stateful or not, is an inefficient burden on the > > server. That is because while processing the mechanism, the mechanism has > > to operate in two different modes simultaneously, retaining state and not > > retaining state, which depends on the object (or POA) for which it is > > getting the request. > > I don't get this. If you want mechanism specific client side > optimization policy to be included in mechanisms, then what you are > talking about are mechanisms whose definition includes whether or not > they support stateful clients. In a sense, correct. However, I'd rather not think of them as "stateless clients" or "stateful clients" as this implies there is something amiss with its security implementation, because it refers to handing state regardless of mechanism. A "stateless client" or "stateful client" isn't a feature or a deficiency of the CSS, a point I brought up before. I'd rather think of it as a client that *chooses* to use a CSI mechanism in a "stateful" way, or a "stateless" way, depending on its requirements. > Please respond if you choose, but I won't be getting back to this for a > little while. I think I will be away from work for most of Wednesday. I > may be able to call in. > > > I intend to comment on GSSUP (tonight), and review the module > reorganization proposed by Polar (tomorrow). On the latter, I did a > quick review of what he did and looked very good. Thank You. > Ron > > > > > Cheers, > > -Polar > > > > > > > > > > Proposed Solution: > > > > > > > > Move the stateful field, as follows: > > > > > > > > module CSIIOP { > > > > // type used in the body of a TAG_CSI_SEC_MECH_LIST > component to describe a > > > > // compound mechanism > > > > > > > > struct CompoundSecMech { > > > > AssociationOptions target_requires; > > > > IOP::TaggedComponent transport_mech; > > > > AS_ContextSec as_context_mech; > > > > SAS_ContextSec sas_context_mech; > > > > boolean stateful; > > > > }; > > > > > > > > // type corresponding to the body of a > TAG_CSI_SEC_MECH_LIST component > > > > > > > > struct CompoundSecMechList { > > > > sequence mechanism_list; > > > > }; > > > > > > > > }; > > > > > > > > Cheers, > > > > -Polar > > > > > > > > > ------------------------------------------------------------------- > > > > Polar Humenn Adiron, LLC > > > > mailto:polar@adiron.com 2-212 CST > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Tue, 23 Jan 2001 17:43:59 -0500 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn CC: issues@omg.org, csiv2-ftf@omg.org Subject: Re: CSIv2 Issue Polar-4: Stateful boolean causes all CSI mechanismstooperate the same way. References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: %;[!!6%I!!]pl!!Ael!! Polar Humenn wrote: > > Ron, et al, > > Comments below: > > On Mon, 22 Jan 2001, Ron Monzillo wrote: > > > Polar Humenn wrote: > > > > > > Ron, et al, > > > > > > Comments below. > > > > > > On Mon, 22 Jan 2001, Ron Monzillo wrote: > > > > > > > > > > > > > > > Polar Humenn wrote: > > > > > > > > > > Issue Polar-4: > > > > > Subject: Stateful boolean causes all CSI mechanisms to operate the same way. > > > > > Document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-0117011.pdf > > > > > Summary: > > > > > > > > > > The stateful boolean of the CSIIOP::CompoundSecMech forces all CSI > > > > > mechanisms to behave the same way with respect to state retention. This is > > > > > problematic and makes mechanisms parametric on the POA they are > > > > > supporting. The retention of state is actually a function of an > > > > > established transport, not a POA. > > > > > > > > > > Discussion: > > > > > > > > > > In the architecture (OMA) POA's are the 'owners' of object references. > > > > > Therefore, the state retention boolean must be set there, as there is only > > > > > one CompundSecMecList per object reference. > > > > > > > > > > You may have cases where multiple CSI mechanisms must support one POA. > > > > > > > > > > These mechanisms may span POA's as they may be defaults for many POA's. If > > > > > state retention is parameterized on the particular mechanism, then > > > > > negotiating the state retention for each mechanism becomes easier to > > > > > handle, as the state retention algorithm is mechanism specific. Therefore, > > > > > that mechanism may operate independently of knowing the POA. > > > > > > > > > > This makes the TSS mechanisms to be able to work independently of the POA > > > > > policy. > > > > > > > > > > Also, for another reason, CSI state retention is based on the established > > > > > transport, which has nothing to do with a POA, therefore it is part of the > > > > > CSI mechanism over which the transport it is working. > > > > > > > > > > I think the purpose for the "stateful" boolean was ill conceived. It was > > > > > thought of by some as a deficiency in your implementation and you needed > > > > > to provide a single boolean so one could RED FLAG a security service > > > > > "inferior" in some sense. > > > > > > > > This in not the reason the "stateful" boolean was created. It was > > > > created to support a client optimization, or in deference to client > > > > resources, such that a client could know when not to go to the extra > > > > overhead of setting up a stateful context when it knows the target is > > > > stateless. > > > > > > Okay. so we agree that we have "extra" overhead on the Client side. > > > Exactly my point. There is also some overhead incurred on the server. See > > > below. > > > > > > > This does not mean that it could never be useful for a target to vary > > > > with respect to its statefulness on a mechanism by mechanism basis. In > > > > which case the same optimization could be applied (wrt each mechanism). > > > > However, doing so would be functionality above and beyond that defined > > > > by the adopted submission. > > > > > > I merely raised it as an issue such that I think is a problem with the > > > "adopted" submission, based on implementation experience, and my reasons > > > are below. > > > > > > > > The fact is that state retention can be inefficient in some cases. State > > > > > retention is actually parameter that is a function of the mechanism over a > > > > > particular transport mechanism. One may want to use mechanisms that retain > > > > > their state where one makes lots of invocations over a single transport > > > > > (long live connections). (State retention is a function of transport). > > > > > Short lived connections need not incur the overhead. > > > > > > > > Can you give us an example using required CSIv2 mechanisms where such > > > > "inefficiency" would occur? > > > > > > Okay, > > > > > > I am a server. > > > > > > I may have a mechanism that requires fairly extensive authorization > > > validation, and retaining state over the transport for invocations on many > > > objects by that client will be beneficial to BOTH the client and server, > > > should the client choose to use it. I expect connections from clients > > > using this mechanism to be fairly long lived. > > > > > > I think everyone is agreed on this point. > > > > > > One thing that I want you to note is this: > > > > > > A CSI mechanism is not *exclusively* tied to the object. That mechanism > > > can show up in many IORs and a smart client can figure out when it has a > > > match on host/port/CSImechanism for reuse, even on different objects. > > > > > > Now, I may also have a CSI mechanism that does not require such lengthy > > > authorization, and quite possibly a different transport, associated with > > > the same objects (both in the CompoundSecMechList). I plan on getting many > > > invocations from many different clients using this mechanism, but I'm > > > going to close the connection after each one, for availability of the > > > servers resources. > > > > > > However, since my "stateful" boolean at the top of the CompoundSecMech > > > must say "stateful" to support the above arduous mechanism, the "eager to > > > optimize" client keeps sending me client_context_ids that I have to deny. > > > The client must manage this. Not realizing that the connection is going to > > > be shut down after the reply, he incurs the overhead you speak of for no > > > good reason. > > > > > > Therefore, the "eager to optimize" client turns out NOT to optimized. > > > > > > If the "stateful" boolean where associated with each CSI mechanism and not > > > the object, this scenario can be avoided. > > > > > > The basic cruxt is the FUNDEMENTAL architecture difference. The CSI > > > mechanism is not exclusively tied to the object, where as the "stateful" > > > attribute currently is. > > > > > > I believe this is a fundamental flaw in the CSIv2 Architecture. > > > > > > > That seems a little overboard. > > Not really. the "stateless" bit is for optimization, but it is tied to the > object, not the mechanism. I really do think this is fundemental. > > > The Stateless bit is for optimization > > purposes. As stated in para 96, a stateful TSS can respond statelessly > > (to a stateful request) as long as it has no existing matching context. > > It is true that the IOR schema is not rich enough to optimize the > > client's behavior on a per mechanism basis. When a stateful request is > > negotiated down to stateless, a stateful client has enough information > > to modify its state such that it does not in the future act statefully > > using that Mechanism. > > That means the Client has to negotiate at the outset regardless of whether > the mechanism supports stateless or not. > > Hmmmm, we keep talking about the mechanism supporting state, not the > object. > > > This perhaps is not ideal, as it is not optimized for a case where the > > target supports more than one mechanism, some of which are stateful and > > some are not. > > True, that is the point I am trying to rectify. > > > My first thought was that if you want to do what you are suggesting, > > then maybe you could put multiple profiles in your IORs. I don't think > > this will be workable, as you may wind up interfering with other uses > > of multiple profiles (i.e fault tolerance) and you may not like the > > overhead of duplicating a profile, mostly to change a bit. > > Agreed. > > > My second thought was that if context_id scopes are defined by transport > > layer session (as defined in para 88), then perhaps you are right; i.e > > this change should be made. > > I think I am. :-) > > > My third thought was that moving this bit down such that it can > > influence individual mechanisms, may create some complexity in the > > interpretation of requests made against multiple mechanism IOR's where > > there are two or more mechanisms which are identical in their transport > > definition, but differ in their statefulness (and other layer > > definitions). I think this would conflict with para 88, in that it would > > be possible to indicate that a context_id scope does not apply to all > > the connections on a single transport session (one mechanims being > > stateful, another not). > > I don't think so. para 88 of csiv2-0117011.pdf says: > > Each transport layer session defines a context identifier number scope. > The CSS selects context identifiers for use within a scope. > > The client_context_id scope is per transport session *regardless* of the > CSI mechanism used on the session. The client_context_id refers to a > particular *security context*, which matches one of possibly many CSI > mechanisms. The ability of the CSI mechanism to handle state is orthogonal > to this argument. > Yes I think you are right. > The case you state above is only interesting if every component of two CSI > mechanisms are the same and the client would up generate the same CSI > security context for each. One mechanism claims it retains state, and the > other doesn't. > > A stateless client can still choose the mechanism if it says it retains > state, and use it without retaining state. And, even if the client wants > to retain state, a client can still choose the mechanism if it says it > doesn't retain state, and process it "statelessly". > > > > On the server side, trying to implement "stateful" and "stateless" over a > > > single mechanism is a possibility in the same server because that > > > attribute would have to be associated the the POAs and not the mechanisms > > > themselves. > > > > > > Using the same mechanism implementation for many objects within a server > > > is beneficial. Having to determine the POA of each request, to figure out > > > whether the policy is stateful or not, is an inefficient burden on the > > > server. That is because while processing the mechanism, the mechanism has > > > to operate in two different modes simultaneously, retaining state and not > > > retaining state, which depends on the object (or POA) for which it is > > > getting the request. > > > > I don't get this. If you want mechanism specific client side > > optimization policy to be included in mechanisms, then what you are > > talking about are mechanisms whose definition includes whether or not > > they support stateful clients. > > In a sense, correct. However, I'd rather not think of them as "stateless > clients" or "stateful clients" as this implies there is something amiss > with its security implementation, because it refers to handing state > regardless of mechanism. A "stateless client" or "stateful client" isn't a > feature or a deficiency of the CSS, a point I brought up before. > > I'd rather think of it as a client that *chooses* to use a CSI mechanism > in a "stateful" way, or a "stateless" way, depending on its requirements. > I know that the stateful bit was not added to IORs to allow for a TSS to be differentially stateful with respect to the objects/mechanisms that it exports. This bit was added, with the presumption that a stateful TSS is stateful or stateless for all the objects that it exports, and for all the mechanism definitions under which it exports those objects. We were having enough trouble convincing people to provide stateful support within the protocol, without implying the extra complexity of a single TSS having to specify on a per mechanism basis whether or not it is stateful. That's how we got where we are. If we move the bit as you suggest, the IOR schema will become powerful enough to allow a TSS to set this bit per mechanism, and if it chooses, act differentially with respect to the objects and mechanisms that it exports. I can support this change as long as we do not add any corresponding requirement that a stateful TSS must be be able to be stateful with respect to some objects/mechanisms and stateless with respect to others. To claim stateful conformance, a TSS need only be able to be uniformly stateful with respect to all the objects and mechanisms that it exports. In this case, the value of this bit would be true in every mechanism definition of every object exported by the TSS. To ensure that the the movement of this bit, does not lead to a more rigorous interpretation of what is required for conformance, we would have to properly set expectations in the corresponding conformance chapter. My understanding is that the IDL would change by moving the existing bit to the CompoundSecMech structure, and the CompoundSecMechList structure would be changed back to a simple sequence as apposed to a structure. Independent of this change, we should add a para like the followng after 137, and a cross reference it to para 185. A TSS is required to indicate in its IOR's via the stateful bit whether or not it is capable of operating in the mode of accepting reusable security contexts. Independent of this change, we should also add a new para after 185 which says something like: A TSS that is capable of operating in the mode of accepting stateful security contexts for one or more (including all) of the mechanism definitions in its exported IORs may legitimately claim stateful conformance. I'm not a big proponent of this change being necessary, but I can accept it if there is consensus on it. Talk to you tomorrow, Ron > > Please respond if you choose, but I won't be getting back to this for a > > little while. I think I will be away from work for most of Wednesday. I > > may be able to call in. > > > > > > I intend to comment on GSSUP (tonight), and review the module > > reorganization proposed by Polar (tomorrow). On the latter, I did a > > quick review of what he did and looked very good. > > Thank You. > > > Ron > > > > > > > > Cheers, > > > -Polar > > > > > > > > > > > > > Proposed Solution: > > > > > > > > > > Move the stateful field, as follows: > > > > > > > > > > module CSIIOP { > > > > > // type used in the body of a TAG_CSI_SEC_MECH_LIST component to describe a > > > > > // compound mechanism > > > > > > > > > > struct CompoundSecMech { > > > > > AssociationOptions target_requires; > > > > > IOP::TaggedComponent transport_mech; > > > > > AS_ContextSec as_context_mech; > > > > > SAS_ContextSec sas_context_mech; > > > > > boolean stateful; > > > > > }; > > > > > > > > > > // type corresponding to the body of a TAG_CSI_SEC_MECH_LIST component > > > > > > > > > > struct CompoundSecMechList { > > > > > sequence mechanism_list; > > > > > }; > > > > > > > > > > }; > > > > > > > > > > Cheers, > > > > > -Polar > > > > > > > > > > ------------------------------------------------------------------- > > > > > Polar Humenn Adiron, LLC > > > > > mailto:polar@adiron.com 2-212 CST > > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > ------------------------------------------------------------------- > > > Polar Humenn Adiron, LLC > > > mailto:polar@adiron.com 2-212 CST > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > Fax: 315-443-4745 http://www.adiron.com > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 23 Jan 2001 18:07:21 -0500 (EST) From: Polar Humenn To: Ron Monzillo cc: csiv2-ftf@omg.org Subject: Re: CSIv2 Issue Polar-4: Stateful boolean causes all CSI mechanismstooperate the same way. In-Reply-To: <3A6E092F.4B4335A1@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: VJ,!!WVmd9@Ee!!JX7!! Comments below: On Tue, 23 Jan 2001, Ron Monzillo wrote: > > > Polar Humenn wrote: > > > > Ron, et al, > > > > Comments below: > > > > On Mon, 22 Jan 2001, Ron Monzillo wrote: > > > > > > > Polar Humenn wrote: > > > > > > > > Ron, et al, > > > > > > > > Comments below. > > > > > > > > On Mon, 22 Jan 2001, Ron Monzillo wrote: > > > > > > > > > > > > > > > > > > > Polar Humenn wrote: > > > > > > > > > > > > Issue Polar-4: > > > > > > Subject: Stateful boolean causes all CSI mechanisms to > operate the same way. > > > > > > Document: > http://cgi.omg.org/pub/csiv2-ftf/csiv2-0117011.pdf > > > > > > Summary: > > > > > > > > > > > > The stateful boolean of the CSIIOP::CompoundSecMech forces > all CSI > > > > > > mechanisms to behave the same way with respect to state > retention. This is > > > > > > problematic and makes mechanisms parametric on the POA > they are > > > > > > supporting. The retention of state is actually a function > of an > > > > > > established transport, not a POA. > > > > > > > > > > > > Discussion: > > > > > > > > > > > > In the architecture (OMA) POA's are the 'owners' of object > references. > > > > > > Therefore, the state retention boolean must be set there, > as there is only > > > > > > one CompundSecMecList per object reference. > > > > > > > > > > > > You may have cases where multiple CSI mechanisms must > support one POA. > > > > > > > > > > > > These mechanisms may span POA's as they may be defaults > for many POA's. If > > > > > > state retention is parameterized on the particular > mechanism, then > > > > > > negotiating the state retention for each mechanism becomes > easier to > > > > > > handle, as the state retention algorithm is mechanism > specific. Therefore, > > > > > > that mechanism may operate independently of knowing the > POA. > > > > > > > > > > > > This makes the TSS mechanisms to be able to work > independently of the POA > > > > > > policy. > > > > > > > > > > > > Also, for another reason, CSI state retention is based on > the established > > > > > > transport, which has nothing to do with a POA, therefore > it is part of the > > > > > > CSI mechanism over which the transport it is working. > > > > > > > > > > > > I think the purpose for the "stateful" boolean was ill > conceived. It was > > > > > > thought of by some as a deficiency in your implementation > and you needed > > > > > > to provide a single boolean so one could RED FLAG a > security service > > > > > > "inferior" in some sense. > > > > > > > > > > This in not the reason the "stateful" boolean was > created. It was > > > > > created to support a client optimization, or in deference to > client > > > > > resources, such that a client could know when not to go to > the extra > > > > > overhead of setting up a stateful context when it knows the > target is > > > > > stateless. > > > > > > > > Okay. so we agree that we have "extra" overhead on the Client > side. > > > > Exactly my point. There is also some overhead incurred on the > server. See > > > > below. > > > > > > > > > This does not mean that it could never be useful for a > target to vary > > > > > with respect to its statefulness on a mechanism by mechanism > basis. In > > > > > which case the same optimization could be applied (wrt each > mechanism). > > > > > However, doing so would be functionality above and beyond > that defined > > > > > by the adopted submission. > > > > > > > > I merely raised it as an issue such that I think is a problem > with the > > > > "adopted" submission, based on implementation experience, and > my reasons > > > > are below. > > > > > > > > > > The fact is that state retention can be inefficient in > some cases. State > > > > > > retention is actually parameter that is a function of the > mechanism over a > > > > > > particular transport mechanism. One may want to use > mechanisms that retain > > > > > > their state where one makes lots of invocations over a > single transport > > > > > > (long live connections). (State retention is a function of > transport). > > > > > > Short lived connections need not incur the overhead. > > > > > > > > > > Can you give us an example using required CSIv2 mechanisms > where such > > > > > "inefficiency" would occur? > > > > > > > > Okay, > > > > > > > > I am a server. > > > > > > > > I may have a mechanism that requires fairly extensive > authorization > > > > validation, and retaining state over the transport for > invocations on many > > > > objects by that client will be beneficial to BOTH the client > and server, > > > > should the client choose to use it. I expect connections from > clients > > > > using this mechanism to be fairly long lived. > > > > > > > > I think everyone is agreed on this point. > > > > > > > > One thing that I want you to note is this: > > > > > > > > A CSI mechanism is not *exclusively* tied to the object. That > mechanism > > > > can show up in many IORs and a smart client can figure out > when it has a > > > > match on host/port/CSImechanism for reuse, even on different > objects. > > > > > > > > Now, I may also have a CSI mechanism that does not require > such lengthy > > > > authorization, and quite possibly a different transport, > associated with > > > > the same objects (both in the CompoundSecMechList). I plan on > getting many > > > > invocations from many different clients using this mechanism, > but I'm > > > > going to close the connection after each one, for availability > of the > > > > servers resources. > > > > > > > > However, since my "stateful" boolean at the top of the > CompoundSecMech > > > > must say "stateful" to support the above arduous mechanism, > the "eager to > > > > optimize" client keeps sending me client_context_ids that I > have to deny. > > > > The client must manage this. Not realizing that the connection > is going to > > > > be shut down after the reply, he incurs the overhead you speak > of for no > > > > good reason. > > > > > > > > Therefore, the "eager to optimize" client turns out NOT to > optimized. > > > > > > > > If the "stateful" boolean where associated with each CSI > mechanism and not > > > > the object, this scenario can be avoided. > > > > > > > > The basic cruxt is the FUNDEMENTAL architecture > difference. The CSI > > > > mechanism is not exclusively tied to the object, where as the > "stateful" > > > > attribute currently is. > > > > > > > > I believe this is a fundamental flaw in the CSIv2 > Architecture. > > > > > > > > > > That seems a little overboard. > > > > Not really. the "stateless" bit is for optimization, but it is > tied to the > > object, not the mechanism. I really do think this is fundemental. > > > > > The Stateless bit is for optimization > > > purposes. As stated in para 96, a stateful TSS can respond > statelessly > > > (to a stateful request) as long as it has no existing matching > context. > > > It is true that the IOR schema is not rich enough to optimize > the > > > client's behavior on a per mechanism basis. When a stateful > request is > > > negotiated down to stateless, a stateful client has enough > information > > > to modify its state such that it does not in the future act > statefully > > > using that Mechanism. > > > > That means the Client has to negotiate at the outset regardless of > whether > > the mechanism supports stateless or not. > > > > Hmmmm, we keep talking about the mechanism supporting state, not > the > > object. > > > > > This perhaps is not ideal, as it is not optimized for a case > where the > > > target supports more than one mechanism, some of which are > stateful and > > > some are not. > > > > True, that is the point I am trying to rectify. > > > > > My first thought was that if you want to do what you are > suggesting, > > > then maybe you could put multiple profiles in your IORs. I don't > think > > > this will be workable, as you may wind up interfering with other > uses > > > of multiple profiles (i.e fault tolerance) and you may not like > the > > > overhead of duplicating a profile, mostly to change a bit. > > > > Agreed. > > > > > My second thought was that if context_id scopes are defined by > transport > > > layer session (as defined in para 88), then perhaps you are > right; i.e > > > this change should be made. > > > > I think I am. :-) > > > > > My third thought was that moving this bit down such that it can > > > influence individual mechanisms, may create some complexity in > the > > > interpretation of requests made against multiple mechanism IOR's > where > > > there are two or more mechanisms which are identical in their > transport > > > definition, but differ in their statefulness (and other layer > > > definitions). I think this would conflict with para 88, in that > it would > > > be possible to indicate that a context_id scope does not apply > to all > > > the connections on a single transport session (one mechanims > being > > > stateful, another not). > > > > I don't think so. para 88 of csiv2-0117011.pdf says: > > > > Each transport layer session defines a context identifier > number scope. > > The CSS selects context identifiers for use within a scope. > > > > The client_context_id scope is per transport session *regardless* > of the > > CSI mechanism used on the session. The client_context_id refers to > a > > particular *security context*, which matches one of possibly many > CSI > > mechanisms. The ability of the CSI mechanism to handle state is > orthogonal > > to this argument. > > > > Yes I think you are right. Okay. We are agreed on this point. > > The case you state above is only interesting if every component of two CSI > > mechanisms are the same and the client would up generate the same CSI > > security context for each. One mechanism claims it retains state, and the > > other doesn't. > > > > A stateless client can still choose the mechanism if it says it retains > > state, and use it without retaining state. And, even if the client wants > > to retain state, a client can still choose the mechanism if it says it > > doesn't retain state, and process it "statelessly". > > > > > > On the server side, trying to implement "stateful" and "stateless" over a > > > > single mechanism is a possibility in the same server because that > > > > attribute would have to be associated the the POAs and not the mechanisms > > > > themselves. > > > > > > > > Using the same mechanism implementation for many objects within a server > > > > is beneficial. Having to determine the POA of each request, to figure out > > > > whether the policy is stateful or not, is an inefficient burden on the > > > > server. That is because while processing the mechanism, the mechanism has > > > > to operate in two different modes simultaneously, retaining state and not > > > > retaining state, which depends on the object (or POA) for which it is > > > > getting the request. > > > > > > I don't get this. If you want mechanism specific client side > > > optimization policy to be included in mechanisms, then what you are > > > talking about are mechanisms whose definition includes whether or not > > > they support stateful clients. > > > > In a sense, correct. However, I'd rather not think of them as "stateless > > clients" or "stateful clients" as this implies there is something amiss > > with its security implementation, because it refers to handing state > > regardless of mechanism. A "stateless client" or "stateful client" isn't a > > feature or a deficiency of the CSS, a point I brought up before. > > > > I'd rather think of it as a client that *chooses* to use a CSI mechanism > > in a "stateful" way, or a "stateless" way, depending on its requirements. > > > > I know that the stateful bit was not added to IORs to allow for a TSS > to be differentially stateful with respect to the objects/mechanisms > that it exports. This bit was added, with the presumption that a > stateful TSS is stateful or stateless for all the objects that it > exports, and for all the mechanism definitions under which it exports > those objects. Even so, you cannot make that claim beyond a single IOR, i.e. a single object. Even in the current setting, I can, if I want to, produce an IOR for an object from the same TSS implementation with the stateful bit on, and produce another IOR from the same TSS implementation with the stateful bit off. There is really no way to test conformance in this area without making some flawed assumptions, e.g. that a host/port pair signify a single TSS. > We were having enough trouble convincing people to provide stateful > support within the protocol, without implying the extra complexity > of a > single TSS having to specify on a per mechanism basis whether or not > it > is stateful. Hmmm. that is unfortunate. The only way you can handle state and stateless is if you actually have a good handle on the establishment and take down of the transport sessions. Could this really be the problem that you are running into? > That's how we got where we are. If we move the bit as you suggest,the > IOR schema will become powerful enough to allow a TSS to set this bit > per mechanism, and if it chooses, act differentially with respect to the > objects and mechanisms that it exports. > > I can support this change as long as we do not add any corresponding > requirement that a stateful TSS must be be able to be stateful with > respect to some objects/mechanisms and stateless with respect to others. > To claim stateful conformance, a TSS need only be able to be uniformly > stateful with respect to all the objects and mechanisms that it exports. > In this case, the value of this bit would be true in every mechanism > definition of every object exported by the TSS. Claiming "stateful conformance" merely only means that an implementation can handle retaining state if it wants to. I.e. the capability is there, and I can turn it off, if I please. > To ensure that the the movement of this bit, does not lead to a more > rigorous interpretation of what is required for conformance, we > would > have to properly set expectations in the corresponding conformance > chapter. Again, "stateful conformance" should mean that your implementation has the ability to handle state retention, not that it has to be on all the time. > My understanding is that the IDL would change by moving the existing bit > to the CompoundSecMech structure, and the CompoundSecMechList structure > would be changed back to a simple sequence as apposed to a structure. Well, we can still keep the structure with one list element in it. I like this approach better, as it keeps the type name and structure in language mappings where they the aliased types (typedefs) are dereferenced. Java is only one such language. > Independent of this change, we should add a para like the following after > 137, and a cross reference it to para 185. > > A TSS is required to indicate in its IOR's via the stateful bit whether > or not it is capable of operating in the mode of accepting reusable > security contexts. Surely. > Independent of this change, we should also add a new para after 185 > which says something like: > > A TSS that is capable of operating in the mode of accepting stateful > security contexts for one or more (including all) of the mechanism > definitions in its exported IORs may legitimately claim stateful > conformance. Surely. > I'm not a big proponent of this change being necessary, but I can > accept it if there is consensus on it. Comments from others? Cheers, -Polar > Talk to you tomorrow, > > Ron > > > > Please respond if you choose, but I won't be getting back to > this for a > > > little while. I think I will be away from work for most of > Wednesday. I > > > may be able to call in. > > > > > > > > > I intend to comment on GSSUP (tonight), and review the module > > > reorganization proposed by Polar (tomorrow). On the latter, I > did a > > > quick review of what he did and looked very good. > > > > Thank You. > > > > > Ron > > > > > > > > > > > Cheers, > > > > -Polar > > > > > > > > > > > > > > > > Proposed Solution: > > > > > > > > > > > > Move the stateful field, as follows: > > > > > > > > > > > > module CSIIOP { > > > > > > // type used in the body of a TAG_CSI_SEC_MECH_LIST > component to describe a > > > > > > // compound mechanism > > > > > > > > > > > > struct CompoundSecMech { > > > > > > AssociationOptions target_requires; > > > > > > IOP::TaggedComponent transport_mech; > > > > > > AS_ContextSec as_context_mech; > > > > > > SAS_ContextSec sas_context_mech; > > > > > > boolean stateful; > > > > > > }; > > > > > > > > > > > > // type corresponding to the body of a > TAG_CSI_SEC_MECH_LIST component > > > > > > > > > > > > struct CompoundSecMechList { > > > > > > sequence mechanism_list; > > > > > > }; > > > > > > > > > > > > }; > > > > > > > > > > > > Cheers, > > > > > > -Polar > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > > Polar Humenn Adiron, LLC > > > > > > mailto:polar@adiron.com 2-212 CST > > > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > Polar Humenn Adiron, LLC > > > > mailto:polar@adiron.com 2-212 CST > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 20 Mar 2001 15:53:52 -0500 (EST) From: Polar Humenn To: Ron Monzillo cc: csiv2-ftf@omg.org Subject: Issue 4167: Stateful boolean causes all CSI mechanisms to operate the same way. In-Reply-To: <3AB78762.EF3972C0@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: c~i!!IX>e9";d!!l/]!! Sun's position seems to imply as they did in the submission process that not having a "stateful TSS" is more of a flagging of a deficiency in your implementation than in actuality a beneficial capability. I don't agree with the proposal to close the issue without change. The benefits of distributing the stateful boolean within each security mechanism is that the client can make the decision of whether the target is stateful in it's security mechanism. I may turn on the stateful boolean for long lived connections to an object that are made with SSL and some authorization information, and thereby want to incur the overhead of doing so. However, I don't want it for IIOP connections, because the calls may be short enough. Say that the only call I may allow with IIOP is "_non_existent". I don't really need the client establishing stateful contexts for that. Yet, I cannot set the server side policy to state so. This is a deficiency in the specification. -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com 9. I recommend that we close Issue 4167: Stateful boolean causes all CSI > mechanisms > to operate the same way,with the following proposed modifications. I > realize that > these changes do not provide the desired functionality; they are merely > clarifications > to the spec that I discovered in reviewing this issue. > > [1] After para 139, we should add the following para. > > A TSS is required to indicate in its IOR's via the stateful bit whether > or not it is capable of operating in the mode of accepting reusable > security contexts. > > [2] after para 188, we should add the following para. > > A TSS that is capable of operating in the mode of accepting stateful > security contexts for one or more (including all) of the mechanism > definitions in its exported IORs may legitimately claim stateful > conformance. Date: Thu, 24 May 2001 16:41:50 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: csiv2-ftf@omg.org Subject: Issue 4167: Stateful boolean causes all CSI mechanisms to operate the Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: '*V!!(kp!!2@?!!3>=!! I have reconsidered my position on this issue. I will veto a change to the precision of the stateful annotation within the CSIv2 CSI_SEC_MECH_LIST tagged component to per mechanism (from one annotation that applies to all mechanisms in the list). X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 24 May 2001 16:58:28 -0400 (EDT) From: Polar Humenn To: Ron Monzillo cc: Subject: Re: Issue 4167: Stateful boolean causes all CSI mechanisms to operate the In-Reply-To: <3B0D720E.3E5A8464@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: (2g!!N[,e9&B;e9i# I have reconsidered my position on this issue. I will veto > a change to the precision of the stateful annotation > within the CSIv2 CSI_SEC_MECH_LIST tagged component to per > mechanism (from one annotation that applies to all mechanisms > in the list). > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Importance: Normal Subject: Re: Issue 4167: Stateful boolean causes all CSI mechanisms to operate the To: Polar Humenn Cc: Ron Monzillo , From: "David Chang" Date: Thu, 24 May 2001 18:47:54 -0400 Message-ID: X-MIMETrack: Serialize by Router on D04NM203/04/M/IBM(Release 5.0.6 |December 14, 2000) at 05/24/2001 06:47:56 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: $Co!!!KJe9!Dmd901B!! Status: RO Polar, Per CSIv2 CSI_SEC_MECH_LIST tagged component Stateful Boolean flag is sufficient to address the performance requirement which was raised by IBM during the CSIv2 specification proposal time. The per security mechanism Stateful Boolean flag will complicate the CSIv2 client state diagram. Regards, David Chang WebSphere Security Architect & Team Lead IBM SWS Division, Internal Mail Stop 9131 Austin, Tx 78758 E-Mail:dyc@us.ibm.com Phone:(512)838-0559, T/L 678-0559 Fax: (512)838-1032 Polar Humenn on 05/24/2001 03:58:28 PM To: Ron Monzillo cc: Subject: Re: Issue 4167: Stateful boolean causes all CSI mechanisms to operate the Oh well. So much for that. -Polar On Thu, 24 May 2001, Ron Monzillo wrote: > I have reconsidered my position on this issue. I will veto > a change to the precision of the stateful annotation > within the CSIv2 CSI_SEC_MECH_LIST tagged component to per > mechanism (from one annotation that applies to all mechanisms > in the list). > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Fri, 25 May 2001 09:20:35 -0400 (EDT) From: Polar Humenn To: David Chang cc: Ron Monzillo , Subject: Re: Issue 4167: Stateful boolean causes all CSI mechanisms to operate the In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ~92!!N+3!!LfW!!D5H!! On Thu, 24 May 2001, David Chang wrote: > Polar, > > Per CSIv2 CSI_SEC_MECH_LIST tagged component Stateful Boolean > flag is sufficient to address the performance requirement which was >raised > by IBM during the CSIv2 specification proposal time. The per >security > mechanism Stateful Boolean flag will complicate the CSIv2 client >state > diagram. Well, that's definately not true. The stateful bit in the CSI_SEC_MECH_LIST doesn't even enter into the state diagram. But, as the world would have it, it's not worth arguing about any longer. Sigh. -Polar > > > Regards, > > > David Chang > > WebSphere Security Architect & Team Lead > IBM SWS Division, Internal Mail Stop 9131 > Austin, Tx 78758 > E-Mail:dyc@us.ibm.com > Phone:(512)838-0559, T/L 678-0559 > Fax: (512)838-1032 > > > Polar Humenn on 05/24/2001 03:58:28 PM > > To: Ron Monzillo > cc: > Subject: Re: Issue 4167: Stateful boolean causes all CSI mechanisms >to > operate the > > > > > Oh well. So much for that. > -Polar > > > On Thu, 24 May 2001, Ron Monzillo wrote: > > > I have reconsidered my position on this issue. I will veto > > a change to the precision of the stateful annotation > > within the CSIv2 CSI_SEC_MECH_LIST tagged component to per > > mechanism (from one annotation that applies to all mechanisms > > in the list). > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Wed, 15 May 2002 15:35:17 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en To: corba-rtf@omg.org Subject: Proposed resolution for 4167 The following resolution will appear in the next vote unless there is significant technical objection to it. Jishnu ____________________________________________________________________ Issue 4167: Stateful boolean causes all CSI mechanisms to operate the same way. (csiv2-ftf) http://cgi.omg.org/issues/issue4167.txt Source: Syracuse University (Mr. Polar Humenn, polar@adiron.com) Nature: Uncategorized Issue Severity: Summary: The stateful boolean of the CSIIOP::CompoundSecMech forces all CSI mechanisms to behave the same way with respect to state retention. This is problematic and makes mechanisms parametric on the POA they are supporting. The retention of state is actually a function of an established transport, not a POA. . . . . . . . . Resolution: The proposed change is backward incompatible and contrary to the intent of the original submission. Close no change. Revised Text: Actions taken: Close no change