Issue 4326: CSIv2 TSS state machine lacks states to enforce target policy for (csiv2-ftf) Source: Oracle (Mr. Ron Monzillo, ronald.monzillo(at)east.sun.com) Nature: Uncategorized Issue Severity: Summary: While in state "Waiting for Request", The TSS state machine will accept an unprotected request, without consideration of the target CSIv2 security policy. Also the specification does not describe what is supposed to happen when a target's mechanism definitions/policy requires SAS (i.e. client authentication) and the CSS does not send an EC. Resolution: Close issue with revised text. Revised Text: Base document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf [1] modify the TSS state table Change event "receive unprotected request" in state Waiting for Request to "receive request without SAS message" Change action when in state Waiting for Request, and event is "receive request without SAS message" to accept_transport_context() with no arguments. Change new state when in state Waiting for Request, and event is "receive request without SAS message" to Verify Transport Context. Create new state, "Verify Transport Context" and add it to the TSS table. In state "Verify Transport Context", if event is "accept_transport_context() returned success", action shall be "process request", and new state shall be "Send Only Reply". In state "Verify Transport Context", if event is "accept_transport_context() returned failure", action shall be "send exception (NO_PERMISSION)", and new state shall be "Waiting for Request". Increment state numbers of all states following Send Only Reply, to accomodate insertion of new state, Verify Transport Context". For the corrected TSS state machine see the attachment, fix-tss-protocol.PDF The TSS state diagram will be changed to agree with the state table. The corrected CSS state machine is also available at: Revised TSS State Machine [2] in para 108, add a description of accept_transport_context (after accept_context). o accept_transport_context() This action validates that a request that arrives without a SAS protocol message (i.e. EstablishContext or MessageInContext) satisfies the CSIv2 security requirements of the target object. This routine returns true if the transport layer security context (including none) over which the request was delivered satisfies the security requirements of the target object. Otherwise, accept_transport_context returns false. When accept_transport_context returns FALSE, the TSS shall reject the request and send a NO_PERMISSION seception. [3] Modify the CSS state table In state "Waiting for Context" and a new event "get_context_element returned NULL" with action "send request" and new State "Wait for Reply" For the corrected CSS state machine see the attachment, fix-css-protocol.PDF The CSS state diagram will be changed to agree with the state table. The corrected CSS state machine is also available at: Revised CSS State Machine [4] In para 113 extend the description of get_context_element to describe the circumstances under which this routine may return a NULL SAS protocol context elememt. get_context_element(c, policy, creds, mech, Out element) In the scope of connection c, use the client creds to obtain a SAS protocol context element that satisfies the client policy and the target policy in the mechanism. If the CSS supports reusable contexts, and the client policy is to establish a reusable context, the CSS allocates a client_context_id, and initializes a context element in the context table of the connection. A NULL context element may be returned by get_context_element when the target mechanism definition either does not support or require SAS layer security functionality, and the client establishes a policy not to use such functionality unless required to do so. [5] Modify table 16-4 to reintroduce the two rows that descibe CSIv2 invocations where all the security functionality is performed in the transport. Move column 1, to follow 3, and then introduce two new rows as follows: Row 13. Transport Client Principal = none Staddle SAS Client Authentication principal and SAS identity Token Identity and fill combined cell with "No SAS Message" Client Principal is trusted = Not Applicable Invocation Principal = Anonymous Scenario = Unathenticated Row 14. Transport client Principal = P2 Staddle SAS Client Authentication principal and SAS identity Token Identity and fill combined cell with "No SAS Message" Client Principal is trusted = Not Applicable Invocation Principal = P2 Scenario = client authentication For consistency make the same change to the columns in tables 16-3, and 16-5, without adding any new rows. The corrected principal interpretation tables are contained in the third attachment: request-principal-tables.PDF and at Revised Principal Interpretation Tables Actions Taken: Actions taken: May 30, 2001: received issue October 3, 2001: closed issue Discussion: End of Annotations:===== Date: Tue, 29 May 2001 17:56:24 -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: CSIv2 TSS state machine lacks states to enforce target policy for Content-Type: multipart/mixed; boundary="------------887CB8EE3AB2AFD48E052BD1" X-UIDL: *HIe9~_#!!fT(e9eYA!! Status: RO base document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf discussion: While in state "Waiting for Request", The TSS state machine will accept an unprotected request, without consideration of the target CSIv2 security policy. Also the specification does not describe what is supposed to happen when a target's mechanism definitions/policy requires SAS (i.e. client authentication) and the CSS does not send an EC. proposed resolution: [1] modify the TSS state table Change event "receive unprotected request" in state Waiting for Request to "receive request without SAS message" Change action when in state Waiting for Request, and event is "receive request without SAS message" to accept_transport_context() with no arguments. Change new state when in state Waiting for Request, and event is "receive request without SAS message" to Verify Transport Context. Create new state, "Verify Transport Context" and add it to the TSS table. In state "Verify Transport Context", if event is "accept_transport_context() returned failure", action shall be "process request", and new state shall be "Send Only Reply". In state "Verify Transport Context", if event is "accept_transport_context() returned success", action shall be "send exception (NO_PERMISSION)", and new state shall be "Waiting for Request". Increment state numbers of all states following Send Only Reply, to accomodate insertion of new state, Verify Transport Context". The corrected state machine is contained in the first attachment. The TSS state diagram will also be changed to agree with the state table. [2] in para 108, add a description of accept_transport_context (after accept_context). o accept_transport_context() This action validates that a request that arrives without a SAS protocol message (i.e. EstablishContext or MessageInContext) satisfies the CSIv2 security policy of the target object. This routine returns true if the transport layer security context (including none) over which the request was delivered satisfies the transport layer policy of the target object. Otherwise, accept_transport_context returns false. [3] Modify the CSS state table In state "Waiting for Context" and a new event "get_context_element returned NULL" with action "send request" and new State "Wait for Reply" The corrected state machine is contained in the second attachment. The CSS state diagram will also be changed to agree with the state table. [4] In para 113 extend the description of get_context_element to describe the circumstances under which this routine may return a NULL SAS protocol context elememt. get_context_element(c, policy, creds, mech, Out element) In the scope of connection c, use the client creds to obtain a SAS protocol context element that satisfies the client policy and the target policy in the mechanism. If the CSS supports reusable contexts, and the client policy is to establish a reusable context, the CSS allocates a client_context_id, and initializes a context element in the context table of the connection. A NULL context element may be returned by get_context_element when the target mechanism definition either does not support or require SAS layer security functionality, and the client establishes a policy not to use such functionality unless required to do so. [5] Modify table 16-4 to reintroduce the two rows that descibe CSIv2 invocations where all the security functionality is performed in the transport. Move column 1, to follow 3, and then introduce two new rows as follows: 13. Transport Client Principal = none Staddle SAS Client Authentication principal and SAS identity Token Identity and fill combined cell with "No SAS Message" Client Principal is trusted = Not Applicable Invocation Principal = Anonymous Scenario = Unathenticated 14. Transport client Principal = P2 Staddle SAS Client Authentication principal and SAS identity Token Identity and fill combined cell with "No SAS Message" Client Principal is trusted = Not Applicable Invocation Principal = P2 Scenario = client authentication For consistency make the same change to the columns in tables 16-3, and 16-5, without adding any new rows. The corrected principal interpretation tables are contained in the third attachment. [] fix-tss-protocol.PDF [] fix-css-protocol.PDF [] request-principal-tables.PDF X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 31 May 2001 11:05:15 -0400 (EDT) From: Polar Humenn To: Subject: On Issue 4326. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 6<#e9Wedd9$#-e91;hd9 Issue 4326 states: While in state "Waiting for Request", The TSS state machine will accept an unprotected request, without consideration of the target CSIv2 security policy. There is no specification for target CSIv2 security policy. Furthermore, the TSS state machine states that is only receives an unprotected request, and then goes to "process request". There is nothing that says the TSS has to "accept" it. "Process request" is vague at best (intentially), as there is no API to deliniate requirements on this end. Therefore, "process request" also means to process the request according to its policy, whatever that may be. Issue 4326 also states: Also the specification does not describe what is supposed to happen when a target's mechanism definitions/policy requires SAS (i.e. client authentication) and the CSS does not send an EC. Again, there is no specification for the target's security policy, other than the mechanism definitions in its IOR. If the client does not send an EC, and the IOR states that it needs one, the CSS is operating outside of the specification and the result is undefined. ------------------------------------------------------------------- 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 19:43:44 -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 4326: Proposed Resolution Content-Type: multipart/mixed; boundary="------------A785979E8E543556E5FBCBA3" X-UIDL: J)W!!ffbd9Y'7!!B5R!! Click here for this issue's archive. Source: Sun Microsystems (Mr. Ron Monzillo, ronald.monzillo@east.sun.com) Nature: Uncategorized Issue Severity: Summary: While in state "Waiting for Request", The TSS state machine will accept an unprotected request, without consideration of the target CSIv2 security policy. Also the specification does not describe what is supposed to happen when a target's mechanism definitions/policy requires SAS (i.e. client authentication) and the CSS does not send an EC. Resolution: close issue with revised text (and diagrams) Revised Text: [1] modify the TSS state table Change event "receive unprotected request" in state Waiting for Request to "receive request without SAS message" Change action when in state Waiting for Request, and event is "receive request without SAS message" to accept_transport_context() with no arguments. Change new state when in state Waiting for Request, and event is "receive request without SAS message" to Verify Transport Context. Create new state, "Verify Transport Context" and add it to the TSS table. In state "Verify Transport Context", if event is "accept_transport_context() returned failure", action shall be "process request", and new state shall be "Send Only Reply". In state "Verify Transport Context", if event is "accept_transport_context() returned success", action shall be "send exception (NO_PERMISSION)", and new state shall be "Waiting for Request". Increment state numbers of all states following Send Only Reply, to accomodate insertion of new state, Verify Transport Context". The corrected TSS state machine is shown below. The TSS state diagram will also be changed to agree with the state table. [2] in para 108, add a description of accept_transport_context (after accept_context). o accept_transport_context() This action validates that a request that arrives without a SAS protocol message (i.e. EstablishContext or MessageInContext) satisfies the CSIv2 security requirements of the target object. This routine returns true if the transport layer security context (including none) over which the request was delivered satisfies the security requirements of the target object. Otherwise, accept_transport_context returns false. When accept_transport_context returns FALSE, the TSS shall reject the request and send a NO_PERMISSION seception. [3] Modify the CSS state table In state "Waiting for Context" and a new event "get_context_element returned NULL" with action "send request" and new State "Wait for Reply" The corrected CSS state machine is shown below. The CSS state diagram will also be changed to agree with the state table. [4] In para 113 extend the description of get_context_element to describe the circumstances under which this routine may return a NULL SAS protocol context elememt. get_context_element(c, policy, creds, mech, Out element) In the scope of connection c, use the client creds to obtain a SAS protocol context element that satisfies the client policy and the target policy in the mechanism. If the CSS supports reusable contexts, and the client policy is to establish a reusable context, the CSS allocates a client_context_id, and initializes a context element in the context table of the connection. A NULL context element may be returned by get_context_element when the target mechanism definition either does not support or require SAS layer security functionality, and the client establishes a policy not to use such functionality unless required to do so. [5] Modify table 16-4 to reintroduce the two rows that descibe CSIv2 invocations where all the security functionality is performed in the transport. Move column 1, to follow 3, and then introduce two new rows as follows: 13. Transport Client Principal = none Staddle SAS Client Authentication principal and SAS identity Token Identity and fill combined cell with "No SAS Message" Client Principal is trusted = Not Applicable Invocation Principal = Anonymous Scenario = Unathenticated 14. Transport client Principal = P2 Staddle SAS Client Authentication principal and SAS identity Token Identity and fill combined cell with "No SAS Message" Client Principal is trusted = Not Applicable Invocation Principal = P2 Scenario = client authentication For consistency make the same change to the columns in tables 16-3, and 16-5, without adding any new rows. The corrected principal interpretation tables are contained in the third attachment. 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 10:11:13 -0400 (EDT) From: Polar Humenn To: Ron Monzillo cc: Subject: Re: Issue 4326: Proposed Resolution In-Reply-To: <3B16D730.439CF78A@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ,4R!!FNfd9l$Wd9bIld9 This proposed resolution adds brand new functionality to the TSS state machine, over, above, and beyond what the spec originally intended. Furthermore, its states that if this new function "accept transport context" (without arguments) returns success, the result is return a NO_PERMISSION, while stating as well returning false is required to send the same thing. The CSS state machine is also changed substantively. I suggest that if this kind of functionality change is required it go through the RFP process. 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 19:33: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: csiv2-ftf@omg.org Subject: Re: On Issue 4326. References: Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: b6id9o/#e9h[G!!I"+e9 Polar Humenn wrote: > > Issue 4326 states: > > While in state "Waiting for Request", The TSS state machine will accept > an unprotected request, without consideration of the target CSIv2 > security policy. > > There is no specification for target CSIv2 security policy. > CSIv2 wire-level target security policy is communicated to clients in IOR's. Target's are likely to need additional security policy to implement CSIv2. At least the policy they indicate they require and support in their IORs must be enforced. The state machine was written to erroneously enforce this policy only when an EC msg was received (in accept_context). [84] The entries in Table 16-4 describe the interpretation of client credentials by a TSS after an incoming call has satisecurity requirements and has been validated by the TSS. > Furthermore, the TSS state machine states that is only receives an > unprotected request, and then goes to "process request". There is > nothing > that says the TSS has to "accept" it. > "Process request" as an action also occurs when the TSS receives a request with tokens, which is one form of a "protected request". In this case, the tokens are evaluated to determine if they satisfy (at least) the mechanism definitions of the target (that is its CSIv2 security policy), and if so, the next action is "process request". See the description of accept_context in para 108. > "Process request" is vague at best (intentially), as there is no API to > deliniate requirements on this end. Therefore, "process request" also > means to process the request according to its policy, whatever that may > be. No, that is not what process request means in the state diagrams. It means what you do after the request has been validated by the TSS, which is what you would do if there were no TSS. > > Issue 4326 also states: > > Also the specification does not describe what is supposed to > happen when > a target's mechanism definitions/policy requires SAS (i.e. client > authentication) and the CSS does not send an EC. > You must satisfy at least the CSIv2 security requirements of the target before the request should be considered further. This level of functionality must be common of all implementations. Thus the need to formalize it in the TSS. > Again, there is no specification for the target's security policy, other > than the mechanism definitions in its IOR. > > If the client does not send an EC, and the IOR states that it needs one, > the CSS is operating outside of the specification and the result is > undefined. > Yes except, as currently written some implementations will allow the request to pass through, and that is not an acceptible outcome. One could argue that what a TSS does in this case (other than reject the request) need not be standardized. However, we need to insist that the request be rejected. I won't quibble on the standard rejection form, but in this case, I think it easier to specify one, than to leave TSS's to come with their own form of rejection. > ------------------------------------------------------------------- > 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 sfied the target X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Fri, 1 Jun 2001 09:24:10 -0400 (EDT) From: Polar Humenn To: Ron Monzillo cc: Subject: Re: On Issue 4326. In-Reply-To: <3B16D4BD.800E51A0@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Q;od9YAQ!!-0De9@!&e9 On Thu, 31 May 2001, Ron Monzillo wrote: > Polar wrote: > > Again, there is no specification for the target's security policy, other > > than the mechanism definitions in its IOR. > > > > If the client does not send an EC, and the IOR states that it needs one, > > the CSS is operating outside of the specification and the result is > > undefined. > > > > Yes except, as currently written some implementations will allow the > request to pass through, and that is not an acceptible outcome. Not "yes except", just "yes". There are no exceptions. If the IOR says it needs an EC the CSS must provide one or it is operating outside of the spec, and the result is undefined. If it accepts a request without an EC, then so what? What is the big deal? You cannot force it to be rejected from a client's perspective. However, you might want to force this on your EJB target implementations (in that specification), but not CORBA in general, and not in this protocol from a protocol perspective. > One could argue that what a TSS does in this case (other than reject > the request) need not be standardized. However, we need to insist > that > the request be rejected. I won't quibble on the standard rejection > form, but in this case, I think it easier to specify one, than to > leave TSS's to come with their own form of rejection. If the IOR demands an EC, the CSS must provide one, otherwise the result is undefined. 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: Fri, 01 Jun 2001 15:01:46 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: dflinn@iona.com CC: csiv2-ftf@omg.org, juergen@omg.org Subject: Issue: 4326 Revised resolution Content-Type: multipart/mixed; boundary="------------17C064CB69B52A429159BFCB" X-UIDL: /9m!!N1[!!e)ld96]F!! Don, Please add 4326 (and 4327) to the vote. For (4326) I've included revised state tables and principal evaluation tables as PDF attachments. fix-css-protocol.PDF CSS state table (table 16-7) fix-tss-protocol.PDF TSS state table (table 16-6) request-principal-tables.PDF tables 16-3, 16-4, and 16-5 I will ask Juergen to put the attachments on the OMG web site. The proposed resolution, contains links based on predicted locations. If you can, it would be good if you could also include the 3 PDF files as attachments when you send out the vote (in case I got the links wrong), and until Juergen pust the files on the server. Thanks, Ron [] fix-css-protocol.PDF [] fix-tss-protocol.PDF [] request-principal-tables1.PDF Click here for this issue's archive. Source: Sun Microsystems (Mr. Ron Monzillo, ronald.monzillo@east.sun.com) Nature: Uncategorized Issue Severity: Summary: While in state "Waiting for Request", The TSS state machine will accept an unprotected request, without consideration of the target CSIv2 security policy. Also the specification does not describe what is supposed to happen when a target's mechanism definitions/policy requires SAS (i.e. client authentication) and the CSS does not send an EC. Discussion: The proposed changes are important to completing the specification such that a request doesn't fly under the radar because it doesn't include an EstablishContext. To that end, the proposal requires that a TSS reject requests (prior to dispatching to the code that processes the business logic of the request) that do not satisfy the CSIv2 security mechanism requirements of the target object; independent of the present of an EstablishContext msg in the request. In its current formulation, the CSS State machine will not issue an SSL protected request without an EstablishContext msg. The change to the CSS SM corrects this error, as it is, and has always been and important CSiv2 scenario. Resolution: close issue with revised text (and diagrams) Revised Text: [1] modify the TSS state table Change event "receive unprotected request" in state Waiting for Request to "receive request without SAS message" Change action when in state Waiting for Request, and event is "receive request without SAS message" to accept_transport_context() with no arguments. Change new state when in state Waiting for Request, and event is "receive request without SAS message" to Verify Transport Context. Create new state, "Verify Transport Context" and add it to the TSS table. In state "Verify Transport Context", if event is "accept_transport_context() returned success", action shall be "process request", and new state shall be "Send Only Reply". In state "Verify Transport Context", if event is "accept_transport_context() returned failure", action shall be "send exception (NO_PERMISSION)", and new state shall be "Waiting for Request". Increment state numbers of all states following Send Only Reply, to accomodate insertion of new state, Verify Transport Context". For the corrected TSS state machine see the attachment, fix-tss-protocol.PDF The TSS state diagram will be changed to agree with the state table. The corrected CSS state machine is also available at: Revised TSS State Machine [2] in para 108, add a description of accept_transport_context (after accept_context). o accept_transport_context() This action validates that a request that arrives without a SAS protocol message (i.e. EstablishContext or MessageInContext) satisfies the CSIv2 security requirements of the target object. This routine returns true if the transport layer security context (including none) over which the request was delivered satisfies the security requirements of the target object. Otherwise, accept_transport_context returns false. When accept_transport_context returns FALSE, the TSS shall reject the request and send a NO_PERMISSION seception. [3] Modify the CSS state table In state "Waiting for Context" and a new event "get_context_element returned NULL" with action "send request" and new State "Wait for Reply" For the corrected CSS state machine see the attachment, fix-css-protocol.PDF The CSS state diagram will be changed to agree with the state table. The corrected CSS state machine is also available at: Revised CSS State Machine [4] In para 113 extend the description of get_context_element to describe the circumstances under which this routine may return a NULL SAS protocol context elememt. get_context_element(c, policy, creds, mech, Out element) In the scope of connection c, use the client creds to obtain a SAS protocol context element that satisfies the client policy and the target policy in the mechanism. If the CSS supports reusable contexts, and the client policy is to establish a reusable context, the CSS allocates a client_context_id, and initializes a context element in the context table of the connection. A NULL context element may be returned by get_context_element when the target mechanism definition either does not support or require SAS layer security functionality, and the client establishes a policy not to use such functionality unless required to do so. [5] Modify table 16-4 to reintroduce the two rows that descibe CSIv2 invocations where all the security functionality is performed in the transport. Move column 1, to follow 3, and then introduce two new rows as follows: Row 13. Transport Client Principal = none Staddle SAS Client Authentication principal and SAS identity Token Identity and fill combined cell with "No SAS Message" Client Principal is trusted = Not Applicable Invocation Principal = Anonymous Scenario = Unathenticated Row 14. Transport client Principal = P2 Staddle SAS Client Authentication principal and SAS identity Token Identity and fill combined cell with "No SAS Message" Client Principal is trusted = Not Applicable Invocation Principal = P2 Scenario = client authentication For consistency make the same change to the columns in tables 16-3, and 16-5, without adding any new rows. The corrected principal interpretation tables are contained in the third attachment: request-principal-tables.PDF and at Revised Principal Interpretation Tables Actions taken: May 30, 2001: received issue June XX, 2001: closed issue 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 X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Fri, 1 Jun 2001 15:36:39 -0400 (EDT) From: Polar Humenn To: Ron Monzillo cc: Subject: Re: Issue: 4326 Revised resolution In-Reply-To: <3B17E69A.F50D0E7A@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Wc!e9?,&!! X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn CC: Ron Monzillo , csiv2-ftf@omg.org Subject: Re: Issue: 4326 Revised resolution References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: @3^!!6!_d9[30e92j9e9 Polar Humenn wrote: > > Before we were talking CSIv2, which always required "SAS Functionality" > unless you were sending straight IIOP unprotected requests. > > Now we have a statement in the proposed revised resolution that states: > > get_context_element(c, policy, creds, mech, Out element) > > In the scope of connection c, use the client creds to obtain a SAS > protocol context element that satisfies the client policy and the target > policy in the mechanism. If the CSS supports reusable contexts, and the > client policy is to establish a reusable context, the CSS allocates a > client_context_id, and initializes a context element in the context > table of the connection. A NULL context element may be returned by > get_context_element when the target mechanism definition either does not > support or require SAS layer security functionality, and the client > establishes a policy not to use such functionality unless required to do > so. > > What does "when the target mechanism defnition either does not support or > require SAS layer security functionality" mean? > Earlier parts of the document define SAS as the stuff we do in service context. [138] The CompoundSecMech structure is used to describe support in the target for a compound security mechanism that may include security functionality that is realized in the transport and/or security functionality realized above the transport in service context. Where a compound security mechanism implements security functionality in the transport layer, the transport functionality shall be represented in a transport-specific component (for example, TAG_TLS_SEC_TRANS) contained in the transport_mech field of the CompoundSecMech structure. Where a compound security mechanism implements client authentication functionality in service context, the mechanism shall be represented in an AS_ContextSec structure contained in the as_context_mech field of the CompoundSecMech structure. Where a compound security mechanism supports identity assertion or supports authorization attributes delivered in service context, the mechanism shall be represented in a SAS_ContextSec structure contained in the sas_context_mech field of the CompoundSecMech structure. > On what coditions is it explicitly layed out when it is required and when > it is not? > The role of association options is stated in para 123, and the specific SAS layer aspects of a target's mechanism definitions are defined in the AS_ContextSec and SAS_ContextSec sections; especially in the tables in each of these sections (that talk about AssociationOption bits). Except for the provision of a delegation token, which is pretty blue sky right now, there are no requirements at the secure attribute sub-layer of SAS (that is, what is defined in the SAS_Context struct). If SAS layer security functionality is required, it is defined in the AS sublayer (that is, in the AS_ContextSec tructure). > On what conditions is it explicitly layed out when it is supported and > when it is not? That's all from me for now. > > 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