Issue 3922: GSSUP Names are inconsistent other security mechanisms. (csiv2-ftf) Source: Syracuse University (Dr. Polar Humenn, polar(at)adiron.com) Nature: Uncategorized Issue Severity: Minor Summary: Document: orbos/2000-08-04 CSIv2 Joint Submission Subject: GSSUP Names are inconsistent other security mechanisms. Severity: Medium Summary: The names supplied in the InitialContextToken for the UserName password scheme invents a name type called a Security::ScopedName. This is just yet another name type that must be dealt with and is completely inconsistent with anything else used for names. The contents of the scope and the name are underspecified. Discussion: The structure should allow for all forms of name types. The easiest way to do accomplish consistency is to use a GSS exported Name type. struct InitialContextToken { Security::GSS_NT_ExportedName username; Security::UTF8String password; }; That way a password database can even store names that are DN's, X509GeneneralNames, Kerberos Names, NT Usernames, etc. Resolution: Close issue with revised text Revised Text: The following modifications are presented against document http://cgi.omg.org/pub/csiv2-ftf/csiv2-0117011.pdf. with the assumption that the resolution of Issue 4141 has been applied. (Moving GSS_NT_ExportedName from Security to CSI). [1] Change the IDL between paragraphs 48 and 49 to the following: // GSSUP::InitialContextToken struct InitialContextToken { CSI::UTF8String username; CSI::UTF8String password; CSI::GSS_NT_ExportedName target_name; }; [2] Replace paragraph 49 with the following. The target_name field of the GSSUP::InitialContextToken contains the name of the authentication domain in which the client is authenticating. This field aids the TSS in processing the authentication should the TSS support several authentication domains. A CSS shall fill the target_name field of the GSSUP::InitialContextToken with the contents of the target_name field of the CSIIOP::AS_ContextSec structure of the chosen CSI mechanism. [3] In Section 16.9.5, Module GSSUP change the definition InitialContextToken to the following: struct InitialContextToken { CSI::UTF8String username; CSI::UTF8String password; CSI::GSS_NT_ExportedName target_name; }; [4] In Section 16.9.5, Remove all extraneous definitons from the GSSUP module. Resolution to Issue 4141 introduces NameValue and ScopedName to the GSSUP module, which were moved from the Security Module. Actions taken: September 28, 2000: received issue October 3, 2001: closed issue Discussion: End of Annotations:===== X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 28 Sep 2000 17:13:01 -0400 (EDT) From: Polar Humenn To: issues@omg.org, csiv2-ftf@omg.org, secrev@omg.org Subject: GSSUP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: <(+!!4,Qe9/22!!+IXd9 As much as I hate using this Username Password mechanism for CSIv2 it has a naming issue with is largely not well defined. Issue: Document: orbos/2000-08-04 CSIv2 Joint Submission Subject: GSSUP Names are inconsistent other security mechanisms. Severity: Medium Summary: The names supplied in the InitialContextToken for the UserName password scheme invents a name type called a Security::ScopedName. This is just yet another name type that must be dealt with and is completely inconsistent with anything else used for names. The contents of the scope and the name are underspecified. Discussion: The structure should allow for all forms of name types. The easiest way to do accomplish consistency is to use a GSS exported Name type. struct InitialContextToken { Security::GSS_NT_ExportedName username; Security::UTF8String password; }; That way a password database can even store names that are DN's, X509GeneneralNames, Kerberos Names, NT Usernames, etc. ------------------------------------------------------------------- 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 > > > > > X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 23 Jan 2001 14:37:52 -0500 (EST) From: Polar Humenn To: Ron Monzillo cc: csiv2-ftf@omg.org Subject: Re: [Fwd: GSSUP related issues] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: -Xdd9KQW!!88@!!YY,e9 Actually, now that I got the email back I find I have an error in my Kerberos example: (the target name was wrong, below I labeled a host, when I should have labeled the TGT service for the realm): I'll just post the corrected version here: The GSSUP Token: struct InitialContextToken { username = polar password = xxxxxx target_name = {oid:1.2.840.113554.1.2.2,krbtgt/ADIRON.COM@ADIRON.COM} } Should generate, after successfully applied to "kinit" a GSS_NT_ExportName of: {oid:1.2.840.113554.1.2.2,polar@ADIRON.COM} which can be used in an Identity Assertion further on down the line. Cheers, -Polar On Tue, 23 Jan 2001, Polar Humenn wrote: > > Ron, > > I am only going to address your points in a general fashion. > > If this is the GSSUP initial token you propose: > > struct InitialContextToken { > UTF8String username; > UTF8String password; > GSS_NT_exported_name target_name; > }; > > > I can live with that. In most cases, a user/password scheme is > definitely > an interactive thing requiring typing, so strings are okay, > especially if > you want to use this to handle "embody" a target with your identity, > for a > particular authentication scheme, such as Kerberos, SASL, and other > various yet unknown mechanisms. > > The part that worries me is that there is a distinct mapping from > the name > type OID in the target name to the OID of the mechanism that will be > used. > But we just must have to bite the bullet on that and make it so. > For Kerberos, it will work. > > I'll agree with this form, because all these mechanisms should have > some > canonical version of the name. So, I think you are getting at the > following scenario: > > GSSUP > Token ---target_name---\ > | > find mech > | > \ -------------- > ---> | Auth Mech | > | | > ---username ------------>| | > ---password ------------>| | > --------------- > | > GSS_ExportName() > | > \/ > GSS_NT_ExportedName > > > For example: (oid:1.2.840.113554.1.2.2) is KerberosV5. > > The GSSUP Token: > > struct InitialContextToken { > username = polar > password = xxxxxx > target_name = > {oid:1.2.840.113554.1.2.2,host/m1.adiron.com@ADIRON.COM} > } > > Should generate, after successfully applied to "kinit" a > GSS_NT_ExportName > of: > > {oid:1.2.840.113554.1.2.2,polar@ADIRON.COM} > > which can be used in an Identity Assertion further on down the line. > > We do need a name type for other authentication mechanisms that may > not be > defined, as needed. I can see two immediate needs. "Unix" or an NIS > name. > I'm not really sure what these names would look like in an > GSS_NT_ExportedName format (i.e. sometimes the hostname or domain > name is > useful, but not necessary). However we should define one for use > with > that mechanism, or start an RFP for it. > > Other ones, would be user defined, of which I came up with a name > type > for StringName. I think in a letter you didn't like that, but I > haven't > investigated why. > > The basic upshot is that I like this approach, as long as each OID > used > has an Exported Name format that can be asserted in an Identity > Token, or > otherwise, it doesn't really do much good. > > Cheers, > -Polar > > > > > On Mon, 22 Jan 2001, Ron Monzillo wrote: > > > I patched two messages together, because despite the pain that > > looking at the requirements may cause, I'd like to keep track of > them. > > > > I'll try to be brief in my comments. > > > > Ron Monzillo wrote: > > > > > No, you should not infer that. I like some of the motivation for > > > doing as you say, while at the same time I think it creates some > > > problems, which I need to think about a little more. > > > > > > I will respond with specifics later today. > > > > > > Ron > > > Polar Humenn wrote: > > > > > > > > Ron, > > > > > > > > Just so I understand, am I correct in understanding your > message below, > > > > without referring to all the Bs and Cs and bits of other > messages, that > > > > you in favor of making the GSSUP Initial Context Token have > the following > > > > format: > > > > > > > > struct InitialContextToken { > > > > CSI:GSS_NT_ExportedName username; > > > > CSI::UTF8String password; > > > > }; > > > > > > > > Cheers, > > > > -Polar > > > > Polar Humenn wrote: > > > > > > Ron, > > > > > > First of all let me say that I'm a bit confused over the > > > requirements/reasons you give for the need of GSSUP. See below. > > > > > > On Thu, 18 Jan 2001, Ron Monzillo wrote: > > > > > > > David, > > > > > > > > As noted in my last msg on this subject, approach 2, should > not > > > > be considered further in any effort to satisfy POTENTIAL > reasons > > > > C with B (as repeated below) for wanting to use GSSUP. > > > > > > > > > A. access a non-GSSAPI username password authentication > mechanism from > > > > > a communications protocol using GSSUP as a GSSAPI > mechanism. > > > > > > I don't understand this "access a non-GSSAPI" username password > > > autthencation mechanism. We have created one, it's called GSSUP, > it DOES > > > username/password, it is GSS-API. > > > > GSSUP can be used to send usernames and passwords to an > > existing authentication mechanism/user database that (prior to > GSSUP) > > did not support remote authentication via GSSAPI. > > > > > > > > > > B. do username password authentication where the target > GSSAPI > > > > > authentication mechanism does not support > username-password > > > > > authentication via its ICT. > > > > > > I don't understand why you need to do username/password > authentication > > > where the target doesn't support it. I'm really a little lost on > this one. > > > But I really don't want to get into pedantic discussions ad > nausem. > > > > > > > because you want a light-weight way to authenticate an identity > (such as > > a K5 principal) whose corresponding GSSAPI mechanism (that is K5) > may > > require more (than GSSUP) client infrastructure or a more > sophisticated > > client configuration than can be imposed on your clients. > > > > > C. establish a GSSAPI mechanism specific authentication > identity (an > > > > > exported name) as the result of either A. or B. > > > > > > The establishment of this GSSUP mechanism that has as its > username > > > component a GSS Exported Name would be extremely benefical and > simple. > > > > > > The following scenario applies: > > > > > > Client ---- GSSUP Token containing -----> Intermediate > > > GSS_NT_ExportedName > > > > > > Intermediate works on behalf of Client. > > > > > > Intermediate --->> Identity Token containing ----> Target > > > GSS_NT_ExportedName > > > > > > Target supports the particular naming type. This name is lifted > directly > > > from Client's GSSUP Token, quite possibly without the security > service > > > even looking inside of it. (The security service can merely hand > the > > > username/password combo to a password validation service), okay, > then move > > > on. Amazingly Simple. No hoops to jump through. > > > > > > > I'll talk about hoops later. But for now, I' like to say that > there is > > another potential reason for what I call using GSSUP as a pseudo > > mechanism, > > that I'll call reason B2. That is, sometimes we want to send a > username > > password to an intermediate, so that we can create an Initial > Login > > Context, that we can then use either via an assertion, or directly > in > > CAT tokens. The reasons for doing this are not really different > then > > those listed for B. > > > > > Using the GSS_NT_ExportedName makes for a clean implemenation > and is > > > consistent with the naming issues of the rest of the spec. Added > benefit, > > > it gives flexibility that allows most any name form to be used, > such as a > > > DN, even a KerberosName, or a simple "flat" string name, a > certificate, > > > etc. > > > > > > I have taken to promoting this type of solution in: > > > > > > > ftp://greene.case.syr.edu/pub/omg/csiv2-ftf/FTF-Issue3922.html > > > > > > of which I highly recommend. > > > > > ... > > > > ... > > > > > > > > (C)establish (i.e authenticate) a GSSAPI mechanism specific > > > > authentication identity (an exported name) where (B) the > target GSSAPI > > > > authentication mechanism does not support username-password > > > > authentication via its ICT. > > > > > > I still don't understand this. GSSUP sends two pieces of data. A > name, and > > > a password. We are not talking about anything else but GSSUP, > and that is > > > username/password. I don't really care as if the target calls > "kinit" with > > > the information, it's still username/password. > > > > > > > this is an example of what I call reason B (or using GSSUP as a > pseudo > > mechanism), and the extra (that is in addition to GSSUP) thing we > are > > talking about is (in your example) the fact that there is an > existing > > kerberos GSSAPI mechanism with a corresponding exported name form. > > > > If we want to use GSSUP as a pseudo-mechanism, then I agree that > we > > need an internal mechanism OID in the GSSUP ICT. However, doing so > by > > requiring a client side ability to export the corresponding > mechanism > > specific name form just moves the hoop to the client, which > requires > > that a client have mechanism specific name exporting code in order > to > > use GSSUP with another mechanism (such as kerberos). > > > > I admit that the scenario you propose for asserting through an > > intermediate is interesting, but I think you are worrying about > the > > wrong hoops. > > > > 1. The intermediate better jump though the hoop of making sure > that the > > exported name proposed by the client is the same one that is > proven by > > authentication, otherwise it might not be passing the proper > identity > > forward. In a kerberos environment, let's say the client is not > > configured as a kerberos client, and does not know the realm of > the > > intermediate. It > > fabricates a kerberos exported name containing the username as > > principal) without realm. The intermediate authenticates the > principal, > > in the default realm. The principal that gets sent forward (by the > > intermediate) should not be the one sent by the client, but the > realm > > annotated one that was authenticated by the mechanism at the > > intermediate. > > > > I think the intermediate should call accept_context, and then > export > > from the accepted context if it wants to assert forward. All > GSSAPI/CAT > > mechanisms should work like this, not just GSSUP. > > > > In addition to assertion, the intermediate should also be able to > > fabricate a mechanism specific ICT (i.e. a k5 ICT) to support the > B2 > > scenario identified above. Note that we don't want them to be able > to do > > this for GSSUP (without an internal mechanism). > > > > 2. Making the client pass mechanism specific exported name forms > in its > > GSSUP authenticators imposes a requirement on the client to have > > mechanism specific code to create specific exported forms. It also > > constrains the use of GSSUP by a client only to those mechanisms > for > > which it has exported name support. > > > > I would prefer that the GSSUP ICT look as follows: > > > > struct InitialContextToken { > > UTF8String username; > > UTF8String password; > > GSS_NT_exported_name target_name; > > }; > > > > The target_name would be as specified in the target IOR of the > mechanism > > being responded to by the client. The target_name field is > optional in > > the IOR. If there is a target_name in the IOR it at least contains > an > > OID > > that identifies a GSSAPI mechanism. The client would not have to > > understand these internal OIDs. The string following the OID, if > > present, would be presented to the user, as a cue for the scope in > which > > it must provide a username and password. In the simple GSSUP use > case, > > if a target_name is specified it will contain the GSSUP OID. In > the > > pseudo mechanism case, it will carry an internal mechanism OID > (e.g. > > KRB5). In either case, the value in this field would be directly > taken > > by the client from the IOR, and used to identify the mechanism > > definition being responded to by the client. > > > > The TSS would use the received target_name to identify the > AScontext, > > and the resulting client authentication name form (as a GSS > exported > > name). > > > > In the simple use case, no, other that GSSUP OID, internal > mechanism > > OID would appear in the mechanism selected by the client from the > IOR > > or the ICT fabricated by the client. In this case, the resulting > client > > identity (suitable for assertion) would be something like that > > originally > > defined when this issue was opened. That is, the username > separated by > > an '@' from the GSSUP authentication scope of the target (with > > appropriate byte stuffing to accommodate any embedded '@'s in the > the > > username). > > > > I think this proposal supports the identified scenarios without > imposing > > any additional requirements for name support on the originating > client. > > It does define a new catchall exported name form for GSSUP > (identity > > assertions and a name form to be understood by users). > > > > I considered using the username name form defined by kerberos and > > included in section 2.2.1 of RFC 2473 as the catchall exported > name > > form, but I think it better to be able to carry a notion of scope > > forward which the username form does not provide for (as it is > intended > > to identify a user on a local system). > > > > So, I would like to resolve issues 3922 and 3972 differently than > the > > poposals that you have made. > > > > I need to go home now. > > > > Ron > > > > > > using GSSUP with an inner context token containing a kerberos > (esported) > > > > principal name, and password would be an example of this use > case. > > > > > > Huh????? That is username password. If you are talking about > sending a > > > kerberos ticket, that is a different mechanism than GSSUP, and > works quite > > > nicely, I might add. > > > > > > Cheers, > > > -Polar > > > > > > > > > > > Ron > > > > > > > > Polar Humenn wrote: > > > > > > > > > > On Wed, 17 Jan 2001, David Chang wrote: > > > > > > > > > > > Ron, > > > > > > > > > > > > Does the Approach 2 use the format of the username in the > > > > > > InitilaContextToken to distinguish to the mechanism type > instead of the > > > > > > mechanism OID? > > > > > > > > > > > > struct InitialContextToken { > > > > > > UTF8String username; // for GSSUP username | > username@scope > > > > > > UTF8String password; > > > > > > }; > > > > > > > > > > > > Please clarify. > > > > > > > > > > I would think not. Also, in this case the username cannot be > a DN, it must > > > > > be a flat name with no designation of type of name. Of > course it could > > > > > always be a string version of a DN, but you wouldn't know > it. I still > > > > > think the GSS_NT_ExportName would be the better option. > > > > > > > > > > Cheers, > > > > > -Polar > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > David Chang > > > > > > > > > > > > WebSphere Security Architect & Team Lead > > > > > > IBM SWS Division, Internal Mail Stop 9131 > > > > > > Austin, Tx 78758 > > > > > > E-Mail:dyc@us.ibm.com > > > > > > Phone:(512)838-0559, T/L 678-0559 > > > > > > Fax: (512)838-1032 > > > > > > > > > > > > > > > > > > Ron Monzillo on 01/16/2001 > 05:35:55 PM > > > > > > > > > > > > To: csiv2-ftf@omg.org > > > > > > cc: > > > > > > Subject: [Fwd: GSSUP related issues] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Content-Transfer-Encoding: 7bit > > > > > > Content-Type: text/plain; charset=us-ascii > > > > > > > > > > > > I promised to start the discussion on the following issues > > > > > > > > > > > > Issue 3948: GSSUP names are incompatible with the Identity > Token > > > > > > Issue 3972: Format of GSSUP GSS exported name object > undefined > > > > > > > > > > > > The crux of these issues is really whether or not GSSUP > should be > > > > > > considered a full-fledged GSSAPI mechanism or a > "pseudo-mechanism". > > > > > > > > > > > > The solution proposed to issue 3948 is that GSSUP be > treated as a > > > > > > pseudo- mechanism. According to this proposal, the GSSUP > Initial Context > > > > > > Token (ICT) would be modified to carry a mechanism > (i.e. kereberos, > > > > > > unix,..) specific GSS exported name. The implication of > the proposal is > > > > > > that there would not be an exported name form for the > GSSUP mechanism. > > > > > > > > > > > > The solution proposed to issue 3972 is to define the > exported name form > > > > > > of the GSSUP mechanism, such that it in addition to the > existing > > > > > > definition of the GSSUP ICT, we will also have defined an > exported name > > > > > > form to be used in GSSUP Identity Assertions. > > > > > > > > > > > > These two issues have a different focus, and thus > different proposals > > > > > > have been made. In general the respective proposals may be > summarized as > > > > > > follows: > > > > > > > > > > > > 3948. GSSUP as a pseudo mechanism would be used to > authenticate GSSAPI > > > > > > identities of other types (i.e. Kerberos, unix). > > > > > > > > > > > > 3972. GSSUP as a full-fledged mechanism would be used to > authenticate > > > > > > full-fledged GSSUP (realm/scope specific) identities. > > > > > > > > > > > > We wrote the submission with our intent being focused on > something like > > > > > > that proposed in 3972. It is also clear that this approach > was not > > > > > > completed in the submission, as we neglected to define a > GSSUP exported > > > > > > name form. > > > > > > > > > > > > The proposed solution to 3948 would attempt to more > tightly integerate > > > > > > the GSSUP mechanism with security mechanisms for which > there is at least > > > > > > a defined GSSAPI exported name form. We would presumably > do this to be > > > > > > able to use GSSUP to > > > > > > > > > > > > A. access a non-GSSAPI username password authentication > mechanism from > > > > > > a communications protocol using GSSUP as a GSSAPI > mechanism. > > > > > > > > > > > > B. do username password authentication where the target > GSSAPI > > > > > > authentication mechanism does not support > username-password > > > > > > authentication via its ICT. > > > > > > > > > > > > C. establish a GSSAPI mechanism specific authentication > identity (an > > > > > > exported name) as the result of either A. or B. > > > > > > > > > > > > We created GSSUP for reason A. The Proposed solution to > 3972 only > > > > > > addresses reason A. The proposed solution to 3948 > addresses reasons B > > > > > > and C, in that it limits the use of GSSUP to those > mechanisms for which > > > > > > there is a defined exported name form. > > > > > > > > > > > > The proposed solution to 3972 (the definition of a GSSUP > exported name > > > > > > form) insures that reason A, can be satisfied in all > contexts. > > > > > > > > > > > > The proposed solution to 3972 also ensures that we need > not add (to > > > > > > conformance level 0) any requirement to support additional > GSSAPI > > > > > > mechanisms (that is, their name formats). > > > > > > > > > > > > If we begin with the proposed resolution of 3972 as a > baseline, then we > > > > > > can determine if we want to extend the semantics of the > GSSUP mechanism > > > > > > to satisfy reasons B and C, in which case, we might blend > the solution > > > > > > of 3972 and 3948. > > > > > > > > > > > > Approach 1: > > > > > > > > > > > > That is, the GSSUP ICT Name and Scope could be replaced by > a mechanism > > > > > > specific exported name form of type corresponding to the > OID of the > > > > > > target_name in the AS_ContextSec structure. GSSUP itself > would be a > > > > > > legitimate value for the type OID in the target_name. > > > > > > > > > > > > The inner contents of the GSSUP ICT would be as follows > (preceded by the > > > > > > GSSUP OID). > > > > > > > > > > > > struct InitialContextToken { > > > > > > GSS_NT_exported_name username; > > > > > > UTF8String password; > > > > > > }; > > > > > > > > > > > > Approach 2: > > > > > > > > > > > > Alternatively, we could use the target_name OID to > establish and > > > > > > interpret the form of the name sent and received in a > GSSUP ICT. > > > > > > Mechanism specific (as defined by the target_name OID's) > flat name > > > > > > strings obtained from the user would be sent in name_scope > and > > > > > > name_value. > > > > > > > > > > > > The inner contents of the GSSUP ICT would be as follows > (preceded by the > > > > > > GSSUP OID. > > > > > > > > > > > > struct ScopedName { > > > > > > NameValue name_scope; > > > > > > NameValue name_value; > > > > > > }; > > > > > > > > > > > > struct InitialContextToken { > > > > > > ScopedName username; > > > > > > UTF8String password; > > > > > > }; > > > > > > > > > > > > So to reiterate, if we begin with the proposedPolar Humenn > Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Tue, 13 Feb 2001 15:32:05 -0500 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn , csiv2-ftf@omg.org Subject: Re: Issue 3972 and 3922 References: <3A8475CA.AF48F8C1@east.sun.com> Content-Type: multipart/mixed; boundary="------------AA47326DA53343D375D5986C" X-UIDL: ``%e9na4e9"*^!!i"8e9 It took me longer to get back to this than I had hoped. I have attached revised proposals for 3922, and 3972. The combination of the changes embodied in these proposals should allow us to: 1. import a GSSUP exported name into an "internal" MN GSSName mechName = createName(exportedName, GSSName.NT_EXPORTED_NAME, GSSUPMechOID); 2. import a string name of form scoped username into an "internal" MN. GSSName mechName = createName("name@scope", GSSName.NT_SCOPED_USERNAME, GSSUPMechOID); 3. export an "internal" MN to an exported MN. byte [] exportedName = mechName.export(); I've approximately used the Java GSS-API bindings (from RFC 2853) just as an example. The main point, is that we needed to do all threee of the things listed above, and now I hope we have the necessary OIDs and syntaxes defined to get the job done. I don't think I will be attending tomorrow's conference call. I will try to call in, but I can't be sure that I will be able to. I will try to have someone from Sun replace me. If you have comments on these attached proposals, I will try to respond (today) via email. Ron Ron Monzillo wrote: > > Polar, > > I didn't have as much time to spend on this as I had hoped. > Have you looked at RFC 2853 GSS-API Java bindings. I know that > csiv2 has to be use in other than Java contexts, but I think > the GSSName interface of 2853 was designed to handle the type > of transformation you are interested in (among others) > > see the top of page 23. > > > Since some applications may require MNs without wanting to incur the > > overhead of an authentication operation, creation methods are > > provided that take not only the name buffer and name type, but also > > the mechanism oid for which this name should be created. > > Ron > > Polar Humenn wrote: > > > > On Thu, 8 Feb 2001, Ron Monzillo wrote: > > > > > > > > > > > Polar Humenn wrote: > > > > > > > > On Thu, 8 Feb 2001, Ron Monzillo wrote: > > > > > > > > > Polar, > > > > > > > > > > I'm about to send out a proposed resolution for 3972. > > > > > I think I have covered the exported name form for GSSUP. > > > > > > > > > > There were some other items you included in this issue. > > > > > > > > > > 1. you defined a NameType and used it to define a constant for > > > > > a kerberos name type. In the comments of the constant you say this > > > > > oid is for use in the kereberos exported object. The OID you > > > > > speced is not a name type, but a mechanism OID (I don't think we > > > > > need a new type for such things), and we don't need to describe > > > > > how it is used in kerberos exported name objects. By the way the > > > > > kerberos principal name form has a differnt OID (it has krb5_name(1)) > > > > > at then end. > > > > > > > > Well, then Kerberos GSSExportedName OID is the Mechanism OID for > > > > Kerboeros, surely. However, the format of the name component is that of > > > > KerberosPrincipalName. It has its own OID, but its OID does not show up in > > > > the GSS exported name structure. It is implied. > > > > > > > > GSSUP has no explicit OID definition to refer to its name form. Do you > > > > think it should? > > > > > > I don't see how it can, as its name forms, which I think are really an > > > internal names, should be left unbound to facilitate the binding of the > > > GSSAPI token exchange to any shared secret authentication mechanism > > > (within the mechanism implementation). But I confess you told me some > > > things about how name types are used in gssapi processing, which may > > > force name types to be defined for use with GSSUP. I hope not. > > > > Well, the "internal" name format for a Kerberos name is a two part > > structure (in C) of two fields "name" and "realm". However, that > > is an implemenation issue, and that's why it's "internal". > > > > It has several "exported" name forms, such as GSS_NT_USER_NAME, > > GSS_NT_SERVICE_NAME, .... GSS_NT_EXPORT_NAME, as well as KRB5_NT_KRB5_NAME > > and KRB5_NT_KRB5_PRINCIPAL. These types are used for GSS_import_name as > > the type parameter. Kerberos only exports to one type. > > > > For most "import" types that are not defined by the GSS_NT_* types, > > kerberos has OIDs that point to their definitions. For instance, giving a > > "GSS_import_name" call with a type of GSS_NT_SERVICE_NAME: > > > > * service_name: > > * iso(1) member-body(2) US(840) mit(113554) infosys(1) gssapi(2) > > * generic(1) service_name(4) = 1.2.840.113554.1.2.1.4 > > > > The OID of the corresponds directly to the syntax of a > > KRB5_NT_SERVICE_NAME, which is krb5_principal type is: > > > > * iso(1) member-body(2) US(840) mit(113554) infosys(1) gssapi(2) > > * krb5(2) krb5_principal(2) = 1.2.840.113554.1.2.2.2 > > > > (which is service@host with no escapes). > > > > The question is does the GSS_import_name function for GSSUP supposed to > > take anything else but a GSS_NT_EXPORT_NAME? > > > > I would say that if you wanted to generate the name for a user you would > > have to make a call for > > > > gss_name_t name; > > > > gss_import_name(minor, "user@scope", GSSUP_NT_GSSUPNAME, &name); > > > > char * exportedName; > > > > gss_export_name(minor, name, &exportName); > > > > Otherwise you have to construct the GSS Exported Name structure > > by hand. > > > > Cheers, > > -Polar > > > > > > > At most we could/should define the krb5 mechanism oid, and leave > > > > > it at that. > > > > > > > > Surely, but I still mandate the need to create a name that can be > > > > asserted in the Identity Token that doesn't adhere to any particular > > > > format or mechanism. > > > > > > > > > > My thinking is that the GSSUP exported name object can assume this role, > > > especially if there need not be name types for GSSUP. > > > > > > > So therefore in order to create a name, we need a MechanismOID to "create" > > > > a name that can be asserted out of the blue. > > > > > > > > I wouldn't mind that just being a flat name (no delimiters, no escaping). > > > > UTF-8 characters, and no scoping. > > > > > > > > So, let this resolution to 3972 go to a vote, and I'll raise an issue > > > > based on this discussion. > > > > > > > > > > I would appreciate that, although I would also accept us working this > > > out here; assuming we are close. > > > > > > Ron > > > > > > > Cheers, > > > > -Polar > > > > > > > > > > > > > > // The GSS Object Identifier allocated for the krb5 mechanism is > > > > > // defined below. > > > > > // > > > > > // { iso(1) member-body(2) United States(840) mit(113554) > > > > > // infosys(1) gssapi(2) krb5(2) } > > > > > > > > > > const CSI::StringOID KRB5MechOID = "oid:1.2.840.113554.1.2.2"; > > > > > > > > > > I think the gssup exported name form should be suitable for your string > > > > > name case, I agreed to add another OID if you think you need it but I > > > > > would much rather not. The OIDs in exported name objects are mechanism > > > > > OIDS not name types. > > > > > > > > > > So if we add this OID, it would not be a "NameType", but a synonym for > > > > > the GSSUP mechanism OID. > > > > > > > > > > Ron > > > > > Issue 3922: GSSUP Names are inconsistent other security mechanisms. Click here for this issue's archive. Source: Adiron (Polar Humenn, polar@adiron.com) Document: http://cgi.omg.org/cgi-bin/doc?orbos/2000-08-04 Nature: Uncategorized Issue Severity: Medium Summary: The names supplied in the InitialContextToken for the UserName password scheme invents a name type called a Security::ScopedName. This is just yet another name type that must be dealt with and is completely inconsistent with anything else used for names. The contents of the scope and the name are underspecified. Discussion: The username structure should allow for all forms of name types. The easiest way to do accomplish consistency is to use a GSS exported name type. Resolution: Close issue with revised text. Revised Text: The following modifications are presented against document http://cgi.omg.org/pub/csiv2-ftf/csiv2-0117011.pdf. with the assumption that the resolution of Issue 4141 has been applied. (Moving GSS_NT_ExportedName from Security to CSI). [1] Change the IDL between paragraphs 48 and 49 to the following: // GSSUP::InitialContextToken struct InitialContextToken { CSI::UTF8String username; CSI::UTF8String password; CSI::GSS_NT_ExportedName target_name; }; [2] Replace paragraph 49 with the following. The username component of a GSSUP::InitialContextToken shall be a contiguous string conforming to the scoped-username syntax, where name_value and name_scope contain a sequence of 1 or more UTF8 encoded characters. scoped-username ::= name_value | name_value@name_scope | @name_scope The '@' character shall be used to delimit name_value from name_scope. All non-delimiter instances of '@' and all non-quoting instances of '\' shall be quoted with an immediately-preceding '\'. Except for these cases, the quoting character, '\', shall not be emitted within a UTF8 encoded scoped-username. The Object Identifier corresponding to the GSS scoped-username name form is: {iso-itu-t (2) international-organization (23) omg (130) security (1) naming (2) scoped-username(1)} The target_name field of the GSSUP::InitialContextToken contains the name of the authentication domain in which the client is authenticating. This field aids the TSS in processing the authentication should the TSS support several authentication domains. A CSS shall fill the target_name field of the GSSUP::InitialContextToken with the contents of the target_name field of the CSIIOP::AS_ContextSec structure of the chosen CSI mechanism. [3] In Section 16.9.5, Module GSSUP change the definition InitialContextToken to the following: struct InitialContextToken { CSI::UTF8String username; CSI::UTF8String password; CSI::GSS_NT_ExportedName target_name; }; [3] In Section 16.9.6, Module CSI, add the following, after the definition of GSS_NT_ExportedNameList. // The GSS scoped-username name form is represented by the OID // {iso-itu-t (2) international-organization (23) omg (130) // security (1) naming (2) scoped-username(1)} const StringOID NT_Scoped_Username = "oid:2.23.130.1.2.1"; [4] In Section 16.9.5, Remove all extraneous definitons from the GSSUP module. Resolution to Issue 4141 introduces NameValue and ScopedName to the GSSUP module, which were moved from the Security Module. Actions taken: October 3, 2000: received issue DON FILL IN DATE HERE: closed issue Issue 3972: Format of GSSUP GSS exported name object undefined Click here for this issue's archive. Source: Sun Microsystems (Ron Monzillo, Ronald.Monzillo@east.sun.com) Document: http://cgi.omg.org/cgi-bin/doc?orbos/2000-08-04 Nature: Uncategorized Issue Severity: Critical Summary: Format of GSSUP GSS mechanism-independent exported name object, a special form of "flat" name as described below, is not defined. Discussion: Define a "flat name" type OID and format. It would also be good to have these OIDs specified somewhere. We can do that in IDL with string constants, using dot notation for OIDs. Resolution: Close issue with revised text. Revised Text: The following modifications are presented against document http://cgi.omg.org/pub/csiv2-ftf/csiv2-0117011.pdf. with the assumption that the resolution of Issue 4141 has been applied, i.e. Moving GSS_NT_ExportedName from Security to CSI, and the assumption that the resolution of Issue 4143 has been applied, i.e. creation of the CSI::StringOID type. [1] Add the following at the end (following para 54) of section 15.2.5 Identity Token Format GSS Exported Name Object Form for GSSUP Mechanism The mechanism OID within the exported name object shall be that of the GSSUP mechanism. {iso-itu-t (2) international-organization (23) omg (130) security (1) authentication (1) gssup-mechanism (1)} The name component within the exported name object shall be a contiguous string conforming to the following syntax, where name_value and name_scope contain a sequence of 1 or more UTF8 encoded characters. name component ::= name_value | name_value@name_scope | @name_scope The '@' character shall be used to delimit name_value from name_scope. All non-delimiter instances of '@' and all non-quoting instances of '\' shall be quoted with an immediately-preceding '\'. Except for these cases, the quoting character, '\', shall not be emitted within the name component of an exported name object. The name length component within the exported name object shall represent the length of the name component including any inserted quoting characters. The encoding of GSS mechanism-independent exported name objects is defined in [IETF RFC 2743]. [2] Insert the following definition in Section 16.9.6, Module CSI, after the definition of GSS_NT_ExportedNameList. // The GSS Object Identifier for the KRB5 mechanism is defined below. // // { iso(1) member-body(2) United States(840) mit(113554) // infosys(1) gssapi(2) krb5(2) } const StringOID KRB5MechOID = "oid:1.2.840.113554.1.2.2"; Actions taken: October 13, 2000: received issue DON FILL IN DATE HERE: closed issue X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 14 Feb 2001 09:46:32 -0500 (EST) From: Polar Humenn To: Ron Monzillo cc: csiv2-ftf@omg.org Subject: Re: Issue 3972 and 3922 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 2#h!!6I8e9(BB!!;:>e9 Greetings, Ron and I just had a discussion about some things he was concerned about that he piggy-backed in his resolutions to the 3922 and 3972 issues. The result of the conversation is to retract his resolution 3922-3, reverting back to the previous resolution, 3922-3. Ron will produce another version of 3972 momentarily. So, to keep the History of the World Part III going, I have created FTF-Issue3922-4.html, which is a copy of FTF-Issue3922-2.html, i.e. the current resolution. When Ron posts a new resolution for Issue 3972, it will be listed as FTF-Issue3972-5.html. The ftp site directory is ftp:://greene.case.syr.edu/pub/omg/csiv2-ftf. Cheers, -Polar On Wed, 14 Feb 2001, Polar Humenn wrote: > > I have put Ron's resolutions to issues on my ftp site as: > > ftp://greene.case.syr.edu/pub/omg/csiv2-ftf/FTF-Issue3972-4.html > ftp://greene.case.syr.edu/pub/omg/csiv2-ftf/FTF-Issue3922-3.html > > I am in agreement with these resolutions. > > Cheers, > -Polar > > On Tue, 13 Feb 2001, Ron Monzillo wrote: > > > It took me longer to get back to this than I had hoped. > > > > I have attached revised proposals for 3922, and 3972. The > combination of > > the changes embodied in these proposals should allow us to: > > > > 1. import a GSSUP exported name into an "internal" MN > > > > GSSName mechName = createName(exportedName, > > > GSSName.NT_EXPORTED_NAME, > > GSSUPMechOID); > > > > 2. import a string name of form scoped username into an "internal" > MN. > > > > GSSName mechName = createName("name@scope", > > > GSSName.NT_SCOPED_USERNAME, > > GSSUPMechOID); > > > > 3. export an "internal" MN to an exported MN. > > > > byte [] exportedName = mechName.export(); > > > > > > I've approximately used the Java GSS-API bindings (from RFC 2853) > just > > as an example. The main point, is that we needed to do all threee > of the > > things listed above, and now I hope we have the necessary OIDs and > > syntaxes defined to get the job done. > > > > I don't think I will be attending tomorrow's conference call. > > I will try to call in, but I can't be sure that I will be able to. > > I will try to have someone from Sun replace me. > > > > If you have comments on these attached proposals, I will try to > > respond (today) via email. > > > > Ron > > > > > > Ron Monzillo wrote: > > > > > > Polar, > > > > > > I didn't have as much time to spend on this as I had hoped. > > > Have you looked at RFC 2853 GSS-API Java bindings. I know that > > > csiv2 has to be use in other than Java contexts, but I think > > > the GSSName interface of 2853 was designed to handle the type > > > of transformation you are interested in (among others) > > > > > > see the top of page 23. > > > > > > > Since some applications may require MNs without wanting to > incur the > > > > overhead of an authentication operation, creation methods are > > > > provided that take not only the name buffer and name type, but > also > > > > the mechanism oid for which this name should be created. > > > > > > Ron > > > > > > Polar Humenn wrote: > > > > > > > > On Thu, 8 Feb 2001, Ron Monzillo wrote: > > > > > > > > > > > > > > > > > > > Polar Humenn wrote: > > > > > > > > > > > > On Thu, 8 Feb 2001, Ron Monzillo wrote: > > > > > > > > > > > > > Polar, > > > > > > > > > > > > > > I'm about to send out a proposed resolution for 3972. > > > > > > > I think I have covered the exported name form for GSSUP. > > > > > > > > > > > > > > There were some other items you included in this issue. > > > > > > > > > > > > > > 1. you defined a NameType and used it to define a > constant for > > > > > > > a kerberos name type. In the comments of the constant > you say this > > > > > > > oid is for use in the kereberos exported object. The OID > you > > > > > > > speced is not a name type, but a mechanism OID (I don't > think we > > > > > > > need a new type for such things), and we don't need to > describe > > > > > > > how it is used in kerberos exported name objects. By the > way the > > > > > > > kerberos principal name form has a differnt OID (it has > krb5_name(1)) > > > > > > > at then end. > > > > > > > > > > > > Well, then Kerberos GSSExportedName OID is the Mechanism > OID for > > > > > > Kerboeros, surely. However, the format of the name > component is that of > > > > > > KerberosPrincipalName. It has its own OID, but its OID > does not show up in > > > > > > the GSS exported name structure. It is implied. > > > > > > > > > > > > GSSUP has no explicit OID definition to refer to its name > form. Do you > > > > > > think it should? > > > > > > > > > > I don't see how it can, as its name forms, which I think are > really an > > > > > internal names, should be left unbound to facilitate the > binding of the > > > > > GSSAPI token exchange to any shared secret authentication > mechanism > > > > > (within the mechanism implementation). But I confess you > told me some > > > > > things about how name types are used in gssapi processing, > which may > > > > > force name types to be defined for use with GSSUP. I hope > not. > > > > > > > > Well, the "internal" name format for a Kerberos name is a two > part > > > > structure (in C) of two fields "name" and "realm". However, > that > > > > is an implemenation issue, and that's why it's "internal". > > > > > > > > It has several "exported" name forms, such as > GSS_NT_USER_NAME, > > > > GSS_NT_SERVICE_NAME, .... GSS_NT_EXPORT_NAME, as well as > KRB5_NT_KRB5_NAME > > > > and KRB5_NT_KRB5_PRINCIPAL. These types are used for > GSS_import_name as > > > > the type parameter. Kerberos only exports to one type. > > > > > > > > For most "import" types that are not defined by the GSS_NT_* > types, > > > > kerberos has OIDs that point to their definitions. For > instance, giving a > > > > "GSS_import_name" call with a type of GSS_NT_SERVICE_NAME: > > > > > > > > * service_name: > > > > * iso(1) member-body(2) US(840) mit(113554) infosys(1) > gssapi(2) > > > > * generic(1) service_name(4) = 1.2.840.113554.1.2.1.4 > > > > > > > > The OID of the corresponds directly to the syntax of a > > > > KRB5_NT_SERVICE_NAME, which is krb5_principal type is: > > > > > > > > * iso(1) member-body(2) US(840) mit(113554) infosys(1) > gssapi(2) > > > > * krb5(2) krb5_principal(2) = 1.2.840.113554.1.2.2.2 > > > > > > > > (which is service@host with no escapes). > > > > > > > > The question is does the GSS_import_name function for GSSUP > supposed to > > > > take anything else but a GSS_NT_EXPORT_NAME? > > > > > > > > I would say that if you wanted to generate the name for a user > you would > > > > have to make a call for > > > > > > > > gss_name_t name; > > > > > > > > gss_import_name(minor, "user@scope", GSSUP_NT_GSSUPNAME, > &name); > > > > > > > > char * exportedName; > > > > > > > > gss_export_name(minor, name, &exportName); > > > > > > > > Otherwise you have to construct the GSS Exported Name > structure > > > > by hand. > > > > > > > > Cheers, > > > > -Polar > > > > > > > > > > > At most we could/should define the krb5 mechanism oid, > and leave > > > > > > > it at that. > > > > > > > > > > > > Surely, but I still mandate the need to create a name that > can be > > > > > > asserted in the Identity Token that doesn't adhere to any > particular > > > > > > format or mechanism. > > > > > > > > > > > > > > > > My thinking is that the GSSUP exported name object can > assume this role, > > > > > especially if there need not be name types for GSSUP. > > > > > > > > > > > So therefore in order to create a name, we need a > MechanismOID to "create" > > > > > > a name that can be asserted out of the blue. > > > > > > > > > > > > I wouldn't mind that just being a flat name (no > delimiters, no escaping). > > > > > > UTF-8 characters, and no scoping. > > > > > > > > > > > > So, let this resolution to 3972 go to a vote, and I'll > raise an issue > > > > > > based on this discussion. > > > > > > > > > > > > > > > > I would appreciate that, although I would also accept us > working this > > > > > out here; assuming we are close. > > > > > > > > > > Ron > > > > > > > > > > > Cheers, > > > > > > -Polar > > > > > > > > > > > > > > > > > > > > // The GSS Object Identifier allocated for the krb5 > mechanism is > > > > > > > // defined below. > > > > > > > // > > > > > > > // { iso(1) member-body(2) United States(840) > mit(113554) > > > > > > > // infosys(1) gssapi(2) krb5(2) } > > > > > > > > > > > > > > const CSI::StringOID KRB5MechOID = > "oid:1.2.840.113554.1.2.2"; > > > > > > > > > > > > > > I think the gssup exported name form should be suitable > for your string > > > > > > > name case, I agreed to add another OID if you think you > need it but I > > > > > > > would much rather not. The OIDs in exported name objects > are mechanism > > > > > > > OIDS not name types. > > > > > > > > > > > > > > So if we add this OID, it would not be a "NameType", but > a synonym for > > > > > > > the GSSUP mechanism OID. > > > > > > > > > > > > > > Ron > > > > > > > > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Wed, 14 Feb 2001 10:54:07 -0500 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn CC: csiv2-ftf@omg.org Subject: Re: Issue 3972 and 3922 References: Content-Type: multipart/mixed; boundary="------------E31779A8407DDB54107C9C28" X-UIDL: /50e98#&!!U_(e9@:2!! Polar Humenn wrote: > > Greetings, > > Ron and I just had a discussion about some things he was concerned about > that he piggy-backed in his resolutions to the 3922 and 3972 issues. The > result of the conversation is to retract his resolution 3922-3, reverting > back to the previous resolution, 3922-3. Ron will produce another version > of 3972 momentarily. > > So, to keep the History of the World Part III going, I have created > FTF-Issue3922-4.html, which is a copy of FTF-Issue3922-2.html, i.e. the > current resolution. > > When Ron posts a new resolution for Issue 3972, it will be listed as > FTF-Issue3972-5.html. I've attached a new proposal for 3972. Synopsis of what I changed. 1. I moved the definition of the scoped-username name form in line with the definition of the GSSUP exported name object. 2. I defined the exported name object by refering to the scoped-username name form 3. I removed the stuff about the length-component in the exported name object (as the reference to 2473 should be sufficient) 4. I changed name of the OID for the scoped-username name form 5. I added a const for the OID corresponding to a gss-api-exported-name, derived form RFC 2473. For reference, this proposal is intended to make sure that we can do the moral equivalent of the following things. > > 1. import a GSSUP exported name into an "internal" MN > > > > GSSName mechName = createName(exportedName, > > GSSName.NT_EXPORTED_NAME, > > GSSUPMechOID); > > > > 2. import a string name of form scoped username into an "internal" MN. > > > > GSSName mechName = createName("name@scope", > > GSSName.NT_SCOPED_USERNAME, > > GSSUPMechOID); > > > > 3. export an "internal" MN to an exported MN. > > > > byte [] exportedName = mechName.export(); I'll talk to you soon. Ron > > The ftp site directory is ftp:://greene.case.syr.edu/pub/omg/csiv2-ftf. > > Cheers, > -Polar > Issue 3972: Format of GSSUP GSS exported name object undefined Click here for this issue's archive. Source: Sun Microsystems (Ron Monzillo, Ronald.Monzillo@east.sun.com) Document: http://cgi.omg.org/cgi-bin/doc?orbos/2000-08-04 Nature: Uncategorized Issue Severity: Critical Summary: Format of GSSUP GSS mechanism-independent exported name object, a special form of "flat" name as described below, is not defined. Discussion: Define a "flat name" type OID and format. It would also be good to have these OIDs specified somewhere. We can do that in IDL with string constants, using dot notation for OIDs. Resolution: Close issue with revised text. Revised Text: The following modifications are presented against document http://cgi.omg.org/pub/csiv2-ftf/csiv2-0117011.pdf. with the assumption that the resolution of Issue 4141 has been applied, i.e. Moving GSS_NT_ExportedName from Security to CSI, and the assumption that the resolution of Issue 4143 has been applied, i.e. creation of the CSI::StringOID type. [1] Add the following at the end (following para 54) of section 15.2.5 Identity Token Format GSS Exported Name Object Form for GSSUP Mechanism The mechanism OID within the exported name object shall be that of the GSSUP mechanism. {iso-itu-t (2) international-organization (23) omg (130) security (1) authentication (1) gssup-mechanism (1)} The name component within the exported name object shall be a contiguous string conforming to the syntax of the scoped-username GSS name form. The encoding of GSS mechanism-independent exported name objects is defined in [IETF RFC 2743]. Scoped-Username GSS Name Form The scoped-username GSS name form is defined as follows, where name_value and name_scope contain a sequence of 1 or more UTF8 encoded characters. scoped-username ::= name_value | name_value@name_scope | @name_scope The '@' character shall be used to delimit name_value from name_scope. All non-delimiter instances of '@' and all non-quoting instances of '\' shall be quoted with an immediately-preceding '\'. Except for these cases, the quoting character, '\', shall not be emitted within a scoped-username. The Object Identifier corresponding to the GSS scoped-username name form is: {iso-itu-t (2) international-organization (23) omg (130) security (1) naming (2) scoped-username(1)} [2] Insert the following definitions in Section 16.9.6, Module CSI, after the definition of GSS_NT_ExportedNameList. // The GSS Object Identifier for the KRB5 mechanism is: // // { iso(1) member-body(2) United States(840) mit(113554) // infosys(1) gssapi(2) krb5(2) } const StringOID KRB5MechOID = "oid:1.2.840.113554.1.2.2"; // The GSS Object Identifier for name objects of the // Mechanism-idependent Exported Name Object type is: // {iso(1) org(3) dod(6) internet(1) security(5) nametypes(6) // gss-api-exported-name(4)} const StringOID GSS_NT_Export_Name_OID = "oid:1.3.6.1.5.6.4"; // The GSS Object Identifier for the scoped-username name form is: // {iso-itu-t (2) international-organization (23) omg (130) // security (1) naming (2) scoped-username(1)} const StringOID GSS_NT_Scoped_Username_OID = "oid:2.23.130.1.2.1"; Actions taken: October 13, 2000: received issue DON FILL IN DATE HERE: closed issue From: "Don Flinn" To: "csiv2-ftf" Subject: Issues 3922, 3948 & 3972 Date: Wed, 14 Feb 2001 15:05:05 -0500 Message-ID: <000201c096c1$6c6e8210$7985413f@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 2_