From kitten-bounces@lists.ietf.org Fri Dec 08 16:09:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsmyM-0003dp-De; Fri, 08 Dec 2006 16:09:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsmyL-0003dY-Oi for kitten@ietf.org; Fri, 08 Dec 2006 16:09:33 -0500 Received: from www.ioplex.com ([66.220.1.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsmyK-0004Y5-BO for kitten@ietf.org; Fri, 08 Dec 2006 16:09:33 -0500 Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net [69.142.196.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by www.ioplex.com (Postfix) with ESMTP id 5420242B64; Fri, 8 Dec 2006 16:09:18 -0500 (EST) Date: Fri, 8 Dec 2006 16:09:14 -0500 From: Michael B Allen To: "Henry B. Hotz" Message-Id: <20061208160914.3f6fd611.mba2000@ioplex.com> In-Reply-To: References: <200612041152.19416.blin@gmx.net> <20061204105727.1e8db0be.mba2000@ioplex.com> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: kitten@ietf.org, heimdal-discuss@sics.se, blin@gmx.net Subject: Re: Using GSSAPI with specific providers X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org I'm also sending this to kitten (the GSSAPI working group mailing list). On Fri, 8 Dec 2006 09:48:50 -0800 "Henry B. Hotz" wrote: > If you google "altman sspi gssapi sample" you can find references to > example code for how to use SSPI and GSSAPI in a compatible way. > SPNEGO is a supported mechanism for most current GSSAPI > implementations (including the ones in the MIT and Heimdal > implementations). > > I'm not sure how much of a subset the current GSSAPI implementations > are. The one area I know to worry about is the ability to auto- > negotiate from GSSAPI/SPNEGO/krb5 to GSSAPI/SPNEGO/NTLMv2 if needed. GSSAPI only deals with authentication. As you point out NTLMSSP is not supported by most (any?) GSSAPI implementations but that's not the problem. GSSAPI could support NTLMSSP using the current model just fine (although I don't know about the Schannel provider). The problem has more to do with how SSPI integrates with host credential management. Because everything goes through gss_cred_id_t you have a bunch of issues regarding how to get credentials for use with GSSAPI and with how to get credentials from GSSAPI for use with non-GSSAPI software. For example, how do you get a gss_cred_id_t from a username and password? Not defined. How does a service get the delegated credential in a form that can be used with Kerberos aware software like libcurl or the pgsql driver? Not defined [1]. Also SSPI splits out a lot of functionality like encryption and signing whereas GSSAPI tries to parameterize that with poorly defined concepts like gss_qop_t. For the OP to implement SSPI in WINE GSSAPI alone will not even come close. Mike [1] It has been suggested that a GSSAPI function be added to export a Kerberos 5 credential cache file. The KRB5CCNAME environment variable and credential cache file mechanism is not suitable for acceptors (e.g. HTTP daemon cannot adequately protect ccache files). The creds should really be hosted in memory controlled by the kernel. Then GSSAPI could add a "save cred" flag that specifies that delegated credentials should be saved there in a mechanism specific way that would also be accessible to other non-GSSAPI aware code. -- Michael B Allen PHP Active Directory SSO http://www.ioplex.com/ _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Dec 08 16:47:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsnYd-0005xO-J3; Fri, 08 Dec 2006 16:47:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsnYc-0005xJ-8U for kitten@ietf.org; Fri, 08 Dec 2006 16:47:02 -0500 Received: from mailhost.anl.gov ([130.202.113.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsnYa-000397-No for kitten@ietf.org; Fri, 08 Dec 2006 16:47:02 -0500 Received: from mailhost.anl.gov (localhost [127.0.0.1]) by localhost.ctd.anl.gov (Postfix) with ESMTP id 139DB5C; Fri, 8 Dec 2006 15:47:00 -0600 (CST) Received: from [127.0.0.1] (atalanta.it.anl.gov [146.137.96.104]) by mailhost.anl.gov (Postfix) with ESMTP id 8D31819; Fri, 8 Dec 2006 15:46:59 -0600 (CST) Message-ID: <4579DD53.8050107@anl.gov> Date: Fri, 08 Dec 2006 15:46:59 -0600 From: "Douglas E. Engert" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael B Allen References: <200612041152.19416.blin@gmx.net> <20061204105727.1e8db0be.mba2000@ioplex.com> <20061208160914.3f6fd611.mba2000@ioplex.com> In-Reply-To: <20061208160914.3f6fd611.mba2000@ioplex.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: kitten@ietf.org, heimdal-discuss@sics.se, "Henry B. Hotz" , blin@gmx.net Subject: Re: Using GSSAPI with specific providers X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Michael B Allen wrote: > I'm also sending this to kitten (the GSSAPI working group mailing list). > > On Fri, 8 Dec 2006 09:48:50 -0800 > "Henry B. Hotz" wrote: > > >>If you google "altman sspi gssapi sample" you can find references to >>example code for how to use SSPI and GSSAPI in a compatible way. >>SPNEGO is a supported mechanism for most current GSSAPI >>implementations (including the ones in the MIT and Heimdal >>implementations). >> >>I'm not sure how much of a subset the current GSSAPI implementations >>are. The one area I know to worry about is the ability to auto- >>negotiate from GSSAPI/SPNEGO/krb5 to GSSAPI/SPNEGO/NTLMv2 if needed. > > > GSSAPI only deals with authentication. As you point out NTLMSSP is > not supported by most (any?) GSSAPI implementations but that's not the > problem. GSSAPI could support NTLMSSP using the current model just fine > (although I don't know about the Schannel provider). The problem has > more to do with how SSPI integrates with host credential management. > Because everything goes through gss_cred_id_t you have a bunch of issues > regarding how to get credentials for use with GSSAPI and with how to > get credentials from GSSAPI for use with non-GSSAPI software. > Starting on a Windows client, you can use either SSPI or GSSAPI, You don't normally mix the two, but you could select which one to use base on the credentials you have at hand. > For example, how do you get a gss_cred_id_t from a username and > password? Not defined. True for GSSAPI it is not defined. But you can get a SSPI credential from a username and password similiar to what "runas /netonly" does and use it with SSPI. The gssklog program (used to get AFS tokens) when run on Windows can do both of the above. But normally it would either use the KfW provided gssapi32.dll or the Microsoft SSPI. The -ms option would let you choose which one to look at for credentials first. D:\build\bin>gssklog -help Usage: gssklog [-x] [-principal ] [-password ] [-cell ] [-pipe] [-silent] [-lifetime ] [-setpag] [-port ] [-gsiklog] [-server ] [-p ] [-ms] [-help] Where: -x (obsolete, noop) -pipe read password from stdin -silent silent operation -setpag Create a new setpag before authenticating -gsiklog Use old gsiklog -ms Use MS credentials via sspi before MIT Kerberos > How does a service get the delegated credential > in a form that can be used with Kerberos aware software like libcurl or > the pgsql driver? Not defined [1]. OpenSSH sshd is a good example for this, in that it can store the delegated credenential. As you point out in the note, in a web server, use of the KRB5CCNAME, is not a good choice. I am not aware of any recent advances in this area, but I know in the past, there have been modifications to do this. There is also http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-store-cred-02.txt > > Also SSPI splits out a lot of functionality like encryption and signing > whereas GSSAPI tries to parameterize that with poorly defined concepts > like gss_qop_t. > > For the OP to implement SSPI in WINE GSSAPI alone will not even come > close. Not sure what you are getting at here. > > Mike > > [1] It has been suggested that a GSSAPI function be added to export a > Kerberos 5 credential cache file. The KRB5CCNAME environment variable and > credential cache file mechanism is not suitable for acceptors (e.g. HTTP > daemon cannot adequately protect ccache files). The creds should really > be hosted in memory controlled by the kernel. Then GSSAPI could add a > "save cred" flag that specifies that delegated credentials should be saved > there in a mechanism specific way that would also be accessible to other > non-GSSAPI aware code. > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Dec 08 17:37:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsoKq-0000SU-H2; Fri, 08 Dec 2006 17:36:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsoKq-0000SP-2f for kitten@ietf.org; Fri, 08 Dec 2006 17:36:52 -0500 Received: from www.ioplex.com ([66.220.1.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsoKm-0002yy-PS for kitten@ietf.org; Fri, 08 Dec 2006 17:36:52 -0500 Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net [69.142.196.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by www.ioplex.com (Postfix) with ESMTP id 3C1A142B64; Fri, 8 Dec 2006 17:36:42 -0500 (EST) Date: Fri, 8 Dec 2006 17:36:40 -0500 From: Michael B Allen To: "Douglas E. Engert" Message-Id: <20061208173640.6bad5d11.mba2000@ioplex.com> In-Reply-To: <4579DD53.8050107@anl.gov> References: <200612041152.19416.blin@gmx.net> <20061204105727.1e8db0be.mba2000@ioplex.com> <20061208160914.3f6fd611.mba2000@ioplex.com> <4579DD53.8050107@anl.gov> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: kitten@ietf.org, heimdal-discuss@sics.se, hotz@jpl.nasa.gov, blin@gmx.net Subject: Re: Using GSSAPI with specific providers X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Fri, 08 Dec 2006 15:46:59 -0600 "Douglas E. Engert" wrote: > > For the OP to implement SSPI in WINE GSSAPI alone will not even come > > close. > > Not sure what you are getting at here. Sorry. This was a redirect from the Heimdal list where the OP was asking about using GSSAPI to implement SSPI for the Wine project. I only CC'd the kitten list because I wanted them to see my footnote about saving delegated credentials which I recall was a topic of discussion there. I should have prefixed the message with some context information. Mike -- Michael B Allen PHP Active Directory SSO http://www.ioplex.com/ _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Dec 08 17:55:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsocJ-0000EP-Jc; Fri, 08 Dec 2006 17:54:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsocI-0000EK-EO for kitten@ietf.org; Fri, 08 Dec 2006 17:54:54 -0500 Received: from mailhost.anl.gov ([130.202.113.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsocH-0005af-4R for kitten@ietf.org; Fri, 08 Dec 2006 17:54:54 -0500 Received: from mailhost.anl.gov (localhost [127.0.0.1]) by localhost.ctd.anl.gov (Postfix) with ESMTP id 89A9FF; Fri, 8 Dec 2006 16:54:52 -0600 (CST) Received: from [127.0.0.1] (atalanta.it.anl.gov [146.137.96.104]) by mailhost.anl.gov (Postfix) with ESMTP id 78A1F7; Fri, 8 Dec 2006 16:54:52 -0600 (CST) Message-ID: <4579ED3C.7070205@anl.gov> Date: Fri, 08 Dec 2006 16:54:52 -0600 From: "Douglas E. Engert" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael B Allen References: <200612041152.19416.blin@gmx.net> <20061204105727.1e8db0be.mba2000@ioplex.com> <20061208160914.3f6fd611.mba2000@ioplex.com> <4579DD53.8050107@anl.gov> <20061208173640.6bad5d11.mba2000@ioplex.com> In-Reply-To: <20061208173640.6bad5d11.mba2000@ioplex.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: kitten@ietf.org Subject: Re: Using GSSAPI with specific providers X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org I am on bith the Kitten and Heimdal lists. I was trying to point out on the client side the same application could use either SSPI or GSSAPI depending on what credentials where available. and talk to the same server. Michael B Allen wrote: > On Fri, 08 Dec 2006 15:46:59 -0600 > "Douglas E. Engert" wrote: > > >>>For the OP to implement SSPI in WINE GSSAPI alone will not even come >>>close. >> >>Not sure what you are getting at here. > > > Sorry. This was a redirect from the Heimdal list where the OP was asking > about using GSSAPI to implement SSPI for the Wine project. I only CC'd > the kitten list because I wanted them to see my footnote about saving > delegated credentials which I recall was a topic of discussion there. I > should have prefixed the message with some context information. > > Mike > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Dec 21 18:54:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxXjt-0003jX-7U; Thu, 21 Dec 2006 18:54:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxXjs-0003is-5m; Thu, 21 Dec 2006 18:54:16 -0500 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxXjq-0002FN-0g; Thu, 21 Dec 2006 18:54:16 -0500 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id kBLNsDg7002531; Thu, 21 Dec 2006 15:54:13 -0800 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id kBLNsDWe002530; Thu, 21 Dec 2006 15:54:13 -0800 Date: Thu, 21 Dec 2006 15:54:13 -0800 Message-Id: <200612212354.kBLNsDWe002530@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: kitten@lists.ietf.org, rfc-editor@rfc-editor.org Subject: RFC 4768 on Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4768 Title: Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming Author: S. Hartman Status: Informational Date: December 2006 Mailbox: hartmans-ietf@mit.edu Pages: 12 Characters: 27205 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-kitten-gss-naming-05.txt URL: http://www.rfc-editor.org/rfc/rfc4768.txt The Generic Security Services API (GSS-API) provides a naming architecture that supports name-based authorization. GSS-API authenticates two named parties to each other. Names can be stored on access control lists (ACLs) to make authorization decisions. Advances in security mechanisms and the way implementers wish to use GSS-API require this model to be extended for the next version of GSS-API. As people move within an organization or change their names, the name authenticated by GSS-API may change. Using some sort of constant identifier would make ACLs more stable. Some mechanisms, such as public-key mechanisms, do not have a single name to be used across all environments. Other mechanisms, such as Kerberos, may include group membership or role information as part of authentication. This document motivates extensions to GSS-API naming and describes the extensions under discussion. This memo provides information for the Internet community. This document is a product of the Kitten (GSS-API Next Generation) Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten