Issue 4308: The encoding of GSSUP ICT's is not clearly specified (csiv2-ftf) Source: Oracle (Mr. Ron Monzillo, ronald.monzillo(at)east.sun.com) Nature: Uncategorized Issue Severity: Summary: Document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf Isuse: The encoding of GSSUP ICT's is not clearly specified Para 48 states: [48] The format of a GSSUP initial context token shall be as defined in [IETF RFC 2743] Section 3.1, “Mechanism-Independent Token Format,” pp. 81-82. This GSSToken shall contain an ASN.1 tag followed by a token length, an authentication mechanism identifier, and a CDR encoded sequence of octets corresponding to a GSSUP inner context token as defined by the type GSSUP::InitialContextToken in Section 16.9.2, “Module GSSUP - Username/Password GSSAPI Token Formats,” on page 16-59 (and repeated below). and section 16.9.2 Module GSSUP - Username/Password GSSAPI Token Formats states // The following structure defines the inner contents of the username // password initial context token. This structure is CDR encoded in a // sequence of octets and appended at the end of the username/password // GSS (initial context) Token. struct InitialContextToken { CSI::UTF8String username; CSI::UTF8String password; CSI::GSS_NT_ExportedName target_name; }; Proposed Resolution: Change para 148 to the following: [48] The format of a GSSUP initial context token shall be as defined in [IETF RFC 2743] Section 3.1, “Mechanism-Independent Token Format,” pp. 81-82. This GSSToken shall contain an ASN.1 tag followed by a token length, an authentication mechanism identifier, and an encapsulation octet stream containing a CDR encoded GSSUP inner context token as defined by the type GSSUP::InitialContextToken in Section 16.9.2, “Module GSSUP - Username/Password GSSAPI Token Formats,” on page 16-59 (and repeated below). change the relevant comment in 16.9.2 Module GSSUP - Username/Password GSSAPI Token Formats to the following // The following structure defines the inner contents of the username // password initial context token. This structure is CDR encoded in an // encapsulation octet stream and appended at the end of the username/password // GSS (initial context) Token. Resolution: Close issue with revised text. Revised Text: [1] Change the description of an initial context token in para 48 to The format of a GSSUP initial context token shall be as defined in [IETF RFC 2743] Section 3.1, "Mechanism-Independent Token Format," pp. 81-82. This GSSToken shall contain an ASN.1 tag followed by a token length, an authentication mechanism identifier, and a CDR encapsulation containing a GSSUP inner context token as defined by the type GSSUP::InitialContextToken in Section 16.9.2, "Module GSSUP - Username/Password GSSAPI Token Formats," on page 16-59 (and repeated below). [2] Change the description of a GSSUP ICT in module 16.9.2 to // The following structure defines the inner contents of the username // password initial context token. This structure is CDR encapsulated // and appended at the end of the username/password GSS (initial // context) Token. [3] Add a new paragraph after para 49. The format of the name passed in the username field depends on the authentication domain. If the mechanism identifier of the target domain is GSSUP, then the format of the username shall be a Scoped-Username (with name_value) as defined in section 16.2.5, Scoped-Username GSS Name Form. Actions taken: May 15, 2001: received issue October 3, 2001: closed issue Discussion: End of Annotations:===== X-Authentication-Warning: emerald.omg.org: hobbit.omg.org [192.67.184.3] didn't use HELO protocol Received: from patan.sun.com (192.18.98.43) by hobbit.omg.org asmtp(1.0) id 2889; Tue, 15 May 2001 12:52:25 -0400 (EDT) Received: from jse.East.Sun.COM ([129.148.70.27]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26223; Tue, 15 May 2001 09:47:37 -0700 (PDT) Received: from east.sun.com (seakayak [129.148.71.109]) by jse.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA17685; Tue, 15 May 2001 12:47:32 -0400 (EDT) Message-ID: <3B015CFD.D7AB1E30@east.sun.com> Date: Tue, 15 May 2001 12:44:45 -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 GSSUP initial context token encoding Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: l,hd9maJe94WY!!Dd?e9 Document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf Isuse: The encoding of GSSUP ICT's is not clearly specified Para 48 states: [48] The format of a GSSUP initial context token shall be as defined in [IETF RFC 2743] Section 3.GSSToken shall contain an ASN.1 tag followed by a token length, an authentication mechanism identifier, and a CDR encoded sequence of octets corresponding to a GSSUP inner context token as defined by the type GSSUP::InitialContextToken in Section 16.9.1, 2 on page 16-59 (and repeated below). and section 16.9.2 Module GSSUP - Username/Password GSSAPI Token Formats states // The following structure defines the inner contents of the username // password initial context token. This structure is CDR encoded in a // sequence of octets and appended at the end of the username/password // GSS (initial context) Token. struct InitialContextToken { CSI::UTF8String username; CSI::UTF8String password; CSI::GSS_NT_ExportedName target_name; }; Proposed Resolution: Change para 148 to the following: [48] The format of a GSSUP initial context token shall be as defined in [IETF RFC 2743] Section 3.n shall contain an ASN.1 tag followed by a token length, an authentication mechanism identifier, and an encapsulation octet stream containing a CDR encoded GSSUP inner context token as defined by the type GSSUP::InitialContextToken in Section 16.9.1, 2 on page 16-59 (and repeated below). change the relevant comment in 16.9.2 Module GSSUP - Username/Password GSSAPI Token Formats to the following // The following structure defines the inner contents of the username // password initial context token. This structure is CDR encoded in an // encapsulation octet stream and appended at the end of the username/password // GSS (initial context) Token. , , 3. Is should be possible to close 4308 with the following modifications > > Change para 48 to the following: > > [48] The format of a GSSUP initial context token shall be as defined in > [IETF RFC 2743] Section 3.> pp. 81-82. This GSSToken shall contain an ASN.1 tag followed by a token > length, an authentication mechanism identifier, and an encapsulation > octet stream containing a CDR encoded GSSUP inner context token as > defined by the type GSSUP::InitialContextToken in Section 16.9.2, 1 > on page 16-59 > (and repeated below). > > change the relevant comment in > 16.9.2 Module GSSUP - Username/Password GSSAPI Token Formats > to the following: > > // The following structure defines the inner contents of the username > // password initial context token. This structure is CDR encoded in an > // encapsulation octet stream and appended at the end of the > username/password > // GSS (initial context) Token., Date: Tue, 29 May 2001 17:49:05 -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: ssue 4308: Proposed Resolution - The encoding of GSSUP ICT's is not clearly specified Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: 6E_!!L~dd9(Vid965A!! Status: RO base document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf proposed resolution: [1] Change the description of an initial context token in para 48 to The format of a GSSUP initial context token shall be as defined in [IETF RFC 2743] Section 3.This GSSToken shall contain an ASN.1 tag followed by a token length, an authentication mechanism identifier, and a CDR encapsulation containing a GSSUP inner context token as defined by the type GSSUP::InitialContextToken in Section 16.9.2, Username/Password GSSAPI Token 1,Formats on page 16-59 (and repeated below). [2] Change the description of a GSSUP ICT in module 16.9.2 to // The following structure defines the inner contents of the username // password initial context token. This structure is CDR encapsulated // and appended at the end of the username/password GSS (initial // context) Token. [3] Add a new paragraph after para 49. The format of the name passed in the username field depends on the authentication domain. If the mechanism identifier of the target domain is GSSUP, then the format of the username shall be a Scoped-Username (with name_value) as defined in section 16.2.5, Scoped-Username GSS Name Form. Date: Tue, 29 May 2001 17:49:05 -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: ssue 4308: Proposed Resolution - The encoding of GSSUP ICT's is not clearly specified Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: 6E_!!L~dd9(Vid965A!! Status: RO base document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf proposed resolution: [1] Change the description of an initial context token in para 48 to The format of a GSSUP initial context token shall be as defined in [IETF RFC 2743] Section 3.This GSSToken shall contain an ASN.1 tag followed by a token length, an authentication mechanism identifier, and a CDR encapsulation containing a GSSUP inner context token as defined by the type GSSUP::InitialContextToken in Section 16.9.2, Username/Password GSSAPI Token 1,Formats on page 16-59 (and repeated below). [2] Change the description of a GSSUP ICT in module 16.9.2 to // The following structure defines the inner contents of the username // password initial context token. This structure is CDR encapsulated // and appended at the end of the username/password GSS (initial // context) Token. [3] Add a new paragraph after para 49. The format of the name passed in the username field depends on the authentication domain. If the mechanism identifier of the target domain is GSSUP, then the format of the username shall be a Scoped-Username (with name_value) as defined in section 16.2.5, Scoped-Username GSS Name Form. , , Date: Mon, 26 Nov 2001 20:29:52 -0500 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: issues@omg.org, andrew@omg.org, peter.walker@sun.com, csiv2-ftf@omg.org Subject: CSIv2 issue: length of GSSUP inner context token encapsulation Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: L=)e9o^N!!OH Message-Id: <200111271242.EAA19540@wheel.dcn.davis.ca.us> Subject: Re: CSIv2 issue: length of GSSUP inner context token encapsulation To: Ronald.Monzillo@sun.com (Ron Monzillo) Date: Tue, 27 Nov 2001 04:42:49 -0800 (PST) Cc: andrew@omg.org, peter.walker@sun.com, csiv2-ftf@omg.org In-Reply-To: <3C02EC90.A41C2788@east.sun.com> from "Ron Monzillo" at Nov 26, 2001 08:29:52 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: 8QVd95`Qd9Ak"e9[Gl!! 'Ron Monzillo' writes: > > I have been advised to request that this be treated as an URGENT issue. What is the justification for classifying this as URGENT, rather than being treated as a regular issue? thanks, jeff > > Document: ftp://ftp.omg.org/pub/docs/ptc/01-06-17.pdf > > This is a follow-up to issue 4308 (raised in the FTF) > entitled - Issue: The encoding of GSSUP ICT's is not clearly > specified > > New Issue: length of GSSUP inner context token encapsulation > > Description: > > Issue 4308 caused the description of the encoding of a GSSUP ICT to > be > modified to clarify the definition of the encoding rules applied to > the > ICT. This was accomplished by changing from a "CDR encoded sequence > of > octets corresponding to a GSSUP inner..." to "a CDR encapsulation > containing > a GSSUP inner..." This change eliminated the encoding rule > ambiguity, > while > simultaneously creating an ambiguity as to whether or not there is a > length preceding the ICT encapsulation, and if so, what encoding > rules > pertain > to it. > > para 50 of the finalized spec now states: > > [50] The format of a GSSUP initial context token shall be as defined > in > [IETF RFC 2743] Section 3.> 81-82. This GSSToken shall contain an > ASN.1 tag followed by a token > length, an authentication mechanism > identifier, and a CDR encapsulation containing a GSSUP inner context > token as > defined by the type GSSUP::InitialContextToken in Section 16.9.2, > > Username/Password GSSAPI Token 1,Formats on page 16-65 (and > repeated > below). > > In our interoperability testing, we have encountered some confusion > as > to whether > or not the CDR encapsulation containing the GSSUP inner context > token > shall be > proceeded by a length specifier. The Corba documentation says that a > CDR > encapsulation of an octet stream must be preceded by a length. In > this > case the > encapsulation contains an IDL structure. > > Recommendation: > > Add a clarifying sentence to paragraph 50 indicating that the CDR > encapsulation of the ICT is NOT to be proceeded by an encapsulation > length. > > That is, change para 50 as follows: > > [50] The format of a GSSUP initial context token shall be as defined > in > [IETF RFC 2743] Section 3.> identifier, and a CDR encapsulation > containing a GSSUP inner context > token as > defined by the type GSSUP::InitialContextToken in Section 16.9.2, > > Username/Password GSSAPI Token 1,Formats on page 16-65 (and > repeated > below). The encapsulation of the inner context token shall follow > the > authentication mechanism identifier and there shall be no > representation > of the encapsulation length > between the mechanism identifier and the encapsulation. > > [2] Change the description of a GSSUP ICT in module 16.9.2 to > > // The following structure defines the inner contents of the > username > // password initial context token. This structure is CDR > encapsulated > // and appended at the end of the username/password GSS (initial > // context) Token. The encapsulation of the inner contents > // shall follow the authentication mechanism identifier and > // there shall be no representation of the encapsulation length > // between the mechanism identifier and the encapsulation. > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff.mischkinsky@oracle.com +1 650-506-1975 , , X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 27 Nov 2001 10:11:05 -0500 (EST) From: Polar Humenn To: Jeffrey Mischkinsky cc: Ron Monzillo , , , Subject: Re: CSIv2 issue: length of GSSUP inner context token encapsulation In-Reply-To: <200111271242.EAA19540@wheel.dcn.davis.ca.us> Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by emerald.omg.org id fARExNK07934 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN X-UIDL: CQM!!7`^!!5!ld9F-#!! On Tue, 27 Nov 2001, Jeffrey Mischkinsky wrote: > 'Ron Monzillo' writes: > > > > I have been advised to request that this be treated as an URGENT issue. > > What is the justification for classifying this as URGENT, rather than > being treated as a regular issue? Greetings, I don't see the need for this being a URGENT issue either. Furthermore, it is only calling for a clarification. The spec is correct, although I think it probably says too much. A GSS Initial Token as defined by RFC 2743, explicitly lays out the structure for the token. The spec defines the mechanism-defined object of the token as a CDR encapsulation of the IDL structure that is defined therein. People SHOULD NOT be confused. There is no length preceeding the CDR encoding of an IDL struct and there is no length defined in the initial context token of the GSS-API. >From RFC 2743, page 82: The token tag is immediately followed by a mechanism-defined token object. Note that no independent size specifier intervenes following the object identifier value to indicate the size of the mechanism- defined token object. ..... If anything at all, the spec says too much, repeating the format specifics of RFC 2743, (which may be the real source of the confusion, perhaps steering them away from reading RFC 2743). The spec should probably just say: --- The format of a GSSUP initial context token shall be as defined in [IETF RFC 2743] Section 3.1, "Mechanism-Independent Token Format," page 81-82. The mechanism-defined token object of this token shall contain the CDR encapsulation of the GSSUP::InitialContextToken structure, which is defined below. --- Cheers, -Polar > > identifier, and a CDR encapsulation containing a GSSUP inner context > > token as > > defined by the type GSSUP::InitialContextToken in Section 16.9.2, > > ^SModule GSSUP - > > Username/Password GSSAPI Token Formats,^T on page 16-65 (and repeated > > below). 1 Cheers, -Polar > > thanks, > jeff > > > > > Document: ftp://ftp.omg.org/pub/docs/ptc/01-06-17.pdf > > > > This is a follow-up to issue 4308 (raised in the FTF) > > entitled - Issue: The encoding of GSSUP ICT's is not clearly >specified > > > > New Issue: length of GSSUP inner context token encapsulation > > > > Description: > > > > Issue 4308 caused the description of the encoding of a GSSUP ICT >to be > > modified to clarify the definition of the encoding rules applied >to the > > ICT. This was accomplished by changing from a "CDR encoded >sequence of > > octets corresponding to a GSSUP inner..." to "a CDR encapsulation > > containing > > a GSSUP inner..." This change eliminated the encoding rule >ambiguity, > > while > > simultaneously creating an ambiguity as to whether or not there is >a > > length preceding the ICT encapsulation, and if so, what encoding >rules > > pertain > > to it. > > > > para 50 of the finalized spec now states: > > > > [50] The format of a GSSUP initial context token shall be as >defined in > > [IETF RFC 2743] Section 3. > > 81-82. This GSSToken shall contain an ASN.1 tag followed by a >token > > length, an authentication mechanism > > identifier, and a CDR encapsulation containing a GSSUP inner >context > > token as > > defined by the type GSSUP::InitialContextToken in Section 16.9.2, > > > > Username/Password GSSAPI Token 1,Formats on page 16-65 (and >repeated > > below). > > > > In our interoperability testing, we have encountered some >confusion as > > to whether > > or not the CDR encapsulation containing the GSSUP inner context >token > > shall be > > proceeded by a length specifier. The Corba documentation says that >a CDR > > encapsulation of an octet stream must be preceded by a length. In >this > > case the > > encapsulation contains an IDL structure. > > > > Recommendation: > > > > Add a clarifying sentence to paragraph 50 indicating that the CDR > > encapsulation of the ICT is NOT to be proceeded by an >encapsulation > > length. > > > > That is, change para 50 as follows: > > > > [50] The format of a GSSUP initial context token shall be as >defined in > > [IETF RFC 2743] Section 3.nd a CDR encapsulation containing a >GSSUP inner context > > token as > > defined by the type GSSUP::InitialContextToken in Section 16.9.2, > > > > Username/Password GSSAPI Token 1,Formats on page 16-65 (and >repeated > > below). The encapsulation of the inner context token shall follow >the > > authentication mechanism identifier and there shall be no >representation > > of the encapsulation length > > between the mechanism identifier and the encapsulation. > > > > [2] Change the description of a GSSUP ICT in module 16.9.2 to > > > > // The following structure defines the inner contents of the >username > > // password initial context token. This structure is CDR >encapsulated > > // and appended at the end of the username/password GSS (initial > > // context) Token. The encapsulation of the inner contents > > // shall follow the authentication mechanism identifier and > > // there shall be no representation of the encapsulation length > > // between the mechanism identifier and the encapsulation. > > > > > -- > Jeff Mischkinsky > jmischki@dcn.davis.ca.us +1 530-758-9850 > jeff.mischkinsky@oracle.com +1 650-506-1975 > ------------------------------------------------------------------- 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, 27 Nov 2001 12:33:12 -0500 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jishnu Mukerji CC: Ron Monzillo , interop@omg.org, andrew@omg.org, peter.walker@sun.com, csiv2-ftf@omg.org, Michi Henning Subject: Re: CSIv2 issue: length of GSSUP inner context token encapsulation References: <3C02EC90.A41C2788@east.sun.com> <3C03B20C.26F7359E@hp.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: PHfd9>N?e9/Z5!!&hh!! Jishnu Mukerji wrote: > > First of all, I don't see why this is an urgent issue. Personally I tend > to agree with Polar's analysis of the situation as presented in another > message not excerpted here. However, it is a call for Andrew to make > (hopefully in consultation with appropriate others). > > Second, since there is no active RTF in existence at present covering > CSIv2 (the last RTF expired on 11/19/01) we have two choices of venue > for discussing this issue: > > 1) The Architecture Board (the fallback for all urgent issues when RTFs > to handle them don't exist) Jishnu, Polar, and Jeff, An agreed upon interpretation of the encoding of the GSSUP ICT is necessary to sustain our EJB compatability tests. Some of our EJB container vendors are actively pursuing certification prior to the release of their products. In that context, we have been asked to clarify the encoding to ensure product compatibility with the CSIv2 standard as required by EJB 2.0. Sun raised the issue on behalf of our J2EE vendors. We believe the existing specification to be unambiguous; although we have evidence of alternative interpretation, and as such can see the value of a clarifying sentence. We would accept any treatment of this issue, that accomplishes the objectives stated above which are; that there be an agreed upon interpretation of the description of the encoding with respect to the inclusion of a length prior to the encapsulation, and that this agreement be reached as soon as possible. If the only legitimate interpretation of the relevant statements in the specification (as called out in the issue report) is that the encoding of the encapsulation of the inner token shall not be preceded by its length, then there is no urgency, and the decision as to whether or not there is value to a clarifying sentence can be handled at a later time. Ron PS: Just to be clear, regarding the excerpt from 2473: > From RFC 2743, page 82: > > The token tag is immediately followed by a mechanism-defined > token > object. Note that no independent size specifier intervenes > following > the object identifier value to indicate the size of the > mechanism- > defined token object. ..... This statement says there is no independent (that is common to all mechanisms) length of the mechanism-defined token object (the inner token) following the token tag (the ASN.1 encoded mechanism independent header of the Initial Context Token). What's in the inner token can be anything as defined by the mechanism and its encoding rules, and as such, there is no prohibition on an inner token beginning with a length. That is not to say that I am advocating a length, only that we not read more into 2743 than is there. > > 2) The Interop RTF, which is the targeted RTF for picking up this work. > I am CC-ing the interop mailing list for this reason. > > Jishnu. > > Ron Monzillo wrote: > > > > I have been advised to request that this be treated as an URGENT issue. > > > > Document: ftp://ftp.omg.org/pub/docs/ptc/01-06-17.pdf > > > > This is a follow-up to issue 4308 (raised in the FTF) > > entitled - Issue: The encoding of GSSUP ICT's is not clearly specified > > > > New Issue: length of GSSUP inner context token encapsulation > > > > Description: > > > > Issue 4308 caused the description of the encoding of a GSSUP ICT to be > > modified to clarify the definition of the encoding rules applied to the > > ICT. This was accomplished by changing from a "CDR encoded sequence of > > octets corresponding to a GSSUP inner..." to "a CDR encapsulation > > containing > > a GSSUP inner..." This change eliminated the encoding rule ambiguity, > > while > > simultaneously creating an ambiguity as to whether or not there is a > > length preceding the ICT encapsulation, and if so, what encoding rules > > pertain > > to it. > > > > para 50 of the finalized spec now states: > > > > [50] The format of a GSSUP initial context token shall be as defined in > > [IETF RFC 2743] Section 3.> > 81-82. This GSSToken shall contain an ASN.1 tag followed by a token > > length, an authentication mechanism > > identifier, and a CDR encapsulation containing a GSSUP inner context > > token as > > defined by the type GSSUP::InitialContextToken in Section 16.9.2, > > > > Username/Password GSSAPI Token 1,Formats on page 16-65 (and repeated > > below). > > > > In our interoperability testing, we have encountered some confusion as > > to whether > > or not the CDR encapsulation containing the GSSUP inner context token > > shall be > > proceeded by a length specifier. The Corba documentation says that a CDR > > encapsulation of an octet stream must be preceded by a length. In this > > case the > > encapsulation contains an IDL structure. > > > > Recommendation: > > > > Add a clarifying sentence to paragraph 50 indicating that the CDR > > encapsulation of the ICT is NOT to be proceeded by an encapsulation > > length. > > > > That is, change para 50 as follows: > > > > [50] The format of a GSSUP initial context token shall be as defined in > > [IETF RFC 2743] Section 3.> > 81-82. This GSSToken shall contain an ASN.1 tag followed by a token > > length, an authentication mechanism > > identifier, and a CDR encapsulation containing a GSSUP inner context > > token as > > defined by the type GSSUP::InitialContextToken in Section 16.9.2, > > > > Username/Password GSSAPI Token 1,Formats on page 16-65 (and repeated > > below). The encapsulation of the inner context token shall follow the > > authentication mechanism identifier and there shall be no representation > > of the encapsulation length > > between the mechanism identifier and the encapsulation. > > > > [2] Change the description of a GSSUP ICT in module 16.9.2 to > > > > // The following structure defines the inner contents of the username > > // password initial context token. This structure is CDR encapsulated > > // and appended at the end of the username/password GSS (initial > > // context) Token. The encapsulation of the inner contents > > // shall follow the authentication mechanism identifier and > > // there shall be no representation of the encapsulation length > > // between the mechanism identifier and the encapsulation. > > -- > Jishnu Mukerji > Senior Systems Architect, SSO Staff > Hewlett-Packard Company > 300 Campus Drive, MS 2E-62 > Florham Park NJ 07932, USA > tel:+1 973 443 7528 > mailto:jishnu_mukerji@hp.com , , X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 27 Nov 2001 15:47:35 -0500 (EST) From: Polar Humenn To: Ron Monzillo cc: Jishnu Mukerji , , , , , Michi Henning Subject: Re: CSIv2 issue: length of GSSUP inner context token encapsulation In-Reply-To: <3C03CE58.A738B276@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 9pPe9Z> [Snip all the J2EE developer "misinterpretation" issues] > PS: Just to be clear, regarding the excerpt from 2473: > > > From RFC 2743, page 82: > > > > The token tag is immediately followed by a mechanism-defined >token > > object. Note that no independent size specifier intervenes >following > > the object identifier value to indicate the size of the >mechanism- > > defined token object. ..... > > This statement says there is no independent (that is common to all > mechanisms) length of the mechanism-defined token object (the inner > token) following the token tag (the ASN.1 encoded mechanism > independent header of the Initial Context Token). That is correct. There is no idependent length as per GSS-API. That is exactly what it says, plain and simple. > What's in the inner token can be anything as defined by the mechanism > and its encoding rules, and as such, there is no prohibition on an > inner token beginning with a length. That is not to say that I am > advocating a length, only that we not read more into 2743 than is > there. There is no length parameter in front of a CDR encoding of a struct either. These guys aren't misinterpreting, they just aren't reading all the specifications. Cheers, -Polar X-Sender: andrew@192.67.184.65 (Unverified) Message-Id: In-Reply-To: <3C03B20C.26F7359E@hp.com> References: <3C02EC90.A41C2788@east.sun.com> Mime-Version: 1.0 Date: Tue, 4 Dec 2001 18:46:04 +0000 To: Jishnu Mukerji From: Andrew Watson Subject: Re: CSIv2 issue: length of GSSUP inner context token encapsulation Cc: Ron Monzillo , interop@omg.org, peter.walker@sun.com, csiv2-ftf@omg.org, Michi Henning Content-Type: text/plain; charset="us-ascii" X-UIDL: \ii!!JJ"e9_6ed9SB)!! Status: RO Jishnu, You wrote: > First of all, I don't see why this is an urgent issue. Personally I tend > to agree with Polar's analysis of the situation as presented in another > message not excerpted here. However, it is a call for Andrew to make > (hopefully in consultation with appropriate others). Sorry to be late to the party. Based on the discussion thread, I'm inclined *not* to label this issue as urgent, since no-one who's posted (including Ron) feels the text is ambiguous. If extra clarification text really is needed (is it?), let's apply it via the normal issue resolution process. > Second, since there is no active RTF in existence at present covering > CSIv2 (the last RTF expired on 11/19/01) we have two choices of venue > for discussing this issue: > > 1) The Architecture Board (the fallback for all urgent issues when RTFs > to handle them don't exist) > > 2) The Interop RTF, which is the targeted RTF for picking up this work. > I am CC-ing the interop mailing list for this reason. If this issue were urgent, I'd send it to the interop RTF - I'd prefer to use the AB for urgent resolutions only as a last resort. Thanks, Andrew Date: Wed, 5 Dec 2001 12:46:49 +1000 (EST) From: Michi Henning To: Andrew Watson cc: Jishnu Mukerji , Ron Monzillo , Interoperability RTF , peter.walker@sun.com, csiv2-ftf@omg.org Subject: Re: CSIv2 issue: length of GSSUP inner context token encapsulation In-Reply-To: Message-ID: Organization: IONA Technologies MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: /Bhd9D"Le9hDQe9=="!! On Tue, 4 Dec 2001, Andrew Watson wrote: > > 2) The Interop RTF, which is the targeted RTF for picking up this work. > > I am CC-ing the interop mailing list for this reason. > > If this issue were urgent, I'd send it to the interop RTF - I'd prefer to > use the AB for urgent resolutions only as a last resort. I don't see a problem here either. There is a struct, and that struct is supposed to go into a CDR encapsulation. Fine, no problem; the rules for doing this are well-defined and unambiguous. If no-one objects, I'll put this on the next vote as "no change". Cheers, Michi. -- Michi Henning +61 7 3324 9633 Chief CORBA Scientist +61 4 1118 2700 (mobile) IONA Technologies +61 7 3324 9799 (fax) Total Business Integration http://www.ooc.com.au/staff/michi Date: Tue, 04 Dec 2001 21:52:58 -0500 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Andrew Watson , Jishnu Mukerji , Ron Monzillo , Interoperability RTF , peter.walker@Sun.COM, csiv2-ftf@omg.org Subject: Re: CSIv2 issue: length of GSSUP inner context token encapsulation References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: %/>!!;Z(!!*Tk!!p>Ee9 Thanks, Not that I disagree with your conclusion, but just to make sure we are on the same page. The issue is not with what goes in the encapsulation. It is whether or not a length must precede the encapsulation of a structure when the encapsulation occurs in the middle of a DER encoded octet stream. Ron Michi Henning wrote: > > On Tue, 4 Dec 2001, Andrew Watson wrote: > > > > 2) The Interop RTF, which is the targeted RTF for picking up this work. > > > I am CC-ing the interop mailing list for this reason. > > > > If this issue were urgent, I'd send it to the interop RTF - I'd prefer to > > use the AB for urgent resolutions only as a last resort. > > I don't see a problem here either. There is a struct, and that struct > is supposed to go into a CDR encapsulation. Fine, no problem; the rules > for doing this are well-defined and unambiguous. If no-one objects, I'll > put this on the next vote as "no change". > > Cheers, > > Michi. > -- > Michi Henning +61 7 3324 9633 > Chief CORBA Scientist +61 4 1118 2700 (mobile) > IONA Technologies +61 7 3324 9799 (fax) > Total Business Integration http://www.ooc.com.au/staff/michi X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 5 Dec 2001 09:37:52 -0500 (EST) From: Polar Humenn To: Ron Monzillo cc: Michi Henning , Andrew Watson , Jishnu Mukerji , Interoperability RTF , , Subject: Re: CSIv2 issue: length of GSSUP inner context token encapsulation In-Reply-To: <3C0D8C0A.9A0F4E21@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: W0#e9DIj!!8R)e9I4~!! On Tue, 4 Dec 2001, Ron Monzillo wrote: > Thanks, > > Not that I disagree with your conclusion, but just to make sure we >are > on the same page. The issue is not with what goes in the >encapsulation. > It is whether or not a length must precede the encapsulation of a > structure > when the encapsulation occurs in the middle of a DER encoded octet > stream. Ron, if a length were supposed to preceed the encapsulation, then what encoding would you use? Or should I ask, what encoding of this length are your EJB developers using? -Polar > Ron > > Michi Henning wrote: > > > > On Tue, 4 Dec 2001, Andrew Watson wrote: > > > > > > 2) The Interop RTF, which is the targeted RTF for picking up >this work. > > > > I am CC-ing the interop mailing list for this reason. > > > > > > If this issue were urgent, I'd send it to the interop RTF - I'd >prefer to > > > use the AB for urgent resolutions only as a last resort. > > > > I don't see a problem here either. There is a struct, and that >struct > > is supposed to go into a CDR encapsulation. Fine, no problem; the >rules > > for doing this are well-defined and unambiguous. If no-one >objects, I'll > > put this on the next vote as "no change". > > > > Cheers, > > > > >Michi. > > -- > > Michi Henning +61 7 3324 9633 > > Chief CORBA Scientist +61 4 1118 2700 (mobile) > > IONA Technologies +61 7 3324 9799 (fax) > > Total Business Integration >http://www.ooc.com.au/staff/michi > ------------------------------------------------------------------- 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, 5 Dec 2001 19:28:11 -0500 (EST) From: Polar Humenn To: Ron Monzillo cc: Michi Henning , Andrew Watson , Jishnu Mukerji , Interoperability RTF , , Subject: Re: CSIv2 issue: length of GSSUP inner context token encapsulation In-Reply-To: <3C0E4077.31D0F626@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: "ph!!8l[d92=*e9P4R!! On Wed, 5 Dec 2001, Ron Monzillo wrote: > > > Polar Humenn wrote: > > > > On Tue, 4 Dec 2001, Ron Monzillo wrote: > > > > > Thanks, > > > > > > Not that I disagree with your conclusion, but just to make sure >we are > > > on the same page. The issue is not with what goes in the >encapsulation. > > > It is whether or not a length must precede the encapsulation of >a > > > structure > > > when the encapsulation occurs in the middle of a DER encoded >octet > > > stream. > > > > Ron, if a length were supposed to preceed the encapsulation, then >what > > encoding would you use? > > > > Or should I ask, what encoding of this length are your EJB >developers > > using? > > > > Polar, > > This is the hidden issue behind the consideration of whether there > should be a length. If there should be a length then as you > suggest how it will be encoded must be defined. I'm suggesting nothing of the sort. The question was merely an investigative attempt to try and find out where you and your EJB developers' confusion is eminating. For the ones putting a length in there, if they were using a standard CDR encoding of an unsigned long, then they are offbase, because CDR encoded structs are not preceeded by a length at all. If it were a DER encoded INTEGER, then they are offbase, because the RFC says that there shall be no length preceeding the content of the token. > In one example, they were using the encoding of the > sequence of octets containing the encompassing GSSToken. Of how many octets? 1,2,4,8,16, ??, what's the endian? > An alternate proposal was to use a DER encoding of the length, since > the contents of the mechanism independent part of the GSSToken are > DER encoded. The J2EE RI does not include a length. > > I would much prefer that we all agree that there shall be no length. It's unambiguous. It's agreed, there is no "length", but it doesn't need to be stated in the spec any more than, "Any encoding of the novel entitled "The French Revolution" shall not be included before the content of the token". Again, the confusion is eminating from the spec saying too much. BTW, make sure that they include the CDR encapsulation "boolean" that labels the endian before marshalling the IDL struct. Cheers, -Polar > > Ron > > > -Polar > > > > > Ron > > > > > > Michi Henning wrote: > > > > > > > > On Tue, 4 Dec 2001, Andrew Watson wrote: > > > > > > > > > > 2) The Interop RTF, which is the targeted RTF for picking >up this work. > > > > > > I am CC-ing the interop mailing list for this reason. > > > > > > > > > > If this issue were urgent, I'd send it to the interop RTF - >I'd prefer to > > > > > use the AB for urgent resolutions only as a last resort. > > > > > > > > I don't see a problem here either. There is a struct, and that >struct > > > > is supposed to go into a CDR encapsulation. Fine, no problem; >the rules > > > > for doing this are well-defined and unambiguous. If no-one >objects, I'll > > > > put this on the next vote as "no change". > > > > > > > > >Cheers, > > > > > > > > >Michi. > > > > -- > > > > Michi Henning +61 7 3324 9633 > > > > Chief CORBA Scientist +61 4 1118 2700 >(mobile) > > > > IONA Technologies +61 7 3324 9799 >(fax) > > > > Total Business Integration >http://www.ooc.com.au/staff/michi > > > > > > > >------------------------------------------------------------------- > > 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, 05 Dec 2001 10:42:47 -0500 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn CC: Ron Monzillo , Michi Henning , Andrew Watson , Jishnu Mukerji , Interoperability RTF , peter.walker@sun.com, csiv2-ftf@omg.org Subject: Re: CSIv2 issue: length of GSSUP inner context token encapsulation References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 4fR!!Hb'e9&Ji!!N#3e9 Polar Humenn wrote: > > On Tue, 4 Dec 2001, Ron Monzillo wrote: > > > Thanks, > > > > Not that I disagree with your conclusion, but just to make sure we are > > on the same page. The issue is not with what goes in the encapsulation. > > It is whether or not a length must precede the encapsulation of a > > structure > > when the encapsulation occurs in the middle of a DER encoded octet > > stream. > > Ron, if a length were supposed to preceed the encapsulation, then what > encoding would you use? > > Or should I ask, what encoding of this length are your EJB developers > using? > Polar, This is the hidden issue behind the consideration of whether there should be a length. If there should be a length then as you suggest how it will be encoded must be defined. In one example, they were using the encoding of the sequence of octets containing the encompassing GSSToken. An alternate proposal was to use a DER encoding of the length, since the contents of the mechanism independent part of the GSSToken are DER encoded. The J2EE RI does not include a length. I would much prefer that we all agree that there shall be no length. Ron > -Polar > > > Ron > > > > Michi Henning wrote: > > > > > > On Tue, 4 Dec 2001, Andrew Watson wrote: > > > > > > > > 2) The Interop RTF, which is the targeted RTF for picking up this work. > > > > > I am CC-ing the interop mailing list for this reason. > > > > > > > > If this issue were urgent, I'd send it to the interop RTF - I'd prefer to > > > > use the AB for urgent resolutions only as a last resort. > > > > > > I don't see a problem here either. There is a struct, and that struct > > > is supposed to go into a CDR encapsulation. Fine, no problem; the rules > > > for doing this are well-defined and unambiguous. If no-one objects, I'll > > > put this on the next vote as "no change". > > > > > > Cheers, > > > > > > Michi. > > > -- > > > Michi Henning +61 7 3324 9633 > > > Chief CORBA Scientist +61 4 1118 2700 (mobile) > > > IONA Technologies +61 7 3324 9799 (fax) > > > Total Business Integration http://www.ooc.com.au/staff/michi > > > > ------------------------------------------------------------------- > 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