Issue 3972: Format of GSSUP GSS exported name object undefined (csiv2-ftf) Source: Oracle (Mr. Ron Monzillo, ronald.monzillo(at)east.sun.com) Nature: Uncategorized Issue Severity: Summary: Document: orbos/2000-08-04 CSIv2 Final Submission Issue: Format of GSSUP GSS mechanism-independent exported name object, a special form of "flat" name as described below, is not defined. Description: >From RFC 2473 section 1.1.5 Naming > Different classes of name representations are used in conjunction > with different GSS-API parameters: > > - Internal form (denoted in this document by INTERNAL NAME), > opaque to callers and defined by individual GSS-API > implementations. GSS-API implementations supporting multiple > namespace types must maintain internal tags to disambiguate the > interpretation of particular names. A Mechanism Name (MN) is a > special case of INTERNAL NAME, guaranteed to contain elements > corresponding to one and only one mechanism; calls which are > guaranteed to emit MNs or which require MNs as input are so > identified within this specification. > > - Contiguous string ("flat") form (denoted in this document by > OCTET STRING); accompanied by OID tags identifying the namespace > to which they correspond. Depending on tag value, flat names may > or may not be printable strings for direct acceptance from and > presentation to users. Tagging of flat names allows GSS-API > callers and underlying GSS-API mechanisms to disambiguate name > types and to determine whether an associated name's type is one > which they are capable of processing, avoiding aliasing problems > which could result from misinterpreting a name of one type as a > name of another type. > > - The GSS-API Exported Name Object, a special case of flat name > designated by a reserved OID value, carries a canonicalized form > of a name suitable for binary comparisons. Resolution: Revised Text: Resolution: Define a "flat name" type OID and format. It would also be good to have these OIDs specified somewhere. We can do that in IDL with string constants, using dot notation for OIDs Close issue with revised text. Revised Text: The following modifications are presented against document http://cgi.omg.org/pub/csiv2-ftf/csiv2-0117011.pdf with the assumption that the resolution of Issue 4141 has been applied, i.e. Moving GSS_NT_ExportedName from Security to CSI, and the assumption that the resolution of Issue 4143 has been applied, i.e. creation of the CSI::StringOID type. [1] Add the following at the end (following para 54) of section 15.2.5 Identity Token Format GSS Exported Name Object Form for GSSUP Mechanism. The mechanism OID within the exported name object shall be that of the GSSUP mechanism. {iso-itu-t (2) international-organization (23) omg (130) security (1) authentication (1) gssup-mechanism (1)} The name component within the exported name object shall be a contiguous string conforming to the syntax of the scoped-username GSS name form. The encoding of GSS mechanism-independent exported name objects is defined in [IETF RFC 2743]. Scoped-Username GSS Name Form The scoped-username GSS name form is defined as follows, where name_value and name_scope contain a sequence of 1 or more UTF8 encoded characters. scoped-username ::= name_value | name_value@name_scope | @name_scope The '@' character shall be used to delimit name_value from name_scope. All non-delimiter instances of '@' and all non-quoting instances of '\' shall be quoted with an immediately-preceding '\'. Except for these cases, the quoting character, '\', shall not be emitted within a scoped-username. The Object Identifier corresponding to the GSS scoped-username name form is: {iso-itu-t (2) international-organization (23) omg (130) security (1) naming (2) scoped-username(1)} [2] Insert the following definitions in Section 16.9.6, Module CSI, after the definition of GSS_NT_ExportedNameList. // The GSS Object Identifier for the KRB5 mechanism is: // // { iso(1) member-body(2) United States(840) mit(113554) // infosys(1) gssapi(2) krb5(2) } const StringOID KRB5MechOID = "oid:1.2.840.113554.1.2.2"; // The GSS Object Identifier for name objects of the // Mechanism-idependent Exported Name Object type is: // {iso(1) org(3) dod(6) internet(1) security(5) // nametypes(6) gss-api-exported-name(4)} const StringOID GSS_NT_Export_Name_OID = "oid:1.3.6.1.5.6.4"; // The GSS Object Identifier for the scoped-username name form is: // {iso-itu-t (2) international-organization (23) omg (130) // security (1) naming (2) scoped-username(1)} const StringOID GSS_NT_Scoped_Username_OID = "oid:2.23.130.1.2.1"; Actions taken: October 19, 2000: received issue October 3, 2001: closed issue Discussion: Section 3.5 of the CSIv2 document describes Identity Tokens, however it did not describe the format of the "name blob" (that is the part following the mechanism OID and length) within a GSSUP Exported Name Object. End of Annotations:===== >Date: Thu, 19 Oct 2000 11:50:26 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: juergen@omg.org Subject: [Fwd: ISSUE: Format of GSSUP GSS exported name object undefined] Content-Type: multipart/mixed; boundary="------------DF582230BCF355E65800C6E7" X-UIDL: 4Hdd9+pid9EQb!!?8 Date: Fri, 13 Oct 2000 11:29:39 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: csiv2-ftf@omg.org Subject: ISSUE: Format of GSSUP GSS exported name object undefined Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Document: orbos/2000-08-04 CSIv2 Final Submission Issue: Format of GSSUP GSS mechanism-independent exported name object, a special form of "flat" name as described below, is not defined. Description: >From RFC 2473 section 1.1.5 Naming > Different classes of name representations are used in conjunction > with different GSS-API parameters: > > - Internal form (denoted in this document by INTERNAL NAME), > opaque to callers and defined by individual GSS-API > implementations. GSS-API implementations supporting multiple > namespace types must maintain internal tags to disambiguate > the > interpretation of particular names. A Mechanism Name (MN) is > a > special case of INTERNAL NAME, guaranteed to contain elements > corresponding to one and only one mechanism; calls which are > guaranteed to emit MNs or which require MNs as input are so > identified within this specification. > > - Contiguous string ("flat") form (denoted in this document by > OCTET STRING); accompanied by OID tags identifying the > namespace > to which they correspond. Depending on tag value, flat names > may > or may not be printable strings for direct acceptance from and > presentation to users. Tagging of flat names allows GSS-API > callers and underlying GSS-API mechanisms to disambiguate name > types and to determine whether an associated name's type is > one > which they are capable of processing, avoiding aliasing > problems > which could result from misinterpreting a name of one type as > a > name of another type. > > - The GSS-API Exported Name Object, a special case of flat > name > designated by a reserved OID value, carries a canonicalized > form > of a name suitable for binary comparisons. Discussion: Section 3.5 of the CSIv2 document describes Identity Tokens, however it did not describe the format of the "name blob" (that is the part following the mechanism OID and length) within a GSSUP Exported Name Object. Proposed Solution: Actually this is is just to clarify suggested approach. It was not written for direct inclusion in section 3.5. GSSUP flat name ::= name_value | name_value@name_scope | @name_scope Beginning with a ScopedName (which is the internal form of a GSSUP name), copy the bytes of the name_value into the output string such that each occurance of the delimiter character '@' in the name_value is replaced by "@@" in the output string. If the name_scope field is of length greater than 0, then append a delimter character to the output string, and then apend the bytes of the name_scope to the output string (without byte-stuffing). Set the length encoded in the 4-byte length within the GSS exported name object to the number of bytes written to the output string including all inserted delimiter characters. Date: Tue, 16 Jan 2001 18:35:55 -0500 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: [Fwd: GSSUP related issues] Content-Type: multipart/mixed; boundary="------------C6D86DFEB402C548F2753C58" X-UIDL: 5ELe9^LF!!9`Td9>?V!! Message-ID: <3A64C967.50306F88@east.sun.com> Date: Tue, 16 Jan 2001 17:21:27 -0500 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: monzillo@east.sun.com Subject: GSSUP related issues References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I promised to start the discussion on the following issues Issue 3948: GSSUP names are incompatible with the Identity Token Issue 3972: Format of GSSUP GSS exported name object undefined The crux of these issues is really whether or not GSSUP should be considered a full-fledged GSSAPI mechanism or a "pseudo-mechanism". The solution proposed to issue 3948 is that GSSUP be treated as a pseudo- mechanism. According to this proposal, the GSSUP Initial Context Token (ICT) would be modified to carry a mechanism (i.e. kereberos, unix,..) specific GSS exported name. The implication of the proposal is that there would not be an exported name form for the GSSUP mechanism. The solution proposed to issue 3972 is to define the exported name form of the GSSUP mechanism, such that it in addition to the existing definition of the GSSUP ICT, we will also have defined an exported name form to be used in GSSUP Identity Assertions. These two issues have a different focus, and thus different proposals have been made. In general the respective proposals may be summarized as follows: 3948. GSSUP as a pseudo mechanism would be used to authenticate GSSAPI identities of other types (i.e. Kerberos, unix). 3972. GSSUP as a full-fledged mechanism would be used to authenticate full-fledged GSSUP (realm/scope specific) identities. We wrote the submission with our intent being focused on something like that proposed in 3972. It is also clear that this approach was not completed in the submission, as we neglected to define a GSSUP exported name form. The proposed solution to 3948 would attempt to more tightly integerate the GSSUP mechanism with security mechanisms for which there is at least a defined GSSAPI exported name form. We would presumably do this to be able to use GSSUP to A. access a non-GSSAPI username password authentication mechanism from a communications protocol using GSSUP as a GSSAPI mechanism. B. do username password authentication where the target GSSAPI authentication mechanism does not support username-password authentication via its ICT. C. establish a GSSAPI mechanism specific authentication identity (an exported name) as the result of either A. or B. We created GSSUP for reason A. The Proposed solution to 3972 only addresses reason A. The proposed solution to 3948 addresses reasons B and C, in that it limits the use of GSSUP to those mechanisms for which there is a defined exported name form. The proposed solution to 3972 (the definition of a GSSUP exported name form) insures that reason A, can be satisfied in all contexts. The proposed solution to 3972 also ensures that we need not add (to conformance level 0) any requirement to support additional GSSAPI mechanisms (that is, their name formats). If we begin with the proposed resolution of 3972 as a baseline, then we can determine if we want to extend the semantics of the GSSUP mechanism to satisfy reasons B and C, in which case, we might blend the solution of 3972 and 3948. Approach 1: That is, the GSSUP ICT Name and Scope could be replaced by a mechanism specific exported name form of type corresponding to the OID of the target_name in the AS_ContextSec structure. GSSUP itself would be a legitimate value for the type OID in the target_name. The inner contents of the GSSUP ICT would be as follows (preceded by the GSSUP OID). struct InitialContextToken { GSS_NT_exported_name username; UTF8String password; }; Approach 2: Alternatively, we could use the target_name OID to establish and interpret the form of the name sent and received in a GSSUP ICT. Mechanism specific (as defined by the target_name OID's) flat name strings obtained from the user would be sent in name_scope and name_value. The inner contents of the GSSUP ICT would be as follows (preceded by the GSSUP OID. struct ScopedName { NameValue name_scope; NameValue name_value; }; struct InitialContextToken { ScopedName username; UTF8String password; }; So to reiterate, if we begin with the proposed resolution to 3972 (that is the definition of a GSSUP exported name form), and then decide whether we want to acknowledge reasons B, or C, (that is resolve issue 3948), then I think either of the approaches listed above are workable. Approach 1's inclusion of the name defining mechanism OID in the GSSUP ICT, and the fact that most if not all translations from user presentation forms to flat name forms could be done at data collection, argue in its favor. The extra overhead of sending a second/internal OID for GSSUP ICT's, and the complexity of the ICT with embedded ASN.1 exported name would argue against approach 1, especially if we are not seeking to address B or C. If we are more inclined towards approach 2, then a simplification could be made by removing name_scope and using the mechanism specific flat name encoding as the username. struct InitialContextToken { UTF8String username; // for GSSUP username | username@scope UTF8String password; }; Ron X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 18 Jan 2001 00:06:00 -0500 (EST) From: Polar Humenn To: David Chang cc: Ron Monzillo , csiv2-ftf@omg.org Subject: Re: [Fwd: GSSUP related issues] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: S9%!!`,Le9`G(e9\0'e9 On Wed, 17 Jan 2001, David Chang wrote: > Ron, > > Does the Approach 2 use the format of the username in the > InitilaContextToken to distinguish to the mechanism type instead of > the > mechanism OID? > > struct InitialContextToken { > UTF8String username; // for GSSUP username | > username@scope > UTF8String password; > }; > > Please clarify. I would think not. Also, in this case the username cannot be a DN, it must be a flat name with no designation of type of name. Of course it could always be a string version of a DN, but you wouldn't know it. I still think the GSS_NT_ExportName would be the better option. Cheers, -Polar > > Thanks > > David Chang > > WebSphere Security Architect & Team Lead > IBM SWS Division, Internal Mail Stop 9131 > Austin, Tx 78758 > E-Mail:dyc@us.ibm.com > Phone:(512)838-0559, T/L 678-0559 > Fax: (512)838-1032 > > > Ron Monzillo on 01/16/2001 05:35:55 > PM > > To: csiv2-ftf@omg.org > cc: > Subject: [Fwd: GSSUP related issues] > > > > > Content-Transfer-Encoding: 7bit > Content-Type: text/plain; charset=us-ascii > > I promised to start the discussion on the following issues > > Issue 3948: GSSUP names are incompatible with the Identity Token > Issue 3972: Format of GSSUP GSS exported name object undefined > > The crux of these issues is really whether or not GSSUP should be > considered a full-fledged GSSAPI mechanism or a "pseudo-mechanism". > > The solution proposed to issue 3948 is that GSSUP be treated as a > pseudo- mechanism. According to this proposal, the GSSUP Initial > Context > Token (ICT) would be modified to carry a mechanism (i.e. kereberos, > unix,..) specific GSS exported name. The implication of the proposal > is > that there would not be an exported name form for the GSSUP > mechanism. > > The solution proposed to issue 3972 is to define the exported name > form > of the GSSUP mechanism, such that it in addition to the existing > definition of the GSSUP ICT, we will also have defined an exported > name > form to be used in GSSUP Identity Assertions. > > These two issues have a different focus, and thus different > proposals > have been made. In general the respective proposals may be > summarized as > follows: > > 3948. GSSUP as a pseudo mechanism would be used to authenticate > GSSAPI > identities of other types (i.e. Kerberos, unix). > > 3972. GSSUP as a full-fledged mechanism would be used to > authenticate > full-fledged GSSUP (realm/scope specific) identities. > > We wrote the submission with our intent being focused on something > like > that proposed in 3972. It is also clear that this approach was not > completed in the submission, as we neglected to define a GSSUP > exported > name form. > > The proposed solution to 3948 would attempt to more tightly > integerate > the GSSUP mechanism with security mechanisms for which there is at > least > a defined GSSAPI exported name form. We would presumably do this to > be > able to use GSSUP to > > A. access a non-GSSAPI username password authentication mechanism > from > a communications protocol using GSSUP as a GSSAPI mechanism. > > B. do username password authentication where the target GSSAPI > authentication mechanism does not support username-password > authentication via its ICT. > > C. establish a GSSAPI mechanism specific authentication identity (an > exported name) as the result of either A. or B. > > We created GSSUP for reason A. The Proposed solution to 3972 only > addresses reason A. The proposed solution to 3948 addresses reasons > B > and C, in that it limits the use of GSSUP to those mechanisms for > which > there is a defined exported name form. > > The proposed solution to 3972 (the definition of a GSSUP exported > name > form) insures that reason A, can be satisfied in all contexts. > > The proposed solution to 3972 also ensures that we need not add (to > conformance level 0) any requirement to support additional GSSAPI > mechanisms (that is, their name formats). > > If we begin with the proposed resolution of 3972 as a baseline, then > we > can determine if we want to extend the semantics of the GSSUP > mechanism > to satisfy reasons B and C, in which case, we might blend the > solution > of 3972 and 3948. > > Approach 1: > > That is, the GSSUP ICT Name and Scope could be replaced by a > mechanism > specific exported name form of type corresponding to the OID of the > target_name in the AS_ContextSec structure. GSSUP itself would be a > legitimate value for the type OID in the target_name. > > The inner contents of the GSSUP ICT would be as follows (preceded by > the > GSSUP OID). > > struct InitialContextToken { > GSS_NT_exported_name username; > UTF8String password; > }; > > Approach 2: > > Alternatively, we could use the target_name OID to establish and > interpret the form of the name sent and received in a GSSUP ICT. > Mechanism specific (as defined by the target_name OID's) flat name > strings obtained from the user would be sent in name_scope and > name_value. > > The inner contents of the GSSUP ICT would be as follows (preceded by > the > GSSUP OID. > > struct ScopedName { > NameValue name_scope; > NameValue name_value; > }; > > struct InitialContextToken { > ScopedName username; > UTF8String password; > }; > > So to reiterate, if we begin with the proposed resolution to 3972 > (that > is the definition of a GSSUP exported name form), and then decide > whether we want to acknowledge reasons B, or C, (that is resolve > issue > 3948), then I think either of the approaches listed above are > workable. > > Approach 1's inclusion of the name defining mechanism OID in the > GSSUP > ICT, and the fact that most if not all translations from user > presentation forms to flat name forms could be done at data > collection, > argue in its favor. The extra overhead of sending a second/internal > OID > for GSSUP ICT's, and the complexity of the ICT with embedded ASN.1 > exported name would argue against approach 1, especially if we are > not > seeking to address B or C. > > If we are more inclined towards approach 2, then a simplification > could > be made by removing name_scope and using the mechanism specific flat > name encoding as the username. > > struct InitialContextToken { > UTF8String username; // for GSSUP username | > username@scope > UTF8String password; > }; > > > Ron > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Thu, 18 Jan 2001 15:22:03 -0500 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 CC: David Chang , csiv2-ftf@omg.org Subject: Re: [Fwd: GSSUP related issues] References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: J3a!!@_!!!LCMd9#C[!! David, As noted in my last msg on this subject, approach 2, should not be considered further in any effort to satisfy POTENTIAL reasons C with B (as repeated below) for wanting to use GSSUP. > A. access a non-GSSAPI username password authentication mechanism from > a communications protocol using GSSUP as a GSSAPI mechanism. > > B. do username password authentication where the target GSSAPI > authentication mechanism does not support username-password > authentication via its ICT. > > C. establish a GSSAPI mechanism specific authentication identity (an > exported name) as the result of either A. or B. When 2 was proposed, it was thought that the mechanism OID in the target_name (in the AS_ContextSec structure) would be used to "interpret" the username. This idea was flawed where a target IOR could contain multiple mechanism definitions, and thus multiple, potentially different, target_name embedded mechanism OIDs. So let's focus instead on C with B above. If we want them (together), then we need a second OID in the InitialContextToken (ICT). Using the GSS exported name form as part of a GSSUP inner context token is one way of providing a second OID. I don't think GSSUP was defined for reasons C with B. Together they enable a powerful use model, but not one that was originally required or identified. People I know will have to change code if we decide to embrace this functionality. On the other hand, we neglected to define the asserted name form corresponding to the GSSUP mechanism (i.e. a GSSUP exported name form). So there is more work to do and perhaps undo, in any case. We must complete the GSSUP mechnanism, without inventing any unnecessary new types, without requiring support for any additional GSSAPI mechanisms, without causing any difficult to justify rework of existing implementations, and without unnecessarily constraining the use of the GSSUP mechanism. I see that Polar has been busy on this topic. Problems with the OMG archive server prevent me from seeing everything I need to see to comment further. I think it would help if we could hear from others, perhaps some who were initially calling for the GSSUP mechanism, as to what their position is with respect to enhancing GSSUP such that it can be used to (C)establish (i.e authenticate) a GSSAPI mechanism specific authentication identity (an exported name) where (B) the target GSSAPI authentication mechanism does not support username-password authentication via its ICT. using GSSUP with an inner context token containing a kerberos (esported) principal name, and password would be an example of this use case. Ron Polar Humenn wrote: > > On Wed, 17 Jan 2001, David Chang wrote: > > > Ron, > > > > Does the Approach 2 use the format of the username in the > > InitilaContextToken to distinguish to the mechanism type instead of the > > mechanism OID? > > > > struct InitialContextToken { > > UTF8String username; // for GSSUP username | username@scope > > UTF8String password; > > }; > > > > Please clarify. > > I would think not. Also, in this case the username cannot be a DN, it must > be a flat name with no designation of type of name. Of course it could > always be a string version of a DN, but you wouldn't know it. I still > think the GSS_NT_ExportName would be the better option. > > Cheers, > -Polar > > > > > Thanks > > > > David Chang > > > > WebSphere Security Architect & Team Lead > > IBM SWS Division, Internal Mail Stop 9131 > > Austin, Tx 78758 > > E-Mail:dyc@us.ibm.com > > Phone:(512)838-0559, T/L 678-0559 > > Fax: (512)838-1032 > > > > > > Ron Monzillo on 01/16/2001 05:35:55 PM > > > > To: csiv2-ftf@omg.org > > cc: > > Subject: [Fwd: GSSUP related issues] > > > > > > > > > > Content-Transfer-Encoding: 7bit > > Content-Type: text/plain; charset=us-ascii > > > > I promised to start the discussion on the following issues > > > > Issue 3948: GSSUP names are incompatible with the Identity Token > > Issue 3972: Format of GSSUP GSS exported name object undefined > > > > The crux of these issues is really whether or not GSSUP should be > > considered a full-fledged GSSAPI mechanism or a "pseudo-mechanism". > > > > The solution proposed to issue 3948 is that GSSUP be treated as a > > pseudo- mechanism. According to this proposal, the GSSUP Initial Context > > Token (ICT) would be modified to carry a mechanism (i.e. kereberos, > > unix,..) specific GSS exported name. The implication of the proposal is > > that there would not be an exported name form for the GSSUP mechanism. > > > > The solution proposed to issue 3972 is to define the exported name form > > of the GSSUP mechanism, such that it in addition to the existing > > definition of the GSSUP ICT, we will also have defined an exported name > > form to be used in GSSUP Identity Assertions. > > > > These two issues have a different focus, and thus different proposals > > have been made. In general the respective proposals may be summarized as > > follows: > > > > 3948. GSSUP as a pseudo mechanism would be used to authenticate GSSAPI > > identities of other types (i.e. Kerberos, unix). > > > > 3972. GSSUP as a full-fledged mechanism would be used to authenticate > > full-fledged GSSUP (realm/scope specific) identities. > > > > We wrote the submission with our intent being focused on something like > > that proposed in 3972. It is also clear that this approach was not > > completed in the submission, as we neglected to define a GSSUP exported > > name form. > > > > The proposed solution to 3948 would attempt to more tightly integerate > > the GSSUP mechanism with security mechanisms for which there is at least > > a defined GSSAPI exported name form. We would presumably do this to be > > able to use GSSUP to > > > > A. access a non-GSSAPI username password authentication mechanism from > > a communications protocol using GSSUP as a GSSAPI mechanism. > > > > B. do username password authentication where the target GSSAPI > > authentication mechanism does not support username-password > > authentication via its ICT. > > > > C. establish a GSSAPI mechanism specific authentication identity (an > > exported name) as the result of either A. or B. > > > > We created GSSUP for reason A. The Proposed solution to 3972 only > > addresses reason A. The proposed solution to 3948 addresses reasons B > > and C, in that it limits the use of GSSUP to those mechanisms for which > > there is a defined exported name form. > > > > The proposed solution to 3972 (the definition of a GSSUP exported name > > form) insures that reason A, can be satisfied in all contexts. > > > > The proposed solution to 3972 also ensures that we need not add (to > > conformance level 0) any requirement to support additional GSSAPI > > mechanisms (that is, their name formats). > > > > If we begin with the proposed resolution of 3972 as a baseline, then we > > can determine if we want to extend the semantics of the GSSUP mechanism > > to satisfy reasons B and C, in which case, we might blend the solution > > of 3972 and 3948. > > > > Approach 1: > > > > That is, the GSSUP ICT Name and Scope could be replaced by a mechanism > > specific exported name form of type corresponding to the OID of the > > target_name in the AS_ContextSec structure. GSSUP itself would be a > > legitimate value for the type OID in the target_name. > > > > The inner contents of the GSSUP ICT would be as follows (preceded by the > > GSSUP OID). > > > > struct InitialContextToken { > > GSS_NT_exported_name username; > > UTF8String password; > > }; > > > > Approach 2: > > > > Alternatively, we could use the target_name OID to establish and > > interpret the form of the name sent and received in a GSSUP ICT. > > Mechanism specific (as defined by the target_name OID's) flat name > > strings obtained from the user would be sent in name_scope and > > name_value. > > > > The inner contents of the GSSUP ICT would be as follows (preceded by the > > GSSUP OID. > > > > struct ScopedName { > > NameValue name_scope; > > NameValue name_value; > > }; > > > > struct InitialContextToken { > > ScopedName username; > > UTF8String password; > > }; > > > > So to reiterate, if we begin with the proposed resolution to 3972 (that > > is the definition of a GSSUP exported name form), and then decide > > whether we want to acknowledge reasons B, or C, (that is resolve issue > > 3948), then I think either of the approaches listed above are workable. > > > > Approach 1's inclusion of the name defining mechanism OID in the GSSUP > > ICT, and the fact that most if not all translations from user > > presentation forms to flat name forms could be done at data collection, > > argue in its favor. The extra overhead of sending a second/internal OID > > for GSSUP ICT's, and the complexity of the ICT with embedded ASN.1 > > exported name would argue against approach 1, especially if we are not > > seeking to address B or C. > > > > If we are more inclined towards approach 2, then a simplification could > > be made by removing name_scope and using the mechanism specific flat > > name encoding as the username. > > > > struct InitialContextToken { > > UTF8String username; // for GSSUP username | username@scope > > UTF8String password; > > }; > > > > > > Ron > > > > > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 18 Jan 2001 17:16:21 -0500 (EST) From: Polar Humenn To: Ron Monzillo cc: David Chang , csiv2-ftf@omg.org Subject: Re: [Fwd: GSSUP related issues] In-Reply-To: <3A67506B.56B0C5A4@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: '+g!!\X#"!9bP!!N"ad9 Ron, First of all let me say that I'm a bit confused over the requirements/reasons you give for the need of GSSUP. See below. On Thu, 18 Jan 2001, Ron Monzillo wrote: > David, > > As noted in my last msg on this subject, approach 2, should not > be considered further in any effort to satisfy POTENTIAL reasons > C with B (as repeated below) for wanting to use GSSUP. > > > A. access a non-GSSAPI username password authentication mechanism > from > > a communications protocol using GSSUP as a GSSAPI mechanism. I don't understand this "access a non-GSSAPI" username password autthencation mechanism. We have created one, it's called GSSUP, it DOES username/password, it is GSS-API. > > B. do username password authentication where the target GSSAPI > > authentication mechanism does not support username-password > > authentication via its ICT. I don't understand why you need to do username/password authentication where the target doesn't support it. I'm really a little lost on this one. But I really don't want to get into pedantic discussions ad nausem. > > C. establish a GSSAPI mechanism specific authentication identity (an > > exported name) as the result of either A. or B. The establishment of this GSSUP mechanism that has as its username component a GSS Exported Name would be extremely benefical and simple. The following scenario applies: Client ---- GSSUP Token containing -----> Intermediate GSS_NT_ExportedName Intermediate works on behalf of Client. Intermediate --->> Identity Token containing ----> Target GSS_NT_ExportedName Target supports the particular naming type. This name is lifted directly from Client's GSSUP Token, quite possibly without the security service even looking inside of it. (The security service can merely hand the username/password combo to a password validation service), okay, then move on. Amazingly Simple. No hoops to jump through. Using the GSS_NT_ExportedName makes for a clean implemenation and is consistent with the naming issues of the rest of the spec. Added benefit, it gives flexibility that allows most any name form to be used, such as a DN, even a KerberosName, or a simple "flat" string name, a certificate, etc. I have taken to promoting this type of solution in: ftp://greene.case.syr.edu/pub/omg/csiv2-ftf/FTF-Issue3922.html of which I highly recommend. > When 2 was proposed, it was thought that the mechanism OID in the > target_name (in the AS_ContextSec structure) would be used to > "interpret" the username. This idea was flawed where a target IOR > could > contain multiple mechanism definitions, and thus multiple, > potentially > different, target_name embedded mechanism OIDs. > > So let's focus instead on C with B above. If we want them > (together), > then we need a second OID in the InitialContextToken (ICT). Using > the > GSS exported name form as part of a GSSUP inner context token is one > way > of providing a second OID. > > I don't think GSSUP was defined for reasons C with B. Together they > enable a powerful use model, but not one that was originally > required or > identified. People I know will have to change code if we decide to > embrace this functionality. On the other hand, we neglected to > define > the asserted name form corresponding to the GSSUP mechanism (i.e. a > GSSUP exported name form). So there is more work to do and perhaps > undo, > in any case. > > We must complete the GSSUP mechnanism, without inventing any > unnecessary > new types, without requiring support for any additional GSSAPI > mechanisms, without causing any difficult to justify rework of > existing > implementations, and without unnecessarily constraining the use of > the > GSSUP mechanism. > > I see that Polar has been busy on this topic. Problems with the OMG > archive server prevent me from seeing everything I need to see > to comment further. I think it would help if we could hear from > others, > perhaps some who were initially calling for the GSSUP mechanism, as > to > what their position is with respect to enhancing GSSUP such that it > can > be used to > > (C)establish (i.e authenticate) a GSSAPI mechanism specific > authentication identity (an exported name) where (B) the target > GSSAPI > authentication mechanism does not support username-password > authentication via its ICT. I still don't understand this. GSSUP sends two pieces of data. A name, and a password. We are not talking about anything else but GSSUP, and that is username/password. I don't really care as if the target calls "kinit" with the information, it's still username/password. > using GSSUP with an inner context token containing a kerberos (esported) > principal name, and password would be an example of this use case. Huh????? That is username password. If you are talking about sending a kerberos ticket, that is a different mechanism than GSSUP, and works quite nicely, I might add. Cheers, -Polar > > Ron > > Polar Humenn wrote: > > > > On Wed, 17 Jan 2001, David Chang wrote: > > > > > Ron, > > > > > > Does the Approach 2 use the format of the username in the > > > InitilaContextToken to distinguish to the mechanism type instead > of the > > > mechanism OID? > > > > > > struct InitialContextToken { > > > UTF8String username; // for GSSUP username | > username@scope > > > UTF8String password; > > > }; > > > > > > Please clarify. > > > > I would think not. Also, in this case the username cannot be a DN, > it must > > be a flat name with no designation of type of name. Of course it > could > > always be a string version of a DN, but you wouldn't know it. I > still > > think the GSS_NT_ExportName would be the better option. > > > > Cheers, > > -Polar > > > > > > > > Thanks > > > > > > David Chang > > > > > > WebSphere Security Architect & Team Lead > > > IBM SWS Division, Internal Mail Stop 9131 > > > Austin, Tx 78758 > > > E-Mail:dyc@us.ibm.com > > > Phone:(512)838-0559, T/L 678-0559 > > > Fax: (512)838-1032 > > > > > > > > > Ron Monzillo on 01/16/2001 > 05:35:55 PM > > > > > > To: csiv2-ftf@omg.org > > > cc: > > > Subject: [Fwd: GSSUP related issues] > > > > > > > > > > > > > > > Content-Transfer-Encoding: 7bit > > > Content-Type: text/plain; charset=us-ascii > > > > > > I promised to start the discussion on the following issues > > > > > > Issue 3948: GSSUP names are incompatible with the Identity Token > > > Issue 3972: Format of GSSUP GSS exported name object undefined > > > > > > The crux of these issues is really whether or not GSSUP should > be > > > considered a full-fledged GSSAPI mechanism or a > "pseudo-mechanism". > > > > > > The solution proposed to issue 3948 is that GSSUP be treated as > a > > > pseudo- mechanism. According to this proposal, the GSSUP Initial > Context > > > Token (ICT) would be modified to carry a mechanism > (i.e. kereberos, > > > unix,..) specific GSS exported name. The implication of the > proposal is > > > that there would not be an exported name form for the GSSUP > mechanism. > > > > > > The solution proposed to issue 3972 is to define the exported > name form > > > of the GSSUP mechanism, such that it in addition to the existing > > > definition of the GSSUP ICT, we will also have defined an > exported name > > > form to be used in GSSUP Identity Assertions. > > > > > > These two issues have a different focus, and thus different > proposals > > > have been made. In general the respective proposals may be > summarized as > > > follows: > > > > > > 3948. GSSUP as a pseudo mechanism would be used to authenticate > GSSAPI > > > identities of other types (i.e. Kerberos, unix). > > > > > > 3972. GSSUP as a full-fledged mechanism would be used to > authenticate > > > full-fledged GSSUP (realm/scope specific) identities. > > > > > > We wrote the submission with our intent being focused on > something like > > > that proposed in 3972. It is also clear that this approach was > not > > > completed in the submission, as we neglected to define a GSSUP > exported > > > name form. > > > > > > The proposed solution to 3948 would attempt to more tightly > integerate > > > the GSSUP mechanism with security mechanisms for which there is > at least > > > a defined GSSAPI exported name form. We would presumably do this > to be > > > able to use GSSUP to > > > > > > A. access a non-GSSAPI username password authentication > mechanism from > > > a communications protocol using GSSUP as a GSSAPI mechanism. > > > > > > B. do username password authentication where the target GSSAPI > > > authentication mechanism does not support username-password > > > authentication via its ICT. > > > > > > C. establish a GSSAPI mechanism specific authentication identity > (an > > > exported name) as the result of either A. or B. > > > > > > We created GSSUP for reason A. The Proposed solution to 3972 > only > > > addresses reason A. The proposed solution to 3948 addresses > reasons B > > > and C, in that it limits the use of GSSUP to those mechanisms > for which > > > there is a defined exported name form. > > > > > > The proposed solution to 3972 (the definition of a GSSUP > exported name > > > form) insures that reason A, can be satisfied in all contexts. > > > > > > The proposed solution to 3972 also ensures that we need not add > (to > > > conformance level 0) any requirement to support additional > GSSAPI > > > mechanisms (that is, their name formats). > > > > > > If we begin with the proposed resolution of 3972 as a baseline, > then we > > > can determine if we want to extend the semantics of the GSSUP > mechanism > > > to satisfy reasons B and C, in which case, we might blend the > solution > > > of 3972 and 3948. > > > > > > Approach 1: > > > > > > That is, the GSSUP ICT Name and Scope could be replaced by a > mechanism > > > specific exported name form of type corresponding to the OID of > the > > > target_name in the AS_ContextSec structure. GSSUP itself would > be a > > > legitimate value for the type OID in the target_name. > > > > > > The inner contents of the GSSUP ICT would be as follows > (preceded by the > > > GSSUP OID). > > > > > > struct InitialContextToken { > > > GSS_NT_exported_name username; > > > UTF8String password; > > > }; > > > > > > Approach 2: > > > > > > Alternatively, we could use the target_name OID to establish and > > > interpret the form of the name sent and received in a GSSUP ICT. > > > Mechanism specific (as defined by the target_name OID's) flat > name > > > strings obtained from the user would be sent in name_scope and > > > name_value. > > > > > > The inner contents of the GSSUP ICT would be as follows > (preceded by the > > > GSSUP OID. > > > > > > struct ScopedName { > > > NameValue name_scope; > > > NameValue name_value; > > > }; > > > > > > struct InitialContextToken { > > > ScopedName username; > > > UTF8String password; > > > }; > > > > > > So to reiterate, if we begin with the proposed resolution to > 3972 (that > > > is the definition of a GSSUP exported name form), and then > decide > > > whether we want to acknowledge reasons B, or C, (that is resolve > issue > > > 3948), then I think either of the approaches listed above are > workable. > > > > > > Approach 1's inclusion of the name defining mechanism OID in the > GSSUP > > > ICT, and the fact that most if not all translations from user > > > presentation forms to flat name forms could be done at data > collection, > > > argue in its favor. The extra overhead of sending a > second/internal OID > > > for GSSUP ICT's, and the complexity of the ICT with embedded > ASN.1 > > > exported name would argue against approach 1, especially if we > are not > > > seeking to address B or C. > > > > > > If we are more inclined towards approach 2, then a > simplification could > > > be made by removing name_scope and using the mechanism specific > flat > > > name encoding as the username. > > > > > > struct InitialContextToken { > > > UTF8String username; // for GSSUP username | > username@scope > > > UTF8String password; > > > }; > > > > > > > > > Ron > > > > > > > > > > > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 18 Jan 2001 01:30:41 -0500 (EST) From: Polar Humenn To: csiv2-ftf@omg.org Subject: Proposed Vote Resolution Issue 3972 Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-427817617-1650185928-979799441=:21162" X-UIDL: 79&e9](N!!"9Yd9R00e9 Attached is a proposed vote resolution for: Issue 3972: Format of GSSUP GSS exported name object undefined Basically it defines OIDs in string form in the CSI Module, and registers a new one for a flat string name. 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 [] FTF-Issue3972.html Date: Wed, 17 Jan 2001 07:53:30 -0500 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Ron Monzillo CC: csiv2-ftf@omg.org Subject: Re: [Fwd: GSSUP related issues] References: <3A64DADB.E61E5FA@east.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: eISd9=o+e9U60e9Cj6e9 Ron Monzillo wrote: > ... ... > A. access a non-GSSAPI username password authentication mechanism from > a communications protocol using GSSUP as a GSSAPI mechanism. > > B. do username password authentication where the target GSSAPI > authentication mechanism does not support username-password > authentication via its ICT. > > C. establish a GSSAPI mechanism specific authentication identity (an > exported name) as the result of either A. or B. ... ... > > Approach 2: > > Alternatively, we could use the target_name OID to establish and --- there may not be just one target_name. > interpret the form of the name sent and received in a GSSUP ICT. > Mechanism specific (as defined by the target_name OID's) flat name > strings obtained from the user would be sent in name_scope and > name_value. > > The inner contents of the GSSUP ICT would be as follows (preceded by > the > GSSUP OID. > > struct ScopedName { > NameValue name_scope; > NameValue name_value; > }; > > struct InitialContextToken { > ScopedName username; > UTF8String password; > }; I forgot that if we plan to use GSSUP as a pseudo-mechanism, we must pass two OID's in the GSSUP ICT. This is because the target may > support more than one GSSUP AS_ContextSec mechanism, each with a different mechanism OID in its target_name (both with client_authentication_mech > = GSSUP). The OID in the GSS_NT_ExportedName gives us the place to pass the second OID. So if we are going for reasons B and C, approach 2 is not useful and need not be considered further. ... X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 22 Jan 2001 10:18:01 -0500 (EST) From: Polar Humenn To: Ron Monzillo cc: csiv2-ftf@omg.org Subject: Re: [Fwd: GSSUP related issues] In-Reply-To: <3A6595CA.1B0F12BD@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: F;D!!]87e9aab!!S,M!! Ron, Just so I understand, am I correct in understanding your message below, without referring to all the Bs and Cs and bits of other messages, that you in favor of making the GSSUP Initial Context Token have the following format: struct InitialContextToken { CSI:GSS_NT_ExportedName username; CSI::UTF8String password; }; Cheers, -Polar On Wed, 17 Jan 2001, Ron Monzillo wrote: > Ron Monzillo wrote: > > > ... > > ... > > A. access a non-GSSAPI username password authentication mechanism from > > a communications protocol using GSSUP as a GSSAPI mechanism. > > > > B. do username password authentication where the target GSSAPI > > authentication mechanism does not support username-password > > authentication via its ICT. > > > > C. establish a GSSAPI mechanism specific authentication identity (an > > exported name) as the result of either A. or B. > ... > > ... > > > > Approach 2: > > > > Alternatively, we could use the target_name OID to establish and > --- > there may not be just one target_name. > > > interpret the form of the name sent and received in a GSSUP ICT. > > Mechanism specific (as defined by the target_name OID's) flat name > > strings obtained from the user would be sent in name_scope and > > name_value. > > > > The inner contents of the GSSUP ICT would be as follows (preceded by the > > GSSUP OID. > > > > struct ScopedName { > > NameValue name_scope; > > NameValue name_value; > > }; > > > > struct InitialContextToken { > > ScopedName username; > > UTF8String password; > > }; > I forgot that if we plan to use GSSUP as a pseudo-mechanism, we must > pass two OID's in the GSSUP ICT. This is because the target may support > more than one GSSUP AS_ContextSec mechanism, each with a different > mechanism OID in its target_name (both with client_authentication_mech = > GSSUP). The OID in the GSS_NT_ExportedName gives us the place to pass > the second OID. > > So if we are going for reasons B and C, approach 2 is not useful and > need not be considered further. > > > ... > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Mon, 22 Jan 2001 11:42:32 -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 , csiv2-ftf@omg.org Subject: Re: [Fwd: GSSUP related issues] References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: R?fd9)\f!!Td_!!njgd9 No, you should not infer that. I like some of the motivation for doing as you say, while at the same time I think it creates some problems, which I need to think about a little more. I will respond with specifics later today. Ron Polar Humenn wrote: > > Ron, > > Just so I understand, am I correct in understanding your message below, > without referring to all the Bs and Cs and bits of other messages, that > you in favor of making the GSSUP Initial Context Token have the following > format: > > struct InitialContextToken { > CSI:GSS_NT_ExportedName username; > CSI::UTF8String password; > }; > > Cheers, > -Polar > > On Wed, 17 Jan 2001, Ron Monzillo wrote: > > > Ron Monzillo wrote: > > > > > ... > > > > ... > > > A. access a non-GSSAPI username password authentication mechanism from > > > a communications protocol using GSSUP as a GSSAPI mechanism. > > > > > > B. do username password authentication where the target GSSAPI > > > authentication mechanism does not support username-password > > > authentication via its ICT. > > > > > > C. establish a GSSAPI mechanism specific authentication identity (an > > > exported name) as the result of either A. or B. > > ... > > > > ... > > > > > > Approach 2: > > > > > > Alternatively, we could use the target_name OID to establish and > > --- > > there may not be just one target_name. > > > > > interpret the form of the name sent and received in a GSSUP ICT. > > > Mechanism specific (as defined by the target_name OID's) flat name > > > strings obtained from the user would be sent in name_scope and > > > name_value. > > > > > > The inner contents of the GSSUP ICT would be as follows (preceded by the > > > GSSUP OID. > > > > > > struct ScopedName { > > > NameValue name_scope; > > > NameValue name_value; > > > }; > > > > > > struct InitialContextToken { > > > ScopedName username; > > > UTF8String password; > > > }; > > I forgot that if we plan to use GSSUP as a pseudo-mechanism, we must > > pass two OID's in the GSSUP ICT. This is because the target may support > > more than one GSSUP AS_ContextSec mechanism, each with a different > > mechanism OID in its target_name (both with client_authentication_mech = > > GSSUP). The OID in the GSS_NT_ExportedName gives us the place to pass > > the second OID. > > > > So if we are going for reasons B and C, approach 2 is not useful and > > need not be considered further. > > > > > > ... > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com Date: Mon, 22 Jan 2001 19:22:46 -0500 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: [Fwd: GSSUP related issues] References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: mY[!!(lN!!P$c!!^O2e9 I patched two messages together, because despite the pain that looking at the requirements may cause, I'd like to keep track of them. I'll try to be brief in my comments. Ron Monzillo wrote: > No, you should not infer that. I like some of the motivation for > doing as you say, while at the same time I think it creates some > problems, which I need to think about a little more. > > I will respond with specifics later today. > > Ron > Polar Humenn wrote: > > > > Ron, > > > > Just so I understand, am I correct in understanding your message > below, > > without referring to all the Bs and Cs and bits of other messages, > that > > you in favor of making the GSSUP Initial Context Token have the > following > > format: > > > > struct InitialContextToken { > > CSI:GSS_NT_ExportedName username; > > CSI::UTF8String password; > > }; > > > > Cheers, > > -Polar Polar Humenn wrote: > > Ron, > > First of all let me say that I'm a bit confused over the > requirements/reasons you give for the need of GSSUP. See below. > > On Thu, 18 Jan 2001, Ron Monzillo wrote: > > > David, > > > > As noted in my last msg on this subject, approach 2, should not > > be considered further in any effort to satisfy POTENTIAL reasons > > C with B (as repeated below) for wanting to use GSSUP. > > > > > A. access a non-GSSAPI username password authentication mechanism from > > > a communications protocol using GSSUP as a GSSAPI mechanism. > > I don't understand this "access a non-GSSAPI" username password > autthencation mechanism. We have created one, it's called GSSUP, it DOES > username/password, it is GSS-API. GSSUP can be used to send usernames and passwords to an existing authentication mechanism/user database that (prior to GSSUP) did not support remote authentication via GSSAPI. > > > > B. do username password authentication where the target GSSAPI > > > authentication mechanism does not support username-password > > > authentication via its ICT. > > I don't understand why you need to do username/password authentication > where the target doesn't support it. I'm really a little lost on this one. > But I really don't want to get into pedantic discussions ad nausem. > because you want a light-weight way to authenticate an identity (such as a K5 principal) whose corresponding GSSAPI mechanism (that is K5) may require more (than GSSUP) client infrastructure or a more sophisticated client configuration than can be imposed on your clients. > > > C. establish a GSSAPI mechanism specific authentication identity (an > > > exported name) as the result of either A. or B. > > The establishment of this GSSUP mechanism that has as its username > component a GSS Exported Name would be extremely benefical and simple. > > The following scenario applies: > > Client ---- GSSUP Token containing -----> Intermediate > GSS_NT_ExportedName > > Intermediate works on behalf of Client. > > Intermediate --->> Identity Token containing ----> Target > GSS_NT_ExportedName > > Target supports the particular naming type. This name is lifted directly > from Client's GSSUP Token, quite possibly without the security service > even looking inside of it. (The security service can merely hand the > username/password combo to a password validation service), okay, then move > on. Amazingly Simple. No hoops to jump through. > I'll talk about hoops later. But for now, I' like to say that there is another potential reason for what I call using GSSUP as a pseudo mechanism, that I'll call reason B2. That is, sometimes we want to send a username password to an intermediate, so that we can create an Initial Login Context, that we can then use either via an assertion, or directly in CAT tokens. The reasons for doing this are not really different then those listed for B. > Using the GSS_NT_ExportedName makes for a clean implemenation and is > consistent with the naming issues of the rest of the spec. Added > benefit, > it gives flexibility that allows most any name form to be used, such > as a > DN, even a KerberosName, or a simple "flat" string name, a > certificate, > etc. > > I have taken to promoting this type of solution in: > > ftp://greene.case.syr.edu/pub/omg/csiv2-ftf/FTF-Issue3922.html > > of which I highly recommend. > ... ... > > > > (C)establish (i.e authenticate) a GSSAPI mechanism specific > > authentication identity (an exported name) where (B) the target > GSSAPI > > authentication mechanism does not support username-password > > authentication via its ICT. > > I still don't understand this. GSSUP sends two pieces of data. A > name, and > a password. We are not talking about anything else but GSSUP, and > that is > username/password. I don't really care as if the target calls > "kinit" with > the information, it's still username/password. > this is an example of what I call reason B (or using GSSUP as a pseudo mechanism), and the extra (that is in addition to GSSUP) thing we are talking about is (in your example) the fact that there is an existing kerberos GSSAPI mechanism with a corresponding exported name form. If we want to use GSSUP as a pseudo-mechanism, then I agree that we need an internal mechanism OID in the GSSUP ICT. However, doing so by requiring a client side ability to export the corresponding mechanism specific name form just moves the hoop to the client, which requires that a client have mechanism specific name exporting code in order to use GSSUP with another mechanism (such as kerberos). I admit that the scenario you propose for asserting through an intermediate is interesting, but I think you are worrying about the wrong hoops. 1. The intermediate better jump though the hoop of making sure that the exported name proposed by the client is the same one that is proven by authentication, otherwise it might not be passing the proper identity forward. In a kerberos environment, let's say the client is not configured as a kerberos client, and does not know the realm of the intermediate. It fabricates a kerberos exported name containing the username as principal) without realm. The intermediate authenticates the principal, in the default realm. The principal that gets sent forward (by the intermediate) should not be the one sent by the client, but the realm annotated one that was authenticated by the mechanism at the intermediate. I think the intermediate should call accept_context, and then export from the accepted context if it wants to assert forward. All GSSAPI/CAT mechanisms should work like this, not just GSSUP. In addition to assertion, the intermediate should also be able to fabricate a mechanism specific ICT (i.e. a k5 ICT) to support the B2 scenario identified above. Note that we don't want them to be able to do this for GSSUP (without an internal mechanism). 2. Making the client pass mechanism specific exported name forms in its GSSUP authenticators imposes a requirement on the client to have mechanism specific code to create specific exported forms. It also constrains the use of GSSUP by a client only to those mechanisms for which it has exported name support. I would prefer that the GSSUP ICT look as follows: struct InitialContextToken { UTF8String username; UTF8String password; GSS_NT_exported_name target_name; }; The target_name would be as specified in the target IOR of the mechanism being responded to by the client. The target_name field is optional in the IOR. If there is a target_name in the IOR it at least contains an OID that identifies a GSSAPI mechanism. The client would not have to understand these internal OIDs. The string following the OID, if present, would be presented to the user, as a cue for the scope in which it must provide a username and password. In the simple GSSUP use case, if a target_name is specified it will contain the GSSUP OID. In the pseudo mechanism case, it will carry an internal mechanism OID (e.g. KRB5). In either case, the value in this field would be directly taken by the client from the IOR, and used to identify the mechanism definition being responded to by the client. The TSS would use the received target_name to identify the AScontext, and the resulting client authentication name form (as a GSS exported name). In the simple use case, no, other that GSSUP OID, internal mechanism OID would appear in the mechanism selected by the client from the IOR or the ICT fabricated by the client. In this case, the resulting client identity (suitable for assertion) would be something like that originally defined when this issue was opened. That is, the username separated by an '@' from the GSSUP authentication scope of the target (with appropriate byte stuffing to accommodate any embedded '@'s in the the username). I think this proposal supports the identified scenarios without imposing any additional requirements for name support on the originating client. It does define a new catchall exported name form for GSSUP (identity assertions and a name form to be understood by users). I considered using the username name form defined by kerberos and included in section 2.2.1 of RFC 2473 as the catchall exported name form, but I think it better to be able to carry a notion of scope forward which the username form does not provide for (as it is intended to identify a user on a local system). So, I would like to resolve issues 3922 and 3972 differently than the poposals that you have made. I need to go home now. Ron > > using GSSUP with an inner context token containing a kerberos (esported) > > principal name, and password would be an example of this use case. > > Huh????? That is username password. If you are talking about sending a > kerberos ticket, that is a different mechanism than GSSUP, and works quite > nicely, I might add. > > Cheers, > -Polar > > > > > Ron > > > > Polar Humenn wrote: > > > > > > On Wed, 17 Jan 2001, David Chang wrote: > > > > > > > Ron, > > > > > > > > Does the Approach 2 use the format of the username in the > > > > InitilaContextToken to distinguish to the mechanism type instead of the > > > > mechanism OID? > > > > > > > > struct InitialContextToken { > > > > UTF8String username; // for GSSUP username | username@scope > > > > UTF8String password; > > > > }; > > > > > > > > Please clarify. > > > > > > I would think not. Also, in this case the username cannot be a DN, it must > > > be a flat name with no designation of type of name. Of course it could > > > always be a string version of a DN, but you wouldn't know it. I still > > > think the GSS_NT_ExportName would be the better option. > > > > > > Cheers, > > > -Polar > > > > > > > > > > > Thanks > > > > > > > > David Chang > > > > > > > > WebSphere Security Architect & Team Lead > > > > IBM SWS Division, Internal Mail Stop 9131 > > > > Austin, Tx 78758 > > > > E-Mail:dyc@us.ibm.com > > > > Phone:(512)838-0559, T/L 678-0559 > > > > Fax: (512)838-1032 > > > > > > > > > > > > Ron Monzillo on 01/16/2001 05:35:55 PM > > > > > > > > To: csiv2-ftf@omg.org > > > > cc: > > > > Subject: [Fwd: GSSUP related issues] > > > > > > > > > > > > > > > > > > > > Content-Transfer-Encoding: 7bit > > > > Content-Type: text/plain; charset=us-ascii > > > > > > > > I promised to start the discussion on the following issues > > > > > > > > Issue 3948: GSSUP names are incompatible with the Identity Token > > > > Issue 3972: Format of GSSUP GSS exported name object undefined > > > > > > > > The crux of these issues is really whether or not GSSUP should be > > > > considered a full-fledged GSSAPI mechanism or a "pseudo-mechanism". > > > > > > > > The solution proposed to issue 3948 is that GSSUP be treated as a > > > > pseudo- mechanism. According to this proposal, the GSSUP Initial Context > > > > Token (ICT) would be modified to carry a mechanism (i.e. kereberos, > > > > unix,..) specific GSS exported name. The implication of the proposal is > > > > that there would not be an exported name form for the GSSUP mechanism. > > > > > > > > The solution proposed to issue 3972 is to define the exported name form > > > > of the GSSUP mechanism, such that it in addition to the existing > > > > definition of the GSSUP ICT, we will also have defined an exported name > > > > form to be used in GSSUP Identity Assertions. > > > > > > > > These two issues have a different focus, and thus different proposals > > > > have been made. In general the respective proposals may be summarized as > > > > follows: > > > > > > > > 3948. GSSUP as a pseudo mechanism would be used to authenticate GSSAPI > > > > identities of other types (i.e. Kerberos, unix). > > > > > > > > 3972. GSSUP as a full-fledged mechanism would be used to authenticate > > > > full-fledged GSSUP (realm/scope specific) identities. > > > > > > > > We wrote the submission with our intent being focused on something like > > > > that proposed in 3972. It is also clear that this approach was not > > > > completed in the submission, as we neglected to define a GSSUP exported > > > > name form. > > > > > > > > The proposed solution to 3948 would attempt to more tightly integerate > > > > the GSSUP mechanism with security mechanisms for which there is at least > > > > a defined GSSAPI exported name form. We would presumably do this to be > > > > able to use GSSUP to > > > > > > > > A. access a non-GSSAPI username password authentication mechanism from > > > > a communications protocol using GSSUP as a GSSAPI mechanism. > > > > > > > > B. do username password authentication where the target GSSAPI > > > > authentication mechanism does not support username-password > > > > authentication via its ICT. > > > > > > > > C. establish a GSSAPI mechanism specific authentication identity (an > > > > exported name) as the result of either A. or B. > > > > > > > > We created GSSUP for reason A. The Proposed solution to 3972 only > > > > addresses reason A. The proposed solution to 3948 addresses reasons B > > > > and C, in that it limits the use of GSSUP to those mechanisms for which > > > > there is a defined exported name form. > > > > > > > > The proposed solution to 3972 (the definition of a GSSUP exported name > > > > form) insures that reason A, can be satisfied in all contexts. > > > > > > > > The proposed solution to 3972 also ensures that we need not add (to > > > > conformance level 0) any requirement to support additional GSSAPI > > > > mechanisms (that is, their name formats). > > > > > > > > If we begin with the proposed resolution of 3972 as a baseline, then we > > > > can determine if we want to extend the semantics of the GSSUP mechanism > > > > to satisfy reasons B and C, in which case, we might blend the solution > > > > of 3972 and 3948. > > > > > > > > Approach 1: > > > > > > > > That is, the GSSUP ICT Name and Scope could be replaced by a mechanism > > > > specific exported name form of type corresponding to the OID of the > > > > target_name in the AS_ContextSec structure. GSSUP itself would be a > > > > legitimate value for the type OID in the target_name. > > > > > > > > The inner contents of the GSSUP ICT would be as follows (preceded by the > > > > GSSUP OID). > > > > > > > > struct InitialContextToken { > > > > GSS_NT_exported_name username; > > > > UTF8String password; > > > > }; > > > > > > > > Approach 2: > > > > > > > > Alternatively, we could use the target_name OID to establish and > > > > interpret the form of the name sent and received in a GSSUP ICT. > > > > Mechanism specific (as defined by the target_name OID's) flat name > > > > strings obtained from the user would be sent in name_scope and > > > > name_value. > > > > > > > > The inner contents of the GSSUP ICT would be as follows (preceded by the > > > > GSSUP OID. > > > > > > > > struct ScopedName { > > > > NameValue name_scope; > > > > NameValue name_value; > > > > }; > > > > > > > > struct InitialContextToken { > > > > ScopedName username; > > > > UTF8String password; > > > > }; > > > > > > > > So to reiterate, if we begin with the proposed resolution to 3972 (that > > > > is the definition of a GSSUP exported name form), and then decide > > > > whether we want to acknowledge reasons B, or C, (that is resolve issue > > > > 3948), then I think either of the approaches listed above are workable. > > > > > > > > Approach 1's inclusion of the name defining mechanism OID in the GSSUP > > > > ICT, and the fact that most if not all translations from user > > > > presentation forms to flat name forms could be done at data collection, > > > > argue in its favor. The extra overhead of sending a second/internal OID > > > > for GSSUP ICT's, and the complexity of the ICT with embedded ASN.1 > > > > exported name would argue against approach 1, especially if we are not > > > > seeking to address B or C. > > > > > > > > If we are more inclined towards approach 2, then a simplification could > > > > be made by removing name_scope and using the mechanism specific flat > > > > name encoding as the username. > > > > > > > > struct InitialContextToken { > > > > UTF8String username; // for GSSUP username | username@scope > > > > UTF8String password; > > > > }; > > > > > > > > > > > > Ron > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > Polar Humenn Adiron, LLC > > > mailto:polar@adiron.com 2-212 CST > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > Fax: 315-443-4745 http://www.adiron.com > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 23 Jan 2001 13:11:52 -0500 (EST) From: Polar Humenn To: Ron Monzillo cc: csiv2-ftf@omg.org Subject: Re: [Fwd: GSSUP related issues] In-Reply-To: <3A6CCED6.A621AF69@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: UW&e9M:D!!W4Y!!:^@e9 Ron, I am only going to address your points in a general fashion. If this is the GSSUP initial token you propose: struct InitialContextToken { UTF8String username; UTF8String password; GSS_NT_exported_name target_name; }; I can live with that. In most cases, a user/password scheme is definitely an interactive thing requiring typing, so strings are okay, especially if you want to use this to handle "embody" a target with your identity, for a particular authentication scheme, such as Kerberos, SASL, and other various yet unknown mechanisms. The part that worries me is that there is a distinct mapping from the name type OID in the target name to the OID of the mechanism that will be used. But we just must have to bite the bullet on that and make it so. For Kerberos, it will work. I'll agree with this form, because all these mechanisms should have some canonical version of the name. So, I think you are getting at the following scenario: GSSUP Token ---target_name---\ | find mech | \ -------------- ---> | Auth Mech | | | ---username ------------>| | ---password ------------>| | --------------- | GSS_ExportName() | \/ GSS_NT_ExportedName For example: (oid:1.2.840.113554.1.2.2) is KerberosV5. The GSSUP Token: struct InitialContextToken { username = polar password = xxxxxx target_name = {oid:1.2.840.113554.1.2.2,host/m1.adiron.com@ADIRON.COM} } Should generate, after successfully applied to "kinit" a GSS_NT_ExportName of: {oid:1.2.840.113554.1.2.2,polar@ADIRON.COM} which can be used in an Identity Assertion further on down the line. We do need a name type for other authentication mechanisms that may not be defined, as needed. I can see two immediate needs. "Unix" or an NIS name. I'm not really sure what these names would look like in an GSS_NT_ExportedName format (i.e. sometimes the hostname or domain name is useful, but not necessary). However we should define one for use with that mechanism, or start an RFP for it. Other ones, would be user defined, of which I came up with a name type for StringName. I think in a letter you didn't like that, but I haven't investigated why. The basic upshot is that I like this approach, as long as each OID used has an Exported Name format that can be asserted in an Identity Token, or otherwise, it doesn't really do much good. Cheers, -Polar On Mon, 22 Jan 2001, Ron Monzillo wrote: > I patched two messages together, because despite the pain that > looking at the requirements may cause, I'd like to keep track of > them. > > I'll try to be brief in my comments. > > Ron Monzillo wrote: > > > No, you should not infer that. I like some of the motivation for > > doing as you say, while at the same time I think it creates some > > problems, which I need to think about a little more. > > > > I will respond with specifics later today. > > > > Ron > > Polar Humenn wrote: > > > > > > Ron, > > > > > > Just so I understand, am I correct in understanding your message > below, > > > without referring to all the Bs and Cs and bits of other > messages, that > > > you in favor of making the GSSUP Initial Context Token have the > following > > > format: > > > > > > struct InitialContextToken { > > > CSI:GSS_NT_ExportedName username; > > > CSI::UTF8String password; > > > }; > > > > > > Cheers, > > > -Polar > > Polar Humenn wrote: > > > > Ron, > > > > First of all let me say that I'm a bit confused over the > > requirements/reasons you give for the need of GSSUP. See below. > > > > On Thu, 18 Jan 2001, Ron Monzillo wrote: > > > > > David, > > > > > > As noted in my last msg on this subject, approach 2, should not > > > be considered further in any effort to satisfy POTENTIAL reasons > > > C with B (as repeated below) for wanting to use GSSUP. > > > > > > > A. access a non-GSSAPI username password authentication > mechanism from > > > > a communications protocol using GSSUP as a GSSAPI > mechanism. > > > > I don't understand this "access a non-GSSAPI" username password > > autthencation mechanism. We have created one, it's called GSSUP, > it DOES > > username/password, it is GSS-API. > > GSSUP can be used to send usernames and passwords to an > existing authentication mechanism/user database that (prior to > GSSUP) > did not support remote authentication via GSSAPI. > > > > > > > B. do username password authentication where the target GSSAPI > > > > authentication mechanism does not support username-password > > > > authentication via its ICT. > > > > I don't understand why you need to do username/password > authentication > > where the target doesn't support it. I'm really a little lost on > this one. > > But I really don't want to get into pedantic discussions ad > nausem. > > > > because you want a light-weight way to authenticate an identity > (such as > a K5 principal) whose corresponding GSSAPI mechanism (that is K5) > may > require more (than GSSUP) client infrastructure or a more > sophisticated > client configuration than can be imposed on your clients. > > > > C. establish a GSSAPI mechanism specific authentication > identity (an > > > > exported name) as the result of either A. or B. > > > > The establishment of this GSSUP mechanism that has as its username > > component a GSS Exported Name would be extremely benefical and > simple. > > > > The following scenario applies: > > > > Client ---- GSSUP Token containing -----> Intermediate > > GSS_NT_ExportedName > > > > Intermediate works on behalf of Client. > > > > Intermediate --->> Identity Token containing ----> Target > > GSS_NT_ExportedName > > > > Target supports the particular naming type. This name is lifted > directly > > from Client's GSSUP Token, quite possibly without the security > service > > even looking inside of it. (The security service can merely hand > the > > username/password combo to a password validation service), okay, > then move > > on. Amazingly Simple. No hoops to jump through. > > > > I'll talk about hoops later. But for now, I' like to say that there > is > another potential reason for what I call using GSSUP as a pseudo > mechanism, > that I'll call reason B2. That is, sometimes we want to send a > username > password to an intermediate, so that we can create an Initial Login > Context, that we can then use either via an assertion, or directly > in > CAT tokens. The reasons for doing this are not really different then > those listed for B. > > > Using the GSS_NT_ExportedName makes for a clean implemenation and > is > > consistent with the naming issues of the rest of the spec. Added > benefit, > > it gives flexibility that allows most any name form to be used, > such as a > > DN, even a KerberosName, or a simple "flat" string name, a > certificate, > > etc. > > > > I have taken to promoting this type of solution in: > > > > ftp://greene.case.syr.edu/pub/omg/csiv2-ftf/FTF-Issue3922.html > > > > of which I highly recommend. > > > ... > > ... > > > > > > (C)establish (i.e authenticate) a GSSAPI mechanism specific > > > authentication identity (an exported name) where (B) the target > GSSAPI > > > authentication mechanism does not support username-password > > > authentication via its ICT. > > > > I still don't understand this. GSSUP sends two pieces of data. A > name, and > > a password. We are not talking about anything else but GSSUP, and > that is > > username/password. I don't really care as if the target calls > "kinit" with > > the information, it's still username/password. > > > > this is an example of what I call reason B (or using GSSUP as a > pseudo > mechanism), and the extra (that is in addition to GSSUP) thing we > are > talking about is (in your example) the fact that there is an > existing > kerberos GSSAPI mechanism with a corresponding exported name form. > > If we want to use GSSUP as a pseudo-mechanism, then I agree that we > need an internal mechanism OID in the GSSUP ICT. However, doing so > by > requiring a client side ability to export the corresponding > mechanism > specific name form just moves the hoop to the client, which requires > that a client have mechanism specific name exporting code in order > to > use GSSUP with another mechanism (such as kerberos). > > I admit that the scenario you propose for asserting through an > intermediate is interesting, but I think you are worrying about the > wrong hoops. > > 1. The intermediate better jump though the hoop of making sure that > the > exported name proposed by the client is the same one that is proven > by > authentication, otherwise it might not be passing the proper > identity > forward. In a kerberos environment, let's say the client is not > configured as a kerberos client, and does not know the realm of the > intermediate. It > fabricates a kerberos exported name containing the username as > principal) without realm. The intermediate authenticates the > principal, > in the default realm. The principal that gets sent forward (by the > intermediate) should not be the one sent by the client, but the > realm > annotated one that was authenticated by the mechanism at the > intermediate. > > I think the intermediate should call accept_context, and then export > from the accepted context if it wants to assert forward. All > GSSAPI/CAT > mechanisms should work like this, not just GSSUP. > > In addition to assertion, the intermediate should also be able to > fabricate a mechanism specific ICT (i.e. a k5 ICT) to support the B2 > scenario identified above. Note that we don't want them to be able > to do > this for GSSUP (without an internal mechanism). > > 2. Making the client pass mechanism specific exported name forms in > its > GSSUP authenticators imposes a requirement on the client to have > mechanism specific code to create specific exported forms. It also > constrains the use of GSSUP by a client only to those mechanisms for > which it has exported name support. > > I would prefer that the GSSUP ICT look as follows: > > struct InitialContextToken { > UTF8String username; > UTF8String password; > GSS_NT_exported_name target_name; > }; > > The target_name would be as specified in the target IOR of the > mechanism > being responded to by the client. The target_name field is optional > in > the IOR. If there is a target_name in the IOR it at least contains > an > OID > that identifies a GSSAPI mechanism. The client would not have to > understand these internal OIDs. The string following the OID, if > present, would be presented to the user, as a cue for the scope in > which > it must provide a username and password. In the simple GSSUP use > case, > if a target_name is specified it will contain the GSSUP OID. In the > pseudo mechanism case, it will carry an internal mechanism OID (e.g. > KRB5). In either case, the value in this field would be directly > taken > by the client from the IOR, and used to identify the mechanism > definition being responded to by the client. > > The TSS would use the received target_name to identify the > AScontext, > and the resulting client authentication name form (as a GSS exported > name). > > In the simple use case, no, other that GSSUP OID, internal mechanism > OID would appear in the mechanism selected by the client from the > IOR > or the ICT fabricated by the client. In this case, the resulting > client > identity (suitable for assertion) would be something like that > originally > defined when this issue was opened. That is, the username separated > by > an '@' from the GSSUP authentication scope of the target (with > appropriate byte stuffing to accommodate any embedded '@'s in the > the > username). > > I think this proposal supports the identified scenarios without > imposing > any additional requirements for name support on the originating > client. > It does define a new catchall exported name form for GSSUP (identity > assertions and a name form to be understood by users). > > I considered using the username name form defined by kerberos and > included in section 2.2.1 of RFC 2473 as the catchall exported name > form, but I think it better to be able to carry a notion of scope > forward which the username form does not provide for (as it is > intended > to identify a user on a local system). > > So, I would like to resolve issues 3922 and 3972 differently than > the > poposals that you have made. > > I need to go home now. > > Ron > > > > using GSSUP with an inner context token containing a kerberos > (esported) > > > principal name, and password would be an example of this use > case. > > > > Huh????? That is username password. If you are talking about > sending a > > kerberos ticket, that is a different mechanism than GSSUP, and > works quite > > nicely, I might add. > > > > Cheers, > > -Polar > > > > > > > > Ron > > > > > > Polar Humenn wrote: > > > > > > > > On Wed, 17 Jan 2001, David Chang wrote: > > > > > > > > > Ron, > > > > > > > > > > Does the Approach 2 use the format of the username in the > > > > > InitilaContextToken to distinguish to the mechanism type > instead of the > > > > > mechanism OID? > > > > > > > > > > struct InitialContextToken { > > > > > UTF8String username; // for GSSUP username | > username@scope > > > > > UTF8String password; > > > > > }; > > > > > > > > > > Please clarify. > > > > > > > > I would think not. Also, in this case the username cannot be a > DN, it must > > > > be a flat name with no designation of type of name. Of course > it could > > > > always be a string version of a DN, but you wouldn't know > it. I still > > > > think the GSS_NT_ExportName would be the better option. > > > > > > > > Cheers, > > > > -Polar > > > > > > > > > > > > > > Thanks > > > > > > > > > > David Chang > > > > > > > > > > WebSphere Security Architect & Team Lead > > > > > IBM SWS Division, Internal Mail Stop 9131 > > > > > Austin, Tx 78758 > > > > > E-Mail:dyc@us.ibm.com > > > > > Phone:(512)838-0559, T/L 678-0559 > > > > > Fax: (512)838-1032 > > > > > > > > > > > > > > > Ron Monzillo on 01/16/2001 > 05:35:55 PM > > > > > > > > > > To: csiv2-ftf@omg.org > > > > > cc: > > > > > Subject: [Fwd: GSSUP related issues] > > > > > > > > > > > > > > > > > > > > > > > > > Content-Transfer-Encoding: 7bit > > > > > Content-Type: text/plain; charset=us-ascii > > > > > > > > > > I promised to start the discussion on the following issues > > > > > > > > > > Issue 3948: GSSUP names are incompatible with the Identity > Token > > > > > Issue 3972: Format of GSSUP GSS exported name object > undefined > > > > > > > > > > The crux of these issues is really whether or not GSSUP > should be > > > > > considered a full-fledged GSSAPI mechanism or a > "pseudo-mechanism". > > > > > > > > > > The solution proposed to issue 3948 is that GSSUP be treated > as a > > > > > pseudo- mechanism. According to this proposal, the GSSUP > Initial Context > > > > > Token (ICT) would be modified to carry a mechanism > (i.e. kereberos, > > > > > unix,..) specific GSS exported name. The implication of the > proposal is > > > > > that there would not be an exported name form for the GSSUP > mechanism. > > > > > > > > > > The solution proposed to issue 3972 is to define the > exported name form > > > > > of the GSSUP mechanism, such that it in addition to the > existing > > > > > definition of the GSSUP ICT, we will also have defined an > exported name > > > > > form to be used in GSSUP Identity Assertions. > > > > > > > > > > These two issues have a different focus, and thus different > proposals > > > > > have been made. In general the respective proposals may be > summarized as > > > > > follows: > > > > > > > > > > 3948. GSSUP as a pseudo mechanism would be used to > authenticate GSSAPI > > > > > identities of other types (i.e. Kerberos, unix). > > > > > > > > > > 3972. GSSUP as a full-fledged mechanism would be used to > authenticate > > > > > full-fledged GSSUP (realm/scope specific) identities. > > > > > > > > > > We wrote the submission with our intent being focused on > something like > > > > > that proposed in 3972. It is also clear that this approach > was not > > > > > completed in the submission, as we neglected to define a > GSSUP exported > > > > > name form. > > > > > > > > > > The proposed solution to 3948 would attempt to more tightly > integerate > > > > > the GSSUP mechanism with security mechanisms for which there > is at least > > > > > a defined GSSAPI exported name form. We would presumably do > this to be > > > > > able to use GSSUP to > > > > > > > > > > A. access a non-GSSAPI username password authentication > mechanism from > > > > > a communications protocol using GSSUP as a GSSAPI > mechanism. > > > > > > > > > > B. do username password authentication where the target > GSSAPI > > > > > authentication mechanism does not support > username-password > > > > > authentication via its ICT. > > > > > > > > > > C. establish a GSSAPI mechanism specific authentication > identity (an > > > > > exported name) as the result of either A. or B. > > > > > > > > > > We created GSSUP for reason A. The Proposed solution to 3972 > only > > > > > addresses reason A. The proposed solution to 3948 addresses > reasons B > > > > > and C, in that it limits the use of GSSUP to those > mechanisms for which > > > > > there is a defined exported name form. > > > > > > > > > > The proposed solution to 3972 (the definition of a GSSUP > exported name > > > > > form) insures that reason A, can be satisfied in all > contexts. > > > > > > > > > > The proposed solution to 3972 also ensures that we need not > add (to > > > > > conformance level 0) any requirement to support additional > GSSAPI > > > > > mechanisms (that is, their name formats). > > > > > > > > > > If we begin with the proposed resolution of 3972 as a > baseline, then we > > > > > can determine if we want to extend the semantics of the > GSSUP mechanism > > > > > to satisfy reasons B and C, in which case, we might blend > the solution > > > > > of 3972 and 3948. > > > > > > > > > > Approach 1: > > > > > > > > > > That is, the GSSUP ICT Name and Scope could be replaced by a > mechanism > > > > > specific exported name form of type corresponding to the OID > of the > > > > > target_name in the AS_ContextSec structure. GSSUP itself > would be a > > > > > legitimate value for the type OID in the target_name. > > > > > > > > > > The inner contents of the GSSUP ICT would be as follows > (preceded by the > > > > > GSSUP OID). > > > > > > > > > > struct InitialContextToken { > > > > > GSS_NT_exported_name username; > > > > > UTF8String password; > > > > > }; > > > > > > > > > > Approach 2: > > > > > > > > > > Alternatively, we could use the target_name OID to establish > and > > > > > interpret the form of the name sent and received in a GSSUP > ICT. > > > > > Mechanism specific (as defined by the target_name OID's) > flat name > > > > > strings obtained from the user would be sent in name_scope > and > > > > > name_value. > > > > > > > > > > The inner contents of the GSSUP ICT would be as follows > (preceded by the > > > > > GSSUP OID. > > > > > > > > > > struct ScopedName { > > > > > NameValue name_scope; > > > > > NameValue name_value; > > > > > }; > > > > > > > > > > struct InitialContextToken { > > > > > ScopedName username; > > > > > UTF8String password; > > > > > }; > > > > > > > > > > So to reiterate, if we begin with the proposed resolution to > 3972 (that > > > > > is the definition of a GSSUP exported name form), and then > decide > > > > > whether we want to acknowledge reasons B, or C, (that is > resolve issue > > > > > 3948), then I think either of the approaches listed above > are workable. > > > > > > > > > > Approach 1's inclusion of the name defining mechanism OID in > the GSSUP > > > > > ICT, and the fact that most if not all translations from > user > > > > > presentation forms to flat name forms could be done at data > collection, > > > > > argue in its favor. The extra overhead of sending a > second/internal OID > > > > > for GSSUP ICT's, and the complexity of the ICT with embedded > ASN.1 > > > > > exported name would argue against approach 1, especially if > we are not > > > > > seeking to address B or C. > > > > > > > > > > If we are more inclined towards approach 2, then a > simplification could > > > > > be made by removing name_scope and using the mechanism > specific flat > > > > > name encoding as the username. > > > > > > > > > > struct InitialContextToken { > > > > > UTF8String username; // for GSSUP username | > username@scope > > > > X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 23 Jan 2001 14:37:52 -0500 (EST) From: Polar Humenn To: Ron Monzillo cc: csiv2-ftf@omg.org Subject: Re: [Fwd: GSSUP related issues] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: -Xdd9KQW!!88@!!YY,e9 Actually, now that I got the email back I find I have an error in my Kerberos example: (the target name was wrong, below I labeled a host, when I should have labeled the TGT service for the realm): I'll just post the corrected version here: The GSSUP Token: struct InitialContextToken { username = polar password = xxxxxx target_name = {oid:1.2.840.113554.1.2.2,krbtgt/ADIRON.COM@ADIRON.COM} } Should generate, after successfully applied to "kinit" a GSS_NT_ExportName of: {oid:1.2.840.113554.1.2.2,polar@ADIRON.COM} which can be used in an Identity Assertion further on down the line. Cheers, -Polar On Tue, 23 Jan 2001, Polar Humenn wrote: > > Ron, > > I am only going to address your points in a general fashion. > > If this is the GSSUP initial token you propose: > > struct InitialContextToken { > UTF8String username; > UTF8String password; > GSS_NT_exported_name target_name; > }; > > > I can live with that. In most cases, a user/password scheme is > definitely > an interactive thing requiring typing, so strings are okay, > especially if > you want to use this to handle "embody" a target with your identity, > for a > particular authentication scheme, such as Kerberos, SASL, and other > various yet unknown mechanisms. > > The part that worries me is that there is a distinct mapping from > the name > type OID in the target name to the OID of the mechanism that will be > used. > But we just must have to bite the bullet on that and make it so. > For Kerberos, it will work. > > I'll agree with this form, because all these mechanisms should have > some > canonical version of the name. So, I think you are getting at the > following scenario: > > GSSUP > Token ---target_name---\ > | > find mech > | > \ -------------- > ---> | Auth Mech | > | | > ---username ------------>| | > ---password ------------>| | > --------------- > | > GSS_ExportName() > | > \/ > GSS_NT_ExportedName > > > For example: (oid:1.2.840.113554.1.2.2) is KerberosV5. > > The GSSUP Token: > > struct InitialContextToken { > username = polar > password = xxxxxx > target_name = > {oid:1.2.840.113554.1.2.2,host/m1.adiron.com@ADIRON.COM} > } > > Should generate, after successfully applied to "kinit" a > GSS_NT_ExportName > of: > > {oid:1.2.840.113554.1.2.2,polar@ADIRON.COM} > > which can be used in an Identity Assertion further on down the line. > > We do need a name type for other authentication mechanisms that may > not be > defined, as needed. I can see two immediate needs. "Unix" or an NIS > name. > I'm not really sure what these names would look like in an > GSS_NT_ExportedName format (i.e. sometimes the hostname or domain > name is > useful, but not necessary). However we should define one for use > with > that mechanism, or start an RFP for it. > > Other ones, would be user defined, of which I came up with a name > type > for StringName. I think in a letter you didn't like that, but I > haven't > investigated why. > > The basic upshot is that I like this approach, as long as each OID > used > has an Exported Name format that can be asserted in an Identity > Token, or > otherwise, it doesn't really do much good. > > Cheers, > -Polar > > > > > On Mon, 22 Jan 2001, Ron Monzillo wrote: > > > I patched two messages together, because despite the pain that > > looking at the requirements may cause, I'd like to keep track of > them. > > > > I'll try to be brief in my comments. > > > > Ron Monzillo wrote: > > > > > No, you should not infer that. I like some of the motivation for > > > doing as you say, while at the same time I think it creates some > > > problems, which I need to think about a little more. > > > > > > I will respond with specifics later today. > > > > > > Ron > > > Polar Humenn wrote: > > > > > > > > Ron, > > > > > > > > Just so I understand, am I correct in understanding your > message below, > > > > without referring to all the Bs and Cs and bits of other > messages, that > > > > you in favor of making the GSSUP Initial Context Token have > the following > > > > format: > > > > > > > > struct InitialContextToken { > > > > CSI:GSS_NT_ExportedName username; > > > > CSI::UTF8String password; > > > > }; > > > > > > > > Cheers, > > > > -Polar > > > > Polar Humenn wrote: > > > > > > Ron, > > > > > > First of all let me say that I'm a bit confused over the > > > requirements/reasons you give for the need of GSSUP. See below. > > > > > > On Thu, 18 Jan 2001, Ron Monzillo wrote: > > > > > > > David, > > > > > > > > As noted in my last msg on this subject, approach 2, should > not > > > > be considered further in any effort to satisfy POTENTIAL > reasons > > > > C with B (as repeated below) for wanting to use GSSUP. > > > > > > > > > A. access a non-GSSAPI username password authentication > mechanism from > > > > > a communications protocol using GSSUP as a GSSAPI > mechanism. > > > > > > I don't understand this "access a non-GSSAPI" username password > > > autthencation mechanism. We have created one, it's called GSSUP, > it DOES > > > username/password, it is GSS-API. > > > > GSSUP can be used to send usernames and passwords to an > > existing authentication mechanism/user database that (prior to > GSSUP) > > did not support remote authentication via GSSAPI. > > > > > > > > > > B. do username password authentication where the target > GSSAPI > > > > > authentication mechanism does not support > username-password > > > > > authentication via its ICT. > > > > > > I don't understand why you need to do username/password > authentication > > > where the target doesn't support it. I'm really a little lost on > this one. > > > But I really don't want to get into pedantic discussions ad > nausem. > > > > > > > because you want a light-weight way to authenticate an identity > (such as > > a K5 principal) whose corresponding GSSAPI mechanism (that is K5) > may > > require more (than GSSUP) client infrastructure or a more > sophisticated > > client configuration than can be imposed on your clients. > > > > > C. establish a GSSAPI mechanism specific authentication > identity (an > > > > > exported name) as the result of either A. or B. > > > > > > The establishment of this GSSUP mechanism that has as its > username > > > component a GSS Exported Name would be extremely benefical and > simple. > > > > > > The following scenario applies: > > > > > > Client ---- GSSUP Token containing -----> Intermediate > > > GSS_NT_ExportedName > > > > > > Intermediate works on behalf of Client. > > > > > > Intermediate --->> Identity Token containing ----> Target > > > GSS_NT_ExportedName > > > > > > Target supports the particular naming type. This name is lifted > directly > > > from Client's GSSUP Token, quite possibly without the security > service > > > even looking inside of it. (The security service can merely hand > the > > > username/password combo to a password validation service), okay, > then move > > > on. Amazingly Simple. No hoops to jump through. > > > > > > > I'll talk about hoops later. But for now, I' like to say that > there is > > another potential reason for what I call using GSSUP as a pseudo > > mechanism, > > that I'll call reason B2. That is, sometimes we want to send a > username > > password to an intermediate, so that we can create an Initial > Login > > Context, that we can then use either via an assertion, or directly > in > > CAT tokens. The reasons for doing this are not really different > then > > those listed for B. > > > > > Using the GSS_NT_ExportedName makes for a clean implemenation > and is > > > consistent with the naming issues of the rest of the spec. Added > benefit, > > > it gives flexibility that allows most any name form to be used, > such as a > > > DN, even a KerberosName, or a simple "flat" string name, a > certificate, > > > etc. > > > > > > I have taken to promoting this type of solution in: > > > > > > > ftp://greene.case.syr.edu/pub/omg/csiv2-ftf/FTF-Issue3922.html > > > > > > of which I highly recommend. > > > > > ... > > > > ... > > > > > > > > (C)establish (i.e authenticate) a GSSAPI mechanism specific > > > > authentication identity (an exported name) where (B) the > target GSSAPI > > > > authentication mechanism does not support username-password > > > > authentication via its ICT. > > > > > > I still don't understand this. GSSUP sends two pieces of data. A > name, and > > > a password. We are not talking about anything else but GSSUP, > and that is > > > username/password. I don't really care as if the target calls > "kinit" with > > > the information, it's still username/password. > > > > > > > this is an example of what I call reason B (or using GSSUP as a > pseudo > > mechanism), and the extra (that is in addition to GSSUP) thing we > are > > talking about is (in your example) the fact that there is an > existing > > kerberos GSSAPI mechanism with a corresponding exported name form. > > > > If we want to use GSSUP as a pseudo-mechanism, then I agree that > we > > need an internal mechanism OID in the GSSUP ICT. However, doing so > by > > requiring a client side ability to export the corresponding > mechanism > > specific name form just moves the hoop to the client, which > requires > > that a client have mechanism specific name exporting code in order > to > > use GSSUP with another mechanism (such as kerberos). > > > > I admit that the scenario you propose for asserting through an > > intermediate is interesting, but I think you are worrying about > the > > wrong hoops. > > > > 1. The intermediate better jump though the hoop of making sure > that the > > exported name proposed by the client is the same one that is > proven by > > authentication, otherwise it might not be passing the proper > identity > > forward. In a kerberos environment, let's say the client is not > > configured as a kerberos client, and does not know the realm of > the > > intermediate. It > > fabricates a kerberos exported name containing the username as > > principal) without realm. The intermediate authenticates the > principal, > > in the default realm. The principal that gets sent forward (by the > > intermediate) should not be the one sent by the client, but the > realm > > annotated one that was authenticated by the mechanism at the > > intermediate. > > > > I think the intermediate should call accept_context, and then > export > > from the accepted context if it wants to assert forward. All > GSSAPI/CAT > > mechanisms should work like this, not just GSSUP. > > > > In addition to assertion, the intermediate should also be able to > > fabricate a mechanism specific ICT (i.e. a k5 ICT) to support the > B2 > > scenario identified above. Note that we don't want them to be able > to do > > this for GSSUP (without an internal mechanism). > > > > 2. Making the client pass mechanism specific exported name forms > in its > > GSSUP authenticators imposes a requirement on the client to have > > mechanism specific code to create specific exported forms. It also > > constrains the use of GSSUP by a client only to those mechanisms > for > > which it has exported name support. > > > > I would prefer that the GSSUP ICT look as follows: > > > > struct InitialContextToken { > > UTF8String username; > > UTF8String password; > > GSS_NT_exported_name target_name; > > }; > > > > The target_name would be as specified in the target IOR of the > mechanism > > being responded to by the client. The target_name field is > optional in > > the IOR. If there is a target_name in the IOR it at least contains > an > > OID > > that identifies a GSSAPI mechanism. The client would not have to > > understand these internal OIDs. The string following the OID, if > > present, would be presented to the user, as a cue for the scope in > which > > it must provide a username and password. In the simple GSSUP use > case, > > if a target_name is specified it will contain the GSSUP OID. In > the > > pseudo mechanism case, it will carry an internal mechanism OID > (e.g. > > KRB5). In either case, the value in this field would be directly > taken > > by the client from the IOR, and used to identify the mechanism > > definition being responded to by the client. > > > > The TSS would use the received target_name to identify the > AScontext, > > and the resulting client authentication name form (as a GSS > exported > > name). > > > > In the simple use case, no, other that GSSUP OID, internal > mechanism > > OID would appear in the mechanism selected by the client from the > IOR > > or the ICT fabricated by the client. In this case, the resulting > client > > identity (suitable for assertion) would be something like that > > originally > > defined when this issue was opened. That is, the username > separated by > > an '@' from the GSSUP authentication scope of the target (with > > appropriate byte stuffing to accommodate any embedded '@'s in the > the > > username). > > > > I think this proposal supports the identified scenarios without > imposing > > any additional requirements for name support on the originating > client. > > It does define a new catchall exported name form for GSSUP > (identity > > assertions and a name form to be understood by users). > > > > I considered using the username name form defined by kerberos and > > included in section 2.2.1 of RFC 2473 as the catchall exported > name > > form, but I think it better to be able to carry a notion of scope > > forward which the username form does not provide for (as it is > intended > > to identify a user on a local system). > > > > So, I would like to resolve issues 3922 and 3972 differently than > the > > poposals that you have made. > > > > I need to go home now. > > > > Ron > > > > > > using GSSUP with an inner context token containing a kerberos > (esported) > > > > principal name, and password would be an example of this use > case. > > > > > > Huh????? That is username password. If you are talking about > sending a > > > kerberos ticket, that is a different mechanism than GSSUP, and > works quite > > > nicely, I might add. > > > > > > Cheers, > > > -Polar > > > > > > > > > > > Ron > > > > > > > > Polar Humenn wrote: > > > > > > > > > > On Wed, 17 Jan 2001, David Chang wrote: > > > > > > > > > > > Ron, > > > > > > > > > > > > Does the Approach 2 use the format of the username in the > > > > > > InitilaContextToken to distinguish to the mechanism type > instead of the > > > > > > mechanism OID? > > > > > > > > > > > > struct InitialContextToken { > > > > > > UTF8String username; // for GSSUP username | > username@scope > > > > > > UTF8String password; > > > > > > }; > > > > > > > > > > > > Please clarify. > > > > > > > > > > I would think not. Also, in this case the username cannot be > a DN, it must > > > > > be a flat name with no designation of type of name. Of > course it could > > > > > always be a string version of a DN, but you wouldn't know > it. I still > > > > > think the GSS_NT_ExportName would be the better option. > > > > > > > > > > Cheers, > > > > > -Polar > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > David Chang > > > > > > > > > > > > WebSphere Security Architect & Team Lead > > > > > > IBM SWS Division, Internal Mail Stop 9131 > > > > > > Austin, Tx 78758 > > > > > > E-Mail:dyc@us.ibm.com > > > > > > Phone:(512)838-0559, T/L 678-0559 > > > > > > Fax: (512)838-1032 > > > > > > > > > > > > > > > > > > Ron Monzillo on 01/16/2001 > 05:35:55 PM > > > > > > > > > > > > To: csiv2-ftf@omg.org > > > > > > cc: > > > > > > Subject: [Fwd: GSSUP related issues] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Content-Transfer-Encoding: 7bit > > > > > > Content-Type: text/plain; charset=us-ascii > > > > > > > > > > > > I promised to start the discussion on the following issues > > > > > > > > > > > > Issue 3948: GSSUP names are incompatible with the Identity > Token > > > > > > Issue 3972: Format of GSSUP GSS exported name object > undefined > > > > > > > > > > > > The crux of these issues is really whether or not GSSUP > should be > > > > > > considered a full-fledged GSSAPI mechanism or a > "pseudo-mechanism". > > > > > > > > > > > > The solution proposed to issue 3948 is that GSSUP be > treated as a > > > > > > pseudo- mechanism. According to this proposal, the GSSUP > Initial Context > > > > > > Token (ICT) would be modified to carry a mechanism > (i.e. kereberos, > > > > > > unix,..) specific GSS exported name. The implication of > the proposal is > > > > > > that there would not be an exported name form for the > GSSUP mechanism. > > > > > > > > > > > > The solution proposed to issue 3972 is to define the > exported name form > > > > > > of the GSSUP mechanism, such that it in addition to the > existing > > > > > > definition of the GSSUP ICT, we will also have defined an > exported name > > > > > > form to be used in GSSUP Identity Assertions. > > > > > > > > > > > > These two issues have a different focus, and thus > different proposals > > > > > > have been made. In general the respective proposals may be > summarized as > > > > > > follows: > > > > > > > > > > > > 3948. GSSUP as a pseudo mechanism would be used to > authenticate GSSAPI > > > > > > identities of other types (i.e. Kerberos, unix). > > > > > > > > > > > > 3972. GSSUP as a full-fledged mechanism would be used to > authenticate > > > > > > full-fledged GSSUP (realm/scope specific) identities. > > > > > > > > > > > > We wrote the submission with our intent being focused on > something like > > > > > > that proposed in 3972. It is also clear that this approach > was not > > > > > > completed in the submission, as we neglected to define a > GSSUP exported > > > > > > name form. > > > > > > > > > > > > The proposed solution to 3948 would attempt to more > tightly integerate > > > > > > the GSSUP mechanism with security mechanisms for which > there is at least > > > > > > a defined GSSAPI exported name form. We would presumably > do this to be > > > > > > able to use GSSUP to > > > > > > > > > > > > A. access a non-GSSAPI username password authentication > mechanism from > > > > > > a communications protocol using GSSUP as a GSSAPI > mechanism. > > > > > > > > > > > > B. do username password authentication where the target > GSSAPI > > > > > > authentication mechanism does not support > username-password > > > > > > authentication via its ICT. > > > > > > > > > > > > C. establish a GSSAPI mechanism specific authentication > identity (an > > > > > > exported name) as the result of either A. or B. > > > > > > > > > > > > We created GSSUP for reason A. The Proposed solution to > 3972 only > > > > > > addresses reason A. The proposed solution to 3948 > addresses reasons B > > > > > > and C, in that it limits the use of GSSUP to those > mechanisms for which > > > > > > there is a defined exported name form. > > > > > > > > > > > > The proposed solution to 3972 (the definition of a GSSUP > exported name > > > > > > form) insures that reason A, can be satisfied in all > contexts. > > > > > > > > > > > > The proposed solution to 3972 also ensures that we need > not add (to > > > > > > conformance level 0) any requirement to support additional > GSSAPI > > > > > > mechanisms (that is, their name formats). > > > > > > > > > > > > If we begin with the proposed resolution of 3972 as a > baseline, then we > > > > > > can determine if we want to extend the semantics of the > GSSUP mechanism > > > > > > to satisfy reasons B and C, in which case, we might blend > the solution > > > > > > of 3972 and 3948. > > > > > > > > > > > > Approach 1: > > > > > > > > > > > > That is, the GSSUP ICT Name and Scope could be replaced by > a mechanism > > > > > > specific exported name form of type corresponding to the > OID of the > > > > > > target_name in the AS_ContextSec structure. GSSUP itself > would be a > > > > > > legitimate value for the type OID in the target_name. > > > > > > > > > > > > The inner contents of the GSSUP ICT would be as follows > (preceded by the > > > > > > GSSUP OID). > > > > > > > > > > > > struct InitialContextToken { > > > > > > GSS_NT_exported_name username; > > > > > > UTF8String password; > > > > > > }; > > > > > > > > > > > > Approach 2: > > > > > > > > > > > > Alternatively, we could use the target_name OID to > establish and > > > > > > interpret the form of the name sent and received in a > GSSUP ICT. > > > > > > Mechanism specific (as defined by the target_name OID's) > flat name > > > > > > strings obtained from the user would be sent in name_scope > and > > > > > > name_value. > > > > > > > > > > > > The inner contents of the GSSUP ICT would be as follows > (preceded by the > > > > > > GSSUP OID. > > > > > > > > > > > > struct ScopedName { > > > > > > NameValue name_scope; > > > > > > NameValue name_value; > > > > > > }; > > > > > > > > > > > > struct InitialContextToken { > > > > > > ScopedName username; > > > > > > UTF8String password; > > > > > > }; > > > > > > > > > > > > So to reiterate, if we begin with the proposed resolution > to 3972 (that > > > > > > is the definition of a GSSUP exported name form), and then > decide > > > > > > whether we want to acknowledge reasons B, or C, (that is > resolve issue > > > > > > 3948), then I think either of the approaches listed above > are workable. > > > > > > > > > > > > Approach 1's inclusion of the name defining mechanism OID > in the GSSUP > > > > > > ICT, and the fact that most if not all translations from > user > > > > > > presentation forms to flat name forms could be done, LLC > > > mailto:polar@adiron.com 2-212 CST > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > Fax: 315-443-4745 http://www.adiron.com > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com > --------------------------------------------- X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 25 Jan 2001 19:47:54 -0500 (EST) From: Polar Humenn To: csiv2-ftf@omg.org Subject: Issue 3972: GSSUP Flat Name Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: [?-e9$h/!!B]%!!6/`d9 I think the point about making different authentication mechanism "visible" to the client by way of the OID in the GSS name of the "target_name" is not a good way to go. It should be based solely on the client's interpretation of the entire name. If the client understands the differences, that is fine. We talked about having two different identities for a Microsoft login, and a Unix login at the target side. (You know, I absolutely abhor such abuses of authentication protocols). Anyway, the only thing that is going to matter to the client in this case its interpretation of the target_name. Microsoft actually uses kerberos identifiers, but they are mapped from the user's account id. There is no real way to tell what form is needed except from the name of the machine, or domain itself. So, the OID in the GSS_NT_ExportedName isn't going to give the client a definite tact, just a hunch. It is the name that has all the meaning. I wouldn't prohibit the use of the Kerberos Principal Name format in the GSSUP mechanism, oid:1.2.840.113554.1.2.2, but we definitely need a flat name for all other cases. It's up to the client and target to understand its meaning. Ron wanted to have this name have a "scope" such as name@scope with possibilities of @scope name He wanted a single "@@" to escape the delimiter in case it was to be considered part of the name part or the scope part. such as: c@@fe@wired.com to represent "c@fe@wired.com" (why you want to do this, but we all know it happens) However, there needs to be a bit more work done on escaping characters in an exported name. I propose to take part of the kerberos spec for encoding string names, which seems pretty standard: So, I say we take it as it stands as most deal with these things (such as nulls and backspaces, etc). In order to achieve a distinguished encoding for comparison purposes, the following additional constraints are imposed on the export operation: (1) all occurrences of the characters `@`, `/`, and `\` within principal components or realm names shall be quoted with an immediately-preceding `\`. (2) all occurrences of the null, backspace, tab, or newline characters within principal components or realm names will be represented, respectively, with `\0`, `\b`, `\t`, or `\n`. (3) the `\` quoting character shall not be emitted within an exported name except to accommodate cases (1) and (2). So, the basic upshot on this , is that if you need to contain "@" in a name or scope, it should be "\@" instead of "@@", i.e. "c\@fe@wired.com" Now, we give this definition an OID. Ron made the point that he doesn't want to create a different OID for this name type, and just use the GSSUP oid. However, I think this name type is useful in many ways, so I don't want to restrict it to just the GSS UP mechanism. Therefore, we should create a new OID for this name type with the description. That is not hard. I proposed before // This OID is registered with the OMG. // { iso-itu-t (2) international-organization (23) omg (130) security (1) // naming (2) string-name (1) } const NameType NT_StringName = "oid:2.23.130.1.2.1"; We can call it something else, like "FlatName", "ScopedName" or whatever. Any comments? 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, 06 Feb 2001 14:57:15 -0500 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: Issue 3972: GSSUP Flat Name References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Y9G!!-Pj!!f:R!!LRO!! It has been suggested that we use the kerberos exporting rules to define our GSSUP exported name type. I don't think they are appropriate for GSSUP because: at least the first of the kerberos rules is concerned with distinguishing the use of delimiters within principal components from their use as principal component delimiters. We impose no such structure on our GSSUP (catchall) names, and therefore would expect no useful purpose to be achieved by adopting the corresponding rules. The allowed character set for kerberos principal names includes some special characters as revealed in the second of the kerberos exporting rules. Moreover, the treatment (i.e. quoting of these "special" characters, was presumanly chosen in deference to the use of strcmp, and perhaps to allow for single line print output, in the absence of interpretation. We are defining a catchall mechanism which is intended to be able to carry the union of the character sets of all the authentication systems which may be plugged in under GSSUP. we require only that UTF8 be used as the character encoding. In this case, it is impractical to identify "special" characters, and thus the concept of "quoting" them to facilitate printing and comparision is at best questionable. I think it would be simpler to expect our "flat names" to be neutral with respect to the "specialness" of characters. That is, we would assume that all characters are represented in their UTF8 encoding. If you agree with what I have said above, the only quoting that will be necessary will be to deal with the scope delimiter, should it occur in a name other than as scope delimiter. So I propose(d) the following GSSUP exporting rules. This msg is too cluttered to carry a proposal, but what the heck, I'll put the details in here. If we agree, it will make it easier for someone to propose a more succinct resolution. -------- The following would be added to section 15.2.5 Identity Token Format beneath a new Head3 called "GSSUP exported name object" and following para [54]. The flat name component of a GSSUP exported name object has the following syntax, where name_value and name_scope contain a sequence of 1 or more UTF8 encoded characters. username ::= name_value | name_value@name_scope | @name_scope The '@' character shall be used to delimit name_value from name_scope. All instances of the delimiter character that occur within name_value shall be quoted with an immediately-preceding `@`. The mechanism OID used to identify a GSSUP exported name shall be {iso-itu-t (2) international-organization (23) omg (130) security (1) authentication (1) gssup-mechanism (1)} The length encoded in the 4-byte length within the GSS exported name object shall include any instances of the delimiter character that were "stuffed" in the name_value. ------ Polar Humenn wrote: > > I think the point about making different authentication mechanism > "visible" to the client by way of the OID in the GSS name of the > "target_name" is not a good way to go. It should be based solely on the > client's interpretation of the entire name. If the client understands the > differences, that is fine. > > We talked about having two different identities for a Microsoft login, and > a Unix login at the target side. (You know, I absolutely abhor such > abuses of authentication protocols). Anyway, the only thing that is going > to matter to the client in this case its interpretation of the > target_name. Microsoft actually uses kerberos identifiers, but they are > mapped from the user's account id. There is no real way to tell what form > is needed except from the name of the machine, or domain itself. > > So, the OID in the GSS_NT_ExportedName isn't going to give the client a > definite tact, just a hunch. It is the name that has all the meaning. > > I wouldn't prohibit the use of the Kerberos Principal Name format in the > GSSUP mechanism, oid:1.2.840.113554.1.2.2, but we definitely need a flat > name for all other cases. It's up to the client and target to understand > its meaning. > > Ron wanted to have this name have a "scope" such as > > name@scope > > with possibilities of > @scope > name > > He wanted a single "@@" to escape the delimiter in case it was to be > considered part of the name part or the scope part. such as: > > c@@fe@wired.com > > to represent "c@fe@wired.com" (why you want to do this, but we all know it > happens) > > However, there needs to be a bit more work done on escaping characters in > an exported name. > see comments above. > I propose to take part of the kerberos spec for encoding string names, > which seems pretty standard: So, I say we take it as it stands as most > deal with these things (such as nulls and backspaces, etc). > > In order to achieve a distinguished encoding for comparison purposes, > the following additional constraints are imposed on the export > operation: > > (1) all occurrences of the characters `@`, `/`, and `\` within > principal components or realm names shall be quoted with an > immediately-preceding `\`. > > (2) all occurrences of the null, backspace, tab, or newline > characters within principal components or realm names will be > represented, respectively, with `\0`, `\b`, `\t`, or `\n`. > > (3) the `\` quoting character shall not be emitted within an > exported name except to accommodate cases (1) and (2). > > So, the basic upshot on this , is that if you need to contain "@" in a > name or scope, it should be "\@" instead of "@@", i.e. "c\@fe@wired.com" > > Now, we give this definition an OID. > > Ron made the point that he doesn't want to create a different OID for > name type, and just use the GSSUP oid. However, I think this name type is > useful in many ways, so I don't want to restrict it to just the GSS UP > mechanism. Therefore, we should create a new OID for this name type with > the description. That is not hard. I think Polar wants to have access to an OID that he can use to assert identities independent of any authentication mechanism, including GSSUP. I see no problem with reserving an OID for this purpose, and if he wants it to be defined in the CSIV2 or CSI module (I forget which is which right now), I see no problem with that either. That said, we need to complete the definition of the GSSUP mechanism, which includes defining a mechanism-specific exported name form (which shall use the GSSUP OID). Also, if we define an additional OID, such as the string name OID proposed by Polar, it must be clear that its inclusion in the specification shall not carry with it any requirement that this name type be supported to claim conformance. Ron > > I proposed before > > // This OID is registered with the OMG. > // { iso-itu-t (2) international-organization (23) omg (130) > security (1) > // naming (2) string-name (1) } > const NameType NT_StringName = "oid:2.23.130.1.2.1"; > > We can call it something else, like "FlatName", "ScopedName" or > whatever. > Any comments? > > Cheers, > -Polar > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 6 Feb 2001 15:03:41 -0500 (EST) From: Polar Humenn To: Ron Monzillo cc: csiv2-ftf@omg.org Subject: Re: Issue 3972: GSSUP Flat Name In-Reply-To: <3A80571B.B4FF36C8@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: Q*$e9)U\d9I/Q!!fMUd9 On Tue, 6 Feb 2001, Ron Monzillo wrote: > It has been suggested that we use the kerberos exporting rules to define > our GSSUP exported name type. I don't think they are appropriate for > GSSUP because: > > at least the first of the kerberos rules is concerned with > distinguishing the use of delimiters within principal > components from their use as principal component delimiters. Okay, so there are only two real delimeters "/" and "@". This flat name will only have one, "@". I would rather stay with convention here, and have the escape character for the delimeter be "\". Cheers, -Polar > We impose no such structure on our GSSUP (catchall) names, > and therefore would expect no useful purpose to be achieved > by adopting the corresponding rules. > > The allowed character set for kerberos principal names > includes some > special characters as revealed in the second of the > kerberos exporting rules. Moreover, the treatment > (i.e. quoting > of these "special" characters, was presumanly chosen in > deference > to the use of strcmp, and perhaps to allow for single > line print output, in the absence of interpretation. > > We are defining a catchall mechanism which is intended to > be able to carry the union of the character sets of all the > authentication systems which may be plugged in under GSSUP. > we require only that UTF8 be used as the character encoding. > In this case, it is impractical to identify "special" > characters, and thus the concept of "quoting" them to facilitate > printing and comparision is at best questionable. I think it would > be simpler to expect our "flat names" to be neutral with respect to > the "specialness" of characters. That is, we would assume that > all characters are represented in their UTF8 encoding. If you agree > with what I have said above, the only quoting that will be > necessary will be to deal with the scope delimiter, should it > occur in a name other than as scope delimiter. > > So I propose(d) the following GSSUP exporting rules. > This msg is too cluttered to carry a proposal, but what the > heck, I'll put the details in here. If we agree, it will make it > easier for someone to propose a more succinct resolution. > > -------- > The following would be added to section 15.2.5 Identity Token Format > beneath a new Head3 called "GSSUP exported name object" and > following > para [54]. > > The flat name component of a GSSUP exported name object has the > following syntax, where name_value and name_scope contain a sequence > of > 1 or more UTF8 encoded characters. > > username ::= name_value | name_value@name_scope | @name_scope > > The '@' character shall be used to delimit name_value from > name_scope. All instances of the delimiter character > that occur within name_value shall be quoted with an > immediately-preceding `@`. > > The mechanism OID used to identify a GSSUP exported name shall be > {iso-itu-t (2) international-organization (23) omg (130) security > (1) > authentication (1) gssup-mechanism (1)} > > The length encoded in the 4-byte length within the GSS exported > name object shall include any instances of the delimiter character > that were "stuffed" in the name_value. > ------ > > Polar Humenn wrote: > > > > I think the point about making different authentication mechanism > > "visible" to the client by way of the OID in the GSS name of the > > "target_name" is not a good way to go. It should be based solely > on the > > client's interpretation of the entire name. If the client > understands the > > differences, that is fine. > > > > We talked about having two different identities for a Microsoft > login, and > > a Unix login at the target side. (You know, I absolutely abhor > such > > abuses of authentication protocols). Anyway, the only thing that > is going > > to matter to the client in this case its interpretation of the > > target_name. Microsoft actually uses kerberos identifiers, but > they are > > mapped from the user's account id. There is no real way to tell > what form > > is needed except from the name of the machine, or domain itself. > > > > So, the OID in the GSS_NT_ExportedName isn't going to give the > client a > > definite tact, just a hunch. It is the name that has all the > meaning. > > > > I wouldn't prohibit the use of the Kerberos Principal Name format > in the > > GSSUP mechanism, oid:1.2.840.113554.1.2.2, but we definitely need > a flat > > name for all other cases. It's up to the client and target to > understand > > its meaning. > > > > Ron wanted to have this name have a "scope" such as > > > > name@scope > > > > with possibilities of > > @scope > > name > > > > He wanted a single "@@" to escape the delimiter in case it was to > be > > considered part of the name part or the scope part. such as: > > > > c@@fe@wired.com > > > > to represent "c@fe@wired.com" (why you want to do this, but we all > know it > > happens) > > > > However, there needs to be a bit more work done on escaping > characters in > > an exported name. > > > see comments above. > > > I propose to take part of the kerberos spec for encoding string > names, > > which seems pretty standard: So, I say we take it as it stands as > most > > deal with these things (such as nulls and backspaces, etc). > > > > In order to achieve a distinguished encoding for comparison > purposes, > > the following additional constraints are imposed on the export > > operation: > > > > (1) all occurrences of the characters `@`, `/`, and `\` > within > > principal components or realm names shall be quoted with > an > > immediately-preceding `\`. > > > > (2) all occurrences of the null, backspace, tab, or > newline > > characters within principal components or realm names will > be > > represented, respectively, with `\0`, `\b`, `\t`, or `\n`. > > > > (3) the `\` quoting character shall not be emitted within > an > > exported name except to accommodate cases (1) and (2). > > > > So, the basic upshot on this , is that if you need to contain "@" > in a > > name or scope, it should be "\@" instead of "@@", > i.e. "c\@fe@wired.com" > > > > Now, we give this definition an OID. > > > > Ron made the point that he doesn't want to create a different OID > for > > name type, and just use the GSSUP oid. However, I think this name > type is > > useful in many ways, so I don't want to restrict it to just the > GSS UP > > mechanism. Therefore, we should create a new OID for this name > type with > > the description. That is not hard. > > I think Polar wants to have access to an OID that he can use to > assert > identities independent of any authentication mechanism, including > GSSUP. > I see no problem with reserving an OID for this purpose, and if he > wants > it to be defined in the CSIV2 or CSI module (I forget which is which > right now), I see no problem with that either. That said, we need to > complete the definition of the GSSUP mechanism, which includes > defining > a > mechanism-specific exported name form (which shall use the GSSUP > OID). > Also, if we define an additional OID, such as the string name OID > proposed by Polar, it must be clear that its inclusion in the > specification shall not carry with it any requirement that this > name type be supported to claim conformance. > > Ron > > > > > I proposed before > > > > // This OID is registered with the OMG. > > // { iso-itu-t (2) international-organization (23) omg (130) > security (1) > > // naming (2) string-name (1) } > > const NameType NT_StringName = "oid:2.23.130.1.2.1"; > > > > We can call it something else, like "FlatName", "ScopedName" or > whatever. > > Any comments? > > > > Cheers, > > -Polar > > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Tue, 06 Feb 2001 15:41:48 -0500 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn , csiv2-ftf@omg.org Subject: Re: Issue 3972: GSSUP Flat Name References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: EMl!!N1Ie9d~8e9gcE!! Polar Humenn wrote: > > On Tue, 6 Feb 2001, Ron Monzillo wrote: > > > It has been suggested that we use the kerberos exporting rules to define > > our GSSUP exported name type. I don't think they are appropriate for > > GSSUP because: > > > > at least the first of the kerberos rules is concerned with > > distinguishing the use of delimiters within principal > > components from their use as principal component delimiters. > > Okay, so there are only two real delimeters "/" and "@". > > This flat name will only have one, "@". > > I would rather stay with convention here, and have the escape character > for the delimeter be "\". > Yes, but then you are taking another character out of the set that can be used in names. To recover '\' for use in names, you would have to describe how to escape it. Not that I really care, but it seems to me that Microsoft have a fondness for the '\' character? > Cheers, > -Polar Date: Tue, 06 Feb 2001 15:46:02 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ron Monzillo Cc: Polar Humenn , csiv2-ftf@omg.org Subject: Re: Issue 3972: GSSUP Flat Name References: <3A80571B.B4FF36C8@east.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: d+T!!IWMe9>Z-e9mh8!! > The following would be added to section 15.2.5 Identity Token Format > beneath a new Head3 called "GSSUP exported name object" and > following > para [54]. > > The flat name component of a GSSUP exported name object has the > following syntax, where name_value and name_scope contain a sequence > of > 1 or more UTF8 encoded characters. > > username ::= name_value | name_value@name_scope | @name_scope > > The '@' character shall be used to delimit name_value from > name_scope. All instances of the delimiter character > that occur within name_value shall be quoted with an > immediately-preceding `@`. > > The mechanism OID used to identify a GSSUP exported name shall be > {iso-itu-t (2) international-organization (23) omg (130) security > (1) > authentication (1) gssup-mechanism (1)} > > The length encoded in the 4-byte length within the GSS exported > name object shall include any instances of the delimiter character > that were "stuffed" in the name_value. You also need to say that name_scope shall not contain an '@' character. If name_scope may contain an @ character then this whole scheme does not work too well because foo@@@@@bar is ambiguous.... is it "foo@"@"@bar"? or "foo@@"@bar? or foo@"@@bar"? Jishnu. Date: Tue, 06 Feb 2001 16:24:07 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ron Monzillo Cc: Polar Humenn , csiv2-ftf@omg.org Subject: Re: Issue 3972: GSSUP Flat Name References: <3A80618C.DD2F04E9@east.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: \>M!!-UUd9+$O!!C*Ge9 Ron Monzillo wrote: > > Polar Humenn wrote: > > > > On Tue, 6 Feb 2001, Ron Monzillo wrote: > > > > > It has been suggested that we use the kerberos exporting rules to define > > > our GSSUP exported name type. I don't think they are appropriate for > > > GSSUP because: > > > > > > at least the first of the kerberos rules is concerned with > > > distinguishing the use of delimiters within principal > > > components from their use as principal component delimiters. > > > > Okay, so there are only two real delimeters "/" and "@". > > > > This flat name will only have one, "@". > > > > I would rather stay with convention here, and have the escape character > > for the delimeter be "\". > > > > Yes, but then you are taking another character out of the set that can > be used in names. > > To recover '\' for use in names, you would have to describe how to > escape it. But that is somewhat easier since it is not a delimiter. You can just represent it by repeating itself without causing parsing problems. Seems to work just fine in many widely used regular expression representations, even standard ones like POSIX etc. > Not that I really care, but it seems to me that Microsoft have a > fondness for the '\' character? What does Microsoft have to do with the rules in Kerberos? I thought those rules came out of MIT. Did Microsoft acquire MIT while I was looking the other way?:-) There are actually good reasons for the escape character for the delimiters to be different from the delimiters, and the escape character itself not be a delimiter, for making the life of parsers easier and such. See my ambiguity example in the other message that i sent a while back. Jishnu. Date: Tue, 06 Feb 2001 17:25:17 -0500 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jishnu Mukerji CC: Polar Humenn , csiv2-ftf@omg.org Subject: Re: Issue 3972: GSSUP Flat Name References: <3A80571B.B4FF36C8@east.sun.com> <3A80628A.ED63A30A@hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ~lg!!]Op!!c$)!![o!"! Jishnu Mukerji wrote: > > > The following would be added to section 15.2.5 Identity Token Format > > beneath a new Head3 called "GSSUP exported name object" and following > > para [54]. > > > > The flat name component of a GSSUP exported name object has the > > following syntax, where name_value and name_scope contain a sequence of > > 1 or more UTF8 encoded characters. > > > > username ::= name_value | name_value@name_scope | @name_scope > > > > The '@' character shall be used to delimit name_value from > > name_scope. All instances of the delimiter character > > that occur within name_value shall be quoted with an > > immediately-preceding `@`. > > > > The mechanism OID used to identify a GSSUP exported name shall be > > {iso-itu-t (2) international-organization (23) omg (130) security (1) > > authentication (1) gssup-mechanism (1)} > > > > The length encoded in the 4-byte length within the GSS exported > > name object shall include any instances of the delimiter character > > that were "stuffed" in the name_value. > > You also need to say that name_scope shall not contain an '@' character. > If name_scope may contain an @ character then this whole scheme does not > work too well because > > foo@@@@@bar is ambiguous.... is it "foo@"@"@bar"? or "foo@@"@bar? or > foo@"@@bar"? > > Jishnu. Yes I overlooked this. I think you would need to prohibit the use of @ as the first character in name_scope. I was hoping to avoid such prohibitions. Perhaps this is a reason why we need a separate "quoting" character (from the scope delimiter)? I was distracted, but I see that while I was away you expressed the same conclusion. > There are actually good reasons for the escape character for the > delimiters to be different from the delimiters, and the escape > character > itself not be a delimiter, for making the life of parsers easier and > such. See my ambiguity example in the other message that i sent a > while > back. So let me try again, after having taken a closer look at the kerberos rules > > The following would be added to section 15.2.5 Identity Token Format > > beneath a new Head3 called "GSSUP exported name object" and following > > para [54]. > > > > The flat name component of a GSSUP exported name object has the > > following syntax, where name_value and name_scope contain a sequence of > > 1 or more UTF8 encoded characters. > > > > username ::= name_value | name_value@name_scope | @name_scope > > The '@' character shall be used to delimit name_value from name_scope. All instances of the characters '@' and '\' that occur within name_value shall be quoted with an immediately-preceding '\'. we might also say (although any other interpretation would be ridiculous if not disasterous). This rule shall not be applied (recursively) to instances of the '\' character that are inserted for quoting purposes. > > > > The mechanism OID used to identify a GSSUP exported name shall be > > {iso-itu-t (2) international-organization (23) omg (130) security > >(1) > > authentication (1) gssup-mechanism (1)} > > > > The length encoded in the 4-byte length within the GSS exported > > name object shall include any instances of the delimiter character > > that were "stuffed" in the name_value. Ron Date: Tue, 06 Feb 2001 17:49:00 -0500 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Ron Monzillo Cc: Polar Humenn , csiv2-ftf@omg.org Subject: Re: Issue 3972: GSSUP Flat Name References: <3A80571B.B4FF36C8@east.sun.com> <3A80628A.ED63A30A@hp.com> <3A8079CD.9391E637@east.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: X8X!!(Y;!!T@N!!P7g!! Ron Monzillo wrote: > Jishnu Mukerji wrote: > > > > > The following would be added to section 15.2.5 Identity Token Format > > > beneath a new Head3 called "GSSUP exported name object" and following > > > para [54]. > > > > > > The flat name component of a GSSUP exported name object has the > > > following syntax, where name_value and name_scope contain a sequence of > > > 1 or more UTF8 encoded characters. > > > > > > username ::= name_value | name_value@name_scope | @name_scope > > > > > > The '@' character shall be used to delimit name_value from > > > name_scope. All instances of the delimiter character > > > that occur within name_value shall be quoted with an > > > immediately-preceding `@`. > > > > > > The mechanism OID used to identify a GSSUP exported name shall be > > > {iso-itu-t (2) international-organization (23) omg (130) security (1) > > > authentication (1) gssup-mechanism (1)} > > > > > > The length encoded in the 4-byte length within the GSS exported > > > name object shall include any instances of the delimiter character > > > that were "stuffed" in the name_value. > > > > You also need to say that name_scope shall not contain an '@' character. > > If name_scope may contain an @ character then this whole scheme does not > > work too well because > > > > foo@@@@@bar is ambiguous.... is it "foo@"@"@bar"? or "foo@@"@bar? or > > foo@"@@bar"? > > > > Jishnu. > > Yes I overlooked this. I think you would need to prohibit the use of @ > as the first character in name_scope. I was hoping to avoid such > prohibitions. Perhaps this is a reason why we need > a separate "quoting" character (from the scope delimiter)? > > I was distracted, but I see that while I was away you > expressed the same conclusion. > > > There are actually good reasons for the escape character for the > > delimiters to be different from the delimiters, and the escape character > > itself not be a delimiter, for making the life of parsers easier and > > such. See my ambiguity example in the other message that i sent a while > > back. > > So let me try again, after having taken a closer look at the kerberos > rules > > > > The following would be added to section 15.2.5 Identity Token Format > > > beneath a new Head3 called "GSSUP exported name object" and following > > > para [54]. > > > > > > The flat name component of a GSSUP exported name object has the > > > following syntax, where name_value and name_scope contain a sequence of > > > 1 or more UTF8 encoded characters. > > > > > > username ::= name_value | name_value@name_scope | @name_scope > > > > The '@' character shall be used to delimit name_value from > name_scope. All instances of the characters '@' and '\' > that occur within name_value shall be quoted with an > immediately-preceding '\'. Actually isn't the general rule that "All non-delimiter instances of '@' and all instances of '\' shall be quoted with an immediately-preceding '\'? Why specifically point out name_value if the intent is for the rule to apply throughout the string? > we might also say (although any other interpretation would be > ridiculous if not disasterous). > > This rule shall not be applied (recursively) to instances of the > '\' character that are inserted for quoting purposes. Yes. > > > > > > The mechanism OID used to identify a GSSUP exported name shall > > >be > > > {iso-itu-t (2) international-organization (23) omg (130) > > >security (1) > > > authentication (1) gssup-mechanism (1)} > > > > > > The length encoded in the 4-byte length within the GSS exported > > > name object shall include any instances of the delimiter > > >character > > > that were "stuffed" in the name_value. The last paragraph needs to refer to the quote character rather than the delimiter chracter now I think. Also, I think it should not call out name_value specifically but let the rule apply to the entire string. Cheers, Jishnu. Date: Tue, 06 Feb 2001 18:20:59 -0500 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: jishnu_mukerji@hp.com CC: Polar Humenn , csiv2-ftf@omg.org Subject: Re: Issue 3972: GSSUP Flat Name References: <3A80571B.B4FF36C8@east.sun.com> <3A80628A.ED63A30A@hp.com> <3A8079CD.9391E637@east.sun.com> <3A807F5B.4B58D1EB@hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ABC!!Eej!!1g=!!ngFe9 Jishnu Mukerji wrote: > > Ron Monzillo wrote: > > > Jishnu Mukerji wrote: > > > > > > > The following would be added to section 15.2.5 Identity Token Format > > > > beneath a new Head3 called "GSSUP exported name object" and following > > > > para [54]. > > > > > > > > The flat name component of a GSSUP exported name object has the > > > > following syntax, where name_value and name_scope contain a sequence of > > > > 1 or more UTF8 encoded characters. > > > > > > > > username ::= name_value | name_value@name_scope | @name_scope > > > > > > > > The '@' character shall be used to delimit name_value from > > > > name_scope. All instances of the delimiter character > > > > that occur within name_value shall be quoted with an > > > > immediately-preceding `@`. > > > > > > > > The mechanism OID used to identify a GSSUP exported name shall be > > > > {iso-itu-t (2) international-organization (23) omg (130) security (1) > > > > authentication (1) gssup-mechanism (1)} > > > > > > > > The length encoded in the 4-byte length within the GSS exported > > > > name object shall include any instances of the delimiter character > > > > that were "stuffed" in the name_value. > > > > > > You also need to say that name_scope shall not contain an '@' character. > > > If name_scope may contain an @ character then this whole scheme does not > > > work too well because > > > > > > foo@@@@@bar is ambiguous.... is it "foo@"@"@bar"? or "foo@@"@bar? or > > > foo@"@@bar"? > > > > > > Jishnu. > > > > Yes I overlooked this. I think you would need to prohibit the use of @ > > as the first character in name_scope. I was hoping to avoid such > > prohibitions. Perhaps this is a reason why we need > > a separate "quoting" character (from the scope delimiter)? > > > > I was distracted, but I see that while I was away you > > expressed the same conclusion. > > > > > There are actually good reasons for the escape character for the > > > delimiters to be different from the delimiters, and the escape character > > > itself not be a delimiter, for making the life of parsers easier and > > > such. See my ambiguity example in the other message that i sent a while > > > back. > > > > So let me try again, after having taken a closer look at the kerberos > > rules > > > > > > The following would be added to section 15.2.5 Identity Token Format > > > > beneath a new Head3 called "GSSUP exported name object" and following > > > > para [54]. > > > > > > > > The flat name component of a GSSUP exported name object has the > > > > following syntax, where name_value and name_scope contain a sequence of > > > > 1 or more UTF8 encoded characters. > > > > > > > > username ::= name_value | name_value@name_scope | @name_scope > > > > > > The '@' character shall be used to delimit name_value from > > name_scope. All instances of the characters '@' and '\' > > that occur within name_value shall be quoted with an > > immediately-preceding '\'. > > Actually isn't the general rule that "All non-delimiter instances of '@' and all > instances of '\' shall be quoted with an immediately-preceding '\'? > > Why specifically point out name_value if the intent is for the rule to apply > throughout the string? Now that you have already corrected me twice, I hesitate to venture forth again, but the intent was not to have the rule apply throughout the string. The thought was that depending on whether you parse from the front or the back, you only need this rule on one half (either the value or scope) to find the delimiter. Parsing from the front seems better because it makes it simple for a user to properly position a delimiter. The user just quotes things in the name value that might be confused with its delimiter. Once the delimiter is located, there is no need to do any more fancy footwork, as there is no further opportunity to confuse the parser. The counter argument might be that unless consistent rules are applied to both parts, the user not the parser might be confused. I don't think the extra footwork is necessary, but if others think so then I won't argue it further. > > > we might also say (although any other interpretation would be > > ridiculous if not disasterous). > > > > This rule shall not be applied (recursively) to instances of the > > '\' character that are inserted for quoting purposes. > > Yes. > > > > > > > > > The mechanism OID used to identify a GSSUP exported name shall be > > > > {iso-itu-t (2) international-organization (23) omg (130) security (1) > > > > authentication (1) gssup-mechanism (1)} > > > > > > > > The length encoded in the 4-byte length within the GSS exported > > > > name object shall include any instances of the delimiter character > > > > that were "stuffed" in the name_value. > > The last paragraph needs to refer to the quote character rather than the delimiter > chracter now I think. Also, I think it should not call out name_value specifically > but let the rule apply to the entire string. > yes, there is a problem here. But let's fix it after we decide on where the stuffing should be performed, as then it will be simple to fix this sentence. > Cheers, > > Jishnu. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 8 Feb 2001 12:05:41 -0500 (EST) From: Polar Humenn To: Ron Monzillo cc: csiv2-ftf@omg.org Subject: Re: Issue 3972: GSSUP Flat Name In-Reply-To: <3A80618C.DD2F04E9@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: km)e9RXW!!M9O!!T]5!! On Tue, 6 Feb 2001, Ron Monzillo wrote: > > > Polar Humenn wrote: > > > > On Tue, 6 Feb 2001, Ron Monzillo wrote: > > > > > It has been suggested that we use the kerberos exporting rules > to define > > > our GSSUP exported name type. I don't think they are appropriate > for > > > GSSUP because: > > > > > > at least the first of the kerberos rules is concerned with > > > distinguishing the use of delimiters within principal > > > components from their use as principal component > delimiters. > > > > Okay, so there are only two real delimeters "/" and "@". > > > > This flat name will only have one, "@". > > > > I would rather stay with convention here, and have the escape > character > > for the delimeter be "\". > > > > Yes, but then you are taking another character out of the set that > can > be used in names. > > To recover '\' for use in names, you would have to describe how to > escape it. You use a "\\". > Not that I really care, but it seems to me that Microsoft have a > fondness for the '\' character? Whatever. Sure. I don't see why you would need these. But lets go with "@@". > > > 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, 08 Feb 2001 12:35:47 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn Cc: Ron Monzillo , csiv2-ftf@omg.org Subject: Re: Issue 3972: GSSUP Flat Name References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: c(2!!#:*!!/,+e9$5D!! Polar Humenn wrote: > > On Tue, 6 Feb 2001, Ron Monzillo wrote: > > > > > > > Polar Humenn wrote: > > > > > > On Tue, 6 Feb 2001, Ron Monzillo wrote: > > > > > > > It has been suggested that we use the kerberos exporting rules to define > > > > our GSSUP exported name type. I don't think they are appropriate for > > > > GSSUP because: > > > > > > > > at least the first of the kerberos rules is concerned with > > > > distinguishing the use of delimiters within principal > > > > components from their use as principal component delimiters. > > > > > > Okay, so there are only two real delimeters "/" and "@". > > > > > > This flat name will only have one, "@". > > > > > > I would rather stay with convention here, and have the escape character > > > for the delimeter be "\". > > > > > > > Yes, but then you are taking another character out of the set that can > > be used in names. > > > > To recover '\' for use in names, you would have to describe how to > > escape it. > > You use a "\\". > > > Not that I really care, but it seems to me that Microsoft have a > > fondness for the '\' character? > > Whatever. Sure. I don't see why you would need these. But lets go with > "@@". No. After much discussion yesterday we came to an agreement that we will use '\' as the escape character and '@' as the delimiter. We will stay with the convention. I have also pointed out, that the use of '\' as escape character has nothing to do with Microsoft. It was definitely used in Unix versions 5 and 6 (the original Western Electric stuff, before all these latter day revisionist BSD and Linux stuff:-)) by Dennis Ritchie and Brian Kernighan. It certainly was there in the libC that I got in the tape from Western Electric, that I used to install Unix version 6 on a PDP 11/60 at Stony Brook Computer Science Department, in 1978-79. Dennis and Brian probably got it from somewhere like Multics or some such. If you must know I could ask Brian and see what he says.:-) Jishnu. Date: Thu, 08 Feb 2001 13:07:22 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn Cc: Ron Monzillo , csiv2-ftf@omg.org Subject: Re: Issue 3972: GSSUP Flat Name References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: no8!!)U^!!TS:!!U-?e9 Polar Humenn wrote: > However, if somebody wanted to use microsoft directory file names > for a user name, I guess that would be a problem, eh? > > C:\\winnt\\profiles\\polar@\\\\MICROSOFTSERVER > > Yuck! > > Of course, this is completely contrived. :), and rediculous. So,.... > let's get rid of microsoft! :) Or at least let them worry about how to escape:-), their form of file names I mean. Shouldn't be any harder than it is in Kerberos in any case. Jishnu. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 8 Feb 2001 12:50:15 -0500 (EST) From: Polar Humenn To: Jishnu Mukerji cc: Ron Monzillo , csiv2-ftf@omg.org Subject: Re: Issue 3972: GSSUP Flat Name In-Reply-To: <3A82D8F3.D2C6EB36@hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: j+hd9p#"e9]1G!!3pFe9 On Thu, 8 Feb 2001, Jishnu Mukerji wrote: > Polar Humenn wrote: > > > > On Tue, 6 Feb 2001, Ron Monzillo wrote: > > > > > > > > > > > Polar Humenn wrote: > > > > > > > > On Tue, 6 Feb 2001, Ron Monzillo wrote: > > > > > > > > > It has been suggested that we use the kerberos exporting rules to define > > > > > our GSSUP exported name type. I don't think they are appropriate for > > > > > GSSUP because: > > > > > > > > > > at least the first of the kerberos rules is concerned with > > > > > distinguishing the use of delimiters within principal > > > > > components from their use as principal component delimiters. > > > > > > > > Okay, so there are only two real delimeters "/" and "@". > > > > > > > > This flat name will only have one, "@". > > > > > > > > I would rather stay with convention here, and have the escape character > > > > for the delimeter be "\". > > > > > > > > > > Yes, but then you are taking another character out of the set that can > > > be used in names. > > > > > > To recover '\' for use in names, you would have to describe how to > > > escape it. > > > > You use a "\\". > > > > > Not that I really care, but it seems to me that Microsoft have a > > > fondness for the '\' character? > > > > Whatever. Sure. I don't see why you would need these. But lets go with > > "@@". > > No. After much discussion yesterday we came to an agreement that we will > use '\' as the escape character and '@' as the delimiter. We will stay > with the convention. Yesk, after being away for a day, and subsequently catching a "airplane" cold, I should read *all* my mail before replying to a single message! :) > I have also pointed out, that the use of '\' as escape character has > nothing to do with Microsoft. It was definitely used in Unix > versions 5 > and 6 (the original Western Electric stuff, before all these latter > day > revisionist BSD and Linux stuff:-)) by Dennis Ritchie and Brian > Kernighan. It certainly was there in the libC that I got in the tape > from Western Electric, that I used to install Unix version 6 on a > PDP > 11/60 at Stony Brook Computer Science Department, in 1978-79. Dennis > and > Brian probably got it from somewhere like Multics or some such. If > you > must know I could ask Brian and see what he says.:-) You don't have to tell me that! :) However, if somebody wanted to use microsoft directory file names for a user name, I guess that would be a problem, eh? C:\\winnt\\profiles\\polar@\\\\MICROSOFTSERVER Yuck! Of course, this is completely contrived. :), and rediculous. So,.... let's get rid of microsoft! :) (I think the cold medicine is taking effect). Cheers, -Polar > Jishnu. > ------------------------------------------------------------------- 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, 08 Feb 2001 15:29:47 -0500 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: dflinn@iona.com, csiv2-ftf@omg.org Subject: Proposed resolution to 3972 Content-Type: multipart/mixed; boundary="------------AA7597796D1CA2C26C0AF67A" X-UIDL: Z8!!!Xg/!!$5~!!_l]!! Don et al, I have attached a proposed resolution to issue 3972. In a recent note, I described why I did not follow the elements of Polar's proposal which called for the creation of a "NameType" and for reserving an OID for a StringName NameType. There may be further discussion on this issue. Ron Issue 3972: Format of GSSUP GSS exported name object undefined Click here for this issue's archive. Source: Sun Microsystems (Ron Monzillo, Ronald.Monzillo@east.sun.com) Document: http://cgi.omg.org/cgi-bin/doc?orbos/2000-08-04 Nature: Uncategorized Issue Severity: Critical Summary: Format of GSSUP GSS mechanism-independent exported name object, a special form of "flat" name as described below, is not defined. Discussion: Define a "flat name" type OID and format. It would also be good to have these OIDs specified somewhere. We can do that in IDL with string constants, using dot notation for OIDs. Resolution: Close issue with revised text. Revised Text: The following modifications are presented against document http://cgi.omg.org/pub/csiv2-ftf/csiv2-0117011.pdf. with the assumption that the resolution of Issue 4141 has been applied, i.e. Moving GSS_NT_ExportedName from Security to CSI, and the assumption that the resolution of Issue 4143 has been applied, i.e. creation of the CSI::StringOID type. [1] Add the following at the end (following para 54) of section 15.2.5 Identity Token Format GSS Exported Name Object Form for GSSUP Mechanism The mechanism OID within the exported name object shall be that of the GSSUP mechanism. {iso-itu-t (2) international-organization (23) omg (130) security (1) authentication (1) gssup-mechanism (1)} The name component within the exported name object shall be a contiguous string conforming to the following syntax, where name_value and name_scope contain a sequence of 1 or more UTF8 encoded characters. username ::= name_value | name_value@name_scope | @name_scope The '@' character shall be used to delimit name_value from name_scope. All non-delimiter instances of '@' and all non-quoting instances of '\' shall be quoted with an immediately-preceding '\'. The name length component within the exported name object shall represent the length of the name component including any inserted quoting characters. The encoding of GSS mechanism-independent exported name objects is defined in [IETF RFC 2743]. [2] Insert the following definition in Section 16.9.6, Module CSI, after the definition of GSS_NT_ExportedNameList. // The GSS Object Identifier for the KRB5 mechanism is defined below. // // { iso(1) member-body(2) United States(840) mit(113554) // infosys(1) gssapi(2) krb5(2) } const StringOID KRB5MechOID = "oid:1.2.840.113554.1.2.2"; Actions taken: October 13, 2000: received issue DON FILL IN DATE HERE: closed issue X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 8 Feb 2001 17:47:07 -0500 (EST) From: Polar Humenn To: Ron Monzillo cc: csiv2-ftf@omg.org Subject: Issue 3972 (was Re: Does anybody have minutes In-Reply-To: <3A82FAE5.E37F0E29@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: -9R!!'?dd9R+nd9k'S!! On Thu, 8 Feb 2001, Ron Monzillo wrote: > Polar, > > I'm about to send out a proposed resolution for 3972. > I think I have covered the exported name form for GSSUP. > > There were some other items you included in this issue. > > 1. you defined a NameType and used it to define a constant for > a kerberos name type. In the comments of the constant you say this > oid is for use in the kereberos exported object. The OID you > speced is not a name type, but a mechanism OID (I don't think we > need a new type for such things), and we don't need to describe > how it is used in kerberos exported name objects. By the way the > kerberos principal name form has a differnt OID (it has > krb5_name(1)) > at then end. Well, then Kerberos GSSExportedName OID is the Mechanism OID for Kerboeros, surely. However, the format of the name component is that of KerberosPrincipalName. It has its own OID, but its OID does not show up in the GSS exported name structure. It is implied. GSSUP has no explicit OID definition to refer to its name form. Do you think it should? > At most we could/should define the krb5 mechanism oid, and leave > it at that. Surely, but I still mandate the need to create a name that can be asserted in the Identity Token that doesn't adhere to any particular format or mechanism. So therefore in order to create a name, we need a MechanismOID to "create" a name that can be asserted out of the blue. I wouldn't mind that just being a flat name (no delimiters, no escaping). UTF-8 characters, and no scoping. So, let this resolution to 3972 go to a vote, and I'll raise an issue based on this discussion. Cheers, -Polar > > // The GSS Object Identifier allocated for the krb5 mechanism is > // defined below. > // > // { iso(1) member-body(2) United States(840) mit(113554) > // infosys(1) gssapi(2) krb5(2) } > > const CSI::StringOID KRB5MechOID = "oid:1.2.840.113554.1.2.2"; > > I think the gssup exported name form should be suitable for your > string > name case, I agreed to add another OID if you think you need it but > I > would much rather not. The OIDs in exported name objects are > mechanism > OIDS not name types. > > So if we add this OID, it would not be a "NameType", but a synonym > for > the GSSUP mechanism OID. > > Ron > > Polar Humenn wrote: > > > > Does anyone have minutes of the teleconference yesterday. Sorry I > had to > > miss it, I was busy catching a cold in a florida hotel in which > you > > couldn't open the windows. ( I don't get it, I sould have > brought my > > sleeping bag and slept outside on the lawn, I mean, c'mon! > Florida! > > Geeezz). > > > > Home, in bed, sniffling, > > -Polar > > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Thu, 08 Feb 2001 18:13:43 -0500 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: Issue 3972 (was Re: Does anybody have minutes References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 6>Le9nSj!!SVad9S7W!! Polar Humenn wrote: > > On Thu, 8 Feb 2001, Ron Monzillo wrote: > > > Polar, > > > > I'm about to send out a proposed resolution for 3972. > > I think I have covered the exported name form for GSSUP. > > > > There were some other items you included in this issue. > > > > 1. you defined a NameType and used it to define a constant for > > a kerberos name type. In the comments of the constant you say this > > oid is for use in the kereberos exported object. The OID you > > speced is not a name type, but a mechanism OID (I don't think we > > need a new type for such things), and we don't need to describe > > how it is used in kerberos exported name objects. By the way the > > kerberos principal name form has a differnt OID (it has krb5_name(1)) > > at then end. > > Well, then Kerberos GSSExportedName OID is the Mechanism OID for > Kerboeros, surely. However, the format of the name component is that of > KerberosPrincipalName. It has its own OID, but its OID does not show up in > the GSS exported name structure. It is implied. > > GSSUP has no explicit OID definition to refer to its name form. Do you > think it should? I don't see how it can, as its name forms, which I think are really an internal names, should be left unbound to facilitate the binding of the GSSAPI token exchange to any shared secret authentication mechanism (within the mechanism implementation). But I confess you told me some things about how name types are used in gssapi processing, which may force name types to be defined for use with GSSUP. I hope not. > > > At most we could/should define the krb5 mechanism oid, and leave > > it at that. > > Surely, but I still mandate the need to create a name that can be > asserted in the Identity Token that doesn't adhere to any particular > format or mechanism. > My thinking is that the GSSUP exported name object can assume this role, especially if there need not be name types for GSSUP. > So therefore in order to create a name, we need a MechanismOID to "create" > a name that can be asserted out of the blue. > > I wouldn't mind that just being a flat name (no delimiters, no escaping). > UTF-8 characters, and no scoping. > > So, let this resolution to 3972 go to a vote, and I'll raise an issue > based on this discussion. > I would appreciate that, although I would also accept us working this out here; assuming we are close. Ron > Cheers, > -Polar > > > > > // The GSS Object Identifier allocated for the krb5 mechanism is > > // defined below. > > // > > // { iso(1) member-body(2) United States(840) mit(113554) > > // infosys(1) gssapi(2) krb5(2) } > > > > const CSI::StringOID KRB5MechOID = "oid:1.2.840.113554.1.2.2"; > > > > I think the gssup exported name form should be suitable for your string > > name case, I agreed to add another OID if you think you need it but I > > would much rather not. The OIDs in exported name objects are mechanism > > OIDS not name types. > > > > So if we add this OID, it would not be a "NameType", but a synonym for > > the GSSUP mechanism OID. > > > > Ron > > > > Polar Humenn wrote: > > > > > > Does anyone have minutes of the teleconference yesterday. Sorry I had to > > > miss it, I was busy catching a cold in a florida hotel in which you > > > couldn't open the windows. ( I don't get it, I sould have brought my > > > sleeping bag and slept outside on the lawn, I mean, c'mon! Florida! > > > Geeezz). > > > > > > Home, in bed, sniffling, > > > -Polar > > > > > > ------------------------------------------------------------------- > > > Polar Humenn Adiron, LLC > > > mailto:polar@adiron.com 2-212 CST > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > Fax: 315-443-4745 http://www.adiron.com > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 8 Feb 2001 19:17:49 -0500 (EST) From: Polar Humenn To: Ron Monzillo cc: csiv2-ftf@omg.org Subject: Re: Issue 3972 (was Re: Does anybody have minutes In-Reply-To: <3A832827.5E4076DD@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 5@^!!Lk*!!I@Rd9M0%!! On Thu, 8 Feb 2001, Ron Monzillo wrote: > > > Polar Humenn wrote: > > > > On Thu, 8 Feb 2001, Ron Monzillo wrote: > > > > > Polar, > > > > > > I'm about to send out a proposed resolution for 3972. > > > I think I have covered the exported name form for GSSUP. > > > > > > There were some other items you included in this issue. > > > > > > 1. you defined a NameType and used it to define a constant for > > > a kerberos name type. In the comments of the constant you say > this > > > oid is for use in the kereberos exported object. The OID you > > > speced is not a name type, but a mechanism OID (I don't think we > > > need a new type for such things), and we don't need to describe > > > how it is used in kerberos exported name objects. By the way the > > > kerberos principal name form has a differnt OID (it has > krb5_name(1)) > > > at then end. > > > > Well, then Kerberos GSSExportedName OID is the Mechanism OID for > > Kerboeros, surely. However, the format of the name component is > that of > > KerberosPrincipalName. It has its own OID, but its OID does not > show up in > > the GSS exported name structure. It is implied. > > > > GSSUP has no explicit OID definition to refer to its name form. Do > you > > think it should? > > I don't see how it can, as its name forms, which I think are really > an > internal names, should be left unbound to facilitate the binding of > the > GSSAPI token exchange to any shared secret authentication mechanism > (within the mechanism implementation). But I confess you told me > some > things about how name types are used in gssapi processing, which may > force name types to be defined for use with GSSUP. I hope not. Well, the "internal" name format for a Kerberos name is a two part structure (in C) of two fields "name" and "realm". However, that is an implemenation issue, and that's why it's "internal". It has several "exported" name forms, such as GSS_NT_USER_NAME, GSS_NT_SERVICE_NAME, .... GSS_NT_EXPORT_NAME, as well as KRB5_NT_KRB5_NAME and KRB5_NT_KRB5_PRINCIPAL. These types are used for GSS_import_name as the type parameter. Kerberos only exports to one type. For most "import" types that are not defined by the GSS_NT_* types, kerberos has OIDs that point to their definitions. For instance, giving a "GSS_import_name" call with a type of GSS_NT_SERVICE_NAME: * service_name: * iso(1) member-body(2) US(840) mit(113554) infosys(1) gssapi(2) * generic(1) service_name(4) = 1.2.840.113554.1.2.1.4 The OID of the corresponds directly to the syntax of a KRB5_NT_SERVICE_NAME, which is krb5_principal type is: * iso(1) member-body(2) US(840) mit(113554) infosys(1) gssapi(2) * krb5(2) krb5_principal(2) = 1.2.840.113554.1.2.2.2 (which is service@host with no escapes). The question is does the GSS_import_name function for GSSUP supposed to take anything else but a GSS_NT_EXPORT_NAME? I would say that if you wanted to generate the name for a user you would have to make a call for gss_name_t name; gss_import_name(minor, "user@scope", GSSUP_NT_GSSUPNAME, &name); char * exportedName; gss_export_name(minor, name, &exportName); Otherwise you have to construct the GSS Exported Name structure by hand. Cheers, -Polar > > > At most we could/should define the krb5 mechanism oid, and leave > > > it at that. > > > > Surely, but I still mandate the need to create a name that can be > > asserted in the Identity Token that doesn't adhere to any > > > particular > > format or mechanism. > > > > My thinking is that the GSSUP exported name object can assume this > > > role, > especially if there need not be name types for GSSUP. > > > So therefore in order to create a name, we need a MechanismOID to > > > "create" > > a name that can be asserted out of the blue. > > > > I wouldn't mind that just being a flat name (no delimiters, no > > > escaping). > > UTF-8 characters, and no scoping. > > > > So, let this resolution to 3972 go to a vote, and I'll raise an > > > issue > > based on this discussion. > > > > I would appreciate that, although I would also accept us working > > > this > out here; assuming we are close. > > Ron > > > Cheers, > > -Polar > > > > > > > > // The GSS Object Identifier allocated for the krb5 mechanism is > > > // defined below. > > > // > > > // { iso(1) member-body(2) United States(840) mit(113554) > > > // infosys(1) gssapi(2) krb5(2) } > > > > > > const CSI::StringOID KRB5MechOID = "oid:1.2.840.113554.1.2.2"; > > > > > > I think the gssup exported name form should be suitable for your > > > string > > > name case, I agreed to add another OID if you think you need it > > > but I > > > would much rather not. The OIDs in exported name objects are > > > mechanism > > > OIDS not name types. > > > > > > So if we add this OID, it would not be a "NameType", but a > > > synonym for > > > the GSSUP mechanism OID. > > > > > > Ron > > > > > > Polar Humenn wrote: > > > > > > > > Does anyone have minutes of the teleconference > > > yesterday. Sorry I had to > > > > miss it, I was busy catching a cold in a florida hotel in > > > which you > > > > couldn't open the windows. ( I don't get it, I sould have > > > brought my > > > > sleeping bag and slept outside on the lawn, I mean, c'mon! > > > Florida! > > > > Geeezz). > > > > > > > > Home, in bed, sniffling, > > > > -Polar > > > > > > > > > > > ------------------------------------------------------------------- > > > > Polar Humenn Adiron, LLC > > > > mailto:polar@adiron.com 2-212 CST > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Fri, 09 Feb 2001 17:57:14 -0500 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: Issue 3972 (was Re: Does anybody have minutes References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 3Z Since some applications may require MNs without wanting to incur the > overhead of an authentication operation, creation methods are > provided that take not only the name buffer and name type, but also > the mechanism oid for which this name should be created. Ron Polar Humenn wrote: > > On Thu, 8 Feb 2001, Ron Monzillo wrote: > > > > > > > Polar Humenn wrote: > > > > > > On Thu, 8 Feb 2001, Ron Monzillo wrote: > > > > > > > Polar, > > > > > > > > I'm about to send out a proposed resolution for 3972. > > > > I think I have covered the exported name form for GSSUP. > > > > > > > > There were some other items you included in this issue. > > > > > > > > 1. you defined a NameType and used it to define a constant for > > > > a kerberos name type. In the comments of the constant you say this > > > > oid is for use in the kereberos exported object. The OID you > > > > speced is not a name type, but a mechanism OID (I don't think we > > > > need a new type for such things), and we don't need to describe > > > > how it is used in kerberos exported name objects. By the way the > > > > kerberos principal name form has a differnt OID (it has krb5_name(1)) > > > > at then end. > > > > > > Well, then Kerberos GSSExportedName OID is the Mechanism OID for > > > Kerboeros, surely. However, the format of the name component is that of > > > KerberosPrincipalName. It has its own OID, but its OID does not show up in > > > the GSS exported name structure. It is implied. > > > > > > GSSUP has no explicit OID definition to refer to its name form. Do you > > > think it should? > > > > I don't see how it can, as its name forms, which I think are really an > > internal names, should be left unbound to facilitate the binding of the > > GSSAPI token exchange to any shared secret authentication mechanism > > (within the mechanism implementation). But I confess you told me some > > things about how name types are used in gssapi processing, which may > > force name types to be defined for use with GSSUP. I hope not. > > Well, the "internal" name format for a Kerberos name is a two part > structure (in C) of two fields "name" and "realm". However, that > is an implemenation issue, and that's why it's "internal". > > It has several "exported" name forms, such as GSS_NT_USER_NAME, > GSS_NT_SERVICE_NAME, .... GSS_NT_EXPORT_NAME, as well as KRB5_NT_KRB5_NAME > and KRB5_NT_KRB5_PRINCIPAL. These types are used for GSS_import_name as > the type parameter. Kerberos only exports to one type. > > For most "import" types that are not defined by the GSS_NT_* types, > kerberos has OIDs that point to their definitions. For instance, giving a > "GSS_import_name" call with a type of GSS_NT_SERVICE_NAME: > > * service_name: > * iso(1) member-body(2) US(840) mit(113554) infosys(1) gssapi(2) > * generic(1) service_name(4) = 1.2.840.113554.1.2.1.4 > > The OID of the corresponds directly to the syntax of a > KRB5_NT_SERVICE_NAME, which is krb5_principal type is: > > * iso(1) member-body(2) US(840) mit(113554) infosys(1) gssapi(2) > * krb5(2) krb5_principal(2) = 1.2.840.113554.1.2.2.2 > > (which is service@host with no escapes). > > The question is does the GSS_import_name function for GSSUP supposed to > take anything else but a GSS_NT_EXPORT_NAME? > > I would say that if you wanted to generate the name for a user you would > have to make a call for > > gss_name_t name; > > gss_import_name(minor, "user@scope", GSSUP_NT_GSSUPNAME, &name); > > char * exportedName; > > gss_export_name(minor, name, &exportName); > > Otherwise you have to construct the GSS Exported Name structure > by hand. > > Cheers, > -Polar > > > > > At most we could/should define the krb5 mechanism oid, and leave > > > > it at that. > > > > > > Surely, but I still mandate the need to create a name that can be > > > asserted in the Identity Token that doesn't adhere to any particular > > > format or mechanism. > > > > > > > My thinking is that the GSSUP exported name object can assume this role, > > especially if there need not be name types for GSSUP. > > > > > So therefore in order to create a name, we need a MechanismOID to "create" > > > a name that can be asserted out of the blue. > > > > > > I wouldn't mind that just being a flat name (no delimiters, no escaping). > > > UTF-8 characters, and no scoping. > > > > > > So, let this resolution to 3972 go to a vote, and I'll raise an issue > > > based on this discussion. > > > > > > > I would appreciate that, although I would also accept us working this > > out here; assuming we are close. > > > > Ron > > > > > Cheers, > > > -Polar > > > > > > > > > > > // The GSS Object Identifier allocated for the krb5 mechanism is > > > > // defined below. > > > > // > > > > // { iso(1) member-body(2) United States(840) mit(113554) > > > > // infosys(1) gssapi(2) krb5(2) } > > > > > > > > const CSI::StringOID KRB5MechOID = "oid:1.2.840.113554.1.2.2"; > > > > > > > > I think the gssup exported name form should be suitable for your string > > > > name case, I agreed to add another OID if you think you need it but I > > > > would much rather not. The OIDs in exported name objects are mechanism > > > > OIDS not name types. > > > > > > > > So if we add this OID, it would not be a "NameType", but a synonym for > > > > the GSSUP mechanism OID. > > > > > > > > Ron > > > > > > > > Polar Humenn wrote: > > > > > > > > > > Does anyone have minutes of the teleconference yesterday. Sorry I had to > > > > > miss it, I was busy catching a cold in a florida hotel in which you > > > > > couldn't open the windows. ( I don't get it, I sould have brought my > > > > > sleeping bag and slept outside on the lawn, I mean, c'mon! Florida! > > > > > Geeezz). > > > > > > > > > > Home, in bed, sniffling, > > > > > -Polar > > > > > > > > > > ------------------------------------------------------------------- > > > > > Polar Humenn Adiron, LLC > > > > > mailto:polar@adiron.com 2-212 CST > > > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > > > Fax: 315-443-4745 http://www.adiron.com > > > > > > > > > > ------------------------------------------------------------------- > > > Polar Humenn Adiron, LLC > > > mailto:polar@adiron.com 2-212 CST > > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > > Fax: 315-443-4745 http://www.adiron.com > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com Date: Tue, 13 Feb 2001 15:32:05 -0500 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn , csiv2-ftf@omg.org Subject: Re: Issue 3972 and 3922 References: <3A8475CA.AF48F8C1@east.sun.com> Content-Type: multipart/mixed; boundary="------------AA47326DA53343D375D5986C" X-UIDL: ``%e9na4e9"*^!!i"8e9 It took me longer to get back to this than I had hoped. I have attached revised proposals for 3922, and 3972. The combination of the changes embodied in these proposals should allow us to: 1. import a GSSUP exported name into an "internal" MN GSSName mechName = createName(exportedName, GSSName.NT_EXPORTED_NAME, GSSUPMechOID); 2. import a string name of form scoped username into an "internal" MN. GSSName mechName = createName("name@scope", GSSName.NT_SCOPED_USERNAME, GSSUPMechOID); 3. export an "internal" MN to an exported MN. byte [] exportedName = mechName.export(); I've approximately used the Java GSS-API bindings (from RFC 2853) just as an example. The main point, is that we needed to do all threee of the things listed above, and now I hope we have the necessary OIDs and syntaxes defined to get the job done. I don't think I will be attending tomorrow's conference call. I will try to call in, but I can't be sure that I will be able to. I will try to have someone from Sun replace me. If you have comments on these attached proposals, I will try to respond (today) via email. Ron Ron Monzillo wrote: > > Polar, > > I didn't have as much time to spend on this as I had hoped. > Have you looked at RFC 2853 GSS-API Java bindings. I know that > csiv2 has to be use in other than Java contexts, but I think > the GSSName interface of 2853 was designed to handle the type > of transformation you are interested in (among others) > > see the top of page 23. > > > Since some applications may require MNs without wanting to incur the > > overhead of an authentication operation, creation methods are > > provided that take not only the name buffer and name type, but also > > the mechanism oid for which this name should be created. > > Ron > > Polar Humenn wrote: > > > > On Thu, 8 Feb 2001, Ron Monzillo wrote: > > > > > > > > > > > Polar Humenn wrote: > > > > > > > > On Thu, 8 Feb 2001, Ron Monzillo wrote: > > > > > > > > > Polar, > > > > > > > > > > I'm about to send out a proposed resolution for 3972. > > > > > I think I have covered the exported name form for GSSUP. > > > > > > > > > > There were some other items you included in this issue. > > > > > > > > > > 1. you defined a NameType and used it to define a constant for > > > > > a kerberos name type. In the comments of the constant you say this > > > > > oid is for use in the kereberos exported object. The OID you > > > > > speced is not a name type, but a mechanism OID (I don't think we > > > > > need a new type for such things), and we don't need to describe > > > > > how it is used in kerberos exported name objects. By the way the > > > > > kerberos principal name form has a differnt OID (it has krb5_name(1)) > > > > > at then end. > > > > > > > > Well, then Kerberos GSSExportedName OID is the Mechanism OID for > > > > Kerboeros, surely. However, the format of the name component is that of > > > > KerberosPrincipalName. It has its own OID, but its OID does not show up in > > > > the GSS exported name structure. It is implied. > > > > > > > > GSSUP has no explicit OID definition to refer to its name form. Do you > > > > think it should? > > > > > > I don't see how it can, as its name forms, which I think are really an > > > internal names, should be left unbound to facilitate the binding of the > > > GSSAPI token exchange to any shared secret authentication mechanism > > > (within the mechanism implementation). But I confess you told me some > > > things about how name types are used in gssapi processing, which may > > > force name types to be defined for use with GSSUP. I hope not. > > > > Well, the "internal" name format for a Kerberos name is a two part > > structure (in C) of two fields "name" and "realm". However, that > > is an implemenation issue, and that's why it's "internal". > > > > It has several "exported" name forms, such as GSS_NT_USER_NAME, > > GSS_NT_SERVICE_NAME, .... GSS_NT_EXPORT_NAME, as well as KRB5_NT_KRB5_NAME > > and KRB5_NT_KRB5_PRINCIPAL. These types are used for GSS_import_name as > > the type parameter. Kerberos only exports to one type. > > > > For most "import" types that are not defined by the GSS_NT_* types, > > kerberos has OIDs that point to their definitions. For instance, giving a > > "GSS_import_name" call with a type of GSS_NT_SERVICE_NAME: > > > > * service_name: > > * iso(1) member-body(2) US(840) mit(113554) infosys(1) gssapi(2) > > * generic(1) service_name(4) = 1.2.840.113554.1.2.1.4 > > > > The OID of the corresponds directly to the syntax of a > > KRB5_NT_SERVICE_NAME, which is krb5_principal type is: > > > > * iso(1) member-body(2) US(840) mit(113554) infosys(1) gssapi(2) > > * krb5(2) krb5_principal(2) = 1.2.840.113554.1.2.2.2 > > > > (which is service@host with no escapes). > > > > The question is does the GSS_import_name function for GSSUP supposed to > > take anything else but a GSS_NT_EXPORT_NAME? > > > > I would say that if you wanted to generate the name for a user you would > > have to make a call for > > > > gss_name_t name; > > > > gss_import_name(minor, "user@scope", GSSUP_NT_GSSUPNAME, &name); > > > > char * exportedName; > > > > gss_export_name(minor, name, &exportName); > > > > Otherwise you have to construct the GSS Exported Name structure > > by hand. > > > > Cheers, > > -Polar > > > > > > > At most we could/should define the krb5 mechanism oid, and leave > > > > > it at that. > > > > > > > > Surely, but I still mandate the need to create a name that can be > > > > asserted in the Identity Token that doesn't adhere to any particular > > > > format or mechanism. > > > > > > > > > > My thinking is that the GSSUP exported name object can assume this role, > > > especially if there need not be name types for GSSUP. > > > > > > > So therefore in order to create a name, we need a MechanismOID to "create" > > > > a name that can be asserted out of the blue. > > > > > > > > I wouldn't mind that just being a flat name (no delimiters, no escaping). > > > > UTF-8 characters, and no scoping. > > > > > > > > So, let this resolution to 3972 go to a vote, and I'll raise an issue > > > > based on this discussion. > > > > > > > > > > I would appreciate that, although I would also accept us working this > > > out here; assuming we are close. > > > > > > Ron > > > > > > > Cheers, > > > > -Polar > > > > > > > > > > > > > > // The GSS Object Identifier allocated for the krb5 mechanism is > > > > > // defined below. > > > > > // > > > > > // { iso(1) member-body(2) United States(840) mit(113554) > > > > > // infosys(1) gssapi(2) krb5(2) } > > > > > > > > > > const CSI::StringOID KRB5MechOID = "oid:1.2.840.113554.1.2.2"; > > > > > > > > > > I think the gssup exported name form should be suitable for your string > > > > > name case, I agreed to add another OID if you think you need it but I > > > > > would much rather not. The OIDs in exported name objects are mechanism > > > > > OIDS not name types. > > > > > > > > > > So if we add this OID, it would not be a "NameType", but a synonym for > > > > > the GSSUP mechanism OID. > > > > > > > > > > Ron > > > > > Issue 3922: GSSUP Names are inconsistent other security mechanisms. Click here for this issue's archive. Source: Adiron (Polar Humenn, polar@adiron.com) Document: http://cgi.omg.org/cgi-bin/doc?orbos/2000-08-04 Nature: Uncategorized Issue Severity: Medium Summary: The names supplied in the InitialContextToken for the UserName password scheme invents a name type called a Security::ScopedName. This is just yet another name type that must be dealt with and is completely inconsistent with anything else used for names. The contents of the scope and the name are underspecified. Discussion: The username structure should allow for all forms of name types. The easiest way to do accomplish consistency is to use a GSS exported name type. Resolution: Close issue with revised text. Revised Text: The following modifications are presented against document http://cgi.omg.org/pub/csiv2-ftf/csiv2-0117011.pdf. with the assumption that the resolution of Issue 4141 has been applied. (Moving GSS_NT_ExportedName from Security to CSI). [1] Change the IDL between paragraphs 48 and 49 to the following: // GSSUP::InitialContextToken struct InitialContextToken { CSI::UTF8String username; CSI::UTF8String password; CSI::GSS_NT_ExportedName target_name; }; [2] Replace paragraph 49 with the following. The username component of a GSSUP::InitialContextToken shall be a contiguous string conforming to the scoped-username syntax, where name_value and name_scope contain a sequence of 1 or more UTF8 encoded characters. scoped-username ::= name_value | name_value@name_scope | @name_scope The '@' character shall be used to delimit name_value from name_scope. All non-delimiter instances of '@' and all non-quoting instances of '\' shall be quoted with an immediately-preceding '\'. Except for these cases, the quoting character, '\', shall not be emitted within a UTF8 encoded scoped-username. The Object Identifier corresponding to the GSS scoped-username name form is: {iso-itu-t (2) international-organization (23) omg (130) security (1) naming (2) scoped-username(1)} The target_name field of the GSSUP::InitialContextToken contains the name of the authentication domain in which the client is authenticating. This field aids the TSS in processing the authentication should the TSS support several authentication domains. A CSS shall fill the target_name field of the GSSUP::InitialContextToken with the contents of the target_name field of the CSIIOP::AS_ContextSec structure of the chosen CSI mechanism. [3] In Section 16.9.5, Module GSSUP change the definition InitialContextToken to the following: struct InitialContextToken { CSI::UTF8String username; CSI::UTF8String password; CSI::GSS_NT_ExportedName target_name; }; [3] In Section 16.9.6, Module CSI, add the following, after the definition of GSS_NT_ExportedNameList. // The GSS scoped-username name form is represented by the OID // {iso-itu-t (2) international-organization (23) omg (130) // security (1) naming (2) scoped-username(1)} const StringOID NT_Scoped_Username = "oid:2.23.130.1.2.1"; [4] In Section 16.9.5, Remove all extraneous definitons from the GSSUP module. Resolution to Issue 4141 introduces NameValue and ScopedName to the GSSUP module, which were moved from the Security Module. Actions taken: October 3, 2000: received issue DON FILL IN DATE HERE: closed issue Issue 3972: Format of GSSUP GSS exported name object undefined Click here for this issue's archive. Source: Sun Microsystems (Ron Monzillo, Ronald.Monzillo@east.sun.com) Document: http://cgi.omg.org/cgi-bin/doc?orbos/2000-08-04 Nature: Uncategorized Issue Severity: Critical Summary: Format of GSSUP GSS mechanism-independent exported name object, a special form of "flat" name as described below, is not defined. Discussion: Define a "flat name" type OID and format. It would also be good to have these OIDs specified somewhere. We can do that in IDL with string constants, using dot notation for OIDs. Resolution: Close issue with revised text. Revised Text: The following modifications are presented against document http://cgi.omg.org/pub/csiv2-ftf/csiv2-0117011.pdf. with the assumption that the resolution of Issue 4141 has been applied, i.e. Moving GSS_NT_ExportedName from Security to CSI, and the assumption that the resolution of Issue 4143 has been applied, i.e. creation of the CSI::StringOID type. [1] Add the following at the end (following para 54) of section 15.2.5 Identity Token Format GSS Exported Name Object Form for GSSUP Mechanism The mechanism OID within the exported name object shall be that of the GSSUP mechanism. {iso-itu-t (2) international-organization (23) omg (130) security (1) authentication (1) gssup-mechanism (1)} The name component within the exported name object shall be a contiguous string conforming to the following syntax, where name_value and name_scope contain a sequence of 1 or more UTF8 encoded characters. name component ::= name_value | name_value@name_scope | @name_scope The '@' character shall be used to delimit name_value from name_scope. All non-delimiter instances of '@' and all non-quoting instances of '\' shall be quoted with an immediately-preceding '\'. Except for these cases, the quoting character, '\', shall not be emitted within the name component of an exported name object. The name length component within the exported name object shall represent the length of the name component including any inserted quoting characters. The encoding of GSS mechanism-independent exported name objects is defined in [IETF RFC 2743]. [2] Insert the following definition in Section 16.9.6, Module CSI, after the definition of GSS_NT_ExportedNameList. // The GSS Object Identifier for the KRB5 mechanism is defined below. // // { iso(1) member-body(2) United States(840) mit(113554) // infosys(1) gssapi(2) krb5(2) } const StringOID KRB5MechOID = "oid:1.2.840.113554.1.2.2"; Actions taken: October 13, 2000: received issue DON FILL IN DATE HERE: closed issue X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 14 Feb 2001 09:46:32 -0500 (EST) From: Polar Humenn To: Ron Monzillo cc: csiv2-ftf@omg.org Subject: Re: Issue 3972 and 3922 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 2#h!!6I8e9(BB!!;:>e9 Greetings, Ron and I just had a discussion about some things he was concerned about that he piggy-backed in his resolutions to the 3922 and 3972 issues. The result of the conversation is to retract his resolution 3922-3, reverting back to the previous resolution, 3922-3. Ron will produce another version of 3972 momentarily. So, to keep the History of the World Part III going, I have created FTF-Issue3922-4.html, which is a copy of FTF-Issue3922-2.html, i.e. the current resolution. When Ron posts a new resolution for Issue 3972, it will be listed as FTF-Issue3972-5.html. The ftp site directory is ftp:://greene.case.syr.edu/pub/omg/csiv2-ftf. Cheers, -Polar On Wed, 14 Feb 2001, Polar Humenn wrote: > > I have put Ron's resolutions to issues on my ftp site as: > > ftp://greene.case.syr.edu/pub/omg/csiv2-ftf/FTF-Issue3972-4.html > ftp://greene.case.syr.edu/pub/omg/csiv2-ftf/FTF-Issue3922-3.html > > I am in agreement with these resolutions. > > Cheers, > -Polar > > On Tue, 13 Feb 2001, Ron Monzillo wrote: > > > It took me longer to get back to this than I had hoped. > > > > I have attached revised proposals for 3922, and 3972. The > combination of > > the changes embodied in these proposals should allow us to: > > > > 1. import a GSSUP exported name into an "internal" MN > > > > GSSName mechName = createName(exportedName, > > > GSSName.NT_EXPORTED_NAME, > > GSSUPMechOID); > > > > 2. import a string name of form scoped username into an "internal" > MN. > > > > GSSName mechName = createName("name@scope", > > > GSSName.NT_SCOPED_USERNAME, > > GSSUPMechOID); > > > > 3. export an "internal" MN to an exported MN. > > > > byte [] exportedName = mechName.export(); > > > > > > I've approximately used the Java GSS-API bindings (from RFC 2853) > just > > as an example. The main point, is that we needed to do all threee > of the > > things listed above, and now I hope we have the necessary OIDs and > > syntaxes defined to get the job done. > > > > I don't think I will be attending tomorrow's conference call. > > I will try to call in, but I can't be sure that I will be able to. > > I will try to have someone from Sun replace me. > > > > If you have comments on these attached proposals, I will try to > > respond (today) via email. > > > > Ron > > > > > > Ron Monzillo wrote: > > > > > > Polar, > > > > > > I didn't have as much time to spend on this as I had hoped. > > > Have you looked at RFC 2853 GSS-API Java bindings. I know that > > > csiv2 has to be use in other than Java contexts, but I think > > > the GSSName interface of 2853 was designed to handle the type > > > of transformation you are interested in (among others) > > > > > > see the top of page 23. > > > > > > > Since some applications may require MNs without wanting to > incur the > > > > overhead of an authentication operation, creation methods are > > > > provided that take not only the name buffer and name type, but > also > > > > the mechanism oid for which this name should be created. > > > > > > Ron > > > > > > Polar Humenn wrote: > > > > > > > > On Thu, 8 Feb 2001, Ron Monzillo wrote: > > > > > > > > > > > > > > > > > > > Polar Humenn wrote: > > > > > > > > > > > > On Thu, 8 Feb 2001, Ron Monzillo wrote: > > > > > > > > > > > > > Polar, > > > > > > > > > > > > > > I'm about to send out a proposed resolution for 3972. > > > > > > > I think I have covered the exported name form for GSSUP. > > > > > > > > > > > > > > There were some other items you included in this issue. > > > > > > > > > > > > > > 1. you defined a NameType and used it to define a > constant for > > > > > > > a kerberos name type. In the comments of the constant > you say this > > > > > > > oid is for use in the kereberos exported object. The OID > you > > > > > > > speced is not a name type, but a mechanism OID (I don't > think we > > > > > > > need a new type for such things), and we don't need to > describe > > > > > > > how it is used in kerberos exported name objects. By the > way the > > > > > > > kerberos principal name form has a differnt OID (it has > krb5_name(1)) > > > > > > > at then end. > > > > > > > > > > > > Well, then Kerberos GSSExportedName OID is the Mechanism > OID for > > > > > > Kerboeros, surely. However, the format of the name > component is that of > > > > > > KerberosPrincipalName. It has its own OID, but its OID > does not show up in > > > > > > the GSS exported name structure. It is implied. > > > > > > > > > > > > GSSUP has no explicit OID definition to refer to its name > form. Do you > > > > > > think it should? > > > > > > > > > > I don't see how it can, as its name forms, which I think are > really an > > > > > internal names, should be left unbound to facilitate the > binding of the > > > > > GSSAPI token exchange to any shared secret authentication > mechanism > > > > > (within the mechanism implementation). But I confess you > told me some > > > > > things about how name types are used in gssapi processing, > which may > > > > > force name types to be defined for use with GSSUP. I hope > not. > > > > > > > > Well, the "internal" name format for a Kerberos name is a two > part > > > > structure (in C) of two fields "name" and "realm". However, > that > > > > is an implemenation issue, and that's why it's "internal". > > > > > > > > It has several "exported" name forms, such as > GSS_NT_USER_NAME, > > > > GSS_NT_SERVICE_NAME, .... GSS_NT_EXPORT_NAME, as well as > KRB5_NT_KRB5_NAME > > > > and KRB5_NT_KRB5_PRINCIPAL. These types are used for > GSS_import_name as > > > > the type parameter. Kerberos only exports to one type. > > > > > > > > For most "import" types that are not defined by the GSS_NT_* > types, > > > > kerberos has OIDs that point to their definitions. For > instance, giving a > > > > "GSS_import_name" call with a type of GSS_NT_SERVICE_NAME: > > > > > > > > * service_name: > > > > * iso(1) member-body(2) US(840) mit(113554) infosys(1) > gssapi(2) > > > > * generic(1) service_name(4) = 1.2.840.113554.1.2.1.4 > > > > > > > > The OID of the corresponds directly to the syntax of a > > > > KRB5_NT_SERVICE_NAME, which is krb5_principal type is: > > > > > > > > * iso(1) member-body(2) US(840) mit(113554) infosys(1) > gssapi(2) > > > > * krb5(2) krb5_principal(2) = 1.2.840.113554.1.2.2.2 > > > > > > > > (which is service@host with no escapes). > > > > > > > > The question is does the GSS_import_name function for GSSUP > supposed to > > > > take anything else but a GSS_NT_EXPORT_NAME? > > > > > > > > I would say that if you wanted to generate the name for a user > you would > > > > have to make a call for > > > > > > > > gss_name_t name; > > > > > > > > gss_import_name(minor, "user@scope", GSSUP_NT_GSSUPNAME, > &name); > > > > > > > > char * exportedName; > > > > > > > > gss_export_name(minor, name, &exportName); > > > > > > > > Otherwise you have to construct the GSS Exported Name > structure > > > > by hand. > > > > > > > > Cheers, > > > > -Polar > > > > > > > > > > > At most we could/should define the krb5 mechanism oid, > and leave > > > > > > > it at that. > > > > > > > > > > > > Surely, but I still mandate the need to create a name that > can be > > > > > > asserted in the Identity Token that doesn't adhere to any > particular > > > > > > format or mechanism. > > > > > > > > > > > > > > > > My thinking is that the GSSUP exported name object can > assume this role, > > > > > especially if there need not be name types for GSSUP. > > > > > > > > > > > So therefore in order to create a name, we need a > MechanismOID to "create" > > > > > > a name that can be asserted out of the blue. > > > > > > > > > > > > I wouldn't mind that just being a flat name (no > delimiters, no escaping). > > > > > > UTF-8 characters, and no scoping. > > > > > > > > > > > > So, let this resolution to 3972 go to a vote, and I'll > raise an issue > > > > > > based on this discussion. > > > > > > > > > > > > > > > > I would appreciate that, although I would also accept us > working this > > > > > out here; assuming we are close. > > > > > > > > > > Ron > > > > > > > > > > > Cheers, > > > > > > -Polar > > > > > > > > > > > > > > > > > > > > // The GSS Object Identifier allocated for the krb5 > mechanism is > > > > > > > // defined below. > > > > > > > // > > > > > > > // { iso(1) member-body(2) United States(840) > mit(113554) > > > > > > > // infosys(1) gssapi(2) krb5(2) } > > > > > > > > > > > > > > const CSI::StringOID KRB5MechOID = > "oid:1.2.840.113554.1.2.2"; > > > > > > > > > > > > > > I think the gssup exported name form should be suitable > for your string > > > > > > > name case, I agreed to add another OID if you think you > need it but I > > > > > > > would much rather not. The OIDs in exported name objects > are mechanism > > > > > > > OIDS not name types. > > > > > > > > > > > > > > So if we add this OID, it would not be a "NameType", but > a synonym for > > > > > > > the GSSUP mechanism OID. > > > > > > > > > > > > > > Ron > > > > > > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com > ------------------------------------------------------------------- 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, 14 Feb 2001 10:54:07 -0500 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: Issue 3972 and 3922 References: Content-Type: multipart/mixed; boundary="------------E31779A8407DDB54107C9C28" X-UIDL: /50e98#&!!U_(e9@:2!! Polar Humenn wrote: > > Greetings, > > Ron and I just had a discussion about some things he was concerned about > that he piggy-backed in his resolutions to the 3922 and 3972 issues. The > result of the conversation is to retract his resolution 3922-3, reverting > back to the previous resolution, 3922-3. Ron will produce another version > of 3972 momentarily. > > So, to keep the History of the World Part III going, I have created > FTF-Issue3922-4.html, which is a copy of FTF-Issue3922-2.html, i.e. the > current resolution. > > When Ron posts a new resolution for Issue 3972, it will be listed as > FTF-Issue3972-5.html. I've attached a new proposal for 3972. Synopsis of what I changed. 1. I moved the definition of the scoped-username name form in line with the definition of the GSSUP exported name object. 2. I defined the exported name object by refering to the scoped-username name form 3. I removed the stuff about the length-component in the exported name object (as the reference to 2473 should be sufficient) 4. I changed name of the OID for the scoped-username name form 5. I added a const for the OID corresponding to a gss-api-exported-name, derived form RFC 2473. For reference, this proposal is intended to make sure that we can do the moral equivalent of the following things. > > 1. import a GSSUP exported name into an "internal" MN > > > > GSSName mechName = createName(exportedName, > > GSSName.NT_EXPORTED_NAME, > > GSSUPMechOID); > > > > 2. import a string name of form scoped username into an "internal" MN. > > > > GSSName mechName = createName("name@scope", > > GSSName.NT_SCOPED_USERNAME, > > GSSUPMechOID); > > > > 3. export an "internal" MN to an exported MN. > > > > byte [] exportedName = mechName.export(); I'll talk to you soon. Ron > > The ftp site directory is ftp:://greene.case.syr.edu/pub/omg/csiv2-ftf. > > Cheers, > -Polar > Issue 3972: Format of GSSUP GSS exported name object undefined Click here for this issue's archive. Source: Sun Microsystems (Ron Monzillo, Ronald.Monzillo@east.sun.com) Document: http://cgi.omg.org/cgi-bin/doc?orbos/2000-08-04 Nature: Uncategorized Issue Severity: Critical Summary: Format of GSSUP GSS mechanism-independent exported name object, a special form of "flat" name as described below, is not defined. Discussion: Define a "flat name" type OID and format. It would also be good to have these OIDs specified somewhere. We can do that in IDL with string constants, using dot notation for OIDs. Resolution: Close issue with revised text. Revised Text: The following modifications are presented against document http://cgi.omg.org/pub/csiv2-ftf/csiv2-0117011.pdf. with the assumption that the resolution of Issue 4141 has been applied, i.e. Moving GSS_NT_ExportedName from Security to CSI, and the assumption that the resolution of Issue 4143 has been applied, i.e. creation of the CSI::StringOID type. [1] Add the following at the end (following para 54) of section 15.2.5 Identity Token Format GSS Exported Name Object Form for GSSUP Mechanism The mechanism OID within the exported name object shall be that of the GSSUP mechanism. {iso-itu-t (2) international-organization (23) omg (130) security (1) authentication (1) gssup-mechanism (1)} The name component within the exported name object shall be a contiguous string conforming to the syntax of the scoped-username GSS name form. The encoding of GSS mechanism-independent exported name objects is defined in [IETF RFC 2743]. Scoped-Username GSS Name Form The scoped-username GSS name form is defined as follows, where name_value and name_scope contain a sequence of 1 or more UTF8 encoded characters. scoped-username ::= name_value | name_value@name_scope | @name_scope The '@' character shall be used to delimit name_value from name_scope. All non-delimiter instances of '@' and all non-quoting instances of '\' shall be quoted with an immediately-preceding '\'. Except for these cases, the quoting character, '\', shall not be emitted within a scoped-username. The Object Identifier corresponding to the GSS scoped-username name form is: {iso-itu-t (2) international-organization (23) omg (130) security (1) naming (2) scoped-username(1)} [2] Insert the following definitions in Section 16.9.6, Module CSI, after the definition of GSS_NT_ExportedNameList. // The GSS Object Identifier for the KRB5 mechanism is: // // { iso(1) member-body(2) United States(840) mit(113554) // infosys(1) gssapi(2) krb5(2) } const StringOID KRB5MechOID = "oid:1.2.840.113554.1.2.2"; // The GSS Object Identifier for name objects of the // Mechanism-idependent Exported Name Object type is: // {iso(1) org(3) dod(6) internet(1) security(5) nametypes(6) // gss-api-exported-name(4)} const StringOID GSS_NT_Export_Name_OID = "oid:1.3.6.1.5.6.4"; // The GSS Object Identifier for the scoped-username name form is: // {iso-itu-t (2) international-organization (23) omg (130) // security (1) naming (2) scoped-username(1)} const StringOID GSS_NT_Scoped_Username_OID = "oid:2.23.130.1.2.1"; Actions taken: October 13, 2000: received issue DON FILL IN DATE HERE: closed issue From: "Don Flinn" To: "csiv2-ftf" Subject: Issues 3922, 3948 & 3972 Date: Wed, 14 Feb 2001 15:05:05 -0500 Message-ID: <000201c096c1$6c6e8210$7985413f@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 2_