Issue 3948: GSSUP names are incompatible with the Identity Token (csiv2-ftf) Source: Syracuse University (Dr. Polar Humenn, polar(at)adiron.com) Nature: Uncategorized Issue Severity: Critical Summary: The name type used in the GSSUP mechanism for Client Authentication over the transport name type is not convertible to anything used by the Identity Token. This situation becomes a problem when on the server side where you need to quote, (i.e. identity assert) the client's authenticated identity to another CSIv2 CORBA outcall on behalf of the client. Resolution: Close issue as duplicate of 3922 Revised Text: Actions taken: October 13, 2000: received issue October 3, 2001: closed issue Discussion: The solution is to change the GSSUP name type to a GSS_NT_ExportedName form, where it can easily be lifted. This is also the subject of another previous issue raised about GSSUP name types. This solution will solve both problems. End of Annotations:===== X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Fri, 13 Oct 2000 08:56:25 -0400 (EDT) From: Polar Humenn To: issues@omg.org, csiv2-ftf@omg.org Subject: GSSUP names are incompatible with the Identity Token Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ^R,!!K_9e9^a 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 00:42:48 -0500 (EST) From: Polar Humenn To: csiv2-ftf@omg.org Subject: Proposed Vote Resolution to Issues 3922 and 3948 Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-427817617-1631508336-979796568=:21162" X-UIDL: l$Fe9:f_!!N+D!!#8Ee9 Attached are Proposed Vote Resolutions to the following issues: Issue 3922: GSSUP Names are inconsistent other security mechanisms. Issue 3948: GSSUP names are incompatible with the Identity Token. Resolution of 3948 declares it as a duplicate of issue 3922. Resolution of issue 3922 calmly changes the definition of the username field of the GSSUP InitialToken to a GSS_NT_ExportedName. 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-Issue3948.html [] FTF-Issue3922.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 > > > > > 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 > ------------------------------------------------------------------- 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 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 { > > > 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_