Issue 4327: clarification of csiv2 stateful conformance requirements (csiv2-ftf) Source: Oracle (Mr. Ron Monzillo, ronald.monzillo(at)east.sun.com) Nature: Uncategorized Issue Severity: Summary: The specification is currently weak on its description of what must be done by a TSS with respect to designating a "stateful" value in its IOR's, and in defining under what circumstances a TSS may claim stateful conformance. In particular, the spec does not currently state whether or not a TSS must be stateful for all of its mechanism definitions, at all of its target objects in order to claim stateful conformance. The following paragraphs should be included to clarify these two issues. Resolution: Close issue with revised text Revised Text: Base document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf [1] Add the following new para after para 140, A TSS shall set the stateful bit to FALSE in the CompoundSecMechList structure of IORs corresponding to target objects at which it will not accept reusable security contexts. Actions Taken: Actions taken: May 30, 2001: received issue October 3, 2001: closed issue Discussion: the thing that is missing in the doc, is that we do not currently have anything that says a TSS is required to set the stateful bit. [99] A TSS that supports stateful contexts may negotiate a request to establish a stateful context to a stateless context in order to preserve resources. It may do so only if it does not already have an established matching stateful context. [100] Conversely, a stateful TSS that has negotiated a request to stateless may respond statefully to a subsequent context with the same (non-zero) client_context_id. We have a description of what the bit means (in para 140) which focuses on what a TRUE value means. Perhaps you are saying that we need a description of what a FALSE value means. My sense is that the FALSE semantics are clear enough. [140] A value of TRUE in the stateful field of the CompoundSecMechList structure indicates that the target supports the establishment of stateful or reusable SAS contexts. This field is provided to assist clients in their selection of a target that supports stateful contexts. It is also provided to sustain implementations that serialize stateful context establishment on the client side as a means to conserve precious server-side authentication capacity.10 10.This serialization is only done when an attempt is being made to establish a stateful context. The last part of 140 says that if the stateful bit is true, some CSS implementations will not send multiple concurrent requests to establish the same stateful context. This design changes the multithreaded nature of the client app (for the round-trip time of one request) in exchange for not wasting the resources of the TSS. What it really says is that the serialization is acceptable if it only occurs when the bit is true, as one way or another, multiple requests should be serialized until the stateful context is established. In one design the serialization happens at the CSS, and in the other (if it occurs, it is done) at the TSS. This hint, was strongly argued for, because without it CSS side serialization would be at a disadvantage because it would happen in too many cases where it could come to no benefit. We have decided to let the (stateful) conformance statements stand as they are written. Resolution: End of Annotations:===== Date: Wed, 30 May 2001 07:09:15 -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, issues@omg.org Subject: Issue: clarification of csiv2 stateful conformance requirements Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: XiD!!QR,!!mPe!!WCS!! base document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf Discussion: The specification is currently weak on its description of what must be done by a TSS with respect to designating a "stateful" value in its IOR's, and in defining under what circumstances a TSS may claim stateful conformance. In particular, the spec does not currently state whether or not a TSS must be stateful for all of its mechanism definitions, at all of its target objects in order to claim stateful conformance. The following paragraphs should be included to clarify these two issues. Proposed Resolution: [1] Add the following new para after para 140, A TSS shall set the stateful bit in its IORs to indicate whether or not it is capable of operating in the mode of accepting reusable security contexts. [2] Add the following new para after para 188 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. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 31 May 2001 13:28:48 -0400 (EDT) From: Polar Humenn To: Ron Monzillo cc: Subject: On Proposed Resolution to Issue 4327 [1] In-Reply-To: <3B1665B7.7FDA8CDF@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 4kV!!0J/e9j`'!!/C/!! Sun's proposed resolution for issue 4327 states: base document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf [1] Add the following new para after para 140, A TSS shall set the stateful bit in its IORs to indicate whether or not it is capable of operating in the mode of accepting reusable security contexts. This statement makes requirements on IORs based on the capability of the software being used. The mere fact that a TSS is functionally capable of accepting resuable security contexts does not mean that it must set a bit in its IORs. It may choose not to set the bit, because it doesn't want to process state. (This desire may be a policy decision of the target). I think paragraph 140 says enough and is to the point, which says: "A value of TRUE in the stateful field of the CompoundSecMechList structure indicates that the target supports the establishment of stateful or reusable SAS contexts...." (more to come on this resolution in next email). 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: Thu, 31 May 2001 13:43:30 -0400 (EDT) From: Polar Humenn To: Ron Monzillo cc: Subject: On Resolution to Issue 4327 [2] In-Reply-To: <3B1665B7.7FDA8CDF@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: `+T!!L&%!!!bfd95SLe9 And Sun also writes in its proposed resolution to issue 4327: [2] Add the following new para after para 188 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. This statement gets to the exact point I make about the stateful bit being distributed to each mechanism instead of all of the mechanisms in the list. I believe what is getting in [2] that with [1] of this resolution, is that if one of the mechanisms supports stateful contexts, the stateful bit, which is currently in the CompoundSecMechList must be turned on. If the stateful bit were on each mechanism, statements of this sort wouldn't have to exist. In anycase, what is this statement actually trying to say? Either your product supports stateful security contexts or it doesn't. Are you trying to say that it only has to support stateful security contexts for one supported mechanism? For example, let's say a product supports a bunch of CSIv2 mechanisms, but only supports stateful contexts in a CSIv2 mechanism using SECIOP-SPKM2 only with Identity Assertion, and nothing else. May this product legitimately claim stateful conformance? Even if no body uses the mechanism, ever? Do you see my point? I think this conformance point is pretty useless at best. If a product supports stateful security contexts for specific mechanisms, then you might have a claim that actually meant something tangible. 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: Thu, 31 May 2001 11:27:13 -0700 (PDT) From: Jeff Reply-To: jmischki@dcn.davis.ca.us Subject: Re: On Proposed Resolution to Issue 4327 [1] To: Polar Humenn , Ron Monzillo Cc: csiv2-ftf@omg.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: #K4!!mgIe9:jhd9I]H!! --- Polar Humenn wrote: > > Sun's proposed resolution for issue 4327 states: > > base document: > > http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf > > [1] Add the following new para after para 140, > > A TSS shall set the stateful bit in its IORs to > indicate whether or not > it is capable of operating in the mode of > accepting reusable security > contexts. > > This statement makes requirements on IORs based on > the capability of the > software being used. The mere fact that a TSS is > functionally capable of > accepting resuable security contexts does not mean > that it must set a bit > in its IORs. It may choose not to set the bit, > because it doesn't want to > process state. (This desire may be a policy decision > of the target). I have a slightly different question: What are the intended implications of setting the bit. If the bit is off, then i (the client using the ior) know that the target can't/won't operate in a stateful mode. But if it is set, what conclusions can i draw about the probability that if i attempt to operate in a stateful mode, that i will be successful? jeff > > I think paragraph 140 says enough and is to the > point, which says: > > "A value of TRUE in the stateful field of the > CompoundSecMechList > structure indicates that the target supports the > establishment of > stateful or reusable SAS contexts...." > > (more to come on this resolution in next email). > > 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 > > > ===== jmischki@dcn.davis.ca.us 530-758-9850 jeff.mischkinsky@oracle.com 650-506-1975 Date: Thu, 31 May 2001 15:04:57 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: jmischki@dcn.davis.ca.us CC: Polar Humenn , Ron Monzillo , csiv2-ftf@omg.org Subject: Re: On Proposed Resolution to Issue 4327 [1] References: <20010531182713.22108.qmail@web9302.mail.yahoo.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: AVjd9P\Ke97K7!!T-G!! Jeff wrote: > > --- Polar Humenn wrote: > > > > Sun's proposed resolution for issue 4327 states: > > > > base document: > > > > http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf > > > > [1] Add the following new para after para 140, > > > > A TSS shall set the stateful bit in its IORs to > > indicate whether or not > > it is capable of operating in the mode of > > accepting reusable security > > contexts. > > > > This statement makes requirements on IORs based on > > the capability of the > > software being used. The mere fact that a TSS is > > functionally capable of > > accepting resuable security contexts does not mean > > that it must set a bit > > in its IORs. It may choose not to set the bit, > > because it doesn't want to > > process state. (This desire may be a policy decision > > of the target). > > I have a slightly different question: > > What are the intended implications of setting the bit. > If the bit is off, then i (the client using the ior) > know that the target can't/won't operate in a stateful > mode. But if it is set, what conclusions can i draw > about the probability that if i attempt to operate in > a stateful mode, that i will be successful? > Yes, if you are asking if there are circumstances when the stateful bit is set and the target will not accept a stateful request; the answer is yes. One example, could be if the target has or is about to exhaust all the resources it has for representing state, and to protect itself, it chooses to negotiate everything down to stateless, until its resource crunch clears up. Another server might use some type of a quota algorithm, to limit the number of stateful contexts that may be established by a particular user, network address, etc. the word "capable" was chosen to allow the TSS the latitude to protect itself in ways like those given in the examples above. In retrospect, I agree that the word is too liberal on the other side, as it would most likely be interpretted to mean that a TSS must set the value of this bit to the same value in all its IORs. I propose that item 1 of the proposed resolution be changed to the following: A TSS shall set the stateful bit in its IORs to indicate whether or not it accepts reusable security contexts at the corresponding target objects. Will that work? Ron > jeff > > > > I think paragraph 140 says enough and is to the > > point, which says: > > > > "A value of TRUE in the stateful field of the > > CompoundSecMechList > > structure indicates that the target supports the > > establishment of > > stateful or reusable SAS contexts...." > > > > (more to come on this resolution in next email). > > > > 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 > > > > > > > > ===== > jmischki@dcn.davis.ca.us 530-758-9850 > jeff.mischkinsky@oracle.com 650-506-1975 > > __________________________________________________ > Do You Yahoo!? > Get personalized email addresses from Yahoo! Mail - only $35 > a year! http://personal.mail.yahoo.com/ X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 31 May 2001 15:05:53 -0400 (EDT) From: Polar Humenn To: cc: Ron Monzillo , Subject: Re: On Proposed Resolution to Issue 4327 [1] In-Reply-To: <20010531182713.22108.qmail@web9302.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: m:`!!c,!e9hUJ!!#Xh!! On Thu, 31 May 2001, Jeff wrote: > > --- Polar Humenn wrote: > > > > Sun's proposed resolution for issue 4327 states: > > > > base document: > > > > http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf > > > > [1] Add the following new para after para 140, > > > > A TSS shall set the stateful bit in its IORs to > > indicate whether or not > > it is capable of operating in the mode of > > accepting reusable security > > contexts. > > > > This statement makes requirements on IORs based on > > the capability of the > > software being used. The mere fact that a TSS is > > functionally capable of > > accepting resuable security contexts does not mean > > that it must set a bit > > in its IORs. It may choose not to set the bit, > > because it doesn't want to > > process state. (This desire may be a policy decision > > of the target). > > I have a slightly different question: > > What are the intended implications of setting the bit. > If the bit is off, then i (the client using the ior) > know that the target can't/won't operate in a stateful > mode. But if it is set, what conclusions can i draw > about the probability that if i attempt to operate in > a stateful mode, that i will be successful? Good question. With the current scheme, after a selection of a mechanism, the probability is 0.5*1/n, where n is the number of mechanisms in the CSIv2 CompoundSecMechList structure. That is because you don't have a clue as to which mechanism maybe operating in a stateful way. So that probability is 1/n. Furthermore, you only have a (dumb guess) 50/50 chance that the mechanisms you selected will respond in a stateful manner, since there is no requirement for it to do. Case in point, let's say only one mechanism is listed, it isn't clear whether you would have success state retention by the target. So, the chance of it working is at best 50/50. Note: that if the stateful bit is per mechanism, the requirements can be a bit more stringent, but not much. We might be able to state that if the stateful bit is on, for a specific mechanism, the client can have a high probability that it would succeed. But the upside to that, is you know exactly which ones will not succeed in state retention. I would tend to stay away from saying that state retention is totally required to succeed if the stateful bit is on, because the TSS may have dynamic resource/load problems in which case it might have to deny requests for state retention. Cheers, -Polar > jeff > > > > I think paragraph 140 says enough and is to the > > point, which says: > > > > "A value of TRUE in the stateful field of the > > CompoundSecMechList > > structure indicates that the target supports the > > establishment of > > stateful or reusable SAS contexts...." > > > > (more to come on this resolution in next email). > > > > 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 > > > > > > > > > ===== > jmischki@dcn.davis.ca.us 530-758-9850 > jeff.mischkinsky@oracle.com 650-506-1975 > > __________________________________________________ > Do You Yahoo!? > Get personalized email addresses from Yahoo! Mail - only $35 > a year! http://personal.mail.yahoo.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: Thu, 31 May 2001 15:12:02 -0400 (EDT) From: Polar Humenn To: Ron Monzillo cc: , Subject: Re: On Proposed Resolution to Issue 4327 [1] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: YWVd9'?P!!mc>!!X($e9 OKay, if you want a positive statement: how about this: A TSS shall set the stateful bit to FALSE in its IORs if it will not accept reusable security contexts at the corresponding target objects. On Thu, 31 May 2001, Polar Humenn wrote: > > Since this state is NOT required to be retained by the server if the > stateful bit is on, why try to do form this "requirement" in >positive > terms. > > Don't you really want: > > A TSS shall not set the stateful bit to TRUE in its IORs if it will >not > accept reusable security contexts at the corresponding target >objects. > > Cheers, > -Polar > > > On Thu, 31 May 2001, Ron Monzillo wrote: > > > Jeff wrote: > > > > > > --- Polar Humenn wrote: > > > > > > > > Sun's proposed resolution for issue 4327 states: > > > > > > > > base document: > > > > > > > > http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf > > > > > > > > [1] Add the following new para after para 140, > > > > > > > > A TSS shall set the stateful bit in its IORs to > > > > indicate whether or not > > > > it is capable of operating in the mode of > > > > accepting reusable security > > > > contexts. > > > > > > > > This statement makes requirements on IORs based on > > > > the capability of the > > > > software being used. The mere fact that a TSS is > > > > functionally capable of > > > > accepting resuable security contexts does not mean > > > > that it must set a bit > > > > in its IORs. It may choose not to set the bit, > > > > because it doesn't want to > > > > process state. (This desire may be a policy decision > > > > of the target). > > > > > > I have a slightly different question: > > > > > > What are the intended implications of setting the bit. > > > If the bit is off, then i (the client using the ior) > > > know that the target can't/won't operate in a stateful > > > mode. But if it is set, what conclusions can i draw > > > about the probability that if i attempt to operate in > > > a stateful mode, that i will be successful? > > > > > > > Yes, if you are asking if there are circumstances > > when the stateful bit is set and the target will not accept a > > stateful request; the answer is yes. One example, could be > > if the target has or is about to exhaust all the resources it > > has for representing state, and to protect itself, it chooses > > to negotiate everything down to stateless, until its resource > > crunch clears up. Another server might use some type of a quota > > algorithm, to limit the number of stateful contexts that may > > be established by a particular user, network address, etc. > > > > the word "capable" was chosen to allow the TSS the latitude to > > protect itself in ways like those given in the examples above. > > > > In retrospect, I agree that the word is too liberal > > on the other side, as it would most likely be interpretted to > > mean that a TSS must set the value of this bit to the same value > > in all its IORs. > > > > I propose that item 1 of the proposed resolution be changed > > to the following: > > > > A TSS shall set the stateful bit in its IORs to indicate whether > > or not it accepts reusable security contexts at the corresponding > > target objects. > > > > Will that work? > > > > Ron > > > jeff > > > > > > > > I think paragraph 140 says enough and is to the > > > > point, which says: > > > > > > > > "A value of TRUE in the stateful field of the > > > > CompoundSecMechList > > > > structure indicates that the target supports the > > > > establishment of > > > > stateful or reusable SAS contexts...." > > > > > > > > (more to come on this resolution in next email). > > > > > > > > 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 > > > > > > > > > > > > > > > > > > ===== > > > jmischki@dcn.davis.ca.us 530-758-9850 > > > jeff.mischkinsky@oracle.com 650-506-1975 > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Get personalized email addresses from Yahoo! Mail - only $35 > > > a year! http://personal.mail.yahoo.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: Thu, 31 May 2001 12:23:28 -0700 (PDT) From: Jeff Reply-To: jmischki@dcn.davis.ca.us Subject: Re: On Proposed Resolution to Issue 4327 [1] To: Ron Monzillo , jmischki@dcn.davis.ca.us Cc: Polar Humenn , Ron Monzillo , csiv2-ftf@omg.org In-Reply-To: <3B1695D9.D6666268@east.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: [!kd9n~:e96do!!E wrote: > > > > I have a slightly different question: > > > > What are the intended implications of setting the > bit. > > If the bit is off, then i (the client using the > ior) > > know that the target can't/won't operate in a > stateful > > mode. But if it is set, what conclusions can i > draw > > about the probability that if i attempt to operate > in > > a stateful mode, that i will be successful? > > > > Yes, if you are asking if there are circumstances > when the stateful bit is set and the target will not > accept a > stateful request; the answer is yes. One example, > could be > if the target has or is about to exhaust all the > resources it > has for representing state, and to protect itself, > it chooses > to negotiate everything down to stateless, until its > resource > crunch clears up. Another server might use some type > of a quota > algorithm, to limit the number of stateful contexts > that may > be established by a particular user, network > address, etc. > > the word "capable" was chosen to allow the TSS the > latitude to > protect itself in ways like those given in the > examples above. > > In retrospect, I agree that the word is too liberal > on the other side, as it would most likely be > interpretted to > mean that a TSS must set the value of this bit to > the same value > in all its IORs. > > I propose that item 1 of the proposed resolution be > changed > to the following: > > A TSS shall set the stateful bit in its IORs to > indicate whether > or not it accepts reusable security contexts at the > corresponding > target objects. > > Will that work? I think that this needs a little more clarification explaining that even if the bit is set, there may be times when the stateful request will not be accepted. Something along the lines of: Note: A TSS which indicates that it accepts reusable security contexts may not do so under all circumstances. Clients need to be prepared to deal with such a request being a rejectd. jeff > > Ron > > jeff > > > > > > I think paragraph 140 says enough and is to the > > > point, which says: > > > > > > "A value of TRUE in the stateful field of the > > > CompoundSecMechList > > > structure indicates that the target supports > the > > > establishment of > > > stateful or reusable SAS contexts...." > > > > > > (more to come on this resolution in next > email). > > > > > > 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 > > > > > > > > > > > > > ===== > > jmischki@dcn.davis.ca.us 530-758-9850 > > jeff.mischkinsky@oracle.com 650-506-1975 > > > > __________________________________________________ > > Do You Yahoo!? > > Get personalized email addresses from Yahoo! Mail > - only $35 > > a year! http://personal.mail.yahoo.com/ > > ===== jmischki@dcn.davis.ca.us 530-758-9850 jeff.mischkinsky@oracle.com 650-506-1975 __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ Date: Thu, 31 May 2001 15:29:34 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: jmischki@dcn.davis.ca.us CC: Ron Monzillo , Polar Humenn , csiv2-ftf@omg.org Subject: Re: On Proposed Resolution to Issue 4327 [1] References: <20010531192328.27374.qmail@web9302.mail.yahoo.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: "@]d9Cfm!!^ OKay, if you want a positive statement: how about this: > > A TSS shall set the stateful bit to FALSE in its IORs if it will not > accept reusable security contexts at the corresponding target > objects. > > I'm not sure which form is better. Ron Jeff wrote: > > --- Ron Monzillo wrote: > > > > > > > I have a slightly different question: > > > > > > What are the intended implications of setting the > > bit. > > > If the bit is off, then i (the client using the > > ior) > > > know that the target can't/won't operate in a > > stateful > > > mode. But if it is set, what conclusions can i > > draw > > > about the probability that if i attempt to operate > > in > > > a stateful mode, that i will be successful? > > > > > > > Yes, if you are asking if there are circumstances > > when the stateful bit is set and the target will not > > accept a > > stateful request; the answer is yes. One example, > > could be > > if the target has or is about to exhaust all the > > resources it > > has for representing state, and to protect itself, > > it chooses > > to negotiate everything down to stateless, until its > > resource > > crunch clears up. Another server might use some type > > of a quota > > algorithm, to limit the number of stateful contexts > > that may > > be established by a particular user, network > > address, etc. > > > > the word "capable" was chosen to allow the TSS the > > latitude to > > protect itself in ways like those given in the > > examples above. > > > > In retrospect, I agree that the word is too liberal > > on the other side, as it would most likely be > > interpretted to > > mean that a TSS must set the value of this bit to > > the same value > > in all its IORs. > > > > I propose that item 1 of the proposed resolution be > > changed > > to the following: > > > > A TSS shall set the stateful bit in its IORs to > > indicate whether > > or not it accepts reusable security contexts at the > > corresponding > > target objects. > > > > Will that work? > I think that this needs a little more clarification > explaining that even if the bit is set, there may be > times when the stateful request will not be accepted. > Something along the lines of: > Note: A TSS which indicates that it accepts reusable > security contexts may not do so under all > circumstances. Clients need to be prepared to deal > with such a request being a rejectd. > > jeff > > > > Ron > > > jeff > > > > > > > > I think paragraph 140 says enough and is to the > > > > point, which says: > > > > > > > > "A value of TRUE in the stateful field of the > > > > CompoundSecMechList > > > > structure indicates that the target supports > > the > > > > establishment of > > > > stateful or reusable SAS contexts...." > > > > > > > > (more to come on this resolution in next > > email). > > > > > > > > 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 > > > > > > > > > > > > > > > > > > ===== > > > jmischki@dcn.davis.ca.us 530-758-9850 > > > jeff.mischkinsky@oracle.com 650-506-1975 > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Get personalized email addresses from Yahoo! Mail > > - only $35 > > > a year! http://personal.mail.yahoo.com/ > > > > > > ===== > jmischki@dcn.davis.ca.us 530-758-9850 > jeff.mischkinsky@oracle.com 650-506-1975 > > __________________________________________________ > Do You Yahoo!? > Get personalized email addresses from Yahoo! Mail - only $35 > a year! http://personal.mail.yahoo.com/ X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 31 May 2001 15:10:02 -0400 (EDT) From: Polar Humenn To: Ron Monzillo cc: , Subject: Re: On Proposed Resolution to Issue 4327 [1] In-Reply-To: <3B1695D9.D6666268@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 1BT!!("b!!5ni!!4U\!! Since this state is NOT required to be retained by the server if the stateful bit is on, why try to do form this "requirement" in positive terms. Don't you really want: A TSS shall not set the stateful bit to TRUE in its IORs if it will not accept reusable security contexts at the corresponding target objects. Cheers, -Polar On Thu, 31 May 2001, Ron Monzillo wrote: > Jeff wrote: > > > > --- Polar Humenn wrote: > > > > > > Sun's proposed resolution for issue 4327 states: > > > > > > base document: > > > > > > http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf > > > > > > [1] Add the following new para after para 140, > > > > > > A TSS shall set the stateful bit in its IORs to > > > indicate whether or not > > > it is capable of operating in the mode of > > > accepting reusable security > > > contexts. > > > > > > This statement makes requirements on IORs based on > > > the capability of the > > > software being used. The mere fact that a TSS is > > > functionally capable of > > > accepting resuable security contexts does not mean > > > that it must set a bit > > > in its IORs. It may choose not to set the bit, > > > because it doesn't want to > > > process state. (This desire may be a policy decision > > > of the target). > > > > I have a slightly different question: > > > > What are the intended implications of setting the bit. > > If the bit is off, then i (the client using the ior) > > know that the target can't/won't operate in a stateful > > mode. But if it is set, what conclusions can i draw > > about the probability that if i attempt to operate in > > a stateful mode, that i will be successful? > > > > Yes, if you are asking if there are circumstances > when the stateful bit is set and the target will not accept a > stateful request; the answer is yes. One example, could be > if the target has or is about to exhaust all the resources it > has for representing state, and to protect itself, it chooses > to negotiate everything down to stateless, until its resource > crunch clears up. Another server might use some type of a quota > algorithm, to limit the number of stateful contexts that may > be established by a particular user, network address, etc. > > the word "capable" was chosen to allow the TSS the latitude to > protect itself in ways like those given in the examples above. > > In retrospect, I agree that the word is too liberal > on the other side, as it would most likely be interpretted to > mean that a TSS must set the value of this bit to the same value > in all its IORs. > > I propose that item 1 of the proposed resolution be changed > to the following: > > A TSS shall set the stateful bit in its IORs to indicate whether > or not it accepts reusable security contexts at the corresponding > target objects. > > Will that work? > > Ron > > jeff > > > > > > I think paragraph 140 says enough and is to the > > > point, which says: > > > > > > "A value of TRUE in the stateful field of the > > > CompoundSecMechList > > > structure indicates that the target supports the > > > establishment of > > > stateful or reusable SAS contexts...." > > > > > > (more to come on this resolution in next email). > > > > > > 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 > > > > > > > > > > > > > ===== > > jmischki@dcn.davis.ca.us 530-758-9850 > > jeff.mischkinsky@oracle.com 650-506-1975 > > > > __________________________________________________ > > Do You Yahoo!? > > Get personalized email addresses from Yahoo! Mail - only $35 > > a year! http://personal.mail.yahoo.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: Thu, 31 May 2001 12:43:50 -0700 (PDT) From: Jeff Reply-To: jmischki@dcn.davis.ca.us Subject: Re: On Proposed Resolution to Issue 4327 [1] To: Ron Monzillo Cc: csiv2-ftf@omg.org In-Reply-To: <3B169B9E.5568A137@east.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-UIDL: #Had9gj]d9@o@e90m6!! --- Ron Monzillo wrote: > Jeff, > > The "other" statements you are looking for are > already in the > document. Check out the section on Steful/Reusable > Contexts, > especially para 99 and 100. thx > > [99] A TSS that supports stateful contexts may > negotiate a request to > establish a stateful context to a stateless context > in order to preserve > resources. It may do so only if it does not already > have an established > matching stateful context. > > [100] Conversely, a stateful TSS that has negotiated > a request to > stateless may respond statefully to a subsequent > context with the same > (non-zero) client_context_id. > > I think Polar's last rewrite also has possibilities, > as I think what it > really says is you will not see true, uless there is > some chance of > establishing a reusble context. > > > OKay, if you want a positive statement: how about > this: > > > > A TSS shall set the stateful bit to FALSE in its > IORs if it will not > > accept reusable security contexts at the > corresponding target objects. I think i'd also add the description of what happens when in the other case, just to reduce possible confusion. "Setting the stateful bit to TRUE indicates that it may, but is not required to under all circumstances, to accept reusable security contexts." ===== jmischki@dcn.davis.ca.us 530-758-9850 jeff.mischkinsky@oracle.com 650-506-1975 __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ Date: Thu, 31 May 2001 15:45:20 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn Cc: Ron Monzillo , jmischki@dcn.davis.ca.us, csiv2-ftf@omg.org Subject: Re: On Proposed Resolution to Issue 4327 [1] References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: U#^!!'*"!!;e#!!Bapd9 Polar Humenn wrote: > > OKay, if you want a positive statement: how about this: > > "A TSS shall set the stateful bit to FALSE in its IORs if it will not > accept reusable security contexts at the corresponding target objects." > And Jeff says (with my slight addition): > "Note: A TSS which indicates that it accepts reusable > security contexts by setting the stateful bit to TRUE, > may not do so under all > circumstances. Clients need to be prepared to deal with stateful requests being rejected even under these circumstances." Seems to me that something like those two together does the trick. Jishnu. Date: Thu, 31 May 2001 16:41:27 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: jishnu_mukerji@hp.com CC: Polar Humenn , Ron Monzillo , jmischki@dcn.davis.ca.us, csiv2-ftf@omg.org Subject: Re: On Proposed Resolution to Issue 4327 [1] References: <3B169F50.1D54875A@hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: $T;e9@2]!!4M%!!]-o!! Jishnu, Perhaps you sent this msg without seeing the intervening msgs from myself and Jeff about para 99 and 100. In any case, the thing that is missing in the doc, is that we do not currently have anything that says a TSS is required to set the stateful bit. [99] A TSS that supports stateful contexts may negotiate a request to establish a stateful context to a stateless context in order to preserve resources. It may do so only if it does not already have an established matching stateful context. [100] Conversely, a stateful TSS that has negotiated a request to stateless may respond statefully to a subsequent context with the same (non-zero) client_context_id. We have a description of what the bit means (in para 140) which focuses on what a TRUE value means. Perhaps you are saying that we need a description of what a FALSE value means. My sense is that the FALSE semantics are clear enough. [140] A value of TRUE in the stateful field of the CompoundSecMechList structure indicates that the target supports the establishment of stateful or reusable SAS contexts. This field is provided to assist clients in their selection of a target that supports stateful contexts. It is also provided to sustain implementations that serialize stateful context establishment on the client side as a means to conserve precious server-side authentication capacity.10 10.This serialization is only done when an attempt is being made to establish a stateful context. The last part of 140 says that if the stateful bit is true, some CSS implementations will not send multiple concurrent requests to establish the same stateful context. This design changes the multithreaded nature of the client app (for the round-trip time of one request) in exchange for not wasting the resources of the TSS. What it really says is that the serialization is acceptable if it only occurs when the bit is true, as one way or another, multiple requests should be serialized until the stateful context is established. In one design the serialization happens at the CSS, and in the other (if it occurs, it is done) at the TSS. This hint, was strongly argued for, because without it CSS side serialization would be at a disadvantage because it would happen in too many cases where it could come to no benefit. I hope the supporting semantic descriptions in paras 99 and 100, and my clarification of para 140 help.things. My sense is that we only need to say one of the following: A. "A TSS shall set the stateful bit in its IORs to indicate whether or not it accepts reusable security contexts at the corresponding target objects." B. "A TSS shall set the stateful bit to FALSE in its IORs if it will not accept reusable security contexts at the corresponding target objects." As I said, I feel we need to add a requirement that this bit must be set. I think, by defining the circumstances under which a false value must be set we, by difference, are also defining the circumstances under which a true value must be set (as long as we completely define the circumstances under which false must be set). If we have, then either A|B is OK with me. It was only on the last point that I hesitated to accept B. Ron Jishnu Mukerji wrote: > > Polar Humenn wrote: > > > > OKay, if you want a positive statement: how about this: > > > > "A TSS shall set the stateful bit to FALSE in its IORs if it will not > > accept reusable security contexts at the corresponding target objects." > > > > And Jeff says (with my slight addition): > > "Note: A TSS which indicates that it accepts reusable > > security contexts > > by setting the stateful bit to TRUE, > > > may not do so under all > > circumstances. Clients need to be prepared to deal > > with stateful requests being rejected even under these circumstances." > > Seems to me that something like those two together does the trick. > > Jishnu. Date: Thu, 31 May 2001 19:34:59 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: dflinn@iona.com, csiv2-ftf@omg.org Subject: Issue: 4327 (revised resolution) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: f;4!!@cIe9 X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Ron Monzillo CC: dflinn@iona.com, csiv2-ftf@omg.org Subject: Re: Issue: 4327 (revised resolution) Plus missing attachment References: <3B16D523.3E649D7C@east.sun.com> Content-Type: multipart/mixed; boundary="------------98DB6FDBB0415C1083D55256" X-UIDL: 1?W!!_/Me9:dE!!\@Oe9 Ron Monzillo wrote: > > Don, > > I've attached a corrected proposed resolution to 4327. > I hope this is acceptable to those who have commented. > > Normally I would wait to hear back again, but I realize > that you would like to wrap up. Maybe, you will get some > more feedback after I send this. > > Ron Issue 4327: clarification of csiv2 stateful conformance requirements (csiv2-ftf) Click here for this issue's archive. Source: Sun Microsystems (Mr. Ron Monzillo, ronald.monzillo@east.sun.com) Nature: Uncategorized Issue Severity: Summary: The specification is currently weak on its description of what must be done by a TSS with respect to designating a "stateful" value in its IOR's, and in defining under what circumstances a TSS may claim stateful conformance. In particular, the spec does not currently state whether or not a TSS must be stateful for all of its mechanism definitions, at all of its target objects in order to claim stateful conformance. The following paragraphs should be included to clarify these two issues. Discussion: Resolution: close with revised text Revised Text: base document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf [1] Add the following new para after para 140, A TSS shall set the stateful bit to FALSE in the CompoundSecMechList structure of IORs corresponding to target objects at which it will not accept reusable security contexts. [2] Add the following new para after para 188 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. Actions taken: May 30, 2001: received issue June XX, 2001: closed issue X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Fri, 1 Jun 2001 09:56:52 -0400 (EDT) From: Polar Humenn To: Ron Monzillo cc: , Subject: Re: Issue: 4327 (revised resolution) Plus missing attachment In-Reply-To: <3B16D889.67426D37@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: %lMd9\8)e9p<#e9^o&e9 [1] of this resolution is okay as it states something that a TSS shall do. I do not like [2] of this issue which states: [2] Add the following new para after para 188 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. Paragraph 188 states: For an implementation to claim stateful conformance, it shall implement the stateless and stateful functionality as defined in Section 16.3.2, Session Semantics, on page 16-24 and in Section 16.2.2, SAS context_data Message Body Types, on page 16-9. What more needs to be said than that? Why the convoluted paragraph to be placed after it? If this resolution is trying to "change" the conformance requirements, then that is a no-no, as the FTF is not allowed to change conformance requirements. Cheers, -Polar On Thu, 31 May 2001, Ron Monzillo wrote: > > > Ron Monzillo wrote: > > > > Don, > > > > I've attached a corrected proposed resolution to 4327. > > I hope this is acceptable to those who have commented. > > > > Normally I would wait to hear back again, but I realize > > that you would like to wrap up. Maybe, you will get some > > more feedback after I send this. > > > > Ron ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Fri, 01 Jun 2001 12:23:17 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn CC: dflinn@iona.com, csiv2-ftf@omg.org Subject: Re: Issue: 4327 (revised resolution) Plus missing attachment References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 67\d995(!!Rl8e9Q_%"! Polar Humenn wrote: > > [1] of this resolution is okay as it states something that a TSS shall do. > > I do not like [2] of this issue which states: I'll remove 2. Don, I'll send you an update. Date: Fri, 01 Jun 2001 12:39:18 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: dflinn@iona.comn, csiv2-ftf@omg.org Subject: Issue 4327: revised resolution (itme 2 removed) Content-Type: multipart/mixed; boundary="------------A832F7F26602DF1EC41FD6A0" X-UIDL: C(Ud9;5U!!K=:e9I0 Issue 4327: clarification of csiv2 stateful conformance requirements (csiv2-ftf) Click here for this issue's archive. Source: Sun Microsystems (Mr. Ron Monzillo, ronald.monzillo@east.sun.com) Nature: Uncategorized Issue Severity: Summary: The specification is currently weak on its description of what must be done by a TSS with respect to designating a "stateful" value in its IOR's, and in defining under what circumstances a TSS may claim stateful conformance. In particular, the spec does not currently state whether or not a TSS must be stateful for all of its mechanism definitions, at all of its target objects in order to claim stateful conformance. The following paragraphs should be included to clarify these two issues. Discussion: the thing that is missing in the doc, is that we do not currently have anything that says a TSS is required to set the stateful bit. [99] A TSS that supports stateful contexts may negotiate a request to establish a stateful context to a stateless context in order to preserve resources. It may do so only if it does not already have an established matching stateful context. [100] Conversely, a stateful TSS that has negotiated a request to stateless may respond statefully to a subsequent context with the same (non-zero) client_context_id. We have a description of what the bit means (in para 140) which focuses on what a TRUE value means. Perhaps you are saying that we need a description of what a FALSE value means. My sense is that the FALSE semantics are clear enough. [140] A value of TRUE in the stateful field of the CompoundSecMechList structure indicates that the target supports the establishment of stateful or reusable SAS contexts. This field is provided to assist clients in their selection of a target that supports stateful contexts. It is also provided to sustain implementations that serialize stateful context establishment on the client side as a means to conserve precious server-side authentication capacity.10 10.This serialization is only done when an attempt is being made to establish a stateful context. The last part of 140 says that if the stateful bit is true, some CSS implementations will not send multiple concurrent requests to establish the same stateful context. This design changes the multithreaded nature of the client app (for the round-trip time of one request) in exchange for not wasting the resources of the TSS. What it really says is that the serialization is acceptable if it only occurs when the bit is true, as one way or another, multiple requests should be serialized until the stateful context is established. In one design the serialization happens at the CSS, and in the other (if it occurs, it is done) at the TSS. This hint, was strongly argued for, because without it CSS side serialization would be at a disadvantage because it would happen in too many cases where it could come to no benefit. We have decided to let the (stateful) conformance statements stand as they are written. Resolution: close with revised text Revised Text: base document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf [1] Add the following new para after para 140, A TSS shall set the stateful bit to FALSE in the CompoundSecMechList structure of IORs corresponding to target objects at which it will not accept reusable security contexts. Actions taken: May 30, 2001: received issue June XX, 2001: closed issue From: "Don Flinn" To: "Ron Monzillo" , "Polar Humenn" Cc: Subject: RE: Issue: 4327 (revised resolution) Plus missing attachment Date: Fri, 1 Jun 2001 12:44:02 -0400 Message-ID: <000601c0eaba$10547140$7685413f@boston.amer.iona.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 In-Reply-To: <3B17C175.209F0A60@east.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: g,9!!O^bd9]SZ!!W2?e9 Thanks Ron Did you notice my statement in the mail on vote 6. Your state diagrams did not come through in your mail on issue 4326. Could you resend these also. Don > -----Original Message----- > From: Ron Monzillo [mailto:Ronald.Monzillo@Sun.COM] > Sent: Friday, June 01, 2001 12:23 PM > To: Polar Humenn > Cc: dflinn@iona.com; csiv2-ftf@omg.org > Subject: Re: Issue: 4327 (revised resolution) Plus missing attachment > > > > > Polar Humenn wrote: > > > > [1] of this resolution is okay as it states something that a > TSS shall do. > > > > > I do not like [2] of this issue which states: > > I'll remove 2. > Don, I'll send you an update. >