From owner-ietf-cat-wg@lists.Stanford.EDU Thu Apr 1 11:26:39 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19441 for ; Thu, 1 Apr 2004 11:26:39 -0500 (EST) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i31FcU8a000644 for ietf-cat-wg-out720680; Thu, 1 Apr 2004 07:38:30 -0800 (PST) Received: from hermes.ctd.anl.gov (hermes.ctd.anl.gov [130.202.113.27]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i31FcQNK000562 for ; Thu, 1 Apr 2004 07:38:27 -0800 (PST) Received: from hermes.ctd.anl.gov (localhost [127.0.0.1]) by hermes.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA24053 for ; Thu, 1 Apr 2004 09:37:30 -0600 (CST) Received: from anl.gov (atalanta.ctd.anl.gov [146.137.194.4]) by hermes.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id JAA24030; Thu, 1 Apr 2004 09:37:28 -0600 (CST) Message-ID: <406C3742.6B6F3F87@anl.gov> Date: Thu, 01 Apr 2004 09:37:38 -0600 From: "Douglas E. Engert" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Steve Bellovin , Russ Housley , Cees de Laat , ietf-cat-wg@lists.Stanford.EDU, Von Welch Subject: Re: GGF's extensions to GSS in Public Comment References: <406C3248.8B7FDDA0@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > > Security ADs, > > With my IETF-GGF liaison hat on... please note that the GGF's extensions > to the GSS-API are open for Public Comment (roughly the equivalent of an IETF > Last Call). So far, I hear that the GGF has not got any response from > attempts to get IETF comment (despite draft-engert-ggf-gss-extensions-00.txt). > This looks like the last chance. Can you kindly pass this on to some > competent reviewers? Last week I did send the note below ietf-cat-wg@lists.Stanford.EDU (and am cc'ing them on this note.) There was one comment logged from an IETF member, Tim Alsop, which says: "This document (in my opinion) looks ready, but needs to be reviewed by IETF CAT (or KITTEN) working group to see if there are any concerns from IETF community." The consencus as far as I can tell is to talk about it at the proposed CAT BOF at the next IETF. This may not be the time fram that the GGF was looking for. "Douglas E. Engert" wrote: > > The Global Grid Forum is proceeding with their GSS extensions > document. If anyone would like to comment on it. > > -------- Original Message -------- > Subject: [security-area] GSS Extensions document needs comments > Date: Thu, 25 Mar 2004 13:46:58 -0600 > From: Von Welch > Reply-To: Von Welch > To: security-area@ggf.org > > Folks, > > The GSS Extensions document is in public last call (for a second > time, after changes made to remove the key argument from the > export/import credential calls). GGF is now requiring some amount of > public comment before they will allow a document to pass public > comment. > > So please comment, even if it's nothing more to say you've read the > document. > > You can find WS-Word and PDF versions of the document at the url > below. The version for comment is version 11. > > https://forge.gridforum.org/docman2/ViewCategory.php?group_id=58&category_id=0 > > You can comment at: > http://forge.gridforum.org/tracker/index.php?aid=482 > > Thanks, > > Von > > Thanks > Brian > > -------- Original Message -------- > Subject: Public Comment Documents and Tutorial Update > Date: Fri, 26 Mar 2004 17:48:35 -0500 > From: "Steve Crumb" > Reply-To: > To: > > ----------------------------------------------------------------------- > 1. Documents: 9 Documents in Public Comment > 2. Call for GGF11 Tutorials and GGF11 Tutorial Survey > 3. GGF11 Semantic Grid Applications Workshop Call for Papers > ----------------------------------------------------------------------- > > 1. Documents in Public Comment > GGF process encourages community comment on all documents that have > passed the GGF Editor's initial review. The absence of public comments > may hinder the document's progress through the GGF Editorial process. > Your participation in the comment period is critical. > > There are two ways you may chose to make your comments: > - Visit GGF's SourceForge.net site > (http://sourceforge.net/projects/ggf/). Download the document by > selecting the title of the document you wish to review. You can post > comments using the associated "Forum" (discussion thread) for each > document. These forums can be found by clicking the "Forums" link near > the top of the Sourceforge project page and clicking the forum named > similarly to the document. > - Use the GridForge tracker in the GGF Editor project > (http://forge.gridforum.org/tracker/index.php?func=browse&group_id=90&at > id=414) Visit the provided link and click on the title of document to > open a comment form. You may choose to login to GridForge to submit > comments or make your comments anonymously. After typing your comments > into the form, press the "Save" button and your comments will be posted. > > Documents currently in Public Comment: > - Usage Record-XML (SRM) 60 day > - Persistent Archive Capabilities (DATA) 30 day > - NM-WG Hierarchy (ISP) 60 day > - GSS Extensions (SEC) 60 day > - An Analysis of "Top N" Event Descriptions (ISP) 30 day > - Peer To Peer and Grid: Synergies and Opportunities (P2P) 30 day > - Distributed Resource Management Application API Specification 1.0 > (SRM) 60 day > - GIR-WG Requirements (ISP) 30 day > - Certificates for Automated Clients (SEC) 60 day > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Apr 1 13:16:04 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24580 for ; Thu, 1 Apr 2004 13:16:03 -0500 (EST) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i31Hbf1w021601 for ietf-cat-wg-out720680; Thu, 1 Apr 2004 09:37:41 -0800 (PST) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i31HbcNK021572 for ; Thu, 1 Apr 2004 09:37:38 -0800 (PST) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i31HbUWA024268; Thu, 1 Apr 2004 09:37:31 -0800 (PST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i31HbQcE019441; Thu, 1 Apr 2004 10:37:26 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i31HNEhf015920; Thu, 1 Apr 2004 11:23:15 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i31HNC6X015919; Thu, 1 Apr 2004 11:23:12 -0600 (CST) Date: Thu, 1 Apr 2004 11:23:12 -0600 From: Nicolas Williams To: "Douglas E. Engert" Cc: Brian E Carpenter , Steve Bellovin , Russ Housley , Cees de Laat , ietf-cat-wg@lists.Stanford.EDU, Von Welch Subject: Re: GGF's extensions to GSS in Public Comment Message-ID: <20040401172312.GB5868@binky.central.sun.com> References: <406C3248.8B7FDDA0@zurich.ibm.com> <406C3742.6B6F3F87@anl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <406C3742.6B6F3F87@anl.gov> User-Agent: Mutt/1.4i Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Thu, Apr 01, 2004 at 09:37:38AM -0600, Douglas E. Engert wrote: > > > Brian E Carpenter wrote: > > > > Security ADs, > > > > With my IETF-GGF liaison hat on... please note that the GGF's extensions > > to the GSS-API are open for Public Comment (roughly the equivalent of an IETF > > Last Call). So far, I hear that the GGF has not got any response from > > attempts to get IETF comment (despite draft-engert-ggf-gss-extensions-00.txt). > > This looks like the last chance. Can you kindly pass this on to some > > competent reviewers? I'm not sure when Mr. Carpenter wrote this since Doug did not include a date in the log line, but I assume it was written long after I posted draft-williams-gssapi-store-deleg-creds-00.txt to the I-D repository and subsequent comments to GGF and IETF lists. Neither my comments (made long ago on _both_, GGF and IETF lists) nor Sam Hartman's (made on IETF lists; I don't know if he's posted on GGF lists) seem to be appreciated by the GGF. If I hear no replies anytime soon to my comments then I will give up trying to comment on this proposal. I can't say that my employer would never implement it, but certainly I think there are serious flaws in this proposal and I certainly would not want to implement it as it stands. > Last week I did send the note below ietf-cat-wg@lists.Stanford.EDU (and am cc'ing them > on this note.) There was one comment logged from an IETF member, Tim Alsop, which says: > "This document (in my opinion) looks ready, but needs to be reviewed > by IETF CAT (or KITTEN) working group to see if there are any > concerns from IETF community." I hate to say this Doug but Tim's comment on the CAT WG list was the least significant of all comments made recently. Issues were raised, particularly with respect to the way that the GGF has failed to address comments raised on its and IETF's lists. To quote the lone voice in favor of the proposal as it stands and leave out the others is, well, not useful. > The consencus as far as I can tell is to talk about it at the proposed > CAT BOF at the next IETF. This may not be the time fram that the GGF was looking for. I don't quite agree with this. The GGF could have responded to Sam's or my comments months ago. It still can. And I would still welcome replies from the GGF and give them serious consideration, and I'm sure Sam might be amenable also -- there's no need to wait until August to discuss this. No, there is no CAT WG (or successor), yet, but this does not mean that an IETF document on GSS-API extensions can't be published, discussed and progressed, if only the authors would deign to pursue it. Let's not forget either that we (by which I mean Doug, myself and others) have discussed some of these issues in hallway conversations at IETF meetings and at KRB WG interim meetings, not just discussions on some mailing lists; it's not as though the GGF published an IETF-related proposal that the IETF then proceeded to ignore. Cheers, Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Apr 1 14:55:16 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27762 for ; Thu, 1 Apr 2004 14:55:16 -0500 (EST) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i31JK5Ka009687 for ietf-cat-wg-out720680; Thu, 1 Apr 2004 11:20:05 -0800 (PST) Received: from hermes.ctd.anl.gov (hermes.ctd.anl.gov [130.202.113.27]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i31JK1NK009634 for ; Thu, 1 Apr 2004 11:20:01 -0800 (PST) Received: from hermes.ctd.anl.gov (localhost [127.0.0.1]) by hermes.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA08622 for ; Thu, 1 Apr 2004 13:19:56 -0600 (CST) Received: from anl.gov (atalanta.ctd.anl.gov [146.137.194.4]) by hermes.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id NAA08549; Thu, 1 Apr 2004 13:19:45 -0600 (CST) Message-ID: <406C6B5B.3E2B7DC7@anl.gov> Date: Thu, 01 Apr 2004 13:19:55 -0600 From: "Douglas E. Engert" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Nicolas Williams CC: Brian E Carpenter , Steve Bellovin , Russ Housley , Cees de Laat , ietf-cat-wg@lists.Stanford.EDU, Von Welch , security-area@ggf.org Subject: Re: GGF's extensions to GSS in Public Comment References: <406C3248.8B7FDDA0@zurich.ibm.com> <406C3742.6B6F3F87@anl.gov> <20040401172312.GB5868@binky.central.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Nicolas Williams wrote: > > On Thu, Apr 01, 2004 at 09:37:38AM -0600, Douglas E. Engert wrote: > > > > > > Brian E Carpenter wrote: > > > > > > Security ADs, > > > > > > With my IETF-GGF liaison hat on... please note that the GGF's extensions > > > to the GSS-API are open for Public Comment (roughly the equivalent of an IETF > > > Last Call). So far, I hear that the GGF has not got any response from > > > attempts to get IETF comment (despite draft-engert-ggf-gss-extensions-00.txt). > > > This looks like the last chance. Can you kindly pass this on to some > > > competent reviewers? > > I'm not sure when Mr. Carpenter wrote this since Doug did not include a > date in the log line, but I assume it was written long after I posted > draft-williams-gssapi-store-deleg-creds-00.txt to the I-D repository and > subsequent comments to GGF and IETF lists. No, I got his note today. Thu, 01 Apr 2004 17:16:24 +0200 > > Neither my comments (made long ago on _both_, GGF and IETF lists) nor > Sam Hartman's (made on IETF lists; I don't know if he's posted on GGF > lists) seem to be appreciated by the GGF. Yes that is a problem that the GGF needs to address. > > If I hear no replies anytime soon to my comments then I will give up > trying to comment on this proposal. I can't say that my employer would > never implement it, but certainly I think there are serious flaws in > this proposal and I certainly would not want to implement it as it > stands. > > > Last week I did send the note below ietf-cat-wg@lists.Stanford.EDU (and am cc'ing them > > on this note.) There was one comment logged from an IETF member, Tim Alsop, which says: > > "This document (in my opinion) looks ready, but needs to be reviewed > > by IETF CAT (or KITTEN) working group to see if there are any > > concerns from IETF community." > > I hate to say this Doug but Tim's comment on the CAT WG list was the > least significant of all comments made recently. The point was that Tim sent the comment to the GGF in response to the request to make comments on the web site. Sort of encougaging others, such as yourself, to add your own comment on the GGF web page. If nothing else, that you feel that the GGF has failed to address your previous comments. > Issues were raised, > particularly with respect to the way that the GGF has failed to address > comments raised on its and IETF's lists. To quote the lone voice in > favor of the proposal as it stands and leave out the others is, well, > not useful. I was not quoting him as in favor, but rather that it needed reviewing by the IETF. (He said both.) > > > The consencus as far as I can tell is to talk about it at the proposed > > CAT BOF at the next IETF. This may not be the time fram that the GGF was looking for. > > I don't quite agree with this. > > The GGF could have responded to Sam's or my comments months ago. It > still can. > > And I would still welcome replies from the GGF and give them serious > consideration, and I'm sure Sam might be amenable also -- there's no > need to wait until August to discuss this. That is my intention here as well, to get some dialog going between the GGF and IETF not between myself and other ITEF members. > > No, there is no CAT WG (or successor), yet, but this does not mean that > an IETF document on GSS-API extensions can't be published, discussed and > progressed, if only the authors would deign to pursue it. I know I am listed as an author, but I am not on this project any longer. and don't attend the GGF. But I do have an interest in GSSAPI being a single standard fromthe IETF. So it is up to others in GGF to respond. > > Let's not forget either that we (by which I mean Doug, myself and > others) have discussed some of these issues in hallway conversations at > IETF meetings and at KRB WG interim meetings, not just discussions on > some mailing lists; it's not as though the GGF published an IETF-related > proposal that the IETF then proceeded to ignore. > > Cheers, > > Nico > -- -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Apr 2 10:14:21 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12726 for ; Fri, 2 Apr 2004 10:14:20 -0500 (EST) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i32EUn5u000146 for ietf-cat-wg-out720680; Fri, 2 Apr 2004 06:30:49 -0800 (PST) Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i32EUkNK000138 for ; Fri, 2 Apr 2004 06:30:46 -0800 (PST) Received: from VON-THINKPAD (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id i32EUd0216022; Fri, 2 Apr 2004 08:30:39 -0600 X-Mailer: 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid (via feedmail 10 I); VM 7.14 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16493.30981.963000.758673@gargle.gargle.HOWL> Date: Fri, 2 Apr 2004 08:30:29 -0600 To: ietf-cat-wg@lists.Stanford.EDU Subject: Fwd: Re: GGF's extensions to GSS in Public Comment From: Von Welch Reply-To: Von Welch CC: security-wg@ggf.org Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit [Resending note to Nicolas to lists with right from address for list] ------- start of forwarded message ------- From: "Von Welch" To: Nicolas Williams Cc: "Douglas E. Engert" , Brian E Carpenter , Steve Bellovin , Russ Housley , Cees de Laat , ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: GGF's extensions to GSS in Public Comment Date: Fri, 2 Apr 2004 01:38:11 -0600 Nicolas, I haven't been privy to any of the hallway conversations you mention or known that they have existed. My impression from scanning the mailling lists has been that your draft was basically uncommented on, so I mistook this for a lack of interest. I'll respond here to your critique of our use of environmental variables in gss_export_cred() from your ID[1]. Perhaps you can give me pointers to the other critiques from you and Sam that you refer to. I don't remember these and am not having any luck with google. In regards to your comment regarding our exposure of environmental variables in our gss_export_cred() call: The reason why we chose this route is that we've had bad experiences with functions that manipulate the environment without providing knowledge of that manipulation to their calling applications. Doing this leads to the problem that if that an application wants to clean up its environment, typically in preparation for passing just the needed subset to a child, it has no way of knowing that a particular environment variable is meaningful as a pointer to a credential (unless it assumes knowledge of the underlying GSS mechanism and its use of the environment, which is what most apps seem to do). As I understand your proposal to avoid environmental variables in gss_store_cred(), it seems implicit that when storing credentials in some location other than the default (i.e. default_cred == FALSE) some mechanism-specific environment variable would need to be set by the underlying mechanism (at least for the implementations of GSSAPI I'm familar with) to allow the credential to be found at later time, leading to the problem I mention above. Using only the default credential store is fine if a user only has one set of credentials on a given system, but if a user has, for example, multiple sessions with a different delegated credential for each (so that each delegated credential can be removed on closure of its associated session) this breaks down as there is no way store_cred() can store a credential in a location other than default location and pass it through an exec() call that I can tell. Von [1] http://www.ietf.org/internet-drafts/draft-williams-gssapi-store-deleg-creds-00.txt ------- end of forwarded message ------- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Apr 2 13:29:54 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22242 for ; Fri, 2 Apr 2004 13:29:54 -0500 (EST) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i32HJwSk022740 for ietf-cat-wg-out720680; Fri, 2 Apr 2004 09:19:58 -0800 (PST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i32HJtNK022732 for ; Fri, 2 Apr 2004 09:19:55 -0800 (PST) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i32HJrMt003519; Fri, 2 Apr 2004 10:19:53 -0700 (MST) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i32HJrcE002619; Fri, 2 Apr 2004 10:19:53 -0700 (MST) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i32HJUhf016996; Fri, 2 Apr 2004 11:19:30 -0600 (CST) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i32HJTpW016995; Fri, 2 Apr 2004 11:19:29 -0600 (CST) Date: Fri, 2 Apr 2004 11:19:28 -0600 From: Nicolas Williams To: Von Welch Cc: ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: GGF's extensions to GSS in Public Comment Message-ID: <20040402171928.GU5868@binky.central.sun.com> References: <16493.30981.963000.758673@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16493.30981.963000.758673@gargle.gargle.HOWL> User-Agent: Mutt/1.4i Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Fri, Apr 02, 2004 at 08:30:29AM -0600, Von Welch wrote: > Nicolas, > > I haven't been privy to any of the hallway conversations you mention > or known that they have existed. My impression from scanning the > mailling lists has been that your draft was basically uncommented on, > so I mistook this for a lack of interest. An unfortunate case of miscommunication. I will write separately about how to avoid this in the future, after I think about this some more. > I'll respond here to your critique of our use of environmental > variables in gss_export_cred() from your ID[1]. Perhaps you can give me > pointers to the other critiques from you and Sam that you refer to. I > don't remember these and am not having any luck with google. Sam, myself, (and others?) have posted our critiques on the KRB WG list, and, maybe, on the old CAT WG list, in response to Doug's posts referring to the GGF's proposal or updates thereto. You may want to search the KRB and CAT WG mailing list archives[1]. > In regards to your comment regarding our exposure of environmental > variables in our gss_export_cred() call: The reason why we chose this > route is that we've had bad experiences with functions that manipulate > the environment without providing knowledge of that manipulation to > their calling applications. Doing this leads to the problem that if > that an application wants to clean up its environment, typically in > preparation for passing just the needed subset to a child, it has no > way of knowing that a particular environment variable is meaningful as > a pointer to a credential (unless it assumes knowledge of the > underlying GSS mechanism and its use of the environment, which is what > most apps seem to do). I answer this below. BTW, I have implementation experience with my proposal. > As I understand your proposal to avoid environmental variables in > gss_store_cred(), it seems implicit that when storing credentials in > some location other than the default (i.e. default_cred == FALSE) some > mechanism-specific environment variable would need to be set by the > underlying mechanism (at least for the implementations of GSSAPI I'm > familar with) to allow the credential to be found at later time, > leading to the problem I mention above. You've misunderstood the proposal. The default_cred parameter is NOT about the default credential _store_: it's about the default _credential_, that which would be acquired if using GSS_C_NO_NAME, the GSS_C_NO_CREDENTIAL. Do not confuse "default credential store" and "default credential" -- these are two very different concepts. The issue for both proposals is about addressing a credential store. I deliberately chose to leave that as a platform-specific matter, though I gave some examples of how credential stores would be manipulated on some platforms. More below. Please bear with me. > Using only the default credential store is fine if a user only has > one set of credentials on a given system, but if a user has, for > example, multiple sessions with a different delegated credential for > each (so that each delegated credential can be removed on closure of > its associated session) this breaks down as there is no way > store_cred() can store a credential in a location other than default > location and pass it through an exec() call that I can tell. Again, you've misunderstood the proposal. The following may be long, but please bear with me. GSS_Store_cred() stores credentials into whatever is the caller's "current" credential store. The matter of how to manipulate one's "current" credential store is a platform-specific matter. On Windows, for example, the current credential store might be tied to user impersonation tokens. On Solaris, where only a single credential store per-user is supported (well, for use with Secure NFS anyways) the current credential store is tied to the EUID of the caller. On *nix platforms with PAM support the current credential store might be settable like so: extern char **environ; static uid_t saved_euid = (uid_t)-1; static char **saved_environ = NULL; int set_gss_cred_store(pam_handle_t pamh, struct passwd *pw) { int retval; if ((retval = pam_setcred(pamh, PAM_ESTABLISH_CRED)) != PAM_SUCCESS) return 0; saved_environ = environ; environ = pam_getenvlist(pamh); saved_euid = geteuid(); if (seteuid(pw->pw_uid) < 0) { environ = saved_environ; saved_environ = NULL; saved_euid = (uid_t)-1; return 0; } return 1; } int revert_gss_cred_store(pam_handle_t pamh) { char **tmp_env, **p; if (uid_t == (uid_t)-1) return 0; tmp_env = environ; environ = saved_environ; /* Free PAM env */ for (p = tmp_env ; p != NULL && *p != NULL ; p++) { free(*p); } if (tmp_env != NULL) free(tmp_env); if (seteuid(saved_euid) < 0) return 0; return 1; } Solaris 10 won't require this in that it only supports one credential store per-user (again, for Secure NFS anyways), but this will be perfectly ok to do on Solaris 10. This can actually be abstracted more, and I have an Internet-Draft waiting in the wings that provides for a very basic credential store manipulation API that consists of: - GSS_Get_current_cred_store() -> Get a handle to current cred store. There are no store "names" -- just handles. - GSS_Set_current_cred_store() -> Set a current cred store; creates a new cred store if the given store handle is GSS_C_NULL_CRED_STORE. There are no store "names" -- just handles. This function cannot and does not change the user context of the caller; that remains the caller's responsibility. - GSS_Inquire_mechs_for_cred_context() -> List the mechs which the current store supports. I hope it's clear now that gss_store_cred() does succeed in keeping platform-specific details (e.g., environment variables) out of the spec, and that it does so by punting (with some recommendations and examples) on the matter of how to manipulate one's current credential store. At the risk of repeating too much of the I-D's content here I'll remind you that GSS_Acquire/Add_cred(), and all GSS-API functions that can use GSS_C_NO_CREDENTIAL, implicitly assume that there is a credential store in the background to acquire credentials from. Merely adding a GSS_Store_cred() patterned on GSS_Acquire/Add_cred(), and relaying on the notion of an implicit credential store does not require that we add an abstraction for manipulating one's credential store anymore than having GSS_Acquire/Add_cred() did in the first place. Cheers, Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Apr 5 15:31:41 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29271 for ; Mon, 5 Apr 2004 15:31:41 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i35Il7H5028436 for ietf-cat-wg-out720680; Mon, 5 Apr 2004 11:47:07 -0700 (PDT) Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i35Il3NK028414 for ; Mon, 5 Apr 2004 11:47:04 -0700 (PDT) Received: from VON-THINKPAD (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id i35Ikt0258090; Mon, 5 Apr 2004 13:46:55 -0500 X-Mailer: 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid (via feedmail 10 I); VM 7.14 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16497.43414.143000.902799@gargle.gargle.HOWL> Date: Mon, 5 Apr 2004 13:46:46 -0500 To: Nicolas Williams Cc: ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: GGF's extensions to GSS in Public Comment In-Reply-To: <20040402171928.GU5868@binky.central.sun.com> References: <16493.30981.963000.758673@gargle.gargle.HOWL> <20040402171928.GU5868@binky.central.sun.com> From: Von Welch Reply-To: Von Welch Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Nico, If I can try to summarize your message: 1) You seem to accept the use case of wanting to export/store credentials in stores other than the default and be able to use those stores in a generic manner. 2) You assert that the proper path to solve this is through extensions which separate the storing of credentials from the administration of the credential store. (And this is the crux of your disagreement with gss_export_cred()?) 3) Your current draft handles the storing of credentials and you have a new draft coming that handles credential store administration. 4) I think you imply that the the credential store administration can be done in such a way as to abstract the notion of environment variables (or any other mechanism-specific details) out of the API yet still support that functionality. Am I with you? If so, I'd be interested in seeing your second draft. I think I can see the benefits of your approach, but need see how the rubber and road meet. Von Nicolas Williams writes (11:19 April 2, 2004): > On Fri, Apr 02, 2004 at 08:30:29AM -0600, Von Welch wrote: > > Nicolas, > > > > I haven't been privy to any of the hallway conversations you mention > > or known that they have existed. My impression from scanning the > > mailling lists has been that your draft was basically uncommented on, > > so I mistook this for a lack of interest. > > An unfortunate case of miscommunication. I will write separately about > how to avoid this in the future, after I think about this some more. > > > I'll respond here to your critique of our use of environmental > > variables in gss_export_cred() from your ID[1]. Perhaps you can give me > > pointers to the other critiques from you and Sam that you refer to. I > > don't remember these and am not having any luck with google. > > Sam, myself, (and others?) have posted our critiques on the KRB WG list, > and, maybe, on the old CAT WG list, in response to Doug's posts > referring to the GGF's proposal or updates thereto. > > You may want to search the KRB and CAT WG mailing list archives[1]. > > > In regards to your comment regarding our exposure of environmental > > variables in our gss_export_cred() call: The reason why we chose this > > route is that we've had bad experiences with functions that manipulate > > the environment without providing knowledge of that manipulation to > > their calling applications. Doing this leads to the problem that if > > that an application wants to clean up its environment, typically in > > preparation for passing just the needed subset to a child, it has no > > way of knowing that a particular environment variable is meaningful as > > a pointer to a credential (unless it assumes knowledge of the > > underlying GSS mechanism and its use of the environment, which is what > > most apps seem to do). > > I answer this below. BTW, I have implementation experience with my > proposal. > > > As I understand your proposal to avoid environmental variables in > > gss_store_cred(), it seems implicit that when storing credentials in > > some location other than the default (i.e. default_cred == FALSE) some > > mechanism-specific environment variable would need to be set by the > > underlying mechanism (at least for the implementations of GSSAPI I'm > > familar with) to allow the credential to be found at later time, > > leading to the problem I mention above. > > You've misunderstood the proposal. The default_cred parameter is NOT > about the default credential _store_: it's about the default > _credential_, that which would be acquired if using GSS_C_NO_NAME, the > GSS_C_NO_CREDENTIAL. > > Do not confuse "default credential store" and "default credential" -- > these are two very different concepts. > > The issue for both proposals is about addressing a credential store. I > deliberately chose to leave that as a platform-specific matter, though I > gave some examples of how credential stores would be manipulated on some > platforms. More below. Please bear with me. > > > Using only the default credential store is fine if a user only has > > one set of credentials on a given system, but if a user has, for > > example, multiple sessions with a different delegated credential for > > each (so that each delegated credential can be removed on closure of > > its associated session) this breaks down as there is no way > > store_cred() can store a credential in a location other than default > > location and pass it through an exec() call that I can tell. > > Again, you've misunderstood the proposal. The following may be long, > but please bear with me. > > GSS_Store_cred() stores credentials into whatever is the caller's > "current" credential store. The matter of how to manipulate one's > "current" credential store is a platform-specific matter. > > On Windows, for example, the current credential store might be tied to > user impersonation tokens. > > On Solaris, where only a single credential store per-user is supported > (well, for use with Secure NFS anyways) the current credential store is > tied to the EUID of the caller. > > On *nix platforms with PAM support the current credential store might be > settable like so: > > extern char **environ; > > static uid_t saved_euid = (uid_t)-1; > static char **saved_environ = NULL; > int > set_gss_cred_store(pam_handle_t pamh, struct passwd *pw) > { > int retval; > > if ((retval = pam_setcred(pamh, PAM_ESTABLISH_CRED)) != PAM_SUCCESS) > return 0; > saved_environ = environ; > environ = pam_getenvlist(pamh); > > saved_euid = geteuid(); > if (seteuid(pw->pw_uid) < 0) { > environ = saved_environ; > saved_environ = NULL; > saved_euid = (uid_t)-1; > return 0; > } > > return 1; > } > > int > revert_gss_cred_store(pam_handle_t pamh) > { > char **tmp_env, **p; > > if (uid_t == (uid_t)-1) > return 0; > > tmp_env = environ; > environ = saved_environ; > > /* Free PAM env */ > for (p = tmp_env ; p != NULL && *p != NULL ; p++) { > free(*p); > } > if (tmp_env != NULL) > free(tmp_env); > > if (seteuid(saved_euid) < 0) > return 0; > > return 1; > } > > Solaris 10 won't require this in that it only supports one credential > store per-user (again, for Secure NFS anyways), but this will be > perfectly ok to do on Solaris 10. > > > This can actually be abstracted more, and I have an Internet-Draft > waiting in the wings that provides for a very basic credential store > manipulation API that consists of: > > - GSS_Get_current_cred_store() -> > Get a handle to current cred store. There are no store "names" > -- just handles. > > > - GSS_Set_current_cred_store() -> > Set a current cred store; creates a new cred store if the given > store handle is GSS_C_NULL_CRED_STORE. There are no store > "names" -- just handles. > > This function cannot and does not change the user context of the > caller; that remains the caller's responsibility. > > > - GSS_Inquire_mechs_for_cred_context() -> > List the mechs which the current store supports. > > > I hope it's clear now that gss_store_cred() does succeed in keeping > platform-specific details (e.g., environment variables) out of the spec, > and that it does so by punting (with some recommendations and examples) > on the matter of how to manipulate one's current credential store. > > At the risk of repeating too much of the I-D's content here I'll remind > you that GSS_Acquire/Add_cred(), and all GSS-API functions that can use > GSS_C_NO_CREDENTIAL, implicitly assume that there is a credential store > in the background to acquire credentials from. Merely adding a > GSS_Store_cred() patterned on GSS_Acquire/Add_cred(), and relaying on > the notion of an implicit credential store does not require that we add > an abstraction for manipulating one's credential store anymore than > having GSS_Acquire/Add_cred() did in the first place. > > Cheers, > > Nico > -- > -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Apr 5 21:21:52 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01743 for ; Mon, 5 Apr 2004 21:21:52 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i360djp5024183 for ietf-cat-wg-out720680; Mon, 5 Apr 2004 17:39:45 -0700 (PDT) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i360dgNK024177 for ; Mon, 5 Apr 2004 17:39:42 -0700 (PDT) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i360dVLT004905; Mon, 5 Apr 2004 17:39:35 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i360dV4F016713; Mon, 5 Apr 2004 18:39:31 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i360d6hf019451; Mon, 5 Apr 2004 19:39:06 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i360d5kn019450; Mon, 5 Apr 2004 19:39:05 -0500 (CDT) Date: Mon, 5 Apr 2004 19:39:05 -0500 From: Nicolas Williams To: Von Welch Cc: ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: GGF's extensions to GSS in Public Comment Message-ID: <20040406003905.GS5868@binky.central.sun.com> References: <16493.30981.963000.758673@gargle.gargle.HOWL> <20040402171928.GU5868@binky.central.sun.com> <16497.43414.143000.902799@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16497.43414.143000.902799@gargle.gargle.HOWL> User-Agent: Mutt/1.4i Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Mon, Apr 05, 2004 at 01:46:46PM -0500, Von Welch wrote: > > Nico, > > If I can try to summarize your message: > > 1) You seem to accept the use case of wanting to export/store > credentials in stores other than the default and be able to use those > stores in a generic manner. I accept the first part. And I agree that it would be nice to have a generic interface for manipulating what is the "current credential store" view, but I do not agree that it is necessary. I have given examples of how GSS-API applications can manipulate their current credential store view on various platforms. And I've described (but not fully specified) a generic interface for manipulating one's current credential store view. But do note the limiting factor to designing such a generic interface: user context changes cannot now be easily abstracted in a platform-independent way, but user context switching generally implies a change in the current credential store view. > 2) You assert that the proper path to solve this is through extensions > which separate the storing of credentials from the administration of > the credential store. (And this is the crux of your disagreement with > gss_export_cred()?) My disagreement with gss_export_cred() is all about its use of environment variables. I'm about to post separately on this. > 3) Your current draft handles the storing of credentials and you have > a new draft coming that handles credential store administration. Yes. > 4) I think you imply that the the credential store administration can > be done in such a way as to abstract the notion of environment > variables (or any other mechanism-specific details) out of the API yet > still support that functionality. Yes. > Am I with you? Yes. > If so, I'd be interested in seeing your second draft. I think I can > see the benefits of your approach, but need see how the rubber and > road meet. I'll send you a draft draft privately. Please see my next post about the problems with environment variables. Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Apr 5 21:38:47 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02139 for ; Mon, 5 Apr 2004 21:38:47 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i360jXAq000113 for ietf-cat-wg-out720680; Mon, 5 Apr 2004 17:45:33 -0700 (PDT) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i360jUNK029927 for ; Mon, 5 Apr 2004 17:45:30 -0700 (PDT) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i360jOLT007535; Mon, 5 Apr 2004 17:45:24 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i360jNcE013607; Mon, 5 Apr 2004 18:45:23 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i360ixhf019459; Mon, 5 Apr 2004 19:44:59 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i360ixPG019458; Mon, 5 Apr 2004 19:44:59 -0500 (CDT) Date: Mon, 5 Apr 2004 19:44:59 -0500 From: Nicolas Williams To: Von Welch Cc: ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: GGF's extensions to GSS in Public Comment Message-ID: <20040406004459.GO13507@binky.central.sun.com> References: <16493.30981.963000.758673@gargle.gargle.HOWL> <20040402171928.GU5868@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040402171928.GU5868@binky.central.sun.com> User-Agent: Mutt/1.4i Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Having addressed your comments on GSS_Store_cred(), I'll now re-iterate and expand on the problems with using environment variables in the GGF proposal. The problems with the use of environment variables are: 1. Environment variables are PLATFORM-SPECIFIC: - not all platforms can be expected to have this facility - not all platforms can be expected to have the same semantics it 2. GSS_Export_cred() w/ export-to-env-var CANNOT BE MADE THREAD-SAFE Environment variables are generally global to a process, not local to a thread, which means that exporting credentials to env vars is inherently not thread safe, at least not if the variable names intended to be used are the same for every call. The GGF text says that putenv(3) on the output env var makes the credentials available. There can be no more than one current credential store at any given time, so I conclude that that gss_export_cred() with option_req == 1 followed by putenv(3) cannot be made thread-safe. This precludes any future evolution, of operating systems that support the GGF gss_export_cred() function, towards having multi-threaded GSS-API acceptors w/ PER-THREAD GSS credential stores. (Please don't assume that this means something about the future evolution of Solaris.) 3. Environment variables are ill-suited for sharing credentials with AFS, DFS, NFS, CIFS, etc... Think of AFS tokens, Secure NFS, etc..., where the kernel must know about the current credential store of a thread or process... How can environment variables tell the kernel where those credentials are located? How can putenv(3) do it? putenv(3) doesn't tell the kernel anything. Changing putenv(3) to interpret "special" variables and take special action for them to address this problem is simply not acceptable. Since many operating systems support features such as AFS, DFS, Secure NFS, CIFS, etc... using GSS-API credentials (or similar[1]), we MUST have a way to make credentials available to the OS kernel (or, perhaps, through IPC to special daemons, such as Solaris' gssd(1M) or Windows' LSA). And surely you do not propose that GSS acceptors on AFS/DFS/NFS/CIFS clients do additional platform-specific things to make delegated credentials available to the kernel/gssd/LSA/..., or do you? Have you discussed this at all with any implementors of kerberized/GSSified networked filesystem protocols? One gets the impression that the GGF GSS_Export_cred() model is based on the existing practice of several Kerberos V implementations of using environment variables to address credential stores. (Doesn't the new Kfw MLSA ccache type pretty much mean that Kfw has a single credential store peruser on Windows? Yes, it can still use KRB5CCNAME for other ccache types, but those aren't shared with the LSA...) GSS_Store_cred() does not suffer from any of these problems. The GSS_Store_cred() proposal does acknowledge that manipulation of the caller's view of the "current credential store" is a platform-specific matter, though I've also proposed (not in I-D form) a generic interface to address this (as well as it can be addressed w/o abstracting user impersonation). The only matter that is definitely platform-specific and cannot be addressed by any proposal in this space is the matter of how to switch user contexts, on multi-user systems (which most GSS-API acceptors run on). [1] AFS uses Kerberos IV, though it seems possible to use it with Kerberos V and, in any case, with krb524 it's possible to use GSS-API initiator credentials for the Kerberos V mechanism with AFS. Cheers, Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Apr 5 22:36:05 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07643 for ; Mon, 5 Apr 2004 22:36:04 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i3625LHd010177 for ietf-cat-wg-out720680; Mon, 5 Apr 2004 19:05:21 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (IDENT:cu41754@jalapeno.cc.columbia.edu [128.59.59.238]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i3625INK010172 for ; Mon, 5 Apr 2004 19:05:19 -0700 (PDT) Received: from columbia.edu (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.11/8.12.11) with ESMTP id i3625A4h008426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Apr 2004 22:05:10 -0400 (EDT) Message-ID: <407210B6.5060109@columbia.edu> Date: Mon, 05 Apr 2004 22:06:46 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams CC: Von Welch , ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: GGF's extensions to GSS in Public Comment References: <16493.30981.963000.758673@gargle.gargle.HOWL> <20040402171928.GU5868@binky.central.sun.com> <20040406004459.GO13507@binky.central.sun.com> In-Reply-To: <20040406004459.GO13507@binky.central.sun.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090904030409040109080003" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms090904030409040109080003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nicolas Williams wrote: >Having addressed your comments on GSS_Store_cred(), I'll now re-iterate >and expand on the problems with using environment variables in the GGF >proposal. > >The problems with the use of environment variables are: > >1. Environment variables are PLATFORM-SPECIFIC: > > - not all platforms can be expected to have this facility > - not all platforms can be expected to have the same semantics it > > >2. GSS_Export_cred() w/ export-to-env-var CANNOT BE MADE THREAD-SAFE > > Environment variables are generally global to a process, not local > to a thread, which means that exporting credentials to env vars is > inherently not thread safe, at least not if the variable names > intended to be used are the same for every call. > > The GGF text says that putenv(3) on the output env var makes the > credentials available. There can be no more than one current > credential store at any given time, so I conclude that that > gss_export_cred() with option_req == 1 followed by putenv(3) cannot > be made thread-safe. > > This precludes any future evolution, of operating systems that > support the GGF gss_export_cred() function, towards having > multi-threaded GSS-API acceptors w/ PER-THREAD GSS credential > stores. (Please don't assume that this means something about the > future evolution of Solaris.) > > >3. Environment variables are ill-suited for sharing credentials with > AFS, DFS, NFS, CIFS, etc... > > Think of AFS tokens, Secure NFS, etc..., where the kernel must know > about the current credential store of a thread or process... > > How can environment variables tell the kernel where those > credentials are located? How can putenv(3) do it? > > putenv(3) doesn't tell the kernel anything. > > Changing putenv(3) to interpret "special" variables and take special > action for them to address this problem is simply not acceptable. > > Since many operating systems support features such as AFS, DFS, > Secure NFS, CIFS, etc... using GSS-API credentials (or similar[1]), > we MUST have a way to make credentials available to the OS kernel > (or, perhaps, through IPC to special daemons, such as Solaris' > gssd(1M) or Windows' LSA). > > And surely you do not propose that GSS acceptors on AFS/DFS/NFS/CIFS > clients do additional platform-specific things to make delegated > credentials available to the kernel/gssd/LSA/..., or do you? > > Have you discussed this at all with any implementors of > kerberized/GSSified networked filesystem protocols? > > >One gets the impression that the GGF GSS_Export_cred() model is based on >the existing practice of several Kerberos V implementations of using >environment variables to address credential stores. > >(Doesn't the new Kfw MLSA ccache type pretty much mean that Kfw has a >single credential store peruser on Windows? Yes, it can still use >KRB5CCNAME for other ccache types, but those aren't shared with the >LSA...) > >GSS_Store_cred() does not suffer from any of these problems. > >The GSS_Store_cred() proposal does acknowledge that manipulation of the >caller's view of the "current credential store" is a platform-specific >matter, though I've also proposed (not in I-D form) a generic interface >to address this (as well as it can be addressed w/o abstracting user >impersonation). > >The only matter that is definitely platform-specific and cannot be >addressed by any proposal in this space is the matter of how to switch >user contexts, on multi-user systems (which most GSS-API acceptors run >on). > >[1] AFS uses Kerberos IV, though it seems possible to use it with > Kerberos V and, in any case, with krb524 it's possible to use > GSS-API initiator credentials for the Kerberos V mechanism with > AFS. > > >Cheers, > >Nico > > --------------ms090904030409040109080003 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJUDCC AwYwggJvoAMCAQICAwpxijANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDczMDAyMDkyOFoXDTA0MDcyOTAyMDkyOFowRjEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUamFsdG1h bkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBtDG6ZyGA sK+rZOfKPKGBn6oCTLYSLk/mpeX9QTmTG71qh308KUeN35qqoRXjLvscfw6NPOYXiuxE/RqL sx7WKEnK3C4gzzpioCTX1b7o4M7YbpvCRBFPE9Jgsd0yz2EN+mk/pPuK1GP+iQNot2m4A56A aPe6F5T25GqffU535GNIdAtWPao6wHcOm17se25ny/TNzb9mlA4UzYl9XP7MF1fkpJyaDDAy DNNTSSjxBdPVs2EaYq1p/xadXbIpysQiySXAxoeiZusgJopRHLcBsBmmY9QVD4QnUqZVmfJ5 f1CiNri5vlexKCmdFSrxMLuoLr4EQZCECdusp6ZnIt75AgMBAAGjMTAvMB8GA1UdEQQYMBaB FGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEA DPKe/CuAgEUxsrPskJQx2fL6soAEG2iqrqOGIRREHDaXWDBNMEWEbOEMLvh3+yhqHOUc9x3r 2IfsP/XHnujaqsMVXLagokVTnpPN675wv8LZ8hLHblLnykaTCq6RZpVskh2iAiJwpYMcKNF6 jyYaQyGHBGT3PK8uVGVCG4Pp9k4wggMGMIICb6ADAgECAgMKcYowDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MzAwMjA5 MjhaFw0wNDA3MjkwMjA5MjhaMEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIx IzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwbQxumchgLCvq2TnyjyhgZ+qAky2Ei5P5qXl/UE5kxu9aod9PClH jd+aqqEV4y77HH8OjTzmF4rsRP0ai7Me1ihJytwuIM86YqAk19W+6ODO2G6bwkQRTxPSYLHd Ms9hDfppP6T7itRj/okDaLdpuAOegGj3uheU9uRqn31Od+RjSHQLVj2qOsB3Dpte7HtuZ8v0 zc2/ZpQOFM2JfVz+zBdX5KScmgwwMgzTU0ko8QXT1bNhGmKtaf8WnV2yKcrEIsklwMaHombr ICaKURy3AbAZpmPUFQ+EJ1KmVZnyeX9Qoja4ub5XsSgpnRUq8TC7qC6+BEGQhAnbrKemZyLe +QIDAQABozEwLzAfBgNVHREEGDAWgRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8E AjAAMA0GCSqGSIb3DQEBBAUAA4GBAAzynvwrgIBFMbKz7JCUMdny+rKABBtoqq6jhiEURBw2 l1gwTTBFhGzhDC74d/soahzlHPcd69iH7D/1x57o2qrDFVy2oKJFU56Tzeu+cL/C2fISx25S 58pGkwqukWaVbJIdogIicKWDHCjReo8mGkMhhwRk9zyvLlRlQhuD6fZOMIIDODCCAqGgAwIB AgIQZkVyt8x09c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3 dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lv bjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgy NzIzNTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUq bXA8+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC 9tewkd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEww KQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF15 1j2YwCYTYoEipxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59s ogxYjTFCCRFssBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TY yWJirQXGMYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJu IENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRD ZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIw MDAuOC4zMAIDCnGKMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA0MDQwNjAyMDY0NlowIwYJKoZIhvcNAQkEMRYEFK0l7qyh0i4u ekPS9Rcom36eIED5MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3 EAQxgZ0wgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnGK MIGtBgsqhkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0Eg MjAwMC44LjMwAgMKcYowDQYJKoZIhvcNAQEBBQAEggEAIN6zCtzHP1pg5kw3+JuxXAh1GjQy dyT3ALhHt/iq7kat8AAFuEQlh4kju/tAMtErf4dnRxLIYaQCJJ5Jmu0tLPJV1ywQoD0NOqCx TEMAg0/M9d5DIEaxGiuwlenIYGOGg3XcR8qkZ5zW4jbU8moiXbjSssILzMOXv5YFFJs9EySb kSW0ZMlzYx+dH5ct2e9esC6lp4MbWuv9R+rL6w1O/hkQIFl3dRlWIq0RiR19IL3Z940t4hsY Ykmi86pwRZGQevICDJZ0f8nZbId9rr186Vz0n25lTfhpy4S9Fd4NrlLpwXpYFIqE+wsXNVIC HmKqQfga0U7RBXZp/xBDNTNTEwAAAAAAAA== --------------ms090904030409040109080003-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Apr 5 22:37:29 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07998 for ; Mon, 5 Apr 2004 22:37:29 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i362AaUI010613 for ietf-cat-wg-out720680; Mon, 5 Apr 2004 19:10:36 -0700 (PDT) Received: from pomegranate.cc.columbia.edu (IDENT:cu41754@pomegranate.cc.columbia.edu [128.59.59.134]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i362AWNK010607 for ; Mon, 5 Apr 2004 19:10:33 -0700 (PDT) Received: from columbia.edu (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by pomegranate.cc.columbia.edu (8.12.11/8.12.11) with ESMTP id i362AQDS002880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Apr 2004 22:10:27 -0400 (EDT) Message-ID: <407211F3.9020506@columbia.edu> Date: Mon, 05 Apr 2004 22:12:03 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams CC: Von Welch , ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: GGF's extensions to GSS in Public Comment References: <16493.30981.963000.758673@gargle.gargle.HOWL> <20040402171928.GU5868@binky.central.sun.com> <20040406004459.GO13507@binky.central.sun.com> In-Reply-To: <20040406004459.GO13507@binky.central.sun.com> Content-Type: multipart/alternative; boundary="------------090206070209040408020007" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This is a multi-part message in MIME format. --------------090206070209040408020007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nicolas Williams wrote: >(Doesn't the new Kfw MLSA ccache type pretty much mean that Kfw has a >single credential store peruser on Windows? Yes, it can still use >KRB5CCNAME for other ccache types, but those aren't shared with the >LSA...) > MIT krb5_ccache API provides access to multiple ccache types. These include "FILE:", "API:", "MEMORY:", and "MSLSA:" at the current time. On Windows and Macintosh, the default krb5_ccache type is "API:" (aka CCAPI). The "MSLSA:" krb5_ccache type provides shared access to the LSA cache allowing the same credentials to be used by both MIT Krb5 API clients and Kerberos SSP clients. >[1] AFS uses Kerberos IV, though it seems possible to use it with > Kerberos V and, in any case, with krb524 it's possible to use > GSS-API initiator credentials for the Kerberos V mechanism with > AFS. > OpenAFS and Arla support both Kerberos IV and Kerberos 5 tickets types. krb524d is not required when an appropriate aklog is provided. MIT KfW 2.6.1 will provide such an aklog. Jeffrey Altman --------------090206070209040408020007 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Nicolas Williams wrote:
(Doesn't the new Kfw MLSA ccache type pretty much mean that Kfw has a
single credential store peruser on Windows?  Yes, it can still use
KRB5CCNAME for other ccache types, but those aren't shared with the
LSA...)
MIT krb5_ccache API provides access to multiple
ccache types.  These include "FILE:", "API:",
"MEMORY:", and "MSLSA:" at the current time.
On Windows and Macintosh, the default krb5_ccache type
is "API:" (aka CCAPI).  The "MSLSA:" krb5_ccache type
provides shared access to the LSA cache allowing the
same credentials to be used by both MIT Krb5 API clients
and Kerberos SSP clients.

[1]  AFS uses Kerberos IV, though it seems possible to use it with
     Kerberos V and, in any case, with krb524 it's possible to use
     GSS-API initiator credentials for the Kerberos V mechanism with
     AFS.
OpenAFS and Arla support both Kerberos IV and Kerberos 5 tickets
types.  krb524d is not required when an appropriate aklog is
provided.  MIT KfW 2.6.1 will provide such an aklog.

Jeffrey Altman


--------------090206070209040408020007-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Apr 6 01:38:48 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23168 for ; Tue, 6 Apr 2004 01:38:47 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i364xlE7029110 for ietf-cat-wg-out720680; Mon, 5 Apr 2004 21:59:47 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i364xiNK029104 for ; Mon, 5 Apr 2004 21:59:44 -0700 (PDT) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i364xeMt010392; Mon, 5 Apr 2004 22:59:40 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i364xd4F007213; Mon, 5 Apr 2004 22:59:39 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i364xFhf020027; Mon, 5 Apr 2004 23:59:15 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i364xDTH020026; Mon, 5 Apr 2004 23:59:13 -0500 (CDT) Date: Mon, 5 Apr 2004 23:59:13 -0500 From: Nicolas Williams To: Jeffrey Altman Cc: Von Welch , ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: [OT] Re: GGF's extensions to GSS in Public Comment Message-ID: <20040406045913.GW5868@binky.central.sun.com> References: <16493.30981.963000.758673@gargle.gargle.HOWL> <20040402171928.GU5868@binky.central.sun.com> <20040406004459.GO13507@binky.central.sun.com> <407211F3.9020506@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <407211F3.9020506@columbia.edu> User-Agent: Mutt/1.4i Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk [Off topic] On Mon, Apr 05, 2004 at 10:12:03PM -0400, Jeffrey Altman wrote: > Nicolas Williams wrote: > > >(Doesn't the new Kfw MLSA ccache type pretty much mean that Kfw has a > >single credential store peruser on Windows? Yes, it can still use > >KRB5CCNAME for other ccache types, but those aren't shared with the > >LSA...) > > > MIT krb5_ccache API provides access to multiple > ccache types. These include "FILE:", "API:", > "MEMORY:", and "MSLSA:" at the current time. > On Windows and Macintosh, the default krb5_ccache type > is "API:" (aka CCAPI). The "MSLSA:" krb5_ccache type > provides shared access to the LSA cache allowing the > same credentials to be used by both MIT Krb5 API clients > and Kerberos SSP clients. This was my understanding. Is there only one LSA cache per-user? This is interesting here because where there's one cache per-user the environment variable thing makes no sense at all. > >[1] AFS uses Kerberos IV, though it seems possible to use it with > > Kerberos V and, in any case, with krb524 it's possible to use > > GSS-API initiator credentials for the Kerberos V mechanism with > > AFS. > > > OpenAFS and Arla support both Kerberos IV and Kerberos 5 tickets > types. krb524d is not required when an appropriate aklog is > provided. MIT KfW 2.6.1 will provide such an aklog. Sure, but that's not interesting here. What's interesting is the need to share a credential store with another entity (the kernel, gssd, the LSA, whatever) -- putenv(3) hardly fits the bill for that. Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Apr 6 01:53:05 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23281 for ; Tue, 6 Apr 2004 01:53:04 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i365HpP6000672 for ietf-cat-wg-out720680; Mon, 5 Apr 2004 22:17:51 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (IDENT:cu41754@jalapeno.cc.columbia.edu [128.59.59.238]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i365HmNK000664 for ; Mon, 5 Apr 2004 22:17:48 -0700 (PDT) Received: from columbia.edu (24-193-46-55.nyc.rr.com [24.193.46.55]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.11/8.12.11) with ESMTP id i365HVNb026537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Apr 2004 01:17:36 -0400 (EDT) Message-ID: <40723DCC.3010406@columbia.edu> Date: Tue, 06 Apr 2004 01:19:08 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams CC: Von Welch , ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: [OT] Re: GGF's extensions to GSS in Public Comment References: <16493.30981.963000.758673@gargle.gargle.HOWL> <20040402171928.GU5868@binky.central.sun.com> <20040406004459.GO13507@binky.central.sun.com> <407211F3.9020506@columbia.edu> <20040406045913.GW5868@binky.central.sun.com> In-Reply-To: <20040406045913.GW5868@binky.central.sun.com> Content-Type: multipart/alternative; boundary="------------020708030003050406070506" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.40 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk This is a multi-part message in MIME format. --------------020708030003050406070506 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nicolas Williams wrote: >[Off topic] > >On Mon, Apr 05, 2004 at 10:12:03PM -0400, Jeffrey Altman wrote: > >>Nicolas Williams wrote: >> >> >>>(Doesn't the new Kfw MLSA ccache type pretty much mean that Kfw has a >>>single credential store peruser on Windows? Yes, it can still use >>>KRB5CCNAME for other ccache types, but those aren't shared with the >>>LSA...) >>> >>> >>MIT krb5_ccache API provides access to multiple >>ccache types. These include "FILE:", "API:", >>"MEMORY:", and "MSLSA:" at the current time. >>On Windows and Macintosh, the default krb5_ccache type >>is "API:" (aka CCAPI). The "MSLSA:" krb5_ccache type >>provides shared access to the LSA cache allowing the >>same credentials to be used by both MIT Krb5 API clients >>and Kerberos SSP clients. >> > >This was my understanding. Is there only one LSA cache per-user? This >is interesting here because where there's one cache per-user the >environment variable thing makes no sense at all. > There is one cache associated with the LSA session. A process or thread can create a new cache which is not associated with the session. However, it would be inappropriate to use an environment variable in this case. Within the context of a logon session a krb5_ccache name is unique. There is no guarantee that the krb5_ccache name will be unique across the entire system. Using an environment variable would certainly fail in any situation in which you either had a single process (a multi-threaded server) in which each thread must maintain its own cache reference or where the processes exist in different logon session spaces. For example a user process communicating with a daemon process. Jeffrey Altman --------------020708030003050406070506 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Nicolas Williams wrote: 
[Off topic]

On Mon, Apr 05, 2004 at 10:12:03PM -0400, Jeffrey Altman wrote:

Nicolas Williams wrote:


(Doesn't the new Kfw MLSA ccache type pretty much mean that Kfw has a
single credential store peruser on Windows?  Yes, it can still use
KRB5CCNAME for other ccache types, but those aren't shared with the
LSA...)


MIT krb5_ccache API provides access to multiple
ccache types.  These include "FILE:", "API:",
"MEMORY:", and "MSLSA:" at the current time.
On Windows and Macintosh, the default krb5_ccache type
is "API:" (aka CCAPI).  The "MSLSA:" krb5_ccache type
provides shared access to the LSA cache allowing the
same credentials to be used by both MIT Krb5 API clients
and Kerberos SSP clients.


This was my understanding.  Is there only one LSA cache per-user?  This
is interesting here because where there's one cache per-user the
environment variable thing makes no sense at all.
There is one cache associated with the LSA session.
A process or thread can create a new cache which is not
associated with the session.  However, it would be
inappropriate to use an environment variable in this case. 

Within the context of a logon session a krb5_ccache name is unique.
There is no guarantee that the krb5_ccache name will be unique across
the entire system.   Using an environment variable would certainly
fail in any situation in which you either had a single process (a multi-threaded
server) in which each thread must maintain its own cache reference
or where the processes exist in different logon session spaces.  For example
a user process communicating with a daemon process.

Jeffrey Altman

 --------------020708030003050406070506-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Apr 6 02:12:15 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05964 for ; Tue, 6 Apr 2004 02:12:15 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i365Otcw001162 for ietf-cat-wg-out720680; Mon, 5 Apr 2004 22:24:55 -0700 (PDT) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i365OqNK001146 for ; Mon, 5 Apr 2004 22:24:52 -0700 (PDT) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i365Ojio009005; Mon, 5 Apr 2004 22:24:45 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i365Oi4F015851; Mon, 5 Apr 2004 23:24:44 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i365OKhf020114; Tue, 6 Apr 2004 00:24:20 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i365OKaI020113; Tue, 6 Apr 2004 00:24:20 -0500 (CDT) Date: Tue, 6 Apr 2004 00:24:20 -0500 From: Nicolas Williams To: Jeffrey Altman Cc: Von Welch , ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: [OT] Re: GGF's extensions to GSS in Public Comment Message-ID: <20040406052420.GY5868@binky.central.sun.com> References: <16493.30981.963000.758673@gargle.gargle.HOWL> <20040402171928.GU5868@binky.central.sun.com> <20040406004459.GO13507@binky.central.sun.com> <407211F3.9020506@columbia.edu> <20040406045913.GW5868@binky.central.sun.com> <40723DCC.3010406@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40723DCC.3010406@columbia.edu> User-Agent: Mutt/1.4i Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Tue, Apr 06, 2004 at 01:19:08AM -0400, Jeffrey Altman wrote: > There is one cache associated with the LSA session. > A process or thread can create a new cache which is not > associated with the session. However, it would be > inappropriate to use an environment variable in this case. > > Within the context of a logon session a krb5_ccache name is unique. > There is no guarantee that the krb5_ccache name will be unique across > the entire system. Using an environment variable would certainly > fail in any situation in which you either had a single process (a > multi-threaded > server) in which each thread must maintain its own cache reference > or where the processes exist in different logon session spaces. For example > a user process communicating with a daemon process. You have just proven one of my points. Thank you. Perhaps this was not so off-topic after all :) Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Apr 6 02:12:24 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06124 for ; Tue, 6 Apr 2004 02:12:24 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i365VrGd001688 for ietf-cat-wg-out720680; Mon, 5 Apr 2004 22:31:53 -0700 (PDT) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i365VoNK001679 for ; Mon, 5 Apr 2004 22:31:51 -0700 (PDT) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i365VdLT019291; Mon, 5 Apr 2004 22:31:45 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i365Vd4F018029; Mon, 5 Apr 2004 23:31:39 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i365VFhf020177; Tue, 6 Apr 2004 00:31:15 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i365VEq0020176; Tue, 6 Apr 2004 00:31:14 -0500 (CDT) Date: Tue, 6 Apr 2004 00:31:14 -0500 From: Nicolas Williams To: Von Welch Cc: ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: GGF's extensions to GSS in Public Comment Message-ID: <20040406053114.GR13507@binky.central.sun.com> References: <16493.30981.963000.758673@gargle.gargle.HOWL> <20040402171928.GU5868@binky.central.sun.com> <16497.43414.143000.902799@gargle.gargle.HOWL> <20040406003905.GS5868@binky.central.sun.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: <20040406003905.GS5868@binky.central.sun.com> User-Agent: Mutt/1.4i Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Apr 05, 2004 at 07:39:05PM -0500, Nicolas Williams wrote: > On Mon, Apr 05, 2004 at 01:46:46PM -0500, Von Welch wrote: > > If so, I'd be interested in seeing your second draft. I think I can > > see the benefits of your approach, but need see how the rubber and > > road meet. > > I'll send you a draft draft privately. Or publically. Attached. I've not yet updated my I-D template, and this draft I-D needs more text, particularly an intro. Cheers, Nico -- --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="draft-williams-gssapi-cred-store-00.txt-formatted" INTERNET-DRAFT Nicolas Williams Sun Microsystems September 2003 April 2004 GSS-APIv2 Extension for Storing Delegated Credentials Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The details of Generic Security Service (GSS) credential store management vary by platform and even by GSS mechanism. This document defines a small extension to the GSS-API which facilitates the use of delegated GSS credentials by GSS applications running on multi-user platforms. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Table of Contents N. Williams [Page 1] DRAFT GSS Credential Store API Expires October 2004 1. Introduction pg. 3 2. GSS_Get_current_cred_store() pg. 3 3. GSS_Set_current_cred_store() pg. 3 4. C-Bindings pg. 4 5. Examples pg. 4 6. Security Considerations pg. 4 7. Acknowledgements pg. 4 8. References pg. 5 8.1. Informative References pg. 5 8.2. Normative References pg. 5 9. Author's Address pg. 5 N. Williams [Page 2] DRAFT GSS Credential Store API Expires October 2004 1. Introduction [Text needed on what is a "credential store" and what is a "current credential store,: and their relation to the callers' current execution context.] [See [gss_store_cred].] 2. GSS_Get_current_cred_store() Inputs: o Outputs: o major_status INTEGER, o minor_status INTEGER, o cred_store_handle CREDENTIAL STORE HANDLE Return status codes: o GSS_S_COMPLETE indicates that there is a credential store or that one can be created, when GSS_Store_cred() is called, for the current execution context of the caller. o GSS_S_UNAVAILABLE indicates that no credential store exists for the current execution context of the caller. o GSS_S_FAILURE indicates that an unspecified failure has occurred. This function returns a credential store handle that refers to the credential store from which credentials would be acquired given the current execution context of the caller. Credential store handles may not remain accessible when the caller switches the user of the execution context. 3. GSS_Set_current_cred_store() Inputs: o cred_store_handle CREDENTIAL STORE HANDLE, Outputs: o major_status INTEGER, o minor_status INTEGER N. Williams [Page 3] DRAFT GSS Credential Store API Expires October 2004 Return status codes: o GSS_S_COMPLETE indicates that the given credential store will be used by subsequent GSS-API credential acquisition or storage made in the same execution context as that of the caller to GSS_Set_current_cred_store(). If the given store handle is GSS_C_NO_STORE then either a default or new (which is a platform-specific matter) credential store will be created and set as the current credential store. o GSS_S_BAD_STORE indicates that the given credential store handle is not recognized or refers to a credential store that no longer exists or is otherwise corrupt. o GSS_S_UNAVAILABLE indicates that the current credential store for the current execution context could not be set, possibly due to lack of resources. o GSS_S_FAILURE indicates that a generic failure has occurred. This function changes the credential store for the current execution context. Calls to this function MAY have platform-specific side effects (e.g., setting environment variables, setting a process' "pag," etc...), but an implementation of it MUST NOT change the user context of the application, a restriction applicable only on multi-user platforms. The current credential store may change or become unavailable when the caller switches the user of the execution context. 4. C-Bindings [...] 5. Examples [...] 6. Security Considerations Acceptor applications MUST only store delegated credentials into appropriate credential stores and only after proper authorization of the authenticated initiator principal to the requested service(s). Acceptor applications that have no use for delegated credentials MUST release them (such acceptor applications that use the GSS-API C-Bindings may simply provide a NULL value for the delegated_cred_handle argument to gss_accept_sec_context()). 7. Acknowledgements N. Williams [Page 4] DRAFT GSS Credential Store API Expires October 2004 [...] 8. References 8.1. Informative References [gss_store_cred] N. Williams, draft-williams-gssapi-store-deleg-creds-00: "GSS-APIv2 Extension for Storing Delegated Credentials," September 2003, Status: Internet-Draft. 8.2. Normative References [RFC2026] S. Bradner, RFC2026: "The Internet Standard Process - Revision 3," October 1996, Obsoletes - RFC 1602, Status: Best Current Practice. [RFC2119] S. Bradner, RFC2119 (BCP14): "Key words for use in RFCs to Indicate Requirement Levels," March 1997, Status: Best Current Practice. [RFC2743] J. Linn, RFC2743: "Generic Security Service Application Program Interface Version 2, Update 1," January 2000, Status: Proposed Standard. [RFC2744] J. Wray, RFC2744: "Generic Security Service API Version 2 : C-bindings," January 2000, Status: Proposed Standard. 9. Author's Address Nicolas Williams Sun Microsystems 5300 Riata Trace Ct Austin, TX 78727 Email: Nicolas.Williams@sun.com Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of N. Williams [Page 5] DRAFT GSS Credential Store API Expires October 2004 developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. N. Williams [Page 6] --6c2NcOVqGQ03X4Wi-- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Apr 6 12:05:01 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00827 for ; Tue, 6 Apr 2004 12:05:00 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i36FJHgl028654 for ietf-cat-wg-out720680; Tue, 6 Apr 2004 08:19:17 -0700 (PDT) Received: from hermes.ctd.anl.gov (hermes.ctd.anl.gov [130.202.113.27]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i36FJDNK028308 for ; Tue, 6 Apr 2004 08:19:13 -0700 (PDT) Received: from hermes.ctd.anl.gov (localhost [127.0.0.1]) by hermes.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA26198 for ; Tue, 6 Apr 2004 10:19:06 -0500 (CDT) Received: from anl.gov (atalanta.ctd.anl.gov [146.137.194.4]) by hermes.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id KAA26180; Tue, 6 Apr 2004 10:19:04 -0500 (CDT) Message-ID: <4072CA70.D74BE2E7@anl.gov> Date: Tue, 06 Apr 2004 10:19:12 -0500 From: "Douglas E. Engert" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Nicolas Williams CC: Jeffrey Altman , Von Welch , ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: [OT] Re: GGF's extensions to GSS in Public Comment References: <16493.30981.963000.758673@gargle.gargle.HOWL> <20040402171928.GU5868@binky.central.sun.com> <20040406004459.GO13507@binky.central.sun.com> <407211F3.9020506@columbia.edu> <20040406045913.GW5868@binky.central.sun.com> <40723DCC.3010406@columbia.edu> <20040406052420.GY5868@binky.central.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit There seams to be a more underlying problem here, and that is how to store credentials to be used by the kernel for uses like NFSv4, AFS, DFS or even IPSEC. The problem gets tied in with what AFS and DFS call a Process Authentication Group (PAG) which is a way of associating processes which share credentials in the kernel. Nico appears to be arguing that there is a credential store capability that a process is running under that gssapi needs to be able to store into, where as the GGF is saying, there is not such a credential store and each mechanism has its own way to store credentials and a process may have multiple sets of credentials available, and that gssapi needs to be able to store delegated credentials in such a way that they can be used by gss_acquire_cred in a child process. These are not inconsistent, see below. I think that the older DCE/DFS tried to address both of these situations, i.e. having Kerberos credentials available for use by applications and by DFS via the kernel and PAGs. They did this by constraining the the KRB5CCNAME to be a file in /opt/dcelocal/var/security/dcecreds/krb5cc.XXXXXXXX I may have the exact location wrong, but the idea is it was a well known location with XXXXXXXX being the DFS PAG number. This allowed DFS in the kernel to use the dced process (or some helper process of the kernel) to get additional kerberos tickets to be used in the kernel. (I believe on AIX each thread could have its own PAG, but my memory could be failing.) AFS did not have this problem, as the AFS token in the kernel was only acquired once and there was no need for the kernel to need to acquire additional tokens using credentials stored outside of the kernel. The GGF gss_export_cred returns a string suitable to be used by putenv. But this does not mean that it has to be a file name, it is a URL that can be used by the gssapi in subsequent processes to locate credentials. On a system where credentials are handled by a credential manager, the URL could even be ignored. I don't think we are that far apart. We need to look at the larger picture of how credential management can be done by the operating system, so credentials can be used by the kernel as well as used by the application. We also need to realize that an application may be using multiple credentials for its own purposes i.e. SSL, TCP where the kernel isn't involved at all. We need for gssapi to be able address both needs. Nicolas Williams wrote: > > On Tue, Apr 06, 2004 at 01:19:08AM -0400, Jeffrey Altman wrote: > > There is one cache associated with the LSA session. > > A process or thread can create a new cache which is not > > associated with the session. However, it would be > > inappropriate to use an environment variable in this case. > > > > Within the context of a logon session a krb5_ccache name is unique. > > There is no guarantee that the krb5_ccache name will be unique across > > the entire system. Using an environment variable would certainly > > fail in any situation in which you either had a single process (a > > multi-threaded > > server) in which each thread must maintain its own cache reference > > or where the processes exist in different logon session spaces. For example > > a user process communicating with a daemon process. > > You have just proven one of my points. Thank you. Perhaps this was not > so off-topic after all :) > > Nico > -- > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > This message was posted through the Stanford campus mailing list > server. If you wish to unsubscribe from this mailing list, send the > message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Apr 6 14:55:57 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15866 for ; Tue, 6 Apr 2004 14:55:56 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i36IKCXS025241 for ietf-cat-wg-out720680; Tue, 6 Apr 2004 11:20:12 -0700 (PDT) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i36IK9NK025219 for ; Tue, 6 Apr 2004 11:20:09 -0700 (PDT) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i36IJuLT000972; Tue, 6 Apr 2004 11:19:56 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i36IJs4F019550; Tue, 6 Apr 2004 12:19:55 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i36IJUhf020411; Tue, 6 Apr 2004 13:19:30 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i36IJRcn020410; Tue, 6 Apr 2004 13:19:27 -0500 (CDT) Date: Tue, 6 Apr 2004 13:19:27 -0500 From: Nicolas Williams To: "Douglas E. Engert" Cc: Jeffrey Altman , Von Welch , ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: [OT] Re: GGF's extensions to GSS in Public Comment Message-ID: <20040406181927.GB5868@binky.central.sun.com> References: <16493.30981.963000.758673@gargle.gargle.HOWL> <20040402171928.GU5868@binky.central.sun.com> <20040406004459.GO13507@binky.central.sun.com> <407211F3.9020506@columbia.edu> <20040406045913.GW5868@binky.central.sun.com> <40723DCC.3010406@columbia.edu> <20040406052420.GY5868@binky.central.sun.com> <4072CA70.D74BE2E7@anl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4072CA70.D74BE2E7@anl.gov> User-Agent: Mutt/1.4i Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Tue, Apr 06, 2004 at 10:19:12AM -0500, Douglas E. Engert wrote: > There seams to be a more underlying problem here, and that is how > to store credentials to be used by the kernel for uses like > NFSv4, AFS, DFS or even IPSEC. The problem gets tied in with what AFS > and DFS call a Process Authentication Group (PAG) which is a way of > associating processes which share credentials in the kernel. > > Nico appears to be arguing that there is a credential store capability > that a process is running under that gssapi needs to be able to store into, > where as the GGF is saying, there is not such a credential store > and each mechanism has its own way to store credentials and a process may > have multiple sets of credentials available, and that gssapi needs to > be able to store delegated credentials in such a way that they can be used > by gss_acquire_cred in a child process. These are not inconsistent, see below. [...] > The GGF gss_export_cred returns a string suitable to be used by putenv. > But this does not mean that it has to be a file name, it is a URL that can be > used by the gssapi in subsequent processes to locate credentials. > On a system where credentials are handled by a credential manager, the URL could > even be ignored. Doug, this does not address the issues with the use of environment variables in GSS_Export_cred(). > I don't think we are that far apart. We need to look at the larger picture of > how credential management can be done by the operating system, so credentials > can be used by the kernel as well as used by the application. We also need > to realize that an application may be using multiple credentials for its > own purposes i.e. SSL, TCP where the kernel isn't involved at all. GSS_Store_cred() does not care what sort of credential store you're storing into -- GSS_Store_cred() assumes there's a "current" credential store available when it is called. > We need for gssapi to be able address both needs. I think GSS_Store_cred() + GSS_Get/Set_current_cred_store() proposal covers both needs. The GSS_Get/Set_current_cred_store() proposal needs more text to cover this, but I'm convinced it can cover your needs. If you don't care about the user-land+kernel vs. user-land-only distinction then GSS_Store_cred() may be all you need. Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Apr 6 23:56:38 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01652 for ; Tue, 6 Apr 2004 23:56:37 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i373Okik023968 for ietf-cat-wg-out720680; Tue, 6 Apr 2004 20:24:46 -0700 (PDT) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i373OhNK023962 for ; Tue, 6 Apr 2004 20:24:43 -0700 (PDT) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i373ORio017644; Tue, 6 Apr 2004 20:24:28 -0700 (PDT) Received: from soe-austin.central.sun.com (soe-austin.Central.Sun.COM [129.153.136.70]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i373ORcE007067; Tue, 6 Apr 2004 21:24:27 -0600 (MDT) Received: from soe-austin.central.sun.com (localhost [127.0.0.1]) by soe-austin.central.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i373OQYf586898; Tue, 6 Apr 2004 22:24:26 -0500 (CDT) Received: (from nw141292@localhost) by soe-austin.central.sun.com (8.12.11+Sun/8.12.11/Submit) id i373OOpN586897; Tue, 6 Apr 2004 22:24:24 -0500 (CDT) Date: Tue, 6 Apr 2004 22:24:24 -0500 From: Nicolas Williams To: "Douglas E. Engert" Cc: Jeffrey Altman , Von Welch , ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: [OT] Re: GGF's extensions to GSS in Public Comment Message-ID: <20040407032424.GA586817@soe-austin.central.sun.com> References: <16493.30981.963000.758673@gargle.gargle.HOWL> <20040402171928.GU5868@binky.central.sun.com> <20040406004459.GO13507@binky.central.sun.com> <407211F3.9020506@columbia.edu> <20040406045913.GW5868@binky.central.sun.com> <40723DCC.3010406@columbia.edu> <20040406052420.GY5868@binky.central.sun.com> <4072CA70.D74BE2E7@anl.gov> <20040406181927.GB5868@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040406181927.GB5868@binky.central.sun.com> User-Agent: Mutt/1.4i Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Tue, Apr 06, 2004 at 01:19:27PM -0500, Nicolas Williams wrote: > On Tue, Apr 06, 2004 at 10:19:12AM -0500, Douglas E. Engert wrote: > [...] > > The GGF gss_export_cred returns a string suitable to be used by putenv. > > But this does not mean that it has to be a file name, it is a URL that can be > > used by the gssapi in subsequent processes to locate credentials. > > On a system where credentials are handled by a credential manager, the URL could > > even be ignored. > > Doug, this does not address the issues with the use of environment > variables in GSS_Export_cred(). > > > I don't think we are that far apart. We need to look at the larger picture of > > how credential management can be done by the operating system, so credentials > > can be used by the kernel as well as used by the application. We also need > > to realize that an application may be using multiple credentials for its > > own purposes i.e. SSL, TCP where the kernel isn't involved at all. > > GSS_Store_cred() does not care what sort of credential store you're > storing into -- GSS_Store_cred() assumes there's a "current" credential > store available when it is called. > > > We need for gssapi to be able address both needs. > > I think GSS_Store_cred() + GSS_Get/Set_current_cred_store() proposal > covers both needs. The GSS_Get/Set_current_cred_store() proposal needs > more text to cover this, but I'm convinced it can cover your needs. > > If you don't care about the user-land+kernel vs. user-land-only > distinction then GSS_Store_cred() may be all you need. Actually, I don't think GSS_Store_cred()/GSS_Get/Set_current_cred_store() should directly distinguish between credential stores of one kind (user-land only) and another (kernerl+user-land). I believe that the default_cred parameter of GSS_Store_cred() provides enough of a hint to the implementation as to what kind of store to use, where such a hint is needed at all. I don't think we should saddle generic interfaces with platform-specific details. Cheers, Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Apr 7 13:38:29 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16250 for ; Wed, 7 Apr 2004 13:38:29 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i37HEBLG005756 for ietf-cat-wg-out720680; Wed, 7 Apr 2004 10:14:11 -0700 (PDT) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i37HE8NK005735 for ; Wed, 7 Apr 2004 10:14:08 -0700 (PDT) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i37HDnVq018215; Wed, 7 Apr 2004 10:13:50 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i37HDncE002997; Wed, 7 Apr 2004 11:13:49 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i37HDOhf021278; Wed, 7 Apr 2004 12:13:24 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i37HDLr9021277; Wed, 7 Apr 2004 12:13:21 -0500 (CDT) Date: Wed, 7 Apr 2004 12:13:21 -0500 From: Nicolas Williams To: "Douglas E. Engert" Cc: Jeffrey Altman , Von Welch , ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: [OT] Re: GGF's extensions to GSS in Public Comment Message-ID: <20040407171321.GK5868@binky.central.sun.com> References: <16493.30981.963000.758673@gargle.gargle.HOWL> <20040402171928.GU5868@binky.central.sun.com> <20040406004459.GO13507@binky.central.sun.com> <407211F3.9020506@columbia.edu> <20040406045913.GW5868@binky.central.sun.com> <40723DCC.3010406@columbia.edu> <20040406052420.GY5868@binky.central.sun.com> <4072CA70.D74BE2E7@anl.gov> <20040406181927.GB5868@binky.central.sun.com> <20040407032424.GA586817@soe-austin.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040407032424.GA586817@soe-austin.central.sun.com> User-Agent: Mutt/1.4i Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Tue, Apr 06, 2004 at 10:24:24PM -0500, Nicolas Williams wrote: > Actually, I don't think GSS_Store_cred()/GSS_Get/Set_current_cred_store() > should directly distinguish between credential stores of one kind > (user-land only) and another (kernerl+user-land). I believe that the > default_cred parameter of GSS_Store_cred() provides enough of a hint to > the implementation as to what kind of store to use, where such a hint is > needed at all. To further clarify this: NFS/AFS/DFS/CIFS/etc... generally use the default credential (GSS_C_NO_CREDENTIAL), in fact, they have to because the interfaces[1] through which an application uses filesystems do not provide for an initiator name or credential input parameter. Therefore the default_cred input parameter of GSS_Store_cred() provides enough information for the implementation to decide whether or not to make the given credentials available for use by remote file system protocols. [1] Think of Unix system calls, such as open(2). Cheers, Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Apr 7 14:22:08 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24030 for ; Wed, 7 Apr 2004 14:22:07 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i37HSrbB010109 for ietf-cat-wg-out720680; Wed, 7 Apr 2004 10:28:53 -0700 (PDT) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i37HSnNK010089 for ; Wed, 7 Apr 2004 10:28:49 -0700 (PDT) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i37HShVq027661; Wed, 7 Apr 2004 10:28:43 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i37HSgcE009551; Wed, 7 Apr 2004 11:28:42 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i37HSHhf021313; Wed, 7 Apr 2004 12:28:17 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i37HSHSv021312; Wed, 7 Apr 2004 12:28:17 -0500 (CDT) Date: Wed, 7 Apr 2004 12:28:17 -0500 From: Nicolas Williams To: ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Comments on the GGF GSS-API extensions proposal Message-ID: <20040407172817.GU13507@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk 0. I think that my objections to the GSS_Export_cred() export-to- environment-variable proposal are sufficiently documented elsewhere that I don't need to repeat them. Please see recent discussions on these same lists if you are new to this discussion. 1. I do support the notion of exporting credentials to tokens. For the Kerberos V mechanism the mechanism-specific part of the exported credential token could just be a KRB-CRED with the encrypted part "encrypted" using the NULL enctype. Also, note that the format of exported credentials tokens needs to be specified! There should be a generic token wrapper/header and a mechanism-specific part; for the Kerberos V mechanism a KRB-CRED could be used as described above. 2. I oppose the credential delegation at any time concept. Basically, I see no reason not to re-authenticate in order to delegate fresh credentials. SSHv2 w/ GSS-protected key exchange gets this right since re-keying allows for delegation of fresh credentials. Presumably delegated credentials generally do not expire prior to the expiration of the contexts they are delegated with. And it would not be a good idea, from a security point of view, to delegate fresh credentials without re-authenticating the acceptor if the context one would do it with is expired. Even if/where delegated creds tend to expire earlier than the security context with which they are delegated, credential- delegation-at-any-time is really just an optimization that I don't think we need to make. 3. Can you explain again why the GSS_PROTECTION_FAIL_ON_CONTEXT_EXPIRATION option is needed, why the per-msg token functions shouldn't always fail when the context is expired, period? 4. Can you explain again why we need generic token framing for all GSS tokens? In all IETF protocols that use the GSS-API that I can think of the lack of generic token framing has never been a problem. I.e., SASL, RPCSEC_GSS, FTP, SSHv2, none have had any problems with the lack of generic token framing for non-initial context and per-msg GSS tokens. 5. I do like the idea of extending GSS_Display_status(). I think a context input parameter to GSS_Display_status() would help produce more context-specific information. Changing the prototype of GSS_Display_status() is not possible though, so we'll need an extended replacement for it. Also, I think we need a dummy mechanism to use with GSS_Display_status() when attempting to display _minor_ status codes from GSS-API functions that have no mechanism input/output parameter that could be used instead but which still output a minor status code. E.g., GSS_Indicate_mechs() can output a minor status code, but it cannot be associated with any one mechanism! GSS_C_NULL_OID cannot be used for this purpose because of default mechanism semantics. Also, some functions should be allowed to return GSS_S_COMPLETE but non-zero minor status codes. E.g., GSS_Indicate_mechs() should be able to return GSS_S_COMPLETE and a non-zero minor status code that could be used to indicate that some mechanism could not be loaded. 6. Extensions relating to authorization data are better associated with GSS-API names than with GSS-API credentials and contexts. [Thanks to Sam for this insight.] This approach will lead to a more consistent interface. Plus, for those who have GSS userok()/name_to_localname() type interfaces there is an obvious benefit, namely that said interfaces continue to be useful and workable in the face of authorization data. I suspect that this will be a significant topic at the KITTEN BoF so please do attend it! I don't care to go into the details of what we might propose in this area yet -- I'd rather spend some time writing up a proposal instead. Comments? Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Apr 7 14:26:36 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24221 for ; Wed, 7 Apr 2004 14:26:36 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i37Hw5Md015044 for ietf-cat-wg-out720680; Wed, 7 Apr 2004 10:58:05 -0700 (PDT) Received: from hermes.ctd.anl.gov (hermes.ctd.anl.gov [130.202.113.27]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i37Hw2NK015021 for ; Wed, 7 Apr 2004 10:58:02 -0700 (PDT) Received: from hermes.ctd.anl.gov (localhost [127.0.0.1]) by hermes.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id MAA01933 for ; Wed, 7 Apr 2004 12:57:56 -0500 (CDT) Received: from anl.gov (atalanta.ctd.anl.gov [146.137.194.4]) by hermes.ctd.anl.gov (8.9.1a/8.9.1) with ESMTP id MAA01893; Wed, 7 Apr 2004 12:57:53 -0500 (CDT) Message-ID: <40744128.CD351FA4@anl.gov> Date: Wed, 07 Apr 2004 12:58:00 -0500 From: "Douglas E. Engert" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Nicolas Williams CC: Jeffrey Altman , Von Welch , ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: [OT] Re: GGF's extensions to GSS in Public Comment References: <16493.30981.963000.758673@gargle.gargle.HOWL> <20040402171928.GU5868@binky.central.sun.com> <20040406004459.GO13507@binky.central.sun.com> <407211F3.9020506@columbia.edu> <20040406045913.GW5868@binky.central.sun.com> <40723DCC.3010406@columbia.edu> <20040406052420.GY5868@binky.central.sun.com> <4072CA70.D74BE2E7@anl.gov> <20040406181927.GB5868@binky.central.sun.com> <20040407032424.GA586817@soe-austin.central.sun.com> <20040407171321.GK5868@binky.central.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Nicolas Williams wrote: > > On Tue, Apr 06, 2004 at 10:24:24PM -0500, Nicolas Williams wrote: > > Actually, I don't think GSS_Store_cred()/GSS_Get/Set_current_cred_store() > > should directly distinguish between credential stores of one kind > > (user-land only) and another (kernerl+user-land). I believe that the > > default_cred parameter of GSS_Store_cred() provides enough of a hint to > > the implementation as to what kind of store to use, where such a hint is > > needed at all. > > To further clarify this: NFS/AFS/DFS/CIFS/etc... generally use the > default credential (GSS_C_NO_CREDENTIAL), in fact, they have to because > the interfaces[1] through which an application uses filesystems do not > provide for an initiator name or credential input parameter. > > Therefore the default_cred input parameter of GSS_Store_cred() provides > enough information for the implementation to decide whether or not to > make the given credentials available for use by remote file system > protocols. > > [1] Think of Unix system calls, such as open(2). Ah, but applications like a web server may wish to have multiple credentials one for each sesion, and may wish to keep track of these, and to pass then on to child preocesses or scripts where they ae used for access to NFS/AFS/DFS/CIFS/etc ... The web server itself may wish to access files using different sets of credentials too form the same process too. So how do you propose that the application handle multiple delegated credentials? > > Cheers, > > Nico > -- -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Apr 7 14:48:32 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26396 for ; Wed, 7 Apr 2004 14:48:31 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i37I6ZId016249 for ietf-cat-wg-out720680; Wed, 7 Apr 2004 11:06:35 -0700 (PDT) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i37I6UNK016227 for ; Wed, 7 Apr 2004 11:06:30 -0700 (PDT) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i37I6MVq022247; Wed, 7 Apr 2004 11:06:22 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i37I6L4F010233; Wed, 7 Apr 2004 12:06:21 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i37I5uhf021349; Wed, 7 Apr 2004 13:05:56 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i37I5ucH021348; Wed, 7 Apr 2004 13:05:56 -0500 (CDT) Date: Wed, 7 Apr 2004 13:05:56 -0500 From: Nicolas Williams To: "Douglas E. Engert" Cc: Jeffrey Altman , Von Welch , ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: [OT] Re: GGF's extensions to GSS in Public Comment Message-ID: <20040407180555.GN5868@binky.central.sun.com> References: <20040406004459.GO13507@binky.central.sun.com> <407211F3.9020506@columbia.edu> <20040406045913.GW5868@binky.central.sun.com> <40723DCC.3010406@columbia.edu> <20040406052420.GY5868@binky.central.sun.com> <4072CA70.D74BE2E7@anl.gov> <20040406181927.GB5868@binky.central.sun.com> <20040407032424.GA586817@soe-austin.central.sun.com> <20040407171321.GK5868@binky.central.sun.com> <40744128.CD351FA4@anl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40744128.CD351FA4@anl.gov> User-Agent: Mutt/1.4i Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Wed, Apr 07, 2004 at 12:58:00PM -0500, Douglas E. Engert wrote: > Nicolas Williams wrote: > > To further clarify this: NFS/AFS/DFS/CIFS/etc... generally use the > > default credential (GSS_C_NO_CREDENTIAL), in fact, they have to because > > the interfaces[1] through which an application uses filesystems do not > > provide for an initiator name or credential input parameter. > > > > Therefore the default_cred input parameter of GSS_Store_cred() provides > > enough information for the implementation to decide whether or not to > > make the given credentials available for use by remote file system > > protocols. > > > > [1] Think of Unix system calls, such as open(2). > > Ah, but applications like a web server may wish to have multiple credentials > one for each sesion, and may wish to keep track of these, and to pass then > on to child preocesses or scripts where they ae used for access to > NFS/AFS/DFS/CIFS/etc ... So? They can do so just fine with GSS_Store_cred(). Just keep the delegated credential handle around and GSS_Store_cred() it when switching to the context of the user being impersonated. > The web server itself may wish to access files using different sets of credentials > too form the same process too. A process (or thread, depending on the platform) can only have one set of default credentials for use when accessing the file system. This is true on every *nix platform and on Windows. > So how do you propose that the application handle multiple delegated credentials? Keep all of those delegated credential handles around and store them as necessary when impersonating users. Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Apr 7 14:52:19 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26564 for ; Wed, 7 Apr 2004 14:52:18 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i37IOeOi021338 for ietf-cat-wg-out720680; Wed, 7 Apr 2004 11:24:40 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i37IObNK021331 for ; Wed, 7 Apr 2004 11:24:38 -0700 (PDT) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i37IOY2v013186; Wed, 7 Apr 2004 12:24:34 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i37IOX4F018440; Wed, 7 Apr 2004 12:24:33 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i37IO8hf021375; Wed, 7 Apr 2004 13:24:08 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i37IO8bo021374; Wed, 7 Apr 2004 13:24:08 -0500 (CDT) Date: Wed, 7 Apr 2004 13:24:08 -0500 From: Nicolas Williams To: "Douglas E. Engert" Cc: Jeffrey Altman , Von Welch , ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: [OT] Re: GGF's extensions to GSS in Public Comment Message-ID: <20040407182408.GW13507@binky.central.sun.com> References: <407211F3.9020506@columbia.edu> <20040406045913.GW5868@binky.central.sun.com> <40723DCC.3010406@columbia.edu> <20040406052420.GY5868@binky.central.sun.com> <4072CA70.D74BE2E7@anl.gov> <20040406181927.GB5868@binky.central.sun.com> <20040407032424.GA586817@soe-austin.central.sun.com> <20040407171321.GK5868@binky.central.sun.com> <40744128.CD351FA4@anl.gov> <20040407180555.GN5868@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040407180555.GN5868@binky.central.sun.com> User-Agent: Mutt/1.4i Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Wed, Apr 07, 2004 at 01:05:55PM -0500, Nicolas Williams wrote: > On Wed, Apr 07, 2004 at 12:58:00PM -0500, Douglas E. Engert wrote: > > The web server itself may wish to access files using different sets of credentials > > too form the same process too. > > A process (or thread, depending on the platform) can only have one set > of default credentials for use when accessing the file system. This is > true on every *nix platform and on Windows. This should have read: "A process ... can only have one set of default credentials at any given time for use ..." -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Apr 7 20:43:14 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23933 for ; Wed, 7 Apr 2004 20:43:14 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i37NwGJN018963 for ietf-cat-wg-out720680; Wed, 7 Apr 2004 16:58:16 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.171]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i37NwCNK018940 for ; Wed, 7 Apr 2004 16:58:13 -0700 (PDT) Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id BAA26365; Thu, 8 Apr 2004 01:57:58 +0200 (MESZ) From: Martin Rex Message-Id: <200404072357.BAA12098@uw1048.wdf.sap.corp> Subject: Re: GGF's extensions to GSS in Public Comment To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Thu, 8 Apr 2004 01:57:57 +0200 (MET DST) Cc: welch@mcs.anl.gov, ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org In-Reply-To: <20040406004459.GO13507@binky.central.sun.com> from "Nicolas Williams" at Apr 5, 4 07:44:59 pm Reply-To: martin.rex@sap.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-SAP: out Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 8bit Nicolas Williams wrote: > > The problems with the use of environment variables are: > > 1. Environment variables are PLATFORM-SPECIFIC: > > - not all platforms can be expected to have this facility Correct. I was told that MacOS up to 9.x didn't have environment variables. > - not all platforms can be expected to have the same semantics it Someone who thinks that environment variables are a good idea probably has very little programming experience on Microsoft Windows platforms. On Microsoft Win32 (and Win64 of course) an EXE and every single one of the DLLs that are loaded by the EXE can bring along it's own code instance of a C runtime library with it's own private STDC objects (i.e. private FILE * handles, private heap allocators, private environment variables). And this is not only a theoretical possibility, it actually happens. It can even happen if both, EXE and DLL were linked against the multi-threaded DLL "MSVCRT.DLL", but built with different compiler versions (i.e. one was built with Visual Studio 98 and the other with Visual Studio .NET). The result is that environment variables created/updated by the EXE via putenv() are not visible to the code in the DLL... This is a pretty surprising (mis-)feature of the Win32 platform and the result of indepedent instances of the C-Runtime library. Unfortunately very few developers seem to be aware of this problem. On most Unix systems this is impossible, because the commonly used "brk()" interface for process heap management and this is a highlander interface that cannot be used by several independent heap allocators within a single process. -Martin -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Wed Apr 7 21:36:03 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03666 for ; Wed, 7 Apr 2004 21:36:02 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i3810Hf3027974 for ietf-cat-wg-out720680; Wed, 7 Apr 2004 18:00:17 -0700 (PDT) Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i3810DNK027956 for ; Wed, 7 Apr 2004 18:00:14 -0700 (PDT) Received: from VON-THINKPAD (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id i38104076526; Wed, 7 Apr 2004 20:00:05 -0500 X-Mailer: 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid (via feedmail 10 Q); VM 7.14 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16500.35004.991000.653152@gargle.gargle.HOWL> Date: Wed, 7 Apr 2004 18:03:24 -0500 To: Nicolas Williams Cc: ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: GGF's extensions to GSS in Public Comment In-Reply-To: <20040406053114.GR13507@binky.central.sun.com> References: <16493.30981.963000.758673@gargle.gargle.HOWL> <20040402171928.GU5868@binky.central.sun.com> <16497.43414.143000.902799@gargle.gargle.HOWL> <20040406003905.GS5868@binky.central.sun.com> <20040406053114.GR13507@binky.central.sun.com> From: Von Welch Reply-To: Von Welch Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Nico, This text from your draft describing set_current_cred_store() gets at the problem we were trying to solve by including env variables in the output of gss_export_cred(): > Calls to this function MAY have platform-specific side effects (e.g., > setting environment variables, setting a process' "pag," etc...), but > an implementation of it MUST NOT change the user context of the > application, a restriction applicable only on multi-user platforms. For credential stores that are meaningful to the kernel, the application doesn't in general have to be aware of them since the kernel will generally make sure the process doesn't accidentially meddle with them. (E.g. if a process changes its PAG it typically knows what it is doing.) But for GSS mechanisms that don't have kernel support for their creentials stores and use environment variables, this isn't the case. A process might decide to clean up its environment for a number of reasons and accidentially effect the GSS mechanism's current credential store or fail to pass the meaningful env variable to a child process as in SSHD. This is what led us to have a mechanism that allowed the GSS mechanism to tell the calling application that a particular env variable was meaningful to it so that a well behaved application could treat that variable appropriately. You are right in that our use of environment variables was focused on a couple of specific mechanisms (GSI & Krb5) in which we were interested. I agree the approach does not generalize well to mechanisms that use other methods besides env variables. However I still believe it solves a problem for those mechanisms that I don't undertstand how your approach solves yet. (BTW, is the intent that gss_set_current_cred_store() can create a new credential store, presumably if cred_store_handle has some special value?) Von -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Apr 8 00:43:41 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14661 for ; Thu, 8 Apr 2004 00:43:41 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i383JjtN010940 for ietf-cat-wg-out720680; Wed, 7 Apr 2004 20:19:45 -0700 (PDT) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i383JgNK010935 for ; Wed, 7 Apr 2004 20:19:42 -0700 (PDT) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i383Ja6N014034; Wed, 7 Apr 2004 20:19:36 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i383JZcE017403; Wed, 7 Apr 2004 21:19:35 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i383JAhf021729; Wed, 7 Apr 2004 22:19:10 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i383J94Q021728; Wed, 7 Apr 2004 22:19:09 -0500 (CDT) Date: Wed, 7 Apr 2004 22:19:09 -0500 From: Nicolas Williams To: Martin Rex Cc: welch@mcs.anl.gov, ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: GGF's extensions to GSS in Public Comment Message-ID: <20040408031909.GZ5868@binky.central.sun.com> References: <20040406004459.GO13507@binky.central.sun.com> <200404072357.BAA12098@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404072357.BAA12098@uw1048.wdf.sap.corp> User-Agent: Mutt/1.4i Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Thu, Apr 08, 2004 at 01:57:57AM +0200, Martin Rex wrote: > > Nicolas Williams wrote: > > > > The problems with the use of environment variables are: > > > > 1. Environment variables are PLATFORM-SPECIFIC: > > > > - not all platforms can be expected to have this facility > > Correct. I was told that MacOS up to 9.x didn't have environment variables. Thank you. > > - not all platforms can be expected to have the same semantics it > > Someone who thinks that environment variables are a good idea probably > has very little programming experience on Microsoft Windows platforms. Thanks... Sounds, er, fun? [...] > On most Unix systems this is impossible, because the commonly used "brk()" > interface for process heap management and this is a highlander interface > that cannot be used by several independent heap allocators within a > single process. You'd be surprised at the fun you can have with a modern runtime linker... :) Cheers, Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Apr 8 00:45:56 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15077 for ; Thu, 8 Apr 2004 00:45:55 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i383FNTC010798 for ietf-cat-wg-out720680; Wed, 7 Apr 2004 20:15:23 -0700 (PDT) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i383FKNK010784 for ; Wed, 7 Apr 2004 20:15:20 -0700 (PDT) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i383FDgx002627; Wed, 7 Apr 2004 20:15:13 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i383FC4F006401; Wed, 7 Apr 2004 21:15:13 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i383Eihf021715; Wed, 7 Apr 2004 22:14:44 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i383Eflr021714; Wed, 7 Apr 2004 22:14:41 -0500 (CDT) Date: Wed, 7 Apr 2004 22:14:41 -0500 From: Nicolas Williams To: Von Welch Cc: ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: GGF's extensions to GSS in Public Comment Message-ID: <20040408031441.GX5868@binky.central.sun.com> References: <16493.30981.963000.758673@gargle.gargle.HOWL> <20040402171928.GU5868@binky.central.sun.com> <16497.43414.143000.902799@gargle.gargle.HOWL> <20040406003905.GS5868@binky.central.sun.com> <20040406053114.GR13507@binky.central.sun.com> <16500.35004.991000.653152@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16500.35004.991000.653152@gargle.gargle.HOWL> User-Agent: Mutt/1.4i Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Wed, Apr 07, 2004 at 06:03:24PM -0500, Von Welch wrote: > > Nico, > > This text from your draft describing set_current_cred_store() gets at > the problem we were trying to solve by including env variables in the > output of gss_export_cred(): > > > Calls to this function MAY have platform-specific side effects (e.g., > > setting environment variables, setting a process' "pag," etc...), but > > an implementation of it MUST NOT change the user context of the > > application, a restriction applicable only on multi-user platforms. Yes. See below. > For credential stores that are meaningful to the kernel, the > application doesn't in general have to be aware of them since the > kernel will generally make sure the process doesn't accidentially > meddle with them. (E.g. if a process changes its PAG it typically > knows what it is doing.) > > But for GSS mechanisms that don't have kernel support for their > creentials stores and use environment variables, this isn't the > case. A process might decide to clean up its environment for a number > of reasons and accidentially effect the GSS mechanism's current > credential store or fail to pass the meaningful env variable to a > child process as in SSHD. The calls to [GSS_Set_cred_store()/]GSS_Store_cred() need to happen where your application today would go about setting up the environment (and here I don't mean just variables) of the process it will spawn or exec. > This is what led us to have a mechanism that allowed the GSS mechanism > to tell the calling application that a particular env variable was > meaningful to it so that a well behaved application could treat that > variable appropriately. But you failed to abstract the matter sufficiently. See above. > You are right in that our use of environment variables was focused on > a couple of specific mechanisms (GSI & Krb5) in which we were > interested. I agree the approach does not generalize well to > mechanisms that use other methods besides env variables. I said (or should have, if I said "mechanisms" instead) "implementations." Nothing in rfc1964 (the Kerberos V mechanism) says [or ought say] anything whatsoever about environment variables. The implementation(s) of the Kerberos V mechanism that you are used to happen to use environment variables, but I dare say that this is mostly a result of those implementations being alien to the operating systems on which they are used. Native implementations (e.g., Microsoft's) don't have anything at all to do with environment variables. > However I still believe it solves a problem for those mechanisms that > I don't undertstand how your approach solves yet. I make another attempt to explain it below. To me it's clear as it can be. > (BTW, is the intent that gss_set_current_cred_store() can create a new > credential store, presumably if cred_store_handle has some special > value?) - The intent of GSS_Get_cred_store() is to get a handle for the current credential store. - The purpose of GSS_Set_cred_store() is to set the current cred store to the given handle OR, if the NULL handle is given, to a *new* store. - The intent of GSS_Store_cred() is to store the given credential into the current credential store. I consider GSS_Get_cred_store()/GSS_Set_cred_store() to be optional because the one factor that cannot be easily abstracted is user context switching (e.g., setuid(2)), yet user context switching generally does [must!] change the current credential store (switching user context means giving up access to some objects and gaining access to others). So you see, on platforms with one credential store per-user, as opposed to per-session, there is no need at all for GSS_Get/Set_cred_store()... -- user context switching suffices, and all multi-user platforms have a way to do that already! If this is still not clear maybe we should have a conference call, or perhaps we can discuss this in person at the next IETF meeting, or perhaps at the next KRB WG interim meeting, if one is held and you and I manage to be able to attend it. Cheers, Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Apr 8 10:50:58 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24420 for ; Thu, 8 Apr 2004 10:50:57 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i38DxYek003855 for ietf-cat-wg-out720680; Thu, 8 Apr 2004 06:59:34 -0700 (PDT) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i38DxVNK003844 for ; Thu, 8 Apr 2004 06:59:31 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.89.50]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i38DxP6N019784; Thu, 8 Apr 2004 06:59:25 -0700 (PDT) Received: from sun.com (vpn-129-152-224-77.East.Sun.COM [129.152.224.77]) by jurassic.eng.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i38DxJg0133287; Thu, 8 Apr 2004 06:59:24 -0700 (PDT) Message-ID: <40755AAF.1090103@sun.com> Date: Thu, 08 Apr 2004 09:59:11 -0400 From: Wyllys Ingersoll User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7b) Gecko/20040319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Von Welch CC: Nicolas Williams , ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: GGF's extensions to GSS in Public Comment References: <16493.30981.963000.758673@gargle.gargle.HOWL> <20040402171928.GU5868@binky.central.sun.com> <16497.43414.143000.902799@gargle.gargle.HOWL> <20040406003905.GS5868@binky.central.sun.com> <20040406053114.GR13507@binky.central.sun.com> <16500.35004.991000.653152@gargle.gargle.HOWL> In-Reply-To: <16500.35004.991000.653152@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Von Welch wrote: > But for GSS mechanisms that don't have kernel support for their > creentials stores and use environment variables, this isn't the > case. A process might decide to clean up its environment for a number > of reasons and accidentially effect the GSS mechanism's current > credential store or fail to pass the meaningful env variable to a > child process as in SSHD. > > This is what led us to have a mechanism that allowed the GSS mechanism > to tell the calling application that a particular env variable was > meaningful to it so that a well behaved application could treat that > variable appropriately. Maybe I'm misunderstanding, but wouldn't this mean that the application has to make assumptions about the underlying mechanisms implementation in order to get the variable correctly? > > You are right in that our use of environment variables was focused on > a couple of specific mechanisms (GSI & Krb5) in which we were > interested. I agree the approach does not generalize well to > mechanisms that use other methods besides env variables. I think that specifying the use of environment variables as an interface for manipulating the configuration of the mechanisms is a really ulgy solution. Use of environment variables may be acceptable in a particular implementation of a spec, but they should definitley not be part of any standards document for a generic interface such as this. -Wyllys Ingersoll -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Apr 8 13:50:52 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07945 for ; Thu, 8 Apr 2004 13:50:52 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i38HP9Wv000041 for ietf-cat-wg-out720680; Thu, 8 Apr 2004 10:25:09 -0700 (PDT) Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i38HP6NK000015 for ; Thu, 8 Apr 2004 10:25:07 -0700 (PDT) Received: from VON-THINKPAD (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id i38HOu0248988; Thu, 8 Apr 2004 12:24:56 -0500 X-Mailer: 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid (via feedmail 10 I); VM 7.14 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16501.35547.702000.106042@gargle.gargle.HOWL> Date: Thu, 8 Apr 2004 12:24:43 -0500 To: martin.rex@sap.com Cc: Nicolas.Williams@sun.com (Nicolas Williams), ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: GGF's extensions to GSS in Public Comment From: Von Welch Reply-To: Von Welch Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit > Someone who thinks that environment variables are a good idea probably > has very little programming experience on Microsoft Windows platforms. For implementations that aren't integrated with the Kernel, I don't think its a question of environment variables being a good idea or not, it's a question of "what other choice do you have?" Ideally, I agree - it would be nice we didn't have to use environment variables and didn't have to mess with this. But since we do, it seems like the best idea is to expose it so that it can be handled reasonably. Von Martin Rex writes (01:57 April 8, 2004): > > Nicolas Williams wrote: > > > > The problems with the use of environment variables are: > > > > 1. Environment variables are PLATFORM-SPECIFIC: > > > > - not all platforms can be expected to have this facility > > Correct. I was told that MacOS up to 9.x didn't have environment variables. > > > - not all platforms can be expected to have the same semantics it > > Someone who thinks that environment variables are a good idea probably > has very little programming experience on Microsoft Windows platforms. > > On Microsoft Win32 (and Win64 of course) an EXE and every single one > of the DLLs that are loaded by the EXE can bring along it's own > code instance of a C runtime library with it's own private STDC > objects (i.e. private FILE * handles, private heap allocators, > private environment variables). And this is not only a theoretical > possibility, it actually happens. It can even happen if both, > EXE and DLL were linked against the multi-threaded DLL "MSVCRT.DLL", > but built with different compiler versions (i.e. one was built with > Visual Studio 98 and the other with Visual Studio .NET). > > The result is that environment variables created/updated by the EXE > via putenv() are not visible to the code in the DLL... > > This is a pretty surprising (mis-)feature of the Win32 platform and > the result of indepedent instances of the C-Runtime library. > Unfortunately very few developers seem to be aware of this problem. > > > On most Unix systems this is impossible, because the commonly used "brk()" > interface for process heap management and this is a highlander interface > that cannot be used by several independent heap allocators within a > single process. > > > -Martin > -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Apr 8 13:54:33 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07985 for ; Thu, 8 Apr 2004 13:54:33 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i38HV1tr002995 for ietf-cat-wg-out720680; Thu, 8 Apr 2004 10:31:01 -0700 (PDT) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i38HUxNK002980 for ; Thu, 8 Apr 2004 10:30:59 -0700 (PDT) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i38HUq6N012285; Thu, 8 Apr 2004 10:30:52 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i38HUqcE001871; Thu, 8 Apr 2004 11:30:52 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i38HUQhf022161; Thu, 8 Apr 2004 12:30:26 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i38HUOoN022160; Thu, 8 Apr 2004 12:30:24 -0500 (CDT) Date: Thu, 8 Apr 2004 12:30:24 -0500 From: Nicolas Williams To: Von Welch Cc: ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: GGF's extensions to GSS in Public Comment Message-ID: <20040408173024.GH5868@binky.central.sun.com> References: <16493.30981.963000.758673@gargle.gargle.HOWL> <20040402171928.GU5868@binky.central.sun.com> <16497.43414.143000.902799@gargle.gargle.HOWL> <20040406003905.GS5868@binky.central.sun.com> <20040406053114.GR13507@binky.central.sun.com> <16500.35004.991000.653152@gargle.gargle.HOWL> <20040408031441.GX5868@binky.central.sun.com> <16501.35098.606000.670757@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16501.35098.606000.670757@gargle.gargle.HOWL> User-Agent: Mutt/1.4i Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Thu, Apr 08, 2004 at 12:17:14PM -0500, Von Welch wrote: > > This statement captures what I was missing: > > > The calls to [GSS_Set_cred_store()/]GSS_Store_cred() need to happen > > where your application today would go about setting up the environment > > (and here I don't mean just variables) of the process it will spawn or > > exec. > > I think you are right, if the applicaiton understands that > gss_store_cred() may impact the operating environment and makes sure > to call it at the right point, this should solve the issue of setting > up a child's environment. > > However, it doesn't cover the case of an application spawning a child > through an execle() right? Depends. Before I go into this I should point out that even before the advent of either of our proposals execle()/execve() were a problem on platforms where the current credential store is determined by environment variables. I.e., this is not a new problem, it's not new with my proposal and it's not solved by yours either. Anyways, for platforms where GSS_Set_cred_store()/GSS_Store_cred() deal in environment variables, then yes, the application will have to be careful to preserve parts of its environment when doing any execle() or execve() call. And for other platforms, where GSS_Set_cred_store()/GSS_Store_cred() deal in per-user credential stores, or per-session credential stores where a system call informs the kernel about a process' (or thread's) current credential store, no, there's no execle()/execve() gotcha. Just look at OpenSSH code, for example, and you'll see that it has to be careful about environment variables even without throwing in the GSS-API. Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Apr 8 13:55:14 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08011 for ; Thu, 8 Apr 2004 13:55:14 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i38HHhnW028909 for ietf-cat-wg-out720680; Thu, 8 Apr 2004 10:17:43 -0700 (PDT) Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i38HHeNK028895 for ; Thu, 8 Apr 2004 10:17:40 -0700 (PDT) Received: from VON-THINKPAD (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id i38HHU0313330; Thu, 8 Apr 2004 12:17:31 -0500 X-Mailer: 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid (via feedmail 10 I); VM 7.14 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16501.35098.606000.670757@gargle.gargle.HOWL> Date: Thu, 8 Apr 2004 12:17:14 -0500 To: Nicolas Williams Cc: ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: GGF's extensions to GSS in Public Comment In-Reply-To: <20040408031441.GX5868@binky.central.sun.com> References: <16493.30981.963000.758673@gargle.gargle.HOWL> <20040402171928.GU5868@binky.central.sun.com> <16497.43414.143000.902799@gargle.gargle.HOWL> <20040406003905.GS5868@binky.central.sun.com> <20040406053114.GR13507@binky.central.sun.com> <16500.35004.991000.653152@gargle.gargle.HOWL> <20040408031441.GX5868@binky.central.sun.com> From: Von Welch Reply-To: Von Welch Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit This statement captures what I was missing: > The calls to [GSS_Set_cred_store()/]GSS_Store_cred() need to happen > where your application today would go about setting up the environment > (and here I don't mean just variables) of the process it will spawn or > exec. I think you are right, if the applicaiton understands that gss_store_cred() may impact the operating environment and makes sure to call it at the right point, this should solve the issue of setting up a child's environment. However, it doesn't cover the case of an application spawning a child through an execle() right? Von Nicolas Williams writes (22:14 April 7, 2004): > On Wed, Apr 07, 2004 at 06:03:24PM -0500, Von Welch wrote: > > > > Nico, > > > > This text from your draft describing set_current_cred_store() gets at > > the problem we were trying to solve by including env variables in the > > output of gss_export_cred(): > > > > > Calls to this function MAY have platform-specific side effects (e.g., > > > setting environment variables, setting a process' "pag," etc...), but > > > an implementation of it MUST NOT change the user context of the > > > application, a restriction applicable only on multi-user platforms. > > Yes. See below. > > > For credential stores that are meaningful to the kernel, the > > application doesn't in general have to be aware of them since the > > kernel will generally make sure the process doesn't accidentially > > meddle with them. (E.g. if a process changes its PAG it typically > > knows what it is doing.) > > > > But for GSS mechanisms that don't have kernel support for their > > creentials stores and use environment variables, this isn't the > > case. A process might decide to clean up its environment for a number > > of reasons and accidentially effect the GSS mechanism's current > > credential store or fail to pass the meaningful env variable to a > > child process as in SSHD. > > The calls to [GSS_Set_cred_store()/]GSS_Store_cred() need to happen > where your application today would go about setting up the environment > (and here I don't mean just variables) of the process it will spawn or > exec. > > > This is what led us to have a mechanism that allowed the GSS mechanism > > to tell the calling application that a particular env variable was > > meaningful to it so that a well behaved application could treat that > > variable appropriately. > > But you failed to abstract the matter sufficiently. See above. > > > You are right in that our use of environment variables was focused on > > a couple of specific mechanisms (GSI & Krb5) in which we were > > interested. I agree the approach does not generalize well to > > mechanisms that use other methods besides env variables. > > I said (or should have, if I said "mechanisms" instead) > "implementations." Nothing in rfc1964 (the Kerberos V mechanism) says > [or ought say] anything whatsoever about environment variables. > > The implementation(s) of the Kerberos V mechanism that you are used to > happen to use environment variables, but I dare say that this is mostly > a result of those implementations being alien to the operating systems > on which they are used. Native implementations (e.g., Microsoft's) > don't have anything at all to do with environment variables. > > > However I still believe it solves a problem for those mechanisms that > > I don't undertstand how your approach solves yet. > > I make another attempt to explain it below. To me it's clear as it can > be. > > > (BTW, is the intent that gss_set_current_cred_store() can create a new > > credential store, presumably if cred_store_handle has some special > > value?) > > - The intent of GSS_Get_cred_store() is to get a handle for the current > credential store. > > - The purpose of GSS_Set_cred_store() is to set the current cred store > to the given handle OR, if the NULL handle is given, to a *new* > store. > > - The intent of GSS_Store_cred() is to store the given credential into > the current credential store. > > I consider GSS_Get_cred_store()/GSS_Set_cred_store() to be optional > because the one factor that cannot be easily abstracted is user context > switching (e.g., setuid(2)), yet user context switching generally does > [must!] change the current credential store (switching user context > means giving up access to some objects and gaining access to others). > > So you see, on platforms with one credential store per-user, as opposed > to per-session, there is no need at all for GSS_Get/Set_cred_store()... > -- user context switching suffices, and all multi-user platforms have a > way to do that already! > > If this is still not clear maybe we should have a conference call, or > perhaps we can discuss this in person at the next IETF meeting, or > perhaps at the next KRB WG interim meeting, if one is held and you and I > manage to be able to attend it. > > Cheers, > > Nico > -- > -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Apr 8 13:58:36 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08143 for ; Thu, 8 Apr 2004 13:58:35 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i38HYRu4003363 for ietf-cat-wg-out720680; Thu, 8 Apr 2004 10:34:27 -0700 (PDT) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i38HYPNK003346 for ; Thu, 8 Apr 2004 10:34:25 -0700 (PDT) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i38HYI6N014845; Thu, 8 Apr 2004 10:34:18 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i38HYH4F018236; Thu, 8 Apr 2004 11:34:18 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i38HXqhf022168; Thu, 8 Apr 2004 12:33:52 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i38HXpm1022167; Thu, 8 Apr 2004 12:33:51 -0500 (CDT) Date: Thu, 8 Apr 2004 12:33:51 -0500 From: Nicolas Williams To: Von Welch Cc: martin.rex@sap.com, ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: GGF's extensions to GSS in Public Comment Message-ID: <20040408173351.GI5868@binky.central.sun.com> References: <20040406004459.GO13507@binky.central.sun.com> <200404072357.BAA12098@uw1048.wdf.sap.corp> <16501.35375.214000.871773@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16501.35375.214000.871773@gargle.gargle.HOWL> User-Agent: Mutt/1.4i Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Thu, Apr 08, 2004 at 12:21:51PM -0500, Von Welch wrote: > > > Someone who thinks that environment variables are a good idea probably > > has very little programming experience on Microsoft Windows platforms. > > For implementations that aren't integrated with the Kernel, I don't > think its a question of environment variables being a good idea or > not, it's a question of "what other choice do you have?" Oh, you have a choice: per-user credential stores instead of per-session credential stores. > Ideally, I agree - it would be nice we didn't have to use environment > variables and didn't have to mess with this. But since we do, it seems > like the best idea is to expose it so that it can be handled > reasonably. You don't have to use environment variables. Looks like you used them only because MIT krb5 did (and does). Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Apr 8 14:14:31 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08301 for ; Thu, 8 Apr 2004 14:14:31 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i38Hmilg005221 for ietf-cat-wg-out720680; Thu, 8 Apr 2004 10:48:44 -0700 (PDT) Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i38HmgNK005205 for ; Thu, 8 Apr 2004 10:48:42 -0700 (PDT) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 1134115159C; Thu, 8 Apr 2004 13:48:40 -0400 (EDT) To: Nicolas Williams Cc: ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: Comments on the GGF GSS-API extensions proposal References: <20040407172817.GU13507@binky.central.sun.com> From: Sam Hartman Date: Thu, 08 Apr 2004 13:48:40 -0400 In-Reply-To: <20040407172817.GU13507@binky.central.sun.com> (Nicolas Williams's message of "Wed, 7 Apr 2004 12:28:17 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> 3. Can you explain again why the Nicolas> GSS_PROTECTION_FAIL_ON_CONTEXT_EXPIRATION option is Nicolas> needed, why the per-msg token functions shouldn't always Nicolas> fail when the context is expired, period? I think this basically boils down to making application protocols simpler. It's particularly true for SASL that having contexts expire is mostly unacceptable in practice. AN argument could be made that the SASL GSSAPI mechanism (or all SASL applications) should support rekeying. Honestly, for most applications I just don't think it is worth the complexity. ANd the designers of these protocols tend to agree with me. Things like FTP, many proprietary GSSAPI applications, etc do not support rekeying. There is of course the notable exception of SAP. Especially as we start talking about AES and 128-bit blocks, the lifetime of many keys may be significantly longer than the lifetime of the credentials. And even for moderate traffic contexts, a DES key may usefully be used longer than the context credentials last. --Sam -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Apr 8 14:32:12 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08743 for ; Thu, 8 Apr 2004 14:32:11 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i38HxlNc006402 for ietf-cat-wg-out720680; Thu, 8 Apr 2004 10:59:47 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i38HxjNK006397 for ; Thu, 8 Apr 2004 10:59:45 -0700 (PDT) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i38Hxhaa008239; Thu, 8 Apr 2004 11:59:43 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i38Hxg4F029328; Thu, 8 Apr 2004 11:59:43 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i38HxHhf022190; Thu, 8 Apr 2004 12:59:17 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i38HxHud022189; Thu, 8 Apr 2004 12:59:17 -0500 (CDT) Date: Thu, 8 Apr 2004 12:59:16 -0500 From: Nicolas Williams To: Sam Hartman Cc: ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: Comments on the GGF GSS-API extensions proposal Message-ID: <20040408175916.GK5868@binky.central.sun.com> References: <20040407172817.GU13507@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Thu, Apr 08, 2004 at 01:48:40PM -0400, Sam Hartman wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> 3. Can you explain again why the > Nicolas> GSS_PROTECTION_FAIL_ON_CONTEXT_EXPIRATION option is > Nicolas> needed, why the per-msg token functions shouldn't always > Nicolas> fail when the context is expired, period? > > > I think this basically boils down to making application protocols > simpler. It's particularly true for SASL that having contexts expire > is mostly unacceptable in practice. > > > AN argument could be made that the SASL GSSAPI mechanism (or all SASL > applications) should support rekeying. Honestly, for most > applications I just don't think it is worth the complexity. ANd the > designers of these protocols tend to agree with me. Things like FTP, > many proprietary GSSAPI applications, etc do not support rekeying. > There is of course the notable exception of SAP. Additional exceptions: SSHv2, ONC RPC w/ RPCSEC_GSS. So what's exceptional here? SASL and FTP? Or SAP, SSHv2 and RPCSEC_GSS? Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Apr 8 14:36:49 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08988 for ; Thu, 8 Apr 2004 14:36:49 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i38I4Gf7006949 for ietf-cat-wg-out720680; Thu, 8 Apr 2004 11:04:16 -0700 (PDT) Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i38I4ENK006941 for ; Thu, 8 Apr 2004 11:04:15 -0700 (PDT) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id A181C15159C; Thu, 8 Apr 2004 14:04:14 -0400 (EDT) To: ietf-cat-wg@lists.Stanford.EDU Subject: Kitten status Message-Id: <20040408180414.A181C15159C@konishi-polis.mit.edu> Date: Thu, 8 Apr 2004 14:04:14 -0400 (EDT) From: hartmans@mit.edu (Sam Hartman) Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk We had a rather lively discussion and it has mostly died down. I think that's OK for now; our goal seems to be to have a BOF at the next IETF and that doesn't require immediate action. I know of three people who have said they might be interested in chairing the BOF. We have potential document editors for some documents. We have several items we'd like to address within the working group. Unless there is a reason to do otherwise I don't plan on focusing on kitten again until May. I believe that will still give us enough time to get a BOF request in. At that time, I would like to present a draft charter and possible chairs. Once we know who we are going to propose as a chair, they will presumably lead the actual pre-BOF charter discussion. Of course all this is subject to the approval of an AD to get a BOF and of the IESG to get a WG. --Sam -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Apr 8 14:44:15 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09335 for ; Thu, 8 Apr 2004 14:44:15 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i38IENu0008382 for ietf-cat-wg-out720680; Thu, 8 Apr 2004 11:14:23 -0700 (PDT) Received: from konishi-polis.mit.edu (KONISHI-POLIS.MIT.EDU [18.18.3.10]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i38IELNK008376 for ; Thu, 8 Apr 2004 11:14:22 -0700 (PDT) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 24FF515159C; Thu, 8 Apr 2004 14:14:20 -0400 (EDT) To: Nicolas Williams Cc: ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: Comments on the GGF GSS-API extensions proposal References: <20040407172817.GU13507@binky.central.sun.com> <20040408175916.GK5868@binky.central.sun.com> From: Sam Hartman Date: Thu, 08 Apr 2004 14:14:20 -0400 In-Reply-To: <20040408175916.GK5868@binky.central.sun.com> (Nicolas Williams's message of "Thu, 8 Apr 2004 12:59:16 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Thu, Apr 08, 2004 at 01:48:40PM -0400, Sam Hartman Nicolas> wrote: >> >>>>> "Nicolas" == Nicolas Williams >> writes: >> Nicolas> 3. Can you explain again why the Nicolas> GSS_PROTECTION_FAIL_ON_CONTEXT_EXPIRATION option is Nicolas> needed, why the per-msg token functions shouldn't always Nicolas> fail when the context is expired, period? >> >> >> I think this basically boils down to making application >> protocols simpler. It's particularly true for SASL that having >> contexts expire is mostly unacceptable in practice. >> >> >> AN argument could be made that the SASL GSSAPI mechanism (or >> all SASL applications) should support rekeying. Honestly, for >> most applications I just don't think it is worth the >> complexity. ANd the designers of these protocols tend to agree >> with me. Things like FTP, many proprietary GSSAPI >> applications, etc do not support rekeying. There is of course >> the notable exception of SAP. Nicolas> Additional exceptions: SSHv2, ONC RPC w/ RPCSEC_GSS. Nicolas> So what's exceptional here? SASL and FTP? Or SAP, SSHv2 Nicolas> and RPCSEC_GSS? I don't think sshv2 counts really but don't want to go into why. The answer to your question is that the protocols that support rekeying are exceptional both by number and by usage. But that's not the interesting question. The interesting question is whether GSSAPI can justify the complexity of requiring rekeying from a security standpoint. I say that this complexity is not justified. --Sam -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Thu Apr 8 15:47:28 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14435 for ; Thu, 8 Apr 2004 15:47:27 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i38JHRag018288 for ietf-cat-wg-out720680; Thu, 8 Apr 2004 12:17:27 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.171]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i38JHNNK018262 for ; Thu, 8 Apr 2004 12:17:24 -0700 (PDT) Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id VAA08099; Thu, 8 Apr 2004 21:17:10 +0200 (MESZ) From: Martin Rex Message-Id: <200404081917.VAA20601@uw1048.wdf.sap.corp> Subject: Re: Comments on the GGF GSS-API extensions proposal To: hartmans@mit.edu (Sam Hartman) Date: Thu, 8 Apr 2004 21:17:09 +0200 (MET DST) Cc: Nicolas.Williams@Sun.COM, ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org In-Reply-To: from "Sam Hartman" at Apr 8, 4 01:48:40 pm Reply-To: martin.rex@sap.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 8bit Sam Hartman wrote: > > >>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> 3. Can you explain again why the > Nicolas> GSS_PROTECTION_FAIL_ON_CONTEXT_EXPIRATION option is > Nicolas> needed, why the per-msg token functions shouldn't always > Nicolas> fail when the context is expired, period? > > I think this basically boils down to making application protocols > simpler. It's particularly true for SASL that having contexts expire > is mostly unacceptable in practice. > > AN argument could be made that the SASL GSSAPI mechanism (or all SASL > applications) should support rekeying. Honestly, for most > applications I just don't think it is worth the complexity. ANd the > designers of these protocols tend to agree with me. Things like FTP, > many proprietary GSSAPI applications, etc do not support rekeying. > There is of course the notable exception of SAP. Thanks. :) Reality shows that hardly anyone has implemented security context expiration. The larger fraction of Kerberos 5 gssapi mechanisms only has it because rfc-1964 requires it. Curiously Microsoft disabled it in the Microsoft Kerberos SSP after devastating tests with having it active in W2K3 beta -- little if any of their RPC and application code was able to cope with it either. I agree that dealing with gssapi security context expiration requires an enormous protocol complexity. However the worst thing about it (and about how Kerberos implements it) is would be extremely complex ("expensive) to implement it reliably: - the application needs to address the issue that a security context may expire at a time when there are still unprocessed protected messsages in transit or waiting in network buffers or message queues to be processed. Possible approaches: - app-level unprotected retransmission queues (=most reliable, most expensive) - security context renegotiation with a safety margin prior to context expiration so that the likelyhood of protected messages expiring "in transit" is very low (=reasonable compromise, remaining risk of connection abort) I implemented the latter - In Kerberos, the security context lifetime is derived from the credentials, although independent security contexts have independent session keys, and the reasoning for security context expiration was that no keys should be valid forever. The problem with rfc-1964 is that if you don't think about the effect, you might write code that goes into a tight loop trying to establish a new security context (expecting longer lifetime that for the context one has been using). If the TGT hasn't been refreshed, then the lifetime of the new security context will be exactly the same as the lifetime of the old one (if GSS_C_INDEFINITE is requested), namely the lifetime of the service ticket in the AP_REQ which was copied from the TGTs lifetime. Therefore my code currently uses a plausibility check whether the credentials lifetime is longer than the security context lifetime before it tries to renegotiate a successor security context, and there are delays imposed on how often a security context "refresh" will be attempted, and when security context refresh fails, the message protection will continue on the original security context. - it requires a bidirectional message exchange for the security context establishment at a time determined by the gssapi mechanism, which might be quite unusual for the (legacy) application (protocols), e.g. the FTP data channel. - it requires a synchronized handshake and switch-over to messages protected under the new security context between both peers, flushing of message queues on the communication channel - only the initiator can initiate a replacement security context, so if the acceptor thinks a renegotiation should be performed, it needs to request the initiator to actually try it. -Martin -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Apr 9 17:48:17 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24924 for ; Fri, 9 Apr 2004 17:48:17 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i39LO2pw028966 for ietf-cat-wg-out720680; Fri, 9 Apr 2004 14:24:02 -0700 (PDT) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i39LO0NK028932 for ; Fri, 9 Apr 2004 14:24:00 -0700 (PDT) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i39LNq6N013018; Fri, 9 Apr 2004 14:23:53 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i39LNqcE007114; Fri, 9 Apr 2004 15:23:52 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i39LNQhf023377; Fri, 9 Apr 2004 16:23:26 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i39LNOK2023376; Fri, 9 Apr 2004 16:23:24 -0500 (CDT) Date: Fri, 9 Apr 2004 16:23:24 -0500 From: Nicolas Williams To: Matt Crawford Cc: ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: Comments on the GGF GSS-API extensions proposal Message-ID: <20040409212324.GI22519@binky.central.sun.com> References: <20040407172817.GU13507@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Fri, Apr 09, 2004 at 04:14:59PM -0500, Matt Crawford wrote: > On Apr 7, 2004, at 12:28 PM, Nicolas Williams wrote: > >2. I oppose the credential delegation at any time concept. > > > > Basically, I see no reason not to re-authenticate in order to > > delegate fresh credentials. > > I know that what the globus people have in mind is the possibility of > delegating some credential other than the one that was used to > authenticate the sesssion. For example, to delegate lesser, or > different rights to a remote process. Nothing, I suppose, that couldn't be addressed by the GGF proposal for credential options, without adding delegation-at-any-time. But, see below. But at least my objections to this are not as strongly held as my objections to the export-cred-to-env-var thing... Also, given export-cred-to-token feature and credential options technically that ought to be enough to implement delegation at any time. I don't object to the export-cred-to-token feature. I do object to addressing authorization data through credentials/context options, but don't object to other credentials options. So perhaps I ought not oppose credential-delegation-at-any-time. Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Apr 9 17:48:22 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24957 for ; Fri, 9 Apr 2004 17:48:21 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i39LF5hV027925 for ietf-cat-wg-out720680; Fri, 9 Apr 2004 14:15:05 -0700 (PDT) Received: from mailgw1.fnal.gov (mailgw1.fnal.gov [131.225.111.11]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i39LF2NK027895 for ; Fri, 9 Apr 2004 14:15:03 -0700 (PDT) Received: from conversion-daemon.mailgw1.fnal.gov by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) id <0HVX00G019MK1G@mailgw1.fnal.gov> (original mail from crawdad@fnal.gov) for ietf-cat-wg@lists.Stanford.EDU; Fri, 09 Apr 2004 16:15:02 -0500 (CDT) Received: from [131.225.83.228] (skuld.dhcp.fnal.gov [131.225.83.228]) by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HVX0083H9P117@mailgw1.fnal.gov>; Fri, 09 Apr 2004 16:15:01 -0500 (CDT) Date: Fri, 09 Apr 2004 16:14:59 -0500 From: Matt Crawford Subject: Re: Comments on the GGF GSS-API extensions proposal In-reply-to: <20040407172817.GU13507@binky.central.sun.com> To: Nicolas Williams Cc: ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.613) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <20040407172817.GU13507@binky.central.sun.com> Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7BIT On Apr 7, 2004, at 12:28 PM, Nicolas Williams wrote: > 2. I oppose the credential delegation at any time concept. > > Basically, I see no reason not to re-authenticate in order to > delegate fresh credentials. I know that what the globus people have in mind is the possibility of delegating some credential other than the one that was used to authenticate the sesssion. For example, to delegate lesser, or different rights to a remote process. -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Apr 9 18:43:31 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29233 for ; Fri, 9 Apr 2004 18:43:30 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i39MB9Cg005210 for ietf-cat-wg-out720680; Fri, 9 Apr 2004 15:11:09 -0700 (PDT) Received: from konishi-polis.mit.edu (STRATTON-THREE-FIFTY-THREE.MIT.EDU [18.187.6.98]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i39MB3NK005201 for ; Fri, 9 Apr 2004 15:11:03 -0700 (PDT) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 320AA15159C; Fri, 9 Apr 2004 18:10:59 -0400 (EDT) To: Nicolas Williams Cc: Matt Crawford , ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: Comments on the GGF GSS-API extensions proposal References: <20040407172817.GU13507@binky.central.sun.com> <20040409212324.GI22519@binky.central.sun.com> From: Sam Hartman Date: Fri, 09 Apr 2004 18:10:58 -0400 In-Reply-To: <20040409212324.GI22519@binky.central.sun.com> (Nicolas Williams's message of "Fri, 9 Apr 2004 16:23:24 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> But at least my objections to this are not as strongly Nicolas> held as my objections to the export-cred-to-env-var Nicolas> thing... My objections to delegate cred at any time are somewhat stronger than my objections to the export to env var thing. Both are fairly strong though. Nicolas> Also, given export-cred-to-token feature and credential Nicolas> options technically that ought to be enough to implement Nicolas> delegation at any time. I don't object to the Nicolas> export-cred-to-token feature. I do object to addressing Nicolas> authorization data through credentials/context options, Nicolas> but don't object to other credentials options. EXport to token is useful only on a single system/implementation as export context. I actually think credentials options are the right place for things actually having to do with negative authorization. For example, a time range restriction belongs on a credential. But really we're getting more into this discussion than I want to have now. -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Sat Apr 10 16:32:37 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18057 for ; Sat, 10 Apr 2004 16:32:36 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i3AK7fal018450 for ietf-cat-wg-out720680; Sat, 10 Apr 2004 13:07:41 -0700 (PDT) Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i3AK7cNK018427 for ; Sat, 10 Apr 2004 13:07:39 -0700 (PDT) Received: from VON-THINKPAD (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id i3AK7T080748; Sat, 10 Apr 2004 15:07:30 -0500 X-Mailer: 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid (via feedmail 10 I); VM 7.14 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16504.21495.198000.105854@gargle.gargle.HOWL> Date: Sat, 10 Apr 2004 15:07:19 -0500 To: Nicolas Williams Cc: ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: Comments on the GGF GSS-API extensions proposal In-Reply-To: <20040407172817.GU13507@binky.central.sun.com> References: <20040407172817.GU13507@binky.central.sun.com> From: Von Welch Reply-To: Von Welch Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit Comments inline. Nicolas Williams writes (12:28 April 7, 2004): ... > 1. I do support the notion of exporting credentials to tokens. ... I have to admit I don't have any strong incliation to defend this at the moment. As I recall this seemed like a possibily useful thing and got tacked on as it was easy given gss_export_cred(). > 2. I oppose the credential delegation at any time concept. ... There are several motivations for this function: 1) It allows a client to delegate after authentication when it has established if the service can actually perform some task on its behalf. E.g. Client server authenticate, Client presents description of job, server says ok, client then delegates credential. 2) It allows a client to delegate a credential to express desires about the type of credential it does delegate. For example, whether or not to delegate a forwardable or unforwardable Kerberos credential. (Obviously it has hooks for more complex policies.) 3) It allows for entirely separate credential to be delegated. The use case for this is a job broker that is trusted by resources and the user is not. A user authenticates to the job broker and delegates, the job broker then authorizes the user and decides which resource should run the user's job and then authenticates to the resource and delegates the user's credentials. In many cases the resources are happy to off-load authorization to the job broker so they don't have to maintain a list of authorized users. > 3. Can you explain again why the GSS_PROTECTION_FAIL_ON_CONTEXT_EXPIRATION > option is needed, why the per-msg token functions shouldn't always > fail when the context is expired, period? If an application is partially through a long-running data transfer (think 20+ hour ftp) when the context expires, I'd argue it is reasonable that the application may want to go ahead and finish the transfer (especially if it doesn't have the capability to reestablish and complete). I agree that in the case of an interactive session like SSH, you probably want to fail. Hence this behavior should be application driven. > 4. Can you explain again why we need generic token framing for all GSS > tokens? In all IETF protocols that use the GSS-API that I can think > of the lack of generic token framing has never been a problem. > > I.e., SASL, RPCSEC_GSS, FTP, SSHv2, none have had any problems with > the lack of generic token framing for non-initial context and > per-msg GSS tokens. The thought here is that currently applications have to know from the state way kind of GSS token to expect and what function to feed it to - is it a contact establishment token, a delegation token, a wrapped token, or something unrelated to gss. Basically some way to demux incoming packets and determine how to handle them. > 5. I do like the idea of extending GSS_Display_status(). ... > Changing the prototype of GSS_Display_status() is not possible > though, so we'll need an extended replacement for it. Agreed. ... > 6. Extensions relating to authorization data are better associated with > GSS-API names than with GSS-API credentials and contexts. > > [Thanks to Sam for this insight.] > > This approach will lead to a more consistent interface. Plus, for > those who have GSS userok()/name_to_localname() type interfaces > there is an obvious benefit, namely that said interfaces continue to > be useful and workable in the face of authorization data. Interesting. So the name element basically encapsulates all the information about the entity. I see the wisdom in this. Von > I suspect that this will be a significant topic at the KITTEN BoF so > please do attend it! I don't care to go into the details of what we > might propose in this area yet -- I'd rather spend some time writing > up a proposal instead. > > > Comments? > > Nico > -- > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > This message was posted through the Stanford campus mailing list > server. If you wish to unsubscribe from this mailing list, send the > message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu > -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Sat Apr 10 16:35:09 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18128 for ; Sat, 10 Apr 2004 16:35:08 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i3AK3PTj018152 for ietf-cat-wg-out720680; Sat, 10 Apr 2004 13:03:25 -0700 (PDT) Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i3AK3MNK018143 for ; Sat, 10 Apr 2004 13:03:22 -0700 (PDT) Received: from VON-THINKPAD (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id i3AK380126660; Sat, 10 Apr 2004 15:03:09 -0500 X-Mailer: 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid (via feedmail 10 I); VM 7.14 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16504.21232.300000.55801@gargle.gargle.HOWL> Date: Sat, 10 Apr 2004 15:02:56 -0500 To: Wyllys Ingersoll Cc: Nicolas Williams , ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: GGF's extensions to GSS in Public Comment In-Reply-To: <40755AAF.1090103@sun.com> References: <16493.30981.963000.758673@gargle.gargle.HOWL> <20040402171928.GU5868@binky.central.sun.com> <16497.43414.143000.902799@gargle.gargle.HOWL> <20040406003905.GS5868@binky.central.sun.com> <20040406053114.GR13507@binky.central.sun.com> <16500.35004.991000.653152@gargle.gargle.HOWL> <40755AAF.1090103@sun.com> From: Von Welch Reply-To: Von Welch Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit > Maybe I'm misunderstanding, but wouldn't this mean that the application > has to make assumptions about the underlying mechanisms implementation > in order to get the variable correctly? The specification is that the returned variable is feedable to putenv, so to the extent that is a de facto standard, no. Von Wyllys Ingersoll writes (09:59 April 8, 2004): > Von Welch wrote: > > > But for GSS mechanisms that don't have kernel support for their > > creentials stores and use environment variables, this isn't the > > case. A process might decide to clean up its environment for a number > > of reasons and accidentially effect the GSS mechanism's current > > credential store or fail to pass the meaningful env variable to a > > child process as in SSHD. > > > > This is what led us to have a mechanism that allowed the GSS mechanism > > to tell the calling application that a particular env variable was > > meaningful to it so that a well behaved application could treat that > > variable appropriately. > > Maybe I'm misunderstanding, but wouldn't this mean that the application > has to make assumptions about the underlying mechanisms implementation > in order to get the variable correctly? > > > > > You are right in that our use of environment variables was focused on > > a couple of specific mechanisms (GSI & Krb5) in which we were > > interested. I agree the approach does not generalize well to > > mechanisms that use other methods besides env variables. > > I think that specifying the use of environment variables as an > interface for manipulating the configuration of the mechanisms > is a really ulgy solution. Use of environment variables may > be acceptable in a particular implementation of a spec, but they > should definitley not be part of any standards document for a > generic interface such as this. > > -Wyllys Ingersoll > -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Mon Apr 12 12:31:51 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27627 for ; Mon, 12 Apr 2004 12:31:50 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i3CFx4bJ002305 for ietf-cat-wg-out720680; Mon, 12 Apr 2004 08:59:04 -0700 (PDT) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i3CFx1NK002284 for ; Mon, 12 Apr 2004 08:59:01 -0700 (PDT) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i3CFwogx007734; Mon, 12 Apr 2004 08:58:50 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i3CFwn4F002541; Mon, 12 Apr 2004 09:58:50 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.10+Sun/8.12.10) with ESMTP id i3CFwMhf024529; Mon, 12 Apr 2004 10:58:22 -0500 (CDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.10+Sun/8.12.10/Submit) id i3CFwL4J024528; Mon, 12 Apr 2004 10:58:21 -0500 (CDT) Date: Mon, 12 Apr 2004 10:58:21 -0500 From: Nicolas Williams To: Von Welch Cc: ietf-cat-wg@lists.Stanford.EDU, security-wg@ggf.org Subject: Re: Comments on the GGF GSS-API extensions proposal Message-ID: <20040412155821.GM22519@binky.central.sun.com> References: <20040407172817.GU13507@binky.central.sun.com> <16504.20511.874000.113009@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16504.20511.874000.113009@gargle.gargle.HOWL> User-Agent: Mutt/1.4i Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk On Sat, Apr 10, 2004 at 02:50:55PM -0500, Von Welch wrote: > > Comments inline. > > Nicolas Williams writes (12:28 April 7, 2004): > ... > > 1. I do support the notion of exporting credentials to tokens. > ... > > I have to admit I don't have any strong incliation to defend this at > the moment. As I recall this seemed like a possibily useful thing and > got tacked on as it was easy given gss_export_cred(). I have a use for this, and I think so does Sam. > > 2. I oppose the credential delegation at any time concept. > ... > > There are several motivations for this function: > > 1) It allows a client to delegate after authentication when it has > established if the service can actually perform some task on its > behalf. E.g. Client server authenticate, Client presents description > of job, server says ok, client then delegates credential. I've explained my objection to this. > 2) It allows a client to delegate a credential to express desires > about the type of credential it does delegate. For example, whether or > not to delegate a forwardable or unforwardable Kerberos > credential. (Obviously it has hooks for more complex policies.) I think this might best be done as extensions to either GSS_Init_sec_context() or to GSS_Add()/Acquire_cred() similar to the ones in the GGF proposal. > 3) It allows for entirely separate credential to be delegated. The use > case for this is a job broker that is trusted by resources and the > user is not. A user authenticates to the job broker and delegates, the > job broker then authorizes the user and decides which resource should > run the user's job and then authenticates to the resource and > delegates the user's credentials. In many cases the resources are > happy to off-load authorization to the job broker so they don't have > to maintain a list of authorized users. I object to this but don't have time to commit my objection to bits atm. > > 3. Can you explain again why the GSS_PROTECTION_FAIL_ON_CONTEXT_EXPIRATION > > option is needed, why the per-msg token functions shouldn't always > > fail when the context is expired, period? > > > If an application is partially through a long-running data transfer > (think 20+ hour ftp) when the context expires, I'd argue it is > reasonable that the application may want to go ahead and finish the > transfer (especially if it doesn't have the capability to reestablish > and complete). > > I agree that in the case of an interactive session like SSH, you > probably want to fail. Hence this behavior should be application > driven. Ok, Sam's convinced me that there's a class of apps for this this is a problem. I'd agree to a GSS_Set_context_lifetime() function that initiators and acceptors both must use to set a context's lifetime to infinity. > > 4. Can you explain again why we need generic token framing for all GSS > > tokens? In all IETF protocols that use the GSS-API that I can think > > of the lack of generic token framing has never been a problem. > > > > I.e., SASL, RPCSEC_GSS, FTP, SSHv2, none have had any problems with > > the lack of generic token framing for non-initial context and > > per-msg GSS tokens. > > The thought here is that currently applications have to know from the > state way kind of GSS token to expect and what function to feed it > to - is it a contact establishment token, a delegation token, a > wrapped token, or something unrelated to gss. Basically some way to > demux incoming packets and determine how to handle them. I can't think of a single application that needs this, and for good reason too: all GSS applications have had to deal with this by adding their own framing to GSS tokens. "What a lot of repetition!" you might say, but if you look at these apps many (e.g., RPCSEC_GSS, SSHv2) would have had no use for generic token framing. That said, if you can show us some examples of protocols that could be changed to support the GSS-API with much less effort by using such generic token framing, then I'd support that, though as a separate document altogether, and with functions that the application is responsible for calling in order to make/parse the generic frames. > > 5. I do like the idea of extending GSS_Display_status(). > ... > > Changing the prototype of GSS_Display_status() is not possible > > though, so we'll need an extended replacement for it. > > Agreed. Good. > ... > > > 6. Extensions relating to authorization data are better associated with > > GSS-API names than with GSS-API credentials and contexts. > > > > [Thanks to Sam for this insight.] > > > > This approach will lead to a more consistent interface. Plus, for > > those who have GSS userok()/name_to_localname() type interfaces > > there is an obvious benefit, namely that said interfaces continue to > > be useful and workable in the face of authorization data. > > Interesting. So the name element basically encapsulates all the > information about the entity. I see the wisdom in this. Good. I preferred your approach of associating authorization data with initiator creds and with contexts, but when Sam proposed associating it with names instead I saw the light -- 'tis definitely the way to go. Some issues have to be ironed out. For example, do two otherwise equal names, but associated with different authorization data, compare equal? I'd say yes (if the authz-data is accessible the app can compare that on its own, where comparisons of authz-data make sense.). Nico -- -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Tue Apr 13 19:58:16 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20562 for ; Tue, 13 Apr 2004 19:58:16 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i3DNNilR008403 for ietf-cat-wg-out720680; Tue, 13 Apr 2004 16:23:44 -0700 (PDT) Received: from mailgate01.slac.stanford.edu (mailgate01.slac.stanford.edu [134.79.18.80]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i3DNNhNK008398 for ; Tue, 13 Apr 2004 16:23:43 -0700 (PDT) Received: from telemark.slac.stanford.edu (telemark.slac.stanford.edu [134.79.24.241]) by mailgate01.slac.stanford.edu (8.12.11/8.12.11) with ESMTP id i3DNNg8R002414 for ; Tue, 13 Apr 2004 16:23:42 -0700 (PDT) (envelope-from bbense@slac.stanford.edu) Date: Tue, 13 Apr 2004 16:23:42 -0700 (PDT) From: Booker Bense To: ietf-cat-wg@lists.Stanford.EDU Subject: ADMINISTRIVIA: General unsubscribe Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk _ There are too many complaints and bounces to deal with from the bad data still on this list. I am going to unsubscribe everyone that I don't recognize from recent posts. If you wish stay on the ietf-cat-wg list, please visit https://lists.stanford.edu/subscriber_commands.html _ Booker C. Bense -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Apr 23 15:39:02 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03669 for ; Fri, 23 Apr 2004 15:39:01 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i3NJbQgK025068 for ietf-cat-wg-out720680; Fri, 23 Apr 2004 12:37:26 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.171]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i3NJbNNK025023 for ; Fri, 23 Apr 2004 12:37:24 -0700 (PDT) Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id VAA29603; Fri, 23 Apr 2004 21:37:12 +0200 (MESZ) From: Martin Rex Message-Id: <200404231937.VAA05160@uw1048.wdf.sap.corp> Subject: Re: KITTEN BOF at IETF 60? To: Nicolas.Williams@Sun.COM (Nicolas Williams) Date: Fri, 23 Apr 2004 21:37:11 +0200 (MET DST) Cc: martin.rex@sap.com, hartmans@MIT.EDU, ietf-cat-wg@lists.Stanford.EDU, jhutz@cmu.edu In-Reply-To: <20040317114231.GO26957@binky.central.sun.com> from "Nicolas Williams" at Mar 17, 4 05:42:31 am Reply-To: martin.rex@sap.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 8bit Nicolas Williams wrote: > > Further still, the mechanism requirements doc should also explicitly > require that mechanism specs describe how names are to be canonicalized. Of course, the mechanism spec should describe how names are to be canonicalized and it should standardize the format of the binary canonical exported name, so that ACLs are not implementation- specific but mechanism-specific, which is called "portability" at the API level. > > We should also add text to the base spec's Security Considerations > section about the perils of name-based authorization, specifically the > referential integrity problems that arise when principals are > renamed/deleted or principal names reused. > > An optional facility to obtain internal identifiers for principals > should be provided, as internal identifiers rarely change (indeed, many > organizations ban the reuse of internal identifiers, such as POSIX UIDs > or GIDs, Windows RIDs, etc...). Some platforms, including Solaris, for > example, already have such a facility, but a generic interface that can > be used by portable applications is, IMO, highly desirable. > > I'm also willing to consider the possibility of allowing new mechanisms > to not support the notion of canonical names provided that: a) > GSS_Canonicalize_name() and GSS_Export_name() fail for such mechanisms, > and b) that a facility for obtaining the internal identifier(s) > associated with principals is provided. GSS-API v2 defines "binary" canonical names, not printable canonical names. That was done so that internal identifiers can be used for mechanisms that universally support them. Unfortunately Kerberos is not one of them, the true Kerberos 5 authentication is strictly name-based and both kerberized and gss-api based applications could always rely on (and actively do) that the Kerberos principal name found inside the ticket of an AP_REQ is canonical and can be used for access control and authorization decisions. > > I'm also interested in other name-related extensions, specifically an > interface by which one could query the mechanism of an MN and an > interface by which one could query whether a given MN is compatible with > a given name type (e.g., a krb5 MN that originally derived from > GSS_C_NT_HOSTBASED_SERVICE may display as GSS_C_NULL_OID or > GSS_KRB5_NT_PRINCIPAL_NAME, but it would be nice to know that it is a > name for what qualifies as a hostbased service). Huh? rfc2743 2.4.4 GSS_Display_name call The GSS_C_NO_OID name type is to be returned only when the corresponding internal name was created through import with GSS_C_NO_OID. It is acceptable for mechanisms to normalize names imported with GSS_C_NO_OID into other supported types and, therefore, to display them with types other than GSS_C_NO_OID. Otherwise, gss_display_name() must ALWAYS return an explicit nametype OID (if the output parameter is requested). *I* requested that gss_display_name() should be allowed to GSS_C_NO_OID for this special case. No other GSS-API call was ever allowed to return GSS_C_NO_OID in an OID output parameter on successful return. Check rfc2078 and rfc1508, they don't have this exemption. -Martin -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Apr 23 21:25:16 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27409 for ; Fri, 23 Apr 2004 21:25:15 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i3O1NlS0009368 for ietf-cat-wg-out720680; Fri, 23 Apr 2004 18:23:47 -0700 (PDT) Received: from konishi-polis.mit.edu (STRATTON-FIVE-O-FOUR.MIT.EDU [18.187.6.249]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i3O1NjNK009361 for ; Fri, 23 Apr 2004 18:23:45 -0700 (PDT) Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id D4A52151D5C; Fri, 23 Apr 2004 21:23:44 -0400 (EDT) To: Nicolas Williams Cc: Von Welch , martin.rex@sap.com, ietf-cat-wg@lists.Stanford.EDU Subject: Re: GGF's extensions to GSS in Public Comment References: <20040406004459.GO13507@binky.central.sun.com> <200404072357.BAA12098@uw1048.wdf.sap.corp> <16501.35375.214000.871773@gargle.gargle.HOWL> <20040408173351.GI5868@binky.central.sun.com> From: Sam Hartman Date: Fri, 23 Apr 2004 21:23:44 -0400 In-Reply-To: <20040408173351.GI5868@binky.central.sun.com> (Nicolas Williams's message of "Thu, 8 Apr 2004 12:33:51 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk [ggf security group dropped; I'm not sure my comments are useful to that forum.] >>>>> "Nicolas" == Nicolas Williams writes: >> Ideally, I agree - it would be nice we didn't have to use >> environment variables and didn't have to mess with this. But >> since we do, it seems like the best idea is to expose it so >> that it can be handled reasonably. Nicolas> You don't have to use environment variables. Looks like Nicolas> you used them only because MIT krb5 did (and does). Sorry for the long delay on this issue; somehow this thread got missorted in my mail and I just now noticed it. Random comments Nico has been making on the phone over the last week all start to make more sense;) MIT Kerberos only uses environment variables on some platforms. Fundamentally the putenv solution does not even work with all the common instances of the mechanisms for which it is designed. In the interests of full disclosure, I was one of two reviewers assigned to review this proposal for the security area. My comments were submitted to the ADs about two weeks ago, I believe they have been sent to parties within the GGF, although Google suggests that no one has made them available to the public. --Sam -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu From owner-ietf-cat-wg@lists.Stanford.EDU Fri Apr 23 22:35:17 2004 Received: from lists.Stanford.EDU (lists.Stanford.EDU [171.64.14.236]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00028 for ; Fri, 23 Apr 2004 22:35:16 -0400 (EDT) Received: (from root@localhost) by lists.Stanford.EDU (8.12.10/8.12.10) id i3O2BXGA012401 for ietf-cat-wg-out720680; Fri, 23 Apr 2004 19:11:33 -0700 (PDT) Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by lists.Stanford.EDU (8.12.10/8.12.10) with ESMTP id i3O2BTNK012396 for ; Fri, 23 Apr 2004 19:11:29 -0700 (PDT) Received: from VON-THINKPAD (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id i3O2BM092456 for ; Fri, 23 Apr 2004 21:11:22 -0500 Resent-Date: Fri, 23 Apr 2004 21:11:21 -0500 X-Resent-Mailer: 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid (via feedmail 10 I) Resent-From: "Von Welch" Resent-Message-ID: <16521.52424.542000.486821@gargle.gargle.HOWL> Resent-To: ietf-cat-wg@lists.Stanford.EDU X-Envelope-From: vwelch@ncsa.uiuc.edu X-Mailer: 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid (via feedmail 10 I); VM 7.14 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16521.51656.278000.920109@gargle.gargle.HOWL> In-Reply-To: References: <20040406004459.GO13507@binky.central.sun.com> <200404072357.BAA12098@uw1048.wdf.sap.corp> <16501.35375.214000.871773@gargle.gargle.HOWL> <20040408173351.GI5868@binky.central.sun.com> X-Envelope-To: vwelch X-Deliver-To: vwelch X-MD5SUM: f0b9e1e28071f616eae5b5ae8aca9265 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on mail.ncsa.uiuc.edu X-Spam-Status: No, hits=-2.2 required=4.0 tests=BAYES_00,RCVD_IN_DYNABLOCK, RCVD_IN_SORBS autolearn=no version=2.61 X-UIDL: 8Q3"!F("#!#kQ!!W%`!! From: Von Welch To: Sam Hartman Cc: Nicolas Williams , martin.rex@sap.com, ietf-cat-wg@lists.Stanford.EDU Subject: Re: GGF's extensions to GSS in Public Comment Reply-To: Von Welch Date: Fri, 23 Apr 2004 20:58:32 -0500 Sender: owner-ietf-cat-wg@lists.Stanford.EDU Precedence: bulk Content-Transfer-Encoding: 7bit I posted the comments from Sam and John Lynn, the other reviewer Sam mentioned, and sent out a pointer to the GGF list . You can see them at the url below by clicking on the "View Comments" for the GSS-Extensions document: http://www.ggf.org/Public_Comment_Docs/Public_Comment_Documents.htm To provide an update on the GGF process, I have suggested to the working group that we change the nature of the GGF extensions document from a recommendated standard to a Experimental document (to quote from the GGF document process, an experimental document is "To inform the community about a useful experiment, testbed, or implementation of an idea of set of ideas.") The intent being this would serve to capture the implementation and requirements without confusing the standards space. So far there has been only agreement with the suggestion, so at this time I expect that change to happen. Von Sam Hartman writes (21:23 April 23, 2004): > [ggf security group dropped; I'm not sure my comments are useful to > that forum.] > > >>>>> "Nicolas" == Nicolas Williams writes: > > > >> Ideally, I agree - it would be nice we didn't have to use > >> environment variables and didn't have to mess with this. But > >> since we do, it seems like the best idea is to expose it so > >> that it can be handled reasonably. > > Nicolas> You don't have to use environment variables. Looks like > Nicolas> you used them only because MIT krb5 did (and does). > > > Sorry for the long delay on this issue; somehow this thread got > missorted in my mail and I just now noticed it. > > Random comments Nico has been making on the phone over the last week > all start to make more sense;) > > MIT Kerberos only uses environment variables on some platforms. > Fundamentally the putenv solution does not even work with all the > common instances of the mechanisms for which it is designed. > > In the interests of full disclosure, I was one of two reviewers > assigned to review this proposal for the security area. My comments > were submitted to the ADs about two weeks ago, I believe they have > been sent to parties within the GGF, although Google suggests that no > one has made them available to the public. > > --Sam > > -++**==--++**==--++**==--++**==--++**==--++**==--++**== > This message was posted through the Stanford campus mailing list > server. If you wish to unsubscribe from this mailing list, send the > message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu > -++**==--++**==--++**==--++**==--++**==--++**==--++**== This message was posted through the Stanford campus mailing list server. If you wish to unsubscribe from this mailing list, send the message body of "unsubscribe ietf-cat-wg" to majordomo@lists.stanford.edu