Issue 4281: No Tokens in EstablishContext Message (csiv2-ftf) Source: Oracle (Mr. Ron Monzillo, ronald.monzillo(at)east.sun.com) Nature: Uncategorized Issue Severity: Summary: The spec doesn't say whether or not an EstablishContext with none of cleint authentication, identity, or authorization token is legitimate. I don't think we need the ability to send such mecahnisms (for unprotected requests), as we would just send the request without a CSIv2 service context element. The only down side I can see, to writing this empt EstbalishContext out of spec, would be that a client could not use it to get feedback from a TSS in the form of CompleteEstablishContext, indicating that the TSS supports CSIv2. We must indicate that this is either an invalid msg, or state that it must be supported (and what it's semantics should be). Resolution: close issue with no change Revised Text: Actions taken: April 24, 2001: received issue October 3, 2001: closed issue Discussion: Table 16-4 includes entries which correspond to empty EstablishContext messages, so I now believe that we have adequately defined the semantics of such messages. In retrospect, what is missing from the spec, is the protocol behavior when CSIv2 is used without SAS. I have created a new issue (with proposed resolution) to address that issue. End of Annotations:===== Date: Tue, 24 Apr 2001 19:17:03 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: issues@omg.org, csiv2-ftf@omg.org Subject: No Tokens in EstablishContext Message Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ,QOe9$*Ae93p~!!0/-e9 base document: ftp://ftp.omg.org/pub/docs/ptc/01-03-02.pdf The spec doesn't say whether or not an EstablishContext with none of cleint authentication, identity, or authorization token is legitimate. I don't think we need the ability to send such mecahnisms (for unprotected requests), as we would just send the request without a CSIv2 service context element. The only down side I can see, to writing this empt EstbalishContext out of spec, would be that a client could not use it to get feedback from a TSS in the form of CompleteEstablishContext, indicating that the TSS supports CSIv2. We must indicate that this is either an invalid msg, or state that it must be supported (and what it's semantics should be). 4. It should be possible to close 4281 with modifications based on > something like the following: > > [1] Insert the following para after para 18. > > An EstablishContext message shall contain at least > an identity token, a client authentication token, or an > authorization token. A TSS shall reject an EstablishContext > message that does not satisfy this rule by returning an > exception containing a ContextError service context element > with major and minor status codes indicating that the > evidence was invalid. Date: Tue, 22 May 2001 17:45:33 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Ron Monzillo CC: issues@omg.org, csiv2-ftf@omg.org Subject: Re: No Tokens in EstablishContext Message References: <3AE6096F.F9060565@east.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: fV~!!_X8e9cPJ!!9 > base document: ftp://ftp.omg.org/pub/docs/ptc/01-03-02.pdf > > The spec doesn't say whether or not an EstablishContext with none > of cleint authentication, identity, or authorization token is > legitimate. > > I don't think we need the ability to send such mecahnisms (for > unprotected requests), as we would just send the request without a CSIv2 > service context element. The only down side I can see, to writing this > empt EstbalishContext out of spec, would be that a client could not use > it to get feedback from a TSS in the form of CompleteEstablishContext, > indicating that the TSS supports CSIv2. > > We must indicate that this is either an invalid msg, or state that it > must be supported (and what it's semantics should be). Reply-To: "David Chizmadia" From: "David Chizmadia" To: References: <3AE6096F.F9060565@east.sun.com> <3B0ADDFD.F1B86DD6@east.sun.com> Subject: Re: No Tokens in EstablishContext Message Date: Tue, 22 May 2001 19:29:04 -0400 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: OhS!!+Y7e9@$ad9L!8!! Status: RO Ron, While the intent of your wording is clear, the former (TCSEC) criteria lawyer in me would prefer a more precisely worded formulation. I'd propose: An EstablishContext message shall not be empty. That is, it shall contain at least one of an identity, a client authentication, or an authorization token or any combination of the three. A TSS shall reject an EstablishContext message that does not satisfy this rule by returning an exception containing a ContextError service context element with major and minor status codes indicating that the evidence was invalid. -DMC ----- Original Message ----- From: "Ron Monzillo" To: "Ron Monzillo" Cc: ; Sent: Tuesday, May 22, 2001 5:45 PM Subject: Re: No Tokens in EstablishContext Message > Proposed resolution: > > [1] Insert the following para after para 18. > > An EstablishContext message shall contain at least > an identity token, a client authentication token, or an > authorization token. A TSS shall reject an EstablishContext > message that does not satisfy this rule by returning an > exception containing a ContextError service context element > with major and minor status codes indicating that the > evidence was invalid. > > Ron Monzillo wrote: > > > > base document: ftp://ftp.omg.org/pub/docs/ptc/01-03-02.pdf > > > > The spec doesn't say whether or not an EstablishContext with none > > of cleint authentication, identity, or authorization token is > > legitimate. > > > > I don't think we need the ability to send such mecahnisms (for > > unprotected requests), as we would just send the request without a >CSIv2 > > service context element. The only down side I can see, to writing >this > > empt EstbalishContext out of spec, would be that a client could >not use > > it to get feedback from a TSS in the form of >CompleteEstablishContext, > > indicating that the TSS supports CSIv2. > > > > We must indicate that this is either an invalid msg, or state that >it > > must be supported (and what it's semantics should be). > X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 23 May 2001 10:08:16 -0400 (EDT) From: Polar Humenn To: Ron Monzillo cc: , Subject: Re: No Tokens in EstablishContext Message In-Reply-To: <3B0ADDFD.F1B86DD6@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: f_]!!iX\d9CL^d9d4 Proposed resolution: > > [1] Insert the following para after para 18. > > An EstablishContext message shall contain at least > an identity token, a client authentication token, or an > authorization token. A TSS shall reject an EstablishContext > message that does not satisfy this rule by returning an > exception containing a ContextError service context element > with major and minor status codes indicating that the > evidence was invalid. > > Ron Monzillo wrote: > > > > base document: ftp://ftp.omg.org/pub/docs/ptc/01-03-02.pdf > > > > The spec doesn't say whether or not an EstablishContext with none > > of cleint authentication, identity, or authorization token is > > legitimate. > > > > I don't think we need the ability to send such mecahnisms (for > > unprotected requests), as we would just send the request without a >CSIv2 > > service context element. The only down side I can see, to writing >this > > empt EstbalishContext out of spec, would be that a client could >not use > > it to get feedback from a TSS in the form of >CompleteEstablishContext, > > indicating that the TSS supports CSIv2. > > > > We must indicate that this is either an invalid msg, or state that >it > > must be supported (and what it's semantics should be). > ------------------------------------------------------------------- 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 Reply-To: "David Chizmadia" From: "David Chizmadia" To: References: Subject: Re: No Tokens in EstablishContext Message Date: Wed, 23 May 2001 10:33:15 -0400 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: -H)e9ac@e9bg$e9p`I!! Polar, I'm not particularly religious about whether an empty EstablishContext message is allowed or not, but when I first read through the spec, the absence of a specific meaning for the empty EstablishContext message struck me as a serious oversight. Fortunately, someone else raised the issue. My concern is that not saying anything leaves the decision up to individual vendors and therefore could lead to clients that are surprised by the actions of targets. From your comments, you would appear to prefer a resolution that allows for an empty EstablishContext message. How would you word the specification of its semantics? -DMC ----- Original Message ----- From: "Polar Humenn" To: "Ron Monzillo" Cc: ; Sent: Wednesday, May 23, 2001 10:08 AM Subject: Re: No Tokens in EstablishContext Message > > If you have a CSIv2 ORB that doesn't implement CSIv1 (which I >suspect that > there is still only one orb out there that does :), then in order to > accept the client you have to get an EstablishContext message. > > So, with Sun's solution, this means if you use a fully authenticated > transport and you don't have one of these client authenticators, or >any > authorization information, it seems like you must to send an >idenitity > regardless, which I suppose should be the one that the client is >using in > the authenticated transport. > > This does not mesch well with the assocation options of >target_supports, > since there is no requirement for identity association. > > This puts an requirement on the TSS to always support >IdentityAssertion, > even if all it wants to do is get a ClientAuthenticator in the >situation > where the client doesn't have an SSL private key and certificate to > authenticate with. > > That would change the protocol significantly. > > I don't see what the problem is. > > If you have A as the transport identity, B as the client >authenticator, > and C as the identity asserstion you end up with the principal >statement > of: > > A says B says C says request > > Now if B isn't there, then you have > > A says C says request, > > and then if C isn't there (i.e. ITTAbset) then you have: > > A says request. > > So what is the problem? > > Cheers, > -Polar > > On Tue, 22 May 2001, Ron Monzillo wrote: > > > Proposed resolution: > > > > [1] Insert the following para after para 18. > > > > An EstablishContext message shall contain at least > > an identity token, a client authentication token, or an > > authorization token. A TSS shall reject an EstablishContext > > message that does not satisfy this rule by returning an > > exception containing a ContextError service context element > > with major and minor status codes indicating that the > > evidence was invalid. > > > > Ron Monzillo wrote: > > > > > > base document: ftp://ftp.omg.org/pub/docs/ptc/01-03-02.pdf > > > > > > The spec doesn't say whether or not an EstablishContext with >none > > > of cleint authentication, identity, or authorization token is > > > legitimate. > > > > > > I don't think we need the ability to send such mecahnisms (for > > > unprotected requests), as we would just send the request without >a CSIv2 > > > service context element. The only down side I can see, to >writing this > > > empt EstbalishContext out of spec, would be that a client could >not use > > > it to get feedback from a TSS in the form of >CompleteEstablishContext, > > > indicating that the TSS supports CSIv2. > > > > > > We must indicate that this is either an invalid msg, or state >that it > > > must be supported (and what it's semantics should be). > > > > ------------------------------------------------------------------- > 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: Wed, 23 May 2001 10:50:35 -0400 (EDT) From: Polar Humenn To: David Chizmadia cc: Subject: Re: No Tokens in EstablishContext Message In-Reply-To: <002901c0e395$4da40140$a000a8c0@chizmadia> Message-ID: > MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: = Polar, > > I'm not particularly religious about whether an empty >EstablishContext > message is allowed or not, but when I first read through the spec, >the > absence of a specific meaning for the empty EstablishContext message >struck > me as a serious oversight. Fortunately, someone else raised the >issue. My > concern is that not saying anything leaves the decision up to >individual > vendors and therefore could lead to clients that are surprised by >the > actions of targets. > > From your comments, you would appear to prefer a resolution that >allows > for an empty EstablishContext message. How would you word the >specification > of its semantics? Apparently, there is no need to reject an EstablishContext message that does not have an authorization token, client authenticaiton token, or an ITTAbsent Identity token at the protocol level. >From the specification there is no implication that an EstablishContext message of such nature should be rejected by the protocol. It should be left that way. I don't think there is really a need to call this out. However, if you want to, that's fine. Clarification: An EstablishContext message may contain an empty ClientAuthentication token, an empty Authorization token, and have an IdentityToken of ITTAbsent. Cheers, -Polar > > -DMC > > ----- Original Message ----- > From: "Polar Humenn" > To: "Ron Monzillo" > Cc: ; > Sent: Wednesday, May 23, 2001 10:08 AM > Subject: Re: No Tokens in EstablishContext Message > > > > > > If you have a CSIv2 ORB that doesn't implement CSIv1 (which I suspect that > > there is still only one orb out there that does :), then in order to > > accept the client you have to get an EstablishContext message. > > > > So, with Sun's solution, this means if you use a fully authenticated > > transport and you don't have one of these client authenticators, or any > > authorization information, it seems like you must to send an idenitity > > regardless, which I suppose should be the one that the client is using in > > the authenticated transport. > > > > This does not mesch well with the assocation options of target_supports, > > since there is no requirement for identity association. > > > > This puts an requirement on the TSS to always support IdentityAssertion, > > even if all it wants to do is get a ClientAuthenticator in the situation > > where the client doesn't have an SSL private key and certificate to > > authenticate with. > > > > That would change the protocol significantly. > > > > I don't see what the problem is. > > > > If you have A as the transport identity, B as the client authenticator, > > and C as the identity asserstion you end up with the principal statement > > of: > > > > A says B says C says request > > > > Now if B isn't there, then you have > > > > A says C says request, > > > > and then if C isn't there (i.e. ITTAbset) then you have: > > > > A says request. > > > > So what is the problem? > > > > Cheers, > > -Polar > > > > On Tue, 22 May 2001, Ron Monzillo wrote: > > > > > Proposed resolution: > > > > > > [1] Insert the following para after para 18. > > > > > > An EstablishContext message shall contain at least > > > an identity token, a client authentication token, or an > > > authorization token. A TSS shall reject an EstablishContext > > > message that does not satisfy this rule by returning an > > > exception containing a ContextError service context element > > > with major and minor status codes indicating that the > > > evidence was invalid. > > > > > > Ron Monzillo wrote: > > > > > > > > base document: ftp://ftp.omg.org/pub/docs/ptc/01-03-02.pdf > > > > > > > > The spec doesn't say whether or not an EstablishContext with none > > > > of cleint authentication, identity, or authorization token is > > > > legitimate. > > > > > > > > I don't think we need the ability to send such mecahnisms (for > > > > unprotected requests), as we would just send the request without a > CSIv2 > > > > service context element. The only down side I can see, to writing this > > > > empt EstbalishContext out of spec, would be that a client could not > use > > > > it to get feedback from a TSS in the form of CompleteEstablishContext, > > > > indicating that the TSS supports CSIv2. > > > > > > > > We must indicate that this is either an invalid msg, or state that it > > > > must be supported (and what it's semantics should be). > > > > > > > ------------------------------------------------------------------- > > 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, 23 May 2001 10:55:58 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: David Chizmadia CC: csiv2-ftf@omg.org Subject: Re: No Tokens in EstablishContext Message References: <3AE6096F.F9060565@east.sun.com> <3B0ADDFD.F1B86DD6@east.sun.com> <00c801c0e316$ffa59040$a000a8c0@chizmadia> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: H!6!!a=md94!'!!WDJe9 David, I think I screwed this up in a couple of ways. In any case, I think there is more that needs to be considered to get this correct. The first issue is really whether "empty" EstablishContexts should be written out of the spec in the message definition section or in the context validation section. In other words whether an empty EC is "invalid evidence" or "invalid mechanism". invalid evidence - tokens match mechanism definition of target object but could not be validated invalid mechanism - the mechanism configuration of the target object has not changed, and request is not consistent with target mechanism configuration. In the section which defines the TAG_CSI_SEC_MECH_LIST tagged component, it says the following about a target's mechanism definitions "At least one of the transport_mech, as_context_mech, or sas_context_mech fields shall be configured." This almost, although not quite, means that there are no valid mechanism definitions to which a client can send an empty EC, and get a success outcome (as their are mechanism definitions which support, but do not require, the various SAS tokens). Moreover, an Identity Token can never be required. Based on this, I decided invalid evidence to be more appropriate than invalid evidence. That said, I was not trying to write that all, other than empty, combinations are "supported", as what is supported depends on the target to which the EC is sent. I was trying to more explictly write "empty" EC's out, and to make it clear what the TSS should do if it gets one. I think it would have been better to have proposed [1] Insert the following para after para 18. > An EstablishContext message shall not be empty. That is, it shall contain at > least one of an identity, client authentication, or authorization token. [2] add the following new para, after para 76; that is, at the end of the context validation section. A TSS shall reject a SAS context layer request to establish a security context that does not contain at least one of an identity, client authentication, or authorization token. In this case, the TSS shall return an exception containing a ContextError service context element with major and minor status codes indicating that the evidence was invalid. I have not had as much time as I would have liked to get the words right, so perhaps you will see a way to improve on this. I hope you agree with understaing "any other combinations". Ron David Chizmadia wrote: > > Ron, > > While the intent of your wording is clear, the former (TCSEC) criteria > lawyer in me would prefer a more precisely worded formulation. I'd propose: > > An EstablishContext message shall not be empty. That is, it shall contain at > least one of an identity, a client authentication, or an authorization token > or any combination of the three. A TSS shall reject an EstablishContext > message that does not satisfy this rule by returning an exception > containing a ContextError service context element with major and minor > status codes indicating that the evidence was invalid. > > -DMC > > ----- Original Message ----- > From: "Ron Monzillo" > To: "Ron Monzillo" > Cc: ; > Sent: Tuesday, May 22, 2001 5:45 PM > Subject: Re: No Tokens in EstablishContext Message > > > Proposed resolution: > > > > [1] Insert the following para after para 18. > > > > An EstablishContext message shall contain at least > > an identity token, a client authentication token, or an > > authorization token. A TSS shall reject an EstablishContext > > message that does not satisfy this rule by returning an > > exception containing a ContextError service context element > > with major and minor status codes indicating that the > > evidence was invalid. > > > > Ron Monzillo wrote: > > > > > > base document: ftp://ftp.omg.org/pub/docs/ptc/01-03-02.pdf > > > > > > The spec doesn't say whether or not an EstablishContext with none > > > of cleint authentication, identity, or authorization token is > > > legitimate. > > > > > > I don't think we need the ability to send such mecahnisms (for > > > unprotected requests), as we would just send the request without a CSIv2 > > > service context element. The only down side I can see, to writing this > > > empt EstbalishContext out of spec, would be that a client could not use > > > it to get feedback from a TSS in the form of CompleteEstablishContext, > > > indicating that the TSS supports CSIv2. > > > > > > We must indicate that this is either an invalid msg, or state that it > > > must be supported (and what it's semantics should be). > > Reply-To: "David Chizmadia" From: "David Chizmadia" To: References: Subject: Re: No Tokens in EstablishContext Message Date: Wed, 23 May 2001 11:26:45 -0400 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: e6$e9F@*e9HX-e9),Z!! On Wed, 23 May 2001, Polar Humenn" wrote: > Apparently, there is no need to reject an EstablishContext message that > does not have an authorization token, client authenticaiton token, or an > ITTAbsent Identity token at the protocol level. > > From the specification there is no implication that an EstablishContext > message of such nature should be rejected by the protocol. It should be > left that way. > > I don't think there is really a need to call this out. However, if you > want to, that's fine. > > Clarification: An EstablishContext message may contain an empty > ClientAuthentication token, an empty Authorization token, and have an > IdentityToken of ITTAbsent. I agree that as written, the spec doesn't prohibit an empty EstablishContext message - and I actually don't mind if it is there, but I still contend that we should explain what such a message means, when it would be appropriate to use one, and a standard TSS response to one. Naively, it appears to be redundant - why send the message at all if you don't have anything in it? As the security architect of an Intrusion Detection product, I'm learning not to like empty messages with no explicit meaning because they leave the door open for naive, stupid, or malicious implementors to do things that introduce unnecessary vulnerabilities and incompatabilities. > > Cheers, > -Polar -DMC X-Authentication-Warning: emerald.omg.org: hobbit.omg.org [192.67.184.3] didn't use HELO protocol Received: from unknown (128.230.111.5) by hobbit.omg.org asmtp(1.0) id 12736; Wed, 23 May 2001 10:21:10 -0400 (EDT) Received: from localhost (polar@localhost) by marcy.adiron.com (8.10.2/8.10.2) with ESMTP id f4NE9HD01414; Wed, 23 May 2001 14:09:17 GMT X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 23 May 2001 10:08:16 -0400 (EDT) From: Polar Humenn To: Ron Monzillo cc: , Subject: Re: No Tokens in EstablishContext Message In-Reply-To: <3B0ADDFD.F1B86DD6@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: I*Rd9Rf1!!"NLe9^@_!! If you have a CSIv2 ORB that doesn't implement CSIv1 (which I suspect that there is still only one orb out there that does :), then in order to accept the client you have to get an EstablishContext message. So, with Sun's solution, this means if you use a fully authenticated transport and you don't have one of these client authenticators, or any authorization information, it seems like you must to send an idenitity regardless, which I suppose should be the one that the client is using in the authenticated transport. This does not mesch well with the assocation options of target_supports, since there is no requirement for identity association. This puts an requirement on the TSS to always support IdentityAssertion, even if all it wants to do is get a ClientAuthenticator in the situation where the client doesn't have an SSL private key and certificate to authenticate with. That would change the protocol significantly. I don't see what the problem is. If you have A as the transport identity, B as the client authenticator, and C as the identity asserstion you end up with the principal statement of: A says B says C says request Now if B isn't there, then you have A says C says request, and then if C isn't there (i.e. ITTAbset) then you have: A says request. So what is the problem? Cheers, -Polar On Tue, 22 May 2001, Ron Monzillo wrote: > Proposed resolution: > > [1] Insert the following para after para 18. > > An EstablishContext message shall contain at least > an identity token, a client authentication token, or an > authorization token. A TSS shall reject an EstablishContext > message that does not satisfy this rule by returning an > exception containing a ContextError service context element > with major and minor status codes indicating that the > evidence was invalid. > > Ron Monzillo wrote: > > > > base document: ftp://ftp.omg.org/pub/docs/ptc/01-03-02.pdf > > > > The spec doesn't say whether or not an EstablishContext with none > > of cleint authentication, identity, or authorization token is > > legitimate. > > > > I don't think we need the ability to send such mecahnisms (for > > unprotected requests), as we would just send the request without a >CSIv2 > > service context element. The only down side I can see, to writing >this > > empt EstbalishContext out of spec, would be that a client could >not use > > it to get feedback from a TSS in the form of >CompleteEstablishContext, > > indicating that the TSS supports CSIv2. > > > > We must indicate that this is either an invalid msg, or state that >it > > must be supported (and what it's semantics should be). > ------------------------------------------------------------------- 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: Wed, 23 May 2001 12:09:12 -0400 (EDT) From: Polar Humenn To: Subject: Issue 4281: Re: No Tokens in EstablishContext Message In-Reply-To: <3B0BCF7E.B191E75F@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 1!~!!~-2!!b03!![aD!! Having an EstablishContext message without an authorization token, a client authentication token, and an IdentityToken of ITTAbsent IS consistent with the specification, and specifically rejecting it is NOT consistent with the protocol. Furthermore, an EstablishContext message is required by the CSIv2 protocol. Proof: In Section 16.6.3 the TSS State Machine In state "Wait for Request" there are three possibilities: 1. receive unprotected Request 2. receive Request + EstablishContext 3. receive Request + MessageInContext An unprotected request was merely there to provide for straight IIOP communication. SSL/TLS is considered "protected". In Section 16.6.4 The CSS State Machine In states "Try Mechanism", there are only two options: Event: the selected mechanism is unprotected Action: get_connection (mech, Out c) NextState: Unprotected Request Event: the selected mechanism is protected Action: get_client_creds (policy, mech, Out creds) Next State: Wait for Credentials In state "Wait for Credentials", there is only one relevant event. Event: client credentials ready Action: get_connection (policy, mech, creds, Out c) Next State: Wait for Connection In state "Wait for Connection" there is only one relevant event: Event: connection ready Action: get_context_element (c, policy, creds, mech, Out element) Next State: Wait for Context In state "Wait for Context" there are only three options: Event: get_context_element returned EstablishContext {N = 0, tokens} Action: send Request + EstablishContext {client_context_id = N = 0, tokens} Next State: Wait for SAS Reply Event: get_context_element returned EstablishContext {N != 0, tokens} Action: send Request + EstablishContext {client_context_id = N != 0, tokens} Next State: Wait for SAS Reply Event: get_context_element returned MessageInContext {N != 0, D} Action: send Request + MessageInContext {client_context_id = N != 0, D} Next State: Request In Context So, the only way for a CSIv2 CSS to proceed is to send an unprotected request, or wait for credentials, wait for a connection (using credentials), and then getting the context element (i.e, EstablishContext), and then wait for a context, and send it with the request. So, therefore you MUST send an EstablishContext message and furthermore, you MUST get it. If the EstablishContext message is empty, then it is consistent, and furthermore required by the protocol. I do not support rejecting the EstablishContext message. 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: Tue, 29 May 2001 18:37:57 -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: Re: No Tokens in EstablishContext Message Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Zi!e9kCdd9GC&!!^&7!! Status: RO Ron Monzillo wrote: > > base document: ftp://ftp.omg.org/pub/docs/ptc/01-03-02.pdf > > The spec doesn't say whether or not an EstablishContext with none > of cleint authentication, identity, or authorization token is > legitimate. > > I don't think we need the ability to send such mecahnisms (for > unprotected requests), as we would just send the request without > a CSIv2 service context element. The only down side I can see, > to writing this empt EstbalishContext out of spec, would be that > a client could not use it to get feedback from a TSS in the form > of CompleteEstablishContext, indicating that the TSS supports > CSIv2. > > We must indicate that this is either an invalid msg, or state > that it must be supported (and what it's semantics should be). Discussion: Table 16-4 includes entries which correspond to empty EstablishContext messages, so I now believe that we have adequately defined the semantics of such messages. In retrospect, what is missing from the spec, is the protocol behavior when CSIv2 is used without SAS. I have created a new issue (with proposed resolution) to address that issue. Proposed resolution: Close issue no action