From miallen@ioplex.com Tue Sep 1 10:12:35 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5741B3A684E for ; Tue, 1 Sep 2009 10:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hy-qoniOHppz for ; Tue, 1 Sep 2009 10:12:34 -0700 (PDT) Received: from mail.ioplex.com (li31-113.members.linode.com [207.192.69.113]) by core3.amsl.com (Postfix) with ESMTP id 381DD3A6B9A for ; Tue, 1 Sep 2009 10:11:50 -0700 (PDT) Received: from proton.foo.net (pool-71-187-189-103.nwrknj.fios.verizon.net [71.187.189.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: miallen) by mail.ioplex.com (Postfix) with ESMTP id 8613F411DC for ; Tue, 1 Sep 2009 13:12:02 -0400 (EDT) Date: Tue, 1 Sep 2009 13:12:02 -0400 From: Michael B Allen To: kitten@ietf.org Subject: Re: KITTEN: IETF 75 - 76 Message-Id: <20090901131202.137bdd90.miallen@ioplex.com> In-Reply-To: <200908180013.29152.leifj@mnt.se> References: <4A87A69A.3050408@sun.com> <4A87E02D.7030503@isode.com> <200908180013.29152.leifj@mnt.se> Organization: IOPLEX Software X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.12; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 17:12:35 -0000 On Tue, 18 Aug 2009 00:13:28 +0200 Leif Johansson wrote: > > > 2. listing/iterating credentials > > > 3. exporting/importing credentials > > > > I think Leif has expressed interest in (3) before. > > That was exporting unfinished contexts actually - slightly different. > > > > > > 4. error message reporting > > > 5. asynchronous calls > > > > The last 2 are generally required for use by modern applications. > > hmm, is asynchronous calls related to exportable contexts perhaps...? Exactly they are. To implement async (properly) you would need to be able to serialize a context at any step. Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ From Nicolas.Williams@sun.com Tue Sep 1 10:41:57 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21AD928C8D8 for ; Tue, 1 Sep 2009 10:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.857 X-Spam-Level: X-Spam-Status: No, score=-5.857 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SA9WiWWQXRA for ; Tue, 1 Sep 2009 10:41:55 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id EAA533A67DB for ; Tue, 1 Sep 2009 10:41:54 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n81Hg5lN009060 for ; Tue, 1 Sep 2009 17:42:05 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n81Hg5eg006578 for ; Tue, 1 Sep 2009 11:42:05 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n81HVB2q008289; Tue, 1 Sep 2009 12:31:11 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n81HVBWJ008288; Tue, 1 Sep 2009 12:31:11 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 1 Sep 2009 12:31:11 -0500 From: Nicolas Williams To: Michael B Allen Subject: Re: KITTEN: IETF 75 - 76 Message-ID: <20090901173110.GL1033@Sun.COM> References: <4A87A69A.3050408@sun.com> <4A87E02D.7030503@isode.com> <200908180013.29152.leifj@mnt.se> <20090901131202.137bdd90.miallen@ioplex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090901131202.137bdd90.miallen@ioplex.com> User-Agent: Mutt/1.5.7i Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 17:41:57 -0000 On Tue, Sep 01, 2009 at 01:12:02PM -0400, Michael B Allen wrote: > On Tue, 18 Aug 2009 00:13:28 +0200 > Leif Johansson wrote: > > > > > 2. listing/iterating credentials > > > > 3. exporting/importing credentials > > > > > > I think Leif has expressed interest in (3) before. > > > > That was exporting unfinished contexts actually - slightly different. > > > > > > > > > 4. error message reporting > > > > 5. asynchronous calls > > > > > > The last 2 are generally required for use by modern applications. > > > > hmm, is asynchronous calls related to exportable contexts perhaps...? > > Exactly they are. To implement async (properly) you would need to be > able to serialize a context at any step. Internally, maybe, but as far as the application goes: no. To me async means a pair of functions called, say, gss_init_sec_context_async() and gss_accept_sec_context_async() that do not block, but may return an indication that the call did not complete, and which provide some way for event notification so that the application can call them again when they are ready to be called again. Here's one illustration based on event notification: major = gss_init_sec_context_async_event(&minor, cred, &ctx, target, mech, req_flags, GSS_C_INDEFINITE, cb, &input_token, &output_token, &ret_flags, NULL, &event_notification); if (major == GSS_S_CONTINUE_NEEDED && output_token.length == 0) { /* * hook event notification and contextual args * to gss_init_sec_context_async() into our event loop * and return. when the event fires we'll get here * again and call gss_init_sec_context_async() to make * progress. */ queue_up(&event_notification, cred, &ctx, target, mech, ...); } Here's another based on background threads and a completion callback instead of an event notification: major = gss_init_sec_context_async_cb(&minor, cred, &ctx, target, mech, req_flags, GSS_C_INDEFINITE, cb, &input_token, &output_token, &ret_flags, NULL, cb_func, &cb_data); if (major == GSS_S_CONTINUE_NEEDED && output_token.length == 0) { /* * Our callback will get called when * gss_init_sec_context_async_cb() completes its work. * The callback will arrange to get us called again. */ return (...); } No context serialization needed. The problem with the event notification variant is that event notification is very OS-specific, and even library specific (think kqueues, event ports, poll(), select(), /dev/poll, libevent, ...). On Unix and Unix-like systems we can probably make the event_notification be just an array of file descriptors. The problem with the callback variant is that it implies a threaded process model (which I don't mind, but which won't be feasible for some implementors). Nico -- From Shawn.Emery@Sun.COM Tue Sep 1 10:54:34 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FAC33A704D for ; Tue, 1 Sep 2009 10:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.708 X-Spam-Level: X-Spam-Status: No, score=-3.708 tagged_above=-999 required=5 tests=[AWL=2.339, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmscrBYVNOA8 for ; Tue, 1 Sep 2009 10:54:33 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 47B363A6CFE for ; Tue, 1 Sep 2009 10:54:33 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n81HsYSW019221 for ; Tue, 1 Sep 2009 17:54:34 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KPA00A00XI5A800@mail-amer.sun.com> for kitten@ietf.org; Tue, 01 Sep 2009 11:54:34 -0600 (MDT) Received: from [10.0.0.5] ([unknown] [174.51.183.68]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KPB00JTK0ELXOA0@mail-amer.sun.com> for kitten@ietf.org; Tue, 01 Sep 2009 11:54:21 -0600 (MDT) Date: Tue, 01 Sep 2009 11:53:32 -0600 From: Shawn M Emery Subject: Re: KITTEN: IETF 75 - 76 In-reply-to: <4A87A69A.3050408@sun.com> Sender: Shawn.Emery@Sun.COM To: kitten@ietf.org Message-id: <4A9D5F9C.5010300@sun.com> References: <4A87A69A.3050408@sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090804) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 17:54:34 -0000 Folks, We've had great discussion on the list about the new work items. So now we need volunteers for editors of each of the items. They would need to filter this thread and capture the design in corresponding ID(s). If they have further questions/clarifications then please post this to the list as there has been feed back from multiple sources. If you would like to be an editor then please e-mail the list, so that we can coordinate assignments. We would prefer to have at least one editor to progress this WG. Thanks, Shawn. -- Shawn M Emery wrote: > Folks, > > As our AD (Tim) had mentioned at the last session, we should gage > interest in the working group going forward by polling the members to > see what items they would be willing to work on between now and IETF > 76 (starting November 8). Tim would like one or two new drafts to be > created as an indicator. > > Love had given a set of new work items that would be of interest, as > follows: > > 1. initialization/new credentials > 2. listing/iterating credentials > 3. exporting/importing credentials > 4. error message reporting > 5. asynchronous calls > > ...along with Alexey's recent request for policy/encryption strength. > > We are looking for authors and editors for any of these new items or > something else that you would like to see developed within KITTEN. > -- Shawn. From lha@kth.se Tue Sep 1 11:12:51 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48FE93A7066 for ; Tue, 1 Sep 2009 11:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Env2jsxe0PYq for ; Tue, 1 Sep 2009 11:12:50 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 822FF3A6B99 for ; Tue, 1 Sep 2009 11:12:50 -0700 (PDT) Received: from relay11.apple.com (relay11.apple.com [17.128.113.48]) by mail-out3.apple.com (Postfix) with ESMTP id 7A9517078EEC for ; Tue, 1 Sep 2009 11:13:04 -0700 (PDT) X-AuditID: 11807130-b7ca1ae00000654a-8a-4a9d6430b0ec Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay11.apple.com (Apple SCV relay) with SMTP id 53.D1.25930.0346D9A4; Tue, 1 Sep 2009 11:13:04 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from nutcracker.apple.com (nutcracker.apple.com [17.201.21.139]) by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0KPB00LTS19SAO20@et.apple.com> for kitten@ietf.org; Tue, 01 Sep 2009 11:13:04 -0700 (PDT) Subject: Re: KITTEN: IETF 75 - 76 From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-reply-to: <20090901173110.GL1033@Sun.COM> Date: Tue, 01 Sep 2009 11:13:03 -0700 Message-id: <28C158D0-07C3-4C91-BDAB-378C48F05556@kth.se> References: <4A87A69A.3050408@sun.com> <4A87E02D.7030503@isode.com> <200908180013.29152.leifj@mnt.se> <20090901131202.137bdd90.miallen@ioplex.com> <20090901173110.GL1033@Sun.COM> To: Nicolas Williams X-Mailer: Apple Mail (2.1075.2) X-Brightmail-Tracker: AAAAAQAAAZE= Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 18:12:51 -0000 1 sep 2009 kl. 10:31 skrev Nicolas Williams: > The problem with the callback variant is that it implies a threaded > process model (which I don't mind, but which won't be feasible for > some > implementors). It does not require threads, the caller of the cb enabled ISC will have to call the event loop, that in turn will call the callback call. It does require though that you select one event process system (or threads). Love From Nicolas.Williams@sun.com Tue Sep 1 12:04:20 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C911A28C9A9 for ; Tue, 1 Sep 2009 12:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.709 X-Spam-Level: X-Spam-Status: No, score=-5.709 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUGq6beOccMb for ; Tue, 1 Sep 2009 12:04:20 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id A394928CA14 for ; Tue, 1 Sep 2009 12:03:38 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n81J36nk018880 for ; Tue, 1 Sep 2009 19:03:06 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n81J350i059986 for ; Tue, 1 Sep 2009 13:03:05 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n81IqBK1008332; Tue, 1 Sep 2009 13:52:11 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n81IqBhH008331; Tue, 1 Sep 2009 13:52:11 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 1 Sep 2009 13:52:10 -0500 From: Nicolas Williams To: Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= Subject: Re: KITTEN: IETF 75 - 76 Message-ID: <20090901185210.GO1033@Sun.COM> References: <4A87A69A.3050408@sun.com> <4A87E02D.7030503@isode.com> <200908180013.29152.leifj@mnt.se> <20090901131202.137bdd90.miallen@ioplex.com> <20090901173110.GL1033@Sun.COM> <28C158D0-07C3-4C91-BDAB-378C48F05556@kth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <28C158D0-07C3-4C91-BDAB-378C48F05556@kth.se> User-Agent: Mutt/1.5.7i Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 19:04:20 -0000 On Tue, Sep 01, 2009 at 11:13:03AM -0700, Love Hörnquist Åstrand wrote: > 1 sep 2009 kl. 10:31 skrev Nicolas Williams: > >The problem with the callback variant is that it implies a threaded > >process model (which I don't mind, but which won't be feasible for > >some > >implementors). > > It does not require threads, the caller of the cb enabled ISC will > have to call the event loop, that in turn will call the callback call. > > It does require though that you select one event process system (or > threads). Yes, you're right, the callback variant implies one of: threaded process model or async I/O event loop model. We should at least specify that the callback may be called in a different thread in the case of threaded process models. Nico -- From lha@kth.se Tue Sep 1 14:29:31 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75BDB28C547 for ; Tue, 1 Sep 2009 14:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNh5aXibtWFi for ; Tue, 1 Sep 2009 14:29:30 -0700 (PDT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 98A983A70AC for ; Tue, 1 Sep 2009 14:27:26 -0700 (PDT) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out4.apple.com (Postfix) with ESMTP id CD59E74C67BE for ; Tue, 1 Sep 2009 14:27:04 -0700 (PDT) X-AuditID: 11807136-b7b3cae0000059ab-c0-4a9d91a89012 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay15.apple.com (Apple SCV relay) with SMTP id 4E.22.22955.8A19D9A4; Tue, 1 Sep 2009 14:27:04 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from nutcracker.apple.com (nutcracker.apple.com [17.201.21.139]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0KPB002J9A94YG00@elliott.apple.com> for kitten@ietf.org; Tue, 01 Sep 2009 14:27:04 -0700 (PDT) Subject: Re: KITTEN: IETF 75 - 76 From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-reply-to: <20090901173110.GL1033@Sun.COM> Date: Tue, 01 Sep 2009 14:27:04 -0700 Message-id: <396484EF-9812-40CE-9221-F1A1319FD10B@kth.se> References: <4A87A69A.3050408@sun.com> <4A87E02D.7030503@isode.com> <200908180013.29152.leifj@mnt.se> <20090901131202.137bdd90.miallen@ioplex.com> <20090901173110.GL1033@Sun.COM> To: Nicolas Williams X-Mailer: Apple Mail (2.1075.2) X-Brightmail-Tracker: AAAAAQAAAZE= Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 21:29:31 -0000 1 sep 2009 kl. 10:31 skrev Nicolas Williams: > Here's another based on background threads and a completion callback > instead of an event notification: > > major = gss_init_sec_context_async_cb(&minor, > cred, &ctx, target, mech, req_flags, > GSS_C_INDEFINITE, cb, &input_token, &output_token, > &ret_flags, NULL, cb_func, &cb_data); The callback should take all output variables, for example: OM_uint32 gss_acquire_cred_ex_f(gss_status_id_t /* status */, const gss_name_t /* desired_name */, OM_uint32 /* flags */, OM_uint32 /* time_req */, const gss_OID /*desired_mech */, gss_cred_usage_t /* cred_usage */, gss_auth_identity_t /* identity */, void * /* ctx */, void (* /* complete */)(void *, OM_uint32, gss_status_id_t, gss_cred_id_t, gss_OID_set, OM_uint32)); OM_uint32 gss_iter_creds_f(gss_status_id_t /* status */, OM_uint32 /* flags */, gss_OID /* mech */, void * /* userctx */, void (* /*cred_iter */ )(void *, gss_OID, gss_cred_id_t)); Love From Nicolas.Williams@sun.com Tue Sep 1 14:49:36 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACA6D3A70A4 for ; Tue, 1 Sep 2009 14:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.709 X-Spam-Level: X-Spam-Status: No, score=-5.709 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7Kh7k2FGB+W for ; Tue, 1 Sep 2009 14:49:35 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 91BA53A6CD1 for ; Tue, 1 Sep 2009 14:49:35 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n81LnmLK010308 for ; Tue, 1 Sep 2009 21:49:49 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n81LnmC4054932 for ; Tue, 1 Sep 2009 15:49:48 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n81LcsRc008560; Tue, 1 Sep 2009 16:38:54 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n81Lcrvq008559; Tue, 1 Sep 2009 16:38:53 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 1 Sep 2009 16:38:53 -0500 From: Nicolas Williams To: Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= Subject: Re: KITTEN: IETF 75 - 76 Message-ID: <20090901213853.GY1033@Sun.COM> References: <4A87A69A.3050408@sun.com> <4A87E02D.7030503@isode.com> <200908180013.29152.leifj@mnt.se> <20090901131202.137bdd90.miallen@ioplex.com> <20090901173110.GL1033@Sun.COM> <396484EF-9812-40CE-9221-F1A1319FD10B@kth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <396484EF-9812-40CE-9221-F1A1319FD10B@kth.se> User-Agent: Mutt/1.5.7i Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 21:49:36 -0000 On Tue, Sep 01, 2009 at 02:27:04PM -0700, Love Hörnquist Åstrand wrote: > >Here's another based on background threads and a completion callback > >instead of an event notification: > > > > major = gss_init_sec_context_async_cb(&minor, > > cred, &ctx, target, mech, req_flags, > > GSS_C_INDEFINITE, cb, &input_token, &output_token, > > &ret_flags, NULL, cb_func, &cb_data); > > The callback should take all output variables, for example: As I imagined it the callback would only be to indicate that GISCACB() must get called again to complete its work. (And it might well need fail to complete at that point. Think of krb5_gisc: it may need to do multiple DNS lookups, and multiple TGS exchanges; each time that some I/O is ready that it needs it could call the callback, the app then calls back into GISCACB(), krb5_gisc makes some progress, and if it'd block then it returns continue-needed without an output token. Lather, rinse, repeat. I like it better that way. If we add a new version of GISC with new outputs we'll need not only a new GISC_async, but also a new callback function prototype. Having the callback lead to the application calling GISCACB() again seems reasonable and simple enough to me. I'm not wedded to this, but it does seem simpler. The callback in the credential iterator can be the way you propose. That's because it doesn't need every output of gss_inquire_cred*(), just a cred handle and mechanism OID, and it can find the rest from that. Nico -- From miallen@ioplex.com Tue Sep 1 15:13:04 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A06213A6A91 for ; Tue, 1 Sep 2009 15:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vx1BxSHQOGnJ for ; Tue, 1 Sep 2009 15:13:03 -0700 (PDT) Received: from mail.ioplex.com (li31-113.members.linode.com [207.192.69.113]) by core3.amsl.com (Postfix) with ESMTP id C09643A685E for ; Tue, 1 Sep 2009 15:13:03 -0700 (PDT) Received: from proton.foo.net (pool-71-187-189-103.nwrknj.fios.verizon.net [71.187.189.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: miallen) by mail.ioplex.com (Postfix) with ESMTP id 3F0A5411DC; Tue, 1 Sep 2009 18:13:07 -0400 (EDT) Date: Tue, 1 Sep 2009 18:13:07 -0400 From: Michael B Allen To: Love =?ISO-8859-1?Q?H=F6rnquist_=C5strand?= Subject: Re: KITTEN: IETF 75 - 76 Message-Id: <20090901181307.fe1d4efa.miallen@ioplex.com> In-Reply-To: <396484EF-9812-40CE-9221-F1A1319FD10B@kth.se> References: <4A87A69A.3050408@sun.com> <4A87E02D.7030503@isode.com> <200908180013.29152.leifj@mnt.se> <20090901131202.137bdd90.miallen@ioplex.com> <20090901173110.GL1033@Sun.COM> <396484EF-9812-40CE-9221-F1A1319FD10B@kth.se> Organization: IOPLEX Software X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.12; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" , Nicolas Williams X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 22:13:04 -0000 On Tue, 01 Sep 2009 14:27:04 -0700 Love H=F6rnquist =C5strand wrote: >=20 > 1 sep 2009 kl. 10:31 skrev Nicolas Williams: >=20 > > Here's another based on background threads and a completion callback > > instead of an event notification: > > > > major =3D gss_init_sec_context_async_cb(&minor, > > cred, &ctx, target, mech, req_flags, > > GSS_C_INDEFINITE, cb, &input_token, &output_token, > > &ret_flags, NULL, cb_func, &cb_data); >=20 > The callback should take all output variables, for example: >=20 > OM_uint32 > gss_acquire_cred_ex_f(gss_status_id_t /* status */, > const gss_name_t /* desired_name */, > OM_uint32 /* flags */, > OM_uint32 /* time_req */, > const gss_OID /*desired_mech */, > gss_cred_usage_t /* cred_usage */, > gss_auth_identity_t /* identity */, > void * /* ctx */, > void (* /* complete */)(void *, OM_uint32, gss_status_id_t, =20 > gss_cred_id_t, gss_OID_set, OM_uint32)); Holy moses that's complicated. Do you really need callbacks? Why not just h= ave a flag like GSS_C_NOWAIT that indicates the call should return immediat= ely even if the overall operation has not completed yet? If the status indi= cates more processing is required (EAGAIN for C binding for example) it mea= ns that you need to call it again later. I use this technique in my own stu= ff and the implementation turns out to be surprisingly clean. Also note that in an HTTP server if you cannot serialize the context while = juggle concurrent authentications you may have to commit to using resources= unnecessarily (such as processes on UNIX). That was my primary thought whe= n I first posted to this thread. It's not clear to me that your model would= help that scenario and that scenario is fairly important IMO. Would callba= cks work with a stateless transport like HTTP? Mike --=20 Michael B Allen Java Active Directory Integration http://www.ioplex.com/ From lha@kth.se Tue Sep 1 15:18:01 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51D013A6AF3 for ; Tue, 1 Sep 2009 15:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXr8KFIzcQ3d for ; Tue, 1 Sep 2009 15:18:00 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 797B13A6908 for ; Tue, 1 Sep 2009 15:18:00 -0700 (PDT) Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out3.apple.com (Postfix) with ESMTP id D413B70810D6 for ; Tue, 1 Sep 2009 15:18:14 -0700 (PDT) X-AuditID: 11807137-b7befae000005eb4-ef-4a9d9da64292 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay16.apple.com (Apple SCV relay) with SMTP id 8A.3C.24244.6AD9D9A4; Tue, 1 Sep 2009 15:18:14 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from nutcracker.apple.com (nutcracker.apple.com [17.201.21.139]) by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0KPB0029JCMEYG10@elliott.apple.com> for kitten@ietf.org; Tue, 01 Sep 2009 15:18:14 -0700 (PDT) Subject: Re: KITTEN: IETF 75 - 76 From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-reply-to: <20090901181307.fe1d4efa.miallen@ioplex.com> Date: Tue, 01 Sep 2009 15:18:13 -0700 Message-id: <98F14484-1B48-45A1-86E7-5E78383F5109@kth.se> References: <4A87A69A.3050408@sun.com> <4A87E02D.7030503@isode.com> <200908180013.29152.leifj@mnt.se> <20090901131202.137bdd90.miallen@ioplex.com> <20090901173110.GL1033@Sun.COM> <396484EF-9812-40CE-9221-F1A1319FD10B@kth.se> <20090901181307.fe1d4efa.miallen@ioplex.com> To: Michael B Allen X-Mailer: Apple Mail (2.1075.2) X-Brightmail-Tracker: AAAAAQAAAZE= Cc: "kitten@ietf.org" , Nicolas Williams X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 22:18:01 -0000 1 sep 2009 kl. 15:13 skrev Michael B Allen: > it means that you need to call it again later When is later unless you get a callback ? So far it have not been complicated, note that gss_acquire_cred_ex() does more then gss_acquire_cred(). Love From Nicolas.Williams@sun.com Tue Sep 1 15:33:15 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8E8528C92B for ; Tue, 1 Sep 2009 15:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.71 X-Spam-Level: X-Spam-Status: No, score=-5.71 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDGaHrAWoWO1 for ; Tue, 1 Sep 2009 15:33:15 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 9805C28C61C for ; Tue, 1 Sep 2009 15:31:40 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n81MVrol028984 for ; Tue, 1 Sep 2009 22:31:53 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n81MVqSx001604 for ; Tue, 1 Sep 2009 16:31:52 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n81MKx2q008610; Tue, 1 Sep 2009 17:20:59 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n81MKxog008609; Tue, 1 Sep 2009 17:20:59 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 1 Sep 2009 17:20:59 -0500 From: Nicolas Williams To: Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= Subject: Re: KITTEN: IETF 75 - 76 Message-ID: <20090901222059.GZ1033@Sun.COM> References: <4A87A69A.3050408@sun.com> <4A87E02D.7030503@isode.com> <200908180013.29152.leifj@mnt.se> <20090901131202.137bdd90.miallen@ioplex.com> <20090901173110.GL1033@Sun.COM> <396484EF-9812-40CE-9221-F1A1319FD10B@kth.se> <20090901181307.fe1d4efa.miallen@ioplex.com> <98F14484-1B48-45A1-86E7-5E78383F5109@kth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98F14484-1B48-45A1-86E7-5E78383F5109@kth.se> User-Agent: Mutt/1.5.7i Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 22:33:15 -0000 On Tue, Sep 01, 2009 at 03:18:13PM -0700, Love Hörnquist Åstrand wrote: > > 1 sep 2009 kl. 15:13 skrev Michael B Allen: > > > it means that you need to call it again later > > When is later unless you get a callback ? I agree. Callbacks are easy. My construction (for ISC) is simpler: no need for all the ISC output args in the callback. Love's credential iterator callback is trivial. Callbacks are very common in API design. From lha@kth.se Tue Sep 1 15:39:30 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A982B28C753 for ; Tue, 1 Sep 2009 15:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNKNh4FN3BNK for ; Tue, 1 Sep 2009 15:39:29 -0700 (PDT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 7D6B128C8D2 for ; Tue, 1 Sep 2009 15:39:19 -0700 (PDT) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out4.apple.com (Postfix) with ESMTP id E4B0274CA1F4 for ; Tue, 1 Sep 2009 15:39:33 -0700 (PDT) X-AuditID: 1180711d-b7c98ae000007d91-4d-4a9da2a5af06 Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay13.apple.com (Apple SCV relay) with SMTP id 0C.6D.32145.5A2AD9A4; Tue, 1 Sep 2009 15:39:33 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes Received: from nutcracker.apple.com (nutcracker.apple.com [17.201.21.139]) by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0KPB00CRGDLX7M30@gertie.apple.com> for kitten@ietf.org; Tue, 01 Sep 2009 15:39:33 -0700 (PDT) Subject: Re: KITTEN: IETF 75 - 76 From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-reply-to: <20090901222059.GZ1033@Sun.COM> Date: Tue, 01 Sep 2009 15:39:33 -0700 Content-transfer-encoding: quoted-printable Message-id: References: <4A87A69A.3050408@sun.com> <4A87E02D.7030503@isode.com> <200908180013.29152.leifj@mnt.se> <20090901131202.137bdd90.miallen@ioplex.com> <20090901173110.GL1033@Sun.COM> <396484EF-9812-40CE-9221-F1A1319FD10B@kth.se> <20090901181307.fe1d4efa.miallen@ioplex.com> <98F14484-1B48-45A1-86E7-5E78383F5109@kth.se> <20090901222059.GZ1033@Sun.COM> To: Nicolas Williams X-Mailer: Apple Mail (2.1075.2) X-Brightmail-Tracker: AAAAAQAAAZE= Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 22:39:30 -0000 1 sep 2009 kl. 15:20 skrev Nicolas Williams: > On Tue, Sep 01, 2009 at 03:18:13PM -0700, Love H=F6rnquist =C5strand =20= > wrote: >> >> 1 sep 2009 kl. 15:13 skrev Michael B Allen: >> >>> it means that you need to call it again later >> >> When is later unless you get a callback ? > > I agree. Callbacks are easy. My construction (for ISC) is simpler: =20= > no > need for all the ISC output args in the callback. So what is input token for the second call ? Can input token be freed =20= between first and second call ? Why do I have to pass all those argument that might (or might not) do =20= something. Love From Nicolas.Williams@sun.com Tue Sep 1 16:04:43 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB8EB3A6ACD for ; Tue, 1 Sep 2009 16:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.56 X-Spam-Level: X-Spam-Status: No, score=-4.56 tagged_above=-999 required=5 tests=[AWL=-1.114, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MANGLED_AVOID=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXdePUIst4eB for ; Tue, 1 Sep 2009 16:04:43 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id B40863A6C55 for ; Tue, 1 Sep 2009 16:04:42 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n81N4udI005316 for ; Tue, 1 Sep 2009 23:04:56 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n81N4uVw018303 for ; Tue, 1 Sep 2009 17:04:56 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n81Ms2rL008656; Tue, 1 Sep 2009 17:54:02 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n81Ms2Ah008655; Tue, 1 Sep 2009 17:54:02 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 1 Sep 2009 17:54:02 -0500 From: Nicolas Williams To: Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= Subject: Re: KITTEN: IETF 75 - 76 Message-ID: <20090901225401.GB1033@Sun.COM> References: <4A87A69A.3050408@sun.com> <4A87E02D.7030503@isode.com> <200908180013.29152.leifj@mnt.se> <20090901131202.137bdd90.miallen@ioplex.com> <20090901173110.GL1033@Sun.COM> <396484EF-9812-40CE-9221-F1A1319FD10B@kth.se> <20090901181307.fe1d4efa.miallen@ioplex.com> <98F14484-1B48-45A1-86E7-5E78383F5109@kth.se> <20090901222059.GZ1033@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.7i Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 23:04:43 -0000 On Tue, Sep 01, 2009 at 03:39:33PM -0700, Love Hörnquist Åstrand wrote: > 1 sep 2009 kl. 15:20 skrev Nicolas Williams: > >I agree. Callbacks are easy. My construction (for ISC) is simpler: > >no need for all the ISC output args in the callback. > > So what is input token for the second call ? Can input token be freed > between first and second call ? It should be the same as in the previous call. But that can be relaxed -- we could say that the mech must keep an internal copy if it will continue needing it after the first call. > Why do I have to pass all those argument that might (or might not) do > something. If it's hard to track them you can always place them in the callback function's argument -- a void * that would be a pointer to a struct with all the context that the callback needs, including those GISC args if you're not storing them elsewhere. From miallen@ioplex.com Tue Sep 1 18:41:59 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11CE628C646 for ; Tue, 1 Sep 2009 18:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.724 X-Spam-Level: X-Spam-Status: No, score=-1.724 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEMwlxfU+1aA for ; Tue, 1 Sep 2009 18:41:56 -0700 (PDT) Received: from mail.ioplex.com (li31-113.members.linode.com [207.192.69.113]) by core3.amsl.com (Postfix) with ESMTP id D8F6528C2D6 for ; Tue, 1 Sep 2009 18:41:52 -0700 (PDT) Received: from proton.foo.net (pool-71-187-189-103.nwrknj.fios.verizon.net [71.187.189.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: miallen) by mail.ioplex.com (Postfix) with ESMTP id 1BCDB411DC; Tue, 1 Sep 2009 21:41:00 -0400 (EDT) Date: Tue, 1 Sep 2009 21:40:59 -0400 From: Michael B Allen To: Love =?ISO-8859-1?Q?H=F6rnquist_=C5strand?= Subject: Re: KITTEN: IETF 75 - 76 Message-Id: <20090901214059.17a309e6.miallen@ioplex.com> In-Reply-To: <98F14484-1B48-45A1-86E7-5E78383F5109@kth.se> References: <4A87A69A.3050408@sun.com> <4A87E02D.7030503@isode.com> <200908180013.29152.leifj@mnt.se> <20090901131202.137bdd90.miallen@ioplex.com> <20090901173110.GL1033@Sun.COM> <396484EF-9812-40CE-9221-F1A1319FD10B@kth.se> <20090901181307.fe1d4efa.miallen@ioplex.com> <98F14484-1B48-45A1-86E7-5E78383F5109@kth.se> Organization: IOPLEX Software X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.12; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" , Nicolas Williams X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 01:41:59 -0000 On Tue, 01 Sep 2009 15:18:13 -0700 Love H=F6rnquist =C5strand wrote: >=20 > 1 sep 2009 kl. 15:13 skrev Michael B Allen: >=20 > > it means that you need to call it again later >=20 > When is later unless you get a callback ? When you call the function with the flag GSS_C_NOWAIT, the implementation t= ransmits the network request [1] and then checks to see if data can be read= (such as by using select(2)). If data is not available, the function simpl= y returns a status of EAGAIN. Now the caller is free to perform other work = (and thus it is async). But the caller now knows that the function needs to= be called again to complete the operation. So later, it calls the function= again. If the network response has been received, it returns success. Othe= rwise, if GSS_C_NOWAIT was supplied, it again returns EAGAIN. If GSS_C_NOWA= IT was not supplied, it waits for the operation to complete (e.g. for a net= work response to be received) just like the non-async call. In fact async a= nd non-async uses the same function - the GSS_C_NOWAIT flag alone controls = async behavior. Mike [1] A network request is only one example, the behavior is the same for any= blocking operation. --=20 Michael B Allen Java Active Directory Integration http://www.ioplex.com/ From lha@kth.se Tue Sep 1 22:28:02 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00F363A683B for ; Tue, 1 Sep 2009 22:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.582 X-Spam-Level: X-Spam-Status: No, score=-3.582 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_AVOID=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13vjnyvLTwTN for ; Tue, 1 Sep 2009 22:28:00 -0700 (PDT) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id D9F673A692F for ; Tue, 1 Sep 2009 22:26:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 700F91557D3; Wed, 2 Sep 2009 07:24:36 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([127.0.0.1]) by localhost (smtp-1.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id W72qMgVfzGRN; Wed, 2 Sep 2009 07:24:28 +0200 (CEST) X-KTH-Auth: lha [2002:6334:ca6c:0:21e:c2ff:fec5:249f] Received: from [IPv6:2002:6334:ca6c::21e:c2ff:fec5:249f] (unknown [IPv6:2002:6334:ca6c:0:21e:c2ff:fec5:249f]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 89ECD1551FC; Wed, 2 Sep 2009 07:24:27 +0200 (CEST) Subject: Re: KITTEN: IETF 75 - 76 Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-Reply-To: <20090901225401.GB1033@Sun.COM> Date: Tue, 1 Sep 2009 22:23:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A87A69A.3050408@sun.com> <4A87E02D.7030503@isode.com> <200908180013.29152.leifj@mnt.se> <20090901131202.137bdd90.miallen@ioplex.com> <20090901173110.GL1033@Sun.COM> <396484EF-9812-40CE-9221-F1A1319FD10B@kth.se> <20090901181307.fe1d4efa.miallen@ioplex.com> <98F14484-1B48-45A1-86E7-5E78383F5109@kth.se> <20090901222059.GZ1033@Sun.COM> <20090901225401.GB1033@Sun.COM> To: Nicolas Williams X-Mailer: Apple Mail (2.1075.2) Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 05:28:02 -0000 1 sep 2009 kl. 15:54 skrev Nicolas Williams: > On Tue, Sep 01, 2009 at 03:39:33PM -0700, Love H=F6rnquist =C5strand =20= > wrote: >> 1 sep 2009 kl. 15:20 skrev Nicolas Williams: >>> I agree. Callbacks are easy. My construction (for ISC) is simpler: >>> no need for all the ISC output args in the callback. >> >> So what is input token for the second call ? Can input token be freed >> between first and second call ? > > It should be the same as in the previous call. But that can be =20 > relaxed > -- we could say that the mech must keep an internal copy if it will > continue needing it after the first call. > >> Why do I have to pass all those argument that might (or might not) do >> something. > > If it's hard to track them you can always place them in the callback > function's argument -- a void * that would be a pointer to a struct =20= > with > all the context that the callback needs, including those GISC args if > you're not storing them elsewhere. I find this more complicated then just returning the values to the =20 callback function. In fact, I find it more complicated to have my callback function have =20= to save values so it can call the same function is just was called =20 from just to call the called function again. It just doesn't make sense. Love From metze@samba.org Wed Sep 2 00:48:15 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D75683A6901 for ; Wed, 2 Sep 2009 00:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgBpZ7HG7ibJ for ; Wed, 2 Sep 2009 00:48:15 -0700 (PDT) Received: from mail.mx-netz.de (ip-217-172-181-76.mx-netz.de [217.172.181.76]) by core3.amsl.com (Postfix) with ESMTP id BE1F53A6405 for ; Wed, 2 Sep 2009 00:48:14 -0700 (PDT) Received: from [172.30.76.9] (unknown [172.30.76.9]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (SASL METHOD:[PLAIN] USERNAME:[metze]) by mail.mx-netz.de (SMTP-MAIL-SERVER) with ESMTP id 08B9F20C554; Wed, 2 Sep 2009 09:46:39 +0200 (CEST) Message-ID: <4A9E22D9.9050405@samba.org> Date: Wed, 02 Sep 2009 09:46:33 +0200 From: "Stefan (metze) Metzmacher" User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Michael B Allen Subject: Re: KITTEN: IETF 75 - 76 References: <4A87A69A.3050408@sun.com> <4A87E02D.7030503@isode.com> <200908180013.29152.leifj@mnt.se> <20090901131202.137bdd90.miallen@ioplex.com> <20090901173110.GL1033@Sun.COM> <396484EF-9812-40CE-9221-F1A1319FD10B@kth.se> <20090901181307.fe1d4efa.miallen@ioplex.com> <98F14484-1B48-45A1-86E7-5E78383F5109@kth.se> <20090901214059.17a309e6.miallen@ioplex.com> In-Reply-To: <20090901214059.17a309e6.miallen@ioplex.com> X-Enigmail-Version: 0.95.0 OpenPGP: id=0E53083F Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE3E9B306C1811C6AE63D5039" Cc: "kitten@ietf.org" , Volker Lendecke , Nicolas Williams X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 07:48:15 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE3E9B306C1811C6AE63D5039 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Michael B Allen schrieb: > On Tue, 01 Sep 2009 15:18:13 -0700 > Love H=F6rnquist =C5strand wrote: >=20 >> 1 sep 2009 kl. 15:13 skrev Michael B Allen: >> >>> it means that you need to call it again later >> When is later unless you get a callback ? >=20 > When you call the function with the flag GSS_C_NOWAIT, the implementati= on transmits the network request [1] and then checks to see if data can b= e read (such as by using select(2)). If data is not available, the functi= on simply returns a status of EAGAIN. Now the caller is free to perform o= ther work (and thus it is async). But the caller now knows that the funct= ion needs to be called again to complete the operation. So later, it call= s the function again. If the network response has been received, it retur= ns success. Otherwise, if GSS_C_NOWAIT was supplied, it again returns EAG= AIN. If GSS_C_NOWAIT was not supplied, it waits for the operation to comp= lete (e.g. for a network response to be received) just like the non-async= call. In fact async and non-async uses the same function - the GSS_C_NOW= AIT flag alone controls async behavior. That is true for system calls like send() and recv(), where the caller is supposed to call select. But for gssapi the caller would have to poll like this: while (1) { ret =3D gss_call(&minor, ...); if (ret !=3D 0 && minor =3D=3D EAGAIN) { continue; } ... break; } Or the application needs to try every few milli seconds... What about a generic callback infrastructure: typedef void *gss_async_cookie_t; OM_uint32 gss_init_async_cookie( void (*callback)(gss_async_cookie_t *cookie, void *callback_private), void *callback_private, gss_async_cookie_t **cookie ); OM_uint32 gss_release_async_cookie(gss_async_cookie_t **cookie); #define GSS_S_ASYNC 12345678 and then either one function that autodetects if it should use the input parameters based on its state in the async cookie. OM_uint32 GSSAPI_LIB_FUNCTION gss_init_sec_context_async (OM_uint32 * /*minor_status*/, const gss_cred_id_t /*initiator_cred_handle*/, gss_ctx_id_t * /*context_handle*/, const gss_name_t /*target_name*/, const gss_OID /*mech_type*/, OM_uint32 /*req_flags*/, OM_uint32 /*time_req*/, const gss_channel_bindings_t /*input_chan_bindings*/, const gss_buffer_t /*input_token*/, gss_OID * /*actual_mech_type*/, gss_buffer_t /*output_token*/, OM_uint32 * /*ret_flags*/, OM_uint32 * /*time_rec*/, gss_async_cookie_t * /* cookie */ ); or two functions. OM_uint32 GSSAPI_LIB_FUNCTION gss_init_sec_context_input (OM_uint32 * /*minor_status*/, const gss_cred_id_t /*initiator_cred_handle*/, gss_ctx_id_t * /*context_handle*/, const gss_name_t /*target_name*/, const gss_OID /*mech_type*/, OM_uint32 /*req_flags*/, OM_uint32 /*time_req*/, const gss_channel_bindings_t /*input_chan_bindings*/, const gss_buffer_t /*input_token*/, gss_async_cookie_t * /* cookie */ ); OM_uint32 GSSAPI_LIB_FUNCTION gss_init_sec_context_output (OM_uint32 * /*minor_status*/, gss_OID * /*actual_mech_type*/, gss_buffer_t /*output_token*/, OM_uint32 * /*ret_flags*/, OM_uint32 * /*time_rec*/, gss_async_cookie_t * /* cookie */ ); If the gss_init_sec_context implementation has finished the work it notifies the callback that it's done. But to get the actual results the caller needs to call the gss_init_sec_context_async() function again (or the gss_init_sec_context_output() function) and pass the same async cookie. I think something like this would make the api at least useful for Samba.= metze --------------enigE3E9B306C1811C6AE63D5039 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKniLdm70gjA5TCD8RAumCAKDNs93KoGQiNyHdW7K12enzrC6PxgCfXpd9 opHOyPpxMCRiLiVbpbhQ0DA= =oMZR -----END PGP SIGNATURE----- --------------enigE3E9B306C1811C6AE63D5039-- From miallen@ioplex.com Wed Sep 2 02:17:17 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 817463A6817 for ; Wed, 2 Sep 2009 02:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id def46w5zt43Q for ; Wed, 2 Sep 2009 02:17:16 -0700 (PDT) Received: from mail.ioplex.com (li31-113.members.linode.com [207.192.69.113]) by core3.amsl.com (Postfix) with ESMTP id 9B2E43A680E for ; Wed, 2 Sep 2009 02:17:16 -0700 (PDT) Received: from proton.foo.net (pool-71-187-189-103.nwrknj.fios.verizon.net [71.187.189.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: miallen) by mail.ioplex.com (Postfix) with ESMTP id 1D185411DC; Wed, 2 Sep 2009 03:10:05 -0400 (EDT) Date: Wed, 2 Sep 2009 03:10:04 -0400 From: Michael B Allen To: Love =?ISO-8859-1?Q?H=F6rnquist_=C5strand?= Subject: Re: KITTEN: IETF 75 - 76 Message-Id: <20090902031004.0ea2f93c.miallen@ioplex.com> In-Reply-To: References: <4A87A69A.3050408@sun.com> <4A87E02D.7030503@isode.com> <200908180013.29152.leifj@mnt.se> <20090901131202.137bdd90.miallen@ioplex.com> <20090901173110.GL1033@Sun.COM> <396484EF-9812-40CE-9221-F1A1319FD10B@kth.se> <20090901181307.fe1d4efa.miallen@ioplex.com> <98F14484-1B48-45A1-86E7-5E78383F5109@kth.se> <20090901214059.17a309e6.miallen@ioplex.com> Organization: IOPLEX Software X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.12; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" , Nicolas Williams X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 09:17:17 -0000 On Tue, 1 Sep 2009 22:21:57 -0700 Love H=F6rnquist =C5strand wrote: >=20 > 1 sep 2009 kl. 18:40 skrev Michael B Allen: >=20 > > But the caller now knows that the function needs to be called again =20 > > to complete the operation. >=20 > so consumer got to poll the library, that is no got from the =20 > performance view. Actually now that I think about it I only use the NOWAIT flag technique for= client oriented routines. For example, if you wanted to perform 10 HTTP re= quests in parallel, you could use the NOWAIT flag to initiate the requests = and then not use NOWAIT when collecting the responses. If someone wanted to use async for an event loop (a single thread / process= handling an arbitrary number of contexts concurrently) then the NOWAIT fla= g technique by itself would indeed require polling and would be inefficient. However, if the caller had access to the underlying polling routine (like t= hrough a "gss_process_events" function that called select or whatever), the= n the caller could know if the status of *any* operation had changed and th= us polling would not be required. The benefit of doing this would be that a= single thread / process could be used to do everything. Mike --=20 Michael B Allen Java Active Directory Integration http://www.ioplex.com/ From lha@kth.se Wed Sep 2 02:34:11 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 006323A63CB for ; Wed, 2 Sep 2009 02:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yr51MphMxujS for ; Wed, 2 Sep 2009 02:34:10 -0700 (PDT) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id 41A903A67AC for ; Wed, 2 Sep 2009 02:34:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 40CCE1558ED; Wed, 2 Sep 2009 07:22:37 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([127.0.0.1]) by localhost (smtp-1.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jvx8WYmTAEq7; Wed, 2 Sep 2009 07:22:32 +0200 (CEST) X-KTH-Auth: lha [2002:6334:ca6c:0:21e:c2ff:fec5:249f] Received: from [IPv6:2002:6334:ca6c::21e:c2ff:fec5:249f] (unknown [IPv6:2002:6334:ca6c:0:21e:c2ff:fec5:249f]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 6AC5A1557D3; Wed, 2 Sep 2009 07:22:29 +0200 (CEST) Subject: Re: KITTEN: IETF 75 - 76 Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-Reply-To: <20090901214059.17a309e6.miallen@ioplex.com> Date: Tue, 1 Sep 2009 22:21:57 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <4A87A69A.3050408@sun.com> <4A87E02D.7030503@isode.com> <200908180013.29152.leifj@mnt.se> <20090901131202.137bdd90.miallen@ioplex.com> <20090901173110.GL1033@Sun.COM> <396484EF-9812-40CE-9221-F1A1319FD10B@kth.se> <20090901181307.fe1d4efa.miallen@ioplex.com> <98F14484-1B48-45A1-86E7-5E78383F5109@kth.se> <20090901214059.17a309e6.miallen@ioplex.com> To: Michael B Allen X-Mailer: Apple Mail (2.1075.2) Cc: "kitten@ietf.org" , Nicolas Williams X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 09:34:11 -0000 1 sep 2009 kl. 18:40 skrev Michael B Allen: > But the caller now knows that the function needs to be called again > to complete the operation. so consumer got to poll the library, that is no got from the performance view. Love From Nicolas.Williams@sun.com Wed Sep 2 08:45:47 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EC4328C12E for ; Wed, 2 Sep 2009 08:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[AWL=-0.955, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MANGLED_AVOID=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNdJzBvZ3jFg for ; Wed, 2 Sep 2009 08:45:46 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 6793328C0CF for ; Wed, 2 Sep 2009 08:45:45 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n82FhcUE017920 for ; Wed, 2 Sep 2009 15:43:38 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n82FhbTq016664 for ; Wed, 2 Sep 2009 09:43:37 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n82FWheO009101; Wed, 2 Sep 2009 10:32:43 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n82FWfHl009100; Wed, 2 Sep 2009 10:32:41 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 2 Sep 2009 10:32:41 -0500 From: Nicolas Williams To: "Stefan (metze) Metzmacher" Subject: Re: KITTEN: IETF 75 - 76 Message-ID: <20090902153241.GJ1033@Sun.COM> References: <4A87A69A.3050408@sun.com> <4A87E02D.7030503@isode.com> <200908180013.29152.leifj@mnt.se> <20090901131202.137bdd90.miallen@ioplex.com> <20090901173110.GL1033@Sun.COM> <396484EF-9812-40CE-9221-F1A1319FD10B@kth.se> <20090901181307.fe1d4efa.miallen@ioplex.com> <98F14484-1B48-45A1-86E7-5E78383F5109@kth.se> <20090901214059.17a309e6.miallen@ioplex.com> <4A9E22D9.9050405@samba.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A9E22D9.9050405@samba.org> User-Agent: Mutt/1.5.7i Cc: "kitten@ietf.org" , Volker Lendecke X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 15:45:47 -0000 On Wed, Sep 02, 2009 at 09:46:33AM +0200, Stefan (metze) Metzmacher wrote: > Michael B Allen schrieb: > > When you call the function with the flag GSS_C_NOWAIT, the > > implementation transmits the network request [1] and then checks to > > see if data can be read (such as by using select(2)). If data is not > > available, the function simply returns a status of EAGAIN. Now the > > caller is free to perform other work (and thus it is async). But the > > caller now knows that the function needs to be called again to > > complete the operation. So later, it calls the function again. If > > the network response has been received, it returns success. > > Otherwise, if GSS_C_NOWAIT was supplied, it again returns EAGAIN. If > > GSS_C_NOWAIT was not supplied, it waits for the operation to > > complete (e.g. for a network response to be received) just like the > > non-async call. In fact async and non-async uses the same function - > > the GSS_C_NOWAIT flag alone controls async behavior. > > That is true for system calls like send() and recv(), where the caller > is supposed to call select. But for gssapi the caller would have to poll > like this: > > while (1) { > > ret = gss_call(&minor, ...); > if (ret != 0 && minor == EAGAIN) { > continue; > } > ... > break; > } > > Or the application needs to try every few milli seconds... Absolutely no polling. Async I/O is not rocket science. We can quibble over details, but we've only got so many workable models. And we have to be mindful that not one model will result in fully portable application code. Here are some reasonable models: - Completion callback (or, rather, a callback indicating that there's work to do, not necessarily completion) This implies either a threaded process model or an async I/O process model with one common event loop provided by the OS. This model is the simplest for apps to use, and it will be portable to Linux, *BSD, Solaris, Windows. But not necessarily to embedded devices, real-time OSes, etc... - Return handles to I/O resources that the app can feed into its event loop. This is much more OS-specific. On Unix/Unix-like OSes this means returning an array of file descriptors. On Windows it means returning and array of file handles. This too may not be terribly portable. And it requires that the application plug the returned resources into its event loop, and take them out, on every call to these GSS functions. I much prefer the callback model. It will yield the most portable and simplest code, even if it does not yield universally portable code. > If the gss_init_sec_context implementation has finished the work > it notifies the callback that it's done. But to get the actual results > the caller needs to call the gss_init_sec_context_async() function again > (or the gss_init_sec_context_output() function) and pass the same async > cookie. The partially established context argument is suitable for use as a "cookie", therefore we don't need an extra cookie. Callers of GISC and GASC today already have to ensure they're using all the same input arguments (except for input tokens, of course), on every call related to one security context establishement. Therefore it seems to me that it's not much to ask that async callers do the same. That means we can keep the callback prototype simple: it should take one, at most two, arguments: a void * private data argument, and possibly the "cookie" that you mention, which in this case would be the partially established security context. > I think something like this would make the api at least useful for Samba. Anything that will actually work will, indeed, be useful to Samba. Note that Samba can implement such a thing _now_ by using a worker thread. From miallen@ioplex.com Wed Sep 2 14:24:54 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1A3E3A6AE1 for ; Wed, 2 Sep 2009 14:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1f0DoJ5yqtYv for ; Wed, 2 Sep 2009 14:24:53 -0700 (PDT) Received: from mail.ioplex.com (li31-113.members.linode.com [207.192.69.113]) by core3.amsl.com (Postfix) with ESMTP id 7FFB93A70FA for ; Wed, 2 Sep 2009 14:21:27 -0700 (PDT) Received: from proton.foo.net (pool-71-187-189-103.nwrknj.fios.verizon.net [71.187.189.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: miallen) by mail.ioplex.com (Postfix) with ESMTP id 89044411DC; Wed, 2 Sep 2009 17:20:15 -0400 (EDT) Date: Wed, 2 Sep 2009 17:20:15 -0400 From: Michael B Allen To: Nicolas Williams Subject: Re: KITTEN: IETF 75 - 76 Message-Id: <20090902172015.da056c19.miallen@ioplex.com> In-Reply-To: <20090902153241.GJ1033@Sun.COM> References: <4A87A69A.3050408@sun.com> <4A87E02D.7030503@isode.com> <200908180013.29152.leifj@mnt.se> <20090901131202.137bdd90.miallen@ioplex.com> <20090901173110.GL1033@Sun.COM> <396484EF-9812-40CE-9221-F1A1319FD10B@kth.se> <20090901181307.fe1d4efa.miallen@ioplex.com> <98F14484-1B48-45A1-86E7-5E78383F5109@kth.se> <20090901214059.17a309e6.miallen@ioplex.com> <4A9E22D9.9050405@samba.org> <20090902153241.GJ1033@Sun.COM> Organization: IOPLEX Software X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.12; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" , Love, Volker Lendecke X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 21:24:54 -0000 On Wed, 2 Sep 2009 10:32:41 -0500 Nicolas Williams wrote: > Absolutely no polling. > > Async I/O is not rocket science. We can quibble over details, but we've > only got so many workable models. And we have to be mindful that not > one model will result in fully portable application code. > > Here are some reasonable models: > > - Completion callback (or, rather, a callback indicating that there's > work to do, not necessarily completion) > > This implies either a threaded process model or an async I/O process > model with one common event loop provided by the OS. > > This model is the simplest for apps to use, and it will be portable > to Linux, *BSD, Solaris, Windows. But not necessarily to embedded > devices, real-time OSes, etc... > > - Return handles to I/O resources that the app can feed into its event > loop. > > This is much more OS-specific. On Unix/Unix-like OSes this means > returning an array of file descriptors. On Windows it means > returning and array of file handles. This too may not be terribly > portable. And it requires that the application plug the returned > resources into its event loop, and take them out, on every call to > these GSS functions. There is another model: > > while (1) { gss_process_events(&minor, ...); > > > > ret = gss_call(&minor, GSS_C_NOWAIT, ...); > > if (ret != 0 && minor == EAGAIN) { > > continue; > > } > > ... > > break; > > } The gss_process_events function would power the mechanism's event loop and wait for the status of an operation to change. Basically it would just call an implementation specific event loop without the 'loop'. So there is no callback, it is not polling and it would be portable to pretty much any system because it does not require multiple threads / processes. You could juggle many GSS contexts with a single thread / process without breaking a sweat. Note that I'm not necessarily advocating this technique. Currently I actually do something quite different for event loop stuff which seems to be the use-case we're talking about. There might be some horrendous flaw with it but I can't think of one at the moment. Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ From Nicolas.Williams@Sun.COM Wed Sep 2 15:54:28 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5FB73A6C86 for ; Wed, 2 Sep 2009 15:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.839 X-Spam-Level: X-Spam-Status: No, score=-5.839 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqRpS1j+os0I for ; Wed, 2 Sep 2009 15:54:28 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 4FA5B3A6CD5 for ; Wed, 2 Sep 2009 15:54:27 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n82LbnOY015938 for ; Wed, 2 Sep 2009 21:37:49 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n82Lbmdh037669 for ; Wed, 2 Sep 2009 15:37:48 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n82LQsR8009433; Wed, 2 Sep 2009 16:26:54 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n82LQqu6009432; Wed, 2 Sep 2009 16:26:52 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 2 Sep 2009 16:26:52 -0500 From: Nicolas Williams To: Michael B Allen Subject: Re: KITTEN: IETF 75 - 76 Message-ID: <20090902212652.GX1033@Sun.COM> References: <200908180013.29152.leifj@mnt.se> <20090901131202.137bdd90.miallen@ioplex.com> <20090901173110.GL1033@Sun.COM> <396484EF-9812-40CE-9221-F1A1319FD10B@kth.se> <20090901181307.fe1d4efa.miallen@ioplex.com> <98F14484-1B48-45A1-86E7-5E78383F5109@kth.se> <20090901214059.17a309e6.miallen@ioplex.com> <4A9E22D9.9050405@samba.org> <20090902153241.GJ1033@Sun.COM> <20090902172015.da056c19.miallen@ioplex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090902172015.da056c19.miallen@ioplex.com> User-Agent: Mutt/1.5.7i Cc: "kitten@ietf.org" , Volker Lendecke X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 22:54:28 -0000 On Wed, Sep 02, 2009 at 05:20:15PM -0400, Michael B Allen wrote: > There is another model: > > > > while (1) { > gss_process_events(&minor, ...); > > > ... The problem with this model is that it has the GSS-API impose its own event loop on the application. Imagine if every library did that! An application that uses multiple such libraries, where some such libraries use other such libraries, would be very difficult to get to work at all, particularly without threading or sub-processes. I don't understand your aversion to callbacks. Callbacks are exceedingly common in C APIs nowadays, and that's a good thing, IMO. Nico -- From miallen@ioplex.com Wed Sep 2 21:43:35 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B90593A690B for ; Wed, 2 Sep 2009 21:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wt7IzaUvLpN for ; Wed, 2 Sep 2009 21:43:29 -0700 (PDT) Received: from mail.ioplex.com (li31-113.members.linode.com [207.192.69.113]) by core3.amsl.com (Postfix) with ESMTP id A72183A6AF7 for ; Wed, 2 Sep 2009 21:43:26 -0700 (PDT) Received: from proton.foo.net (pool-71-187-189-103.nwrknj.fios.verizon.net [71.187.189.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: miallen) by mail.ioplex.com (Postfix) with ESMTP id 27179411FF; Wed, 2 Sep 2009 21:12:00 -0400 (EDT) Date: Wed, 2 Sep 2009 21:12:00 -0400 From: Michael B Allen To: Nicolas Williams Subject: Re: KITTEN: IETF 75 - 76 Message-Id: <20090902211200.8a2dd378.miallen@ioplex.com> In-Reply-To: <20090902212652.GX1033@Sun.COM> References: <200908180013.29152.leifj@mnt.se> <20090901131202.137bdd90.miallen@ioplex.com> <20090901173110.GL1033@Sun.COM> <396484EF-9812-40CE-9221-F1A1319FD10B@kth.se> <20090901181307.fe1d4efa.miallen@ioplex.com> <98F14484-1B48-45A1-86E7-5E78383F5109@kth.se> <20090901214059.17a309e6.miallen@ioplex.com> <4A9E22D9.9050405@samba.org> <20090902153241.GJ1033@Sun.COM> <20090902172015.da056c19.miallen@ioplex.com> <20090902212652.GX1033@Sun.COM> Organization: IOPLEX Software X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.12; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" , Love, Volker Lendecke X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 04:43:35 -0000 On Wed, 2 Sep 2009 16:26:52 -0500 Nicolas Williams wrote: > On Wed, Sep 02, 2009 at 05:20:15PM -0400, Michael B Allen wrote: > > There is another model: > > > > > > while (1) { > > gss_process_events(&minor, ...); > > > > ... > > The problem with this model is that it has the GSS-API impose its own > event loop on the application. Imagine if every library did that! An > application that uses multiple such libraries, where some such libraries > use other such libraries, would be very difficult to get to work at all, > particularly without threading or sub-processes. > > I don't understand your aversion to callbacks. Callbacks are > exceedingly common in C APIs nowadays, and that's a good thing, IMO. I think you're exaggerating, if not misrepresenting, the detractions of the NOWAIT flag technique. But it is no matter. For a variety of reasons I will not pursue the issue further. However, before I go back to lurking, I have to declare that callbacks are NOT simple. They can be quite complicated. Just from looking at function signatures posted in this thread I personally have no idea how these callbacks would actually work. Are they called by another thread, by a signal, through another call or by another caller? Is locking required? What data is safe to modify in the callback? They seem C oriented - do the semantics change if a different language is used like Java? Hopefully the answers to these questions will be clear if these callbacks do end up in a GSSAPI implementations. Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ From jhutz@cmu.edu Thu Sep 3 07:40:44 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBE723A6B4B for ; Thu, 3 Sep 2009 07:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5esPJ36YtW3T for ; Thu, 3 Sep 2009 07:40:42 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 871F43A6924 for ; Thu, 3 Sep 2009 07:40:42 -0700 (PDT) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n83EcnCX019829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Sep 2009 10:38:49 -0400 (EDT) Date: Thu, 03 Sep 2009 10:38:49 -0400 From: Jeffrey Hutzelman To: Michael B Allen , Nicolas Williams Subject: Re: KITTEN: IETF 75 - 76 Message-ID: In-Reply-To: <24246_1251926735_n82LPYA9008569_20090902172015.da056c19.miallen@ioplex.com> References: <4A87A69A.3050408@sun.com> <4A87E02D.7030503@isode.com> <200908180013.29152.leifj@mnt.se> <20090901131202.137bdd90.miallen@ioplex.com> <20090901173110.GL1033@Sun.COM> <396484EF-9812-40CE-9221-F1A1319FD10B@kth.se> <20090901181307.fe1d4efa.miallen@ioplex.com> <98F14484-1B48-45A1-86E7-5E78383F5109@kth.se> <20090901214059.17a309e6.miallen@ioplex.com> <4A9E22D9.9050405@samba.org> <20090902153241.GJ1033@Sun.COM> <24246_1251926735_n82LPYA9008569_20090902172015.da056c19.miallen@ioplex.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: kitten@ietf.org, Love@core3.amsl.com, Volker Lendecke , jhutz@cmu.edu X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 14:40:44 -0000 --On Wednesday, September 02, 2009 05:20:15 PM -0400 Michael B Allen wrote: > On Wed, 2 Sep 2009 10:32:41 -0500 > Nicolas Williams wrote: >> Absolutely no polling. >> >> Async I/O is not rocket science. We can quibble over details, but we've >> only got so many workable models. And we have to be mindful that not >> one model will result in fully portable application code. >> >> Here are some reasonable models: >> >> - Completion callback (or, rather, a callback indicating that there's >> work to do, not necessarily completion) >> >> This implies either a threaded process model or an async I/O process >> model with one common event loop provided by the OS. >> >> This model is the simplest for apps to use, and it will be portable >> to Linux, *BSD, Solaris, Windows. But not necessarily to embedded >> devices, real-time OSes, etc... >> >> - Return handles to I/O resources that the app can feed into its event >> loop. >> >> This is much more OS-specific. On Unix/Unix-like OSes this means >> returning an array of file descriptors. On Windows it means >> returning and array of file handles. This too may not be terribly >> portable. And it requires that the application plug the returned >> resources into its event loop, and take them out, on every call to >> these GSS functions. > > There is another model: > >> > while (1) { > gss_process_events(&minor, ...); >> > >> > ret = gss_call(&minor, GSS_C_NOWAIT, ...); >> > if (ret != 0 && minor == EAGAIN) { >> > continue; >> > } >> > ... >> > break; >> > } That's not another model. That's equivalent to using the synchronous form of the call, if gss_process_events() blocks until the mech is ready to be called, or to polling, if it eventually times out. From Nicolas.Williams@sun.com Thu Sep 3 08:48:42 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D55CF3A6BFB for ; Thu, 3 Sep 2009 08:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ip2Rxjj50Lv5 for ; Thu, 3 Sep 2009 08:48:41 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id ACECE3A696B for ; Thu, 3 Sep 2009 08:48:40 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n83FbZDc012784 for ; Thu, 3 Sep 2009 15:37:35 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n83FbYNM042005 for ; Thu, 3 Sep 2009 09:37:34 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n83FQebU009844; Thu, 3 Sep 2009 10:26:40 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n83FQcuN009843; Thu, 3 Sep 2009 10:26:38 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 3 Sep 2009 10:26:38 -0500 From: Nicolas Williams To: Michael B Allen Subject: Re: KITTEN: IETF 75 - 76 Message-ID: <20090903152638.GH1033@Sun.COM> References: <20090901173110.GL1033@Sun.COM> <396484EF-9812-40CE-9221-F1A1319FD10B@kth.se> <20090901181307.fe1d4efa.miallen@ioplex.com> <98F14484-1B48-45A1-86E7-5E78383F5109@kth.se> <20090901214059.17a309e6.miallen@ioplex.com> <4A9E22D9.9050405@samba.org> <20090902153241.GJ1033@Sun.COM> <20090902172015.da056c19.miallen@ioplex.com> <20090902212652.GX1033@Sun.COM> <20090902211200.8a2dd378.miallen@ioplex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090902211200.8a2dd378.miallen@ioplex.com> User-Agent: Mutt/1.5.7i Cc: "kitten@ietf.org" , Volker Lendecke X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 15:48:42 -0000 On Wed, Sep 02, 2009 at 09:12:00PM -0400, Michael B Allen wrote: > On Wed, 2 Sep 2009 16:26:52 -0500 > Nicolas Williams wrote: > > The problem with this model is that it has the GSS-API impose its own > > event loop on the application. Imagine if every library did that! An > > application that uses multiple such libraries, where some such libraries > > use other such libraries, would be very difficult to get to work at all, > > particularly without threading or sub-processes. > > > > I don't understand your aversion to callbacks. Callbacks are > > exceedingly common in C APIs nowadays, and that's a good thing, IMO. > > I think you're exaggerating, if not misrepresenting, the detractions > of the NOWAIT flag technique. But it is no matter. For a variety of > reasons I will not pursue the issue further. I have worked on applications that use over half a dozen layered components, at least two of which need to do blocking I/O operations, plus the application itself being async I/O event driven. Putting together such an application with your async I/O model would result in an enormous amount of complication. I'd much rather have the library give me either file descriptors to select on, or a callback. > However, before I go back to lurking, I have to declare that callbacks > are NOT simple. They can be quite complicated. Just from looking at > function signatures posted in this thread I personally have no idea > how these callbacks would actually work. Are they called by another > thread, by a signal, through another call or by another caller? Is > locking required? What data is safe to modify in the callback? They > seem C oriented - do the semantics change if a different language is > used like Java? Hopefully the answers to these questions will be clear > if these callbacks do end up in a GSSAPI implementations. Callbacks are simple (and the ones I proposed certainly are). One should specify the calling context, as you point out. To be most portable we should say that callback functions must be async-signal- safe, which means that callback functions should limit themselves to: signalling condition variables, writing to a pipe, or otherwise posting an event to another event loop. Nico -- From Nicolas.Williams@sun.com Thu Sep 3 09:20:11 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5614B3A6D64 for ; Thu, 3 Sep 2009 09:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.846 X-Spam-Level: X-Spam-Status: No, score=-5.846 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOs3-dK1oKva for ; Thu, 3 Sep 2009 09:20:09 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id 3F6363A6D8B for ; Thu, 3 Sep 2009 09:20:02 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n83FvCUq006899 for ; Thu, 3 Sep 2009 15:57:12 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n83FvB4J057010 for ; Thu, 3 Sep 2009 09:57:11 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n83FVH9Q009850; Thu, 3 Sep 2009 10:31:17 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n83FVGUa009849; Thu, 3 Sep 2009 10:31:16 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 3 Sep 2009 10:31:16 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Subject: Re: KITTEN: IETF 75 - 76 Message-ID: <20090903153116.GI1033@Sun.COM> References: <396484EF-9812-40CE-9221-F1A1319FD10B@kth.se> <20090901181307.fe1d4efa.miallen@ioplex.com> <98F14484-1B48-45A1-86E7-5E78383F5109@kth.se> <20090901214059.17a309e6.miallen@ioplex.com> <4A9E22D9.9050405@samba.org> <20090902153241.GJ1033@Sun.COM> <20090902172015.da056c19.miallen@ioplex.com> <20090902212652.GX1033@Sun.COM> <395_1251953035_n834hs6R012125_20090902211200.8a2dd378.miallen@ioplex.com> <0AB8FDC38BE7B55EB358D7FA@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0AB8FDC38BE7B55EB358D7FA@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.5.7i Cc: kitten@ietf.org, Love@core3.amsl.com, Volker Lendecke X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 16:20:11 -0000 On Thu, Sep 03, 2009 at 10:45:01AM -0400, Jeffrey Hutzelman wrote: > Really, I think we have three options here: > > 1) Assume POSIX threads(*). > 2) Assume POSIX threads(*), but allow the existence of an implementation > dependent means of indicating use of some other threading model. (2) is feasible. You simply provide completion callbacks and say that they must be async-signal-safe. > 3) Recognize that there is no sane way to provide an portable async API > without either a portable threading model or a portable event model, > and give up. Applications which want to call the GSS-API in an > asynchronous manner can simulate it by running the GSS-API call in > its own thread (under a platform-specific thread model). 4) Assume file descriptors and one or more of poll(), select(), /dev/poll, kevent, event ports, ... Since (3) works today I'm very tempted to do nothing. > (*) This means "you can't have this API unless you have threads". > Unfortunately, it also means we're in the unenviable position of pushing > an API which requires the use of threads but is not itself MT-safe. The GSS-API is not inherently MT-unsafe. Its MT-safety is not defined -- _that_ is a problem. (Should one lock around per-msg token functions called with the same security context handle?) Nico -- From Nicolas.Williams@sun.com Thu Sep 3 09:33:45 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD67B28C4E1 for ; Thu, 3 Sep 2009 09:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.85 X-Spam-Level: X-Spam-Status: No, score=-5.85 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3jlNYlqahz5 for ; Thu, 3 Sep 2009 09:33:45 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 4F5DB28C55D for ; Thu, 3 Sep 2009 09:31:32 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n83GVJdx004922 for ; Thu, 3 Sep 2009 16:31:19 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n83GVIGZ018366 for ; Thu, 3 Sep 2009 10:31:19 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n83G5O0q009884; Thu, 3 Sep 2009 11:05:24 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n83G5O54009883; Thu, 3 Sep 2009 11:05:24 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 3 Sep 2009 11:05:23 -0500 From: Nicolas Williams To: Volker Lendecke Subject: Re: KITTEN: IETF 75 - 76 Message-ID: <20090903160523.GM1033@Sun.COM> References: <20090901181307.fe1d4efa.miallen@ioplex.com> <98F14484-1B48-45A1-86E7-5E78383F5109@kth.se> <20090901214059.17a309e6.miallen@ioplex.com> <4A9E22D9.9050405@samba.org> <20090902153241.GJ1033@Sun.COM> <20090902172015.da056c19.miallen@ioplex.com> <20090902212652.GX1033@Sun.COM> <395_1251953035_n834hs6R012125_20090902211200.8a2dd378.miallen@ioplex.com> <0AB8FDC38BE7B55EB358D7FA@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: kitten@ietf.org, Love@core3.amsl.com, Volker Lendecke , Jeffrey Hutzelman X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 16:33:45 -0000 On Thu, Sep 03, 2009 at 05:43:11PM +0200, Volker Lendecke wrote: > Sorry to step in here, but there's tons of example for > portable async APIs. One that I just adapted Samba to is the > API used in the avahi libs. You hand the avahi libs a set of > callback functions like "listen on this fd for read" and so > on, and you are called back by avahi when something > interesting happens. Yes, that too is possible: abstract the application's event loop and export it to libraries. That is complicated and only sightly more portable than just exporting file descriptor lists from the library to the app. > This is definitely doable without the requirement for > threads. It may be a complex API, but async programming > never has been easy. Indeed. I'm not sure we'll ever reach consensus on a single async GSS API. We might have to do more than one, or none at all. Nico -- From jhutz@cmu.edu Thu Sep 3 10:49:37 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 206BA3A679C for ; Thu, 3 Sep 2009 10:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkpiktwyaNeB for ; Thu, 3 Sep 2009 10:49:33 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id CA3A43A6767 for ; Thu, 3 Sep 2009 10:49:29 -0700 (PDT) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n83Ej1mK005748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Sep 2009 10:45:01 -0400 (EDT) Date: Thu, 03 Sep 2009 10:45:01 -0400 From: Jeffrey Hutzelman To: Michael B Allen , Nicolas Williams Subject: Re: KITTEN: IETF 75 - 76 Message-ID: <0AB8FDC38BE7B55EB358D7FA@minbar.fac.cs.cmu.edu> In-Reply-To: <395_1251953035_n834hs6R012125_20090902211200.8a2dd378.miallen@ioplex.com> References: <200908180013.29152.leifj@mnt.se> <20090901131202.137bdd90.miallen@ioplex.com> <20090901173110.GL1033@Sun.COM> <396484EF-9812-40CE-9221-F1A1319FD10B@kth.se> <20090901181307.fe1d4efa.miallen@ioplex.com> <98F14484-1B48-45A1-86E7-5E78383F5109@kth.se> <20090901214059.17a309e6.miallen@ioplex.com> <4A9E22D9.9050405@samba.org> <20090902153241.GJ1033@Sun.COM> <20090902172015.da056c19.miallen@ioplex.com> <20090902212652.GX1033@Sun.COM> <395_1251953035_n834hs6R012125_20090902211200.8a2dd378.miallen@ioplex.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: kitten@ietf.org, Love@core3.amsl.com, Volker Lendecke , jhutz@cmu.edu X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 17:49:37 -0000 --On Wednesday, September 02, 2009 09:12:00 PM -0400 Michael B Allen wrote: > I think you're exaggerating, if not misrepresenting, the detractions of > the NOWAIT flag technique. No, he's not. Nonblocking API's are OK, but there has to be a way to tell when it's time to try the call again, and neither periodic polling nor busy-wait is acceptable. The GSS-API MUST NOT force such wasteful and performance-killing techniques on applications. Really, I think we have three options here: 1) Assume POSIX threads(*). 2) Assume POSIX threads(*), but allow the existence of an implementation dependent means of indicating use of some other threading model. 3) Recognize that there is no sane way to provide an portable async API without either a portable threading model or a portable event model, and give up. Applications which want to call the GSS-API in an asynchronous manner can simulate it by running the GSS-API call in its own thread (under a platform-specific thread model). (*) This means "you can't have this API unless you have threads". Unfortunately, it also means we're in the unenviable position of pushing an API which requires the use of threads but is not itself MT-safe. -- Jeff From miallen@ioplex.com Thu Sep 3 11:53:56 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AF0F3A6804 for ; Thu, 3 Sep 2009 11:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBP569tgfdfN for ; Thu, 3 Sep 2009 11:53:55 -0700 (PDT) Received: from mail.ioplex.com (li31-113.members.linode.com [207.192.69.113]) by core3.amsl.com (Postfix) with ESMTP id 8F5DA3A6826 for ; Thu, 3 Sep 2009 11:53:55 -0700 (PDT) Received: from proton.foo.net (pool-71-187-189-103.nwrknj.fios.verizon.net [71.187.189.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: miallen) by mail.ioplex.com (Postfix) with ESMTP id 1606D411DC; Thu, 3 Sep 2009 11:17:49 -0400 (EDT) Date: Thu, 3 Sep 2009 11:17:49 -0400 From: Michael B Allen To: Jeffrey Hutzelman Subject: Re: KITTEN: IETF 75 - 76 Message-Id: <20090903111749.267187da.miallen@ioplex.com> In-Reply-To: References: <4A87A69A.3050408@sun.com> <4A87E02D.7030503@isode.com> <200908180013.29152.leifj@mnt.se> <20090901131202.137bdd90.miallen@ioplex.com> <20090901173110.GL1033@Sun.COM> <396484EF-9812-40CE-9221-F1A1319FD10B@kth.se> <20090901181307.fe1d4efa.miallen@ioplex.com> <98F14484-1B48-45A1-86E7-5E78383F5109@kth.se> <20090901214059.17a309e6.miallen@ioplex.com> <4A9E22D9.9050405@samba.org> <20090902153241.GJ1033@Sun.COM> <24246_1251926735_n82LPYA9008569_20090902172015.da056c19.miallen@ioplex.com> Organization: IOPLEX Software X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.12; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, Love@core3.amsl.com, Volker Lendecke , Nicolas Williams X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 18:53:56 -0000 On Thu, 03 Sep 2009 10:38:49 -0400 Jeffrey Hutzelman wrote: > > There is another model: > > > >> > while (1) { > > gss_process_events(&minor, ...); > >> > > >> > ret = gss_call(&minor, GSS_C_NOWAIT, ...); > >> > if (ret != 0 && minor == EAGAIN) { > >> > continue; > >> > } > >> > ... > >> > break; > >> > } > > That's not another model. That's equivalent to using the synchronous form > of the call, if gss_process_events() blocks until the mech is ready to be > called, or to polling, if it eventually times out. But there only needs to be one caller of gss_process_events for any number of NOWAIT calls. So you can build event loops with it. I'm not sure I understand the callback model being discussed but it seems to be an event loop powered by a separate thread firing callbacks in response to changes in status of calls. If that is in fact the case, you could build the callback model you're talking about using only the NOWAIT flag model I'm talking about. Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ From Nicolas.Williams@sun.com Thu Sep 3 13:47:23 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C11AE3A6957 for ; Thu, 3 Sep 2009 13:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.848 X-Spam-Level: X-Spam-Status: No, score=-5.848 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzbXMcNjFkNT for ; Thu, 3 Sep 2009 13:47:22 -0700 (PDT) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id D71F33A6872 for ; Thu, 3 Sep 2009 13:47:17 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n83K3J6N020022 for ; Thu, 3 Sep 2009 20:03:32 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n83K3JuM039609 for ; Thu, 3 Sep 2009 14:03:19 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n83JbNMV010197; Thu, 3 Sep 2009 14:37:23 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n83JbMgf010196; Thu, 3 Sep 2009 14:37:22 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 3 Sep 2009 14:37:22 -0500 From: Nicolas Williams To: Michael B Allen Subject: Re: KITTEN: IETF 75 - 76 Message-ID: <20090903193722.GW1033@Sun.COM> References: <20090901173110.GL1033@Sun.COM> <396484EF-9812-40CE-9221-F1A1319FD10B@kth.se> <20090901181307.fe1d4efa.miallen@ioplex.com> <98F14484-1B48-45A1-86E7-5E78383F5109@kth.se> <20090901214059.17a309e6.miallen@ioplex.com> <4A9E22D9.9050405@samba.org> <20090902153241.GJ1033@Sun.COM> <24246_1251926735_n82LPYA9008569_20090902172015.da056c19.miallen@ioplex.com> <20090903111749.267187da.miallen@ioplex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090903111749.267187da.miallen@ioplex.com> User-Agent: Mutt/1.5.7i Cc: kitten@ietf.org, Love@core3.amsl.com, Volker Lendecke , Jeffrey Hutzelman X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 20:47:23 -0000 On Thu, Sep 03, 2009 at 11:17:49AM -0400, Michael B Allen wrote: > On Thu, 03 Sep 2009 10:38:49 -0400 > Jeffrey Hutzelman wrote: > > > There is another model: > > > > > >> > while (1) { > > > gss_process_events(&minor, ...); > > >> > > > >> > ret = gss_call(&minor, GSS_C_NOWAIT, ...); > > >> > if (ret != 0 && minor == EAGAIN) { > > >> > continue; > > >> > } > > >> > ... > > >> > break; > > >> > } > > > > That's not another model. That's equivalent to using the synchronous form > > of the call, if gss_process_events() blocks until the mech is ready to be > > called, or to polling, if it eventually times out. > > But there only needs to be one caller of gss_process_events for any > number of NOWAIT calls. So you can build event loops with it. I'm not > sure I understand the callback model being discussed but it seems to > be an event loop powered by a separate thread firing callbacks in > response to changes in status of calls. If that is in fact the case, > you could build the callback model you're talking about using only the > NOWAIT flag model I'm talking about. It may be reasonable to have libraries use an externally provided event API (an alternative offered by Volker Lendecke). (A callback model with async-signal-safe callback functions will effectively do just that.) It is not reasonable to have libraries provide an event loop for applications to use. The reason is as I've explained before. Try putting together an application (and libraries) that uses: - an LDAP library, which uses a SASL library, which, through a plug-in, uses a GSS-API library, and through the GSS-API there's the Kerberos V5 GSS-API mechanism, which in turn might use a pluggable crypto lubrary, ... - also uses the GSS-API/SASL/crypto directly and independently of the LDAP library Now, just for fun, add PKCROSS into the picture, deep in the bowels of the krb5 mech. If each library wants to have its own event loop then each one had better provide a way for the caller to use that event loop for other purposes, else there's no way to construct such an application and libraries without resorting to threads. Now say that each library does provide a way for the caller to use the library's event loop, then each layer in the above stack will have to do just that. Once you've built that monstrosity there'll only be one thing left to do: debug it! ;) That kind of complexity is a non-starter. It's much easier to just wrap a thread around any synchronous and slow operation that I want made asynchronous. Still, if you want to write an Internet-Draft outlining your proposal, we'll review it. Nico -- From jhutz@cmu.edu Thu Sep 3 14:43:02 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 342993A682F for ; Thu, 3 Sep 2009 14:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8te1CB3oebja for ; Thu, 3 Sep 2009 14:43:00 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 11C403A6934 for ; Thu, 3 Sep 2009 14:42:57 -0700 (PDT) Received: from atlantis-home.pc.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n83Kts0A027770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Sep 2009 16:55:54 -0400 (EDT) Date: Thu, 03 Sep 2009 16:55:54 -0400 From: Jeffrey Hutzelman To: Michael B Allen Subject: Re: KITTEN: IETF 75 - 76 Message-ID: In-Reply-To: <21582_1252004057_n83IsGex029266_20090903111749.267187da.miallen@ioplex.com> References: <4A87A69A.3050408@sun.com> <4A87E02D.7030503@isode.com> <200908180013.29152.leifj@mnt.se> <20090901131202.137bdd90.miallen@ioplex.com> <20090901173110.GL1033@Sun.COM> <396484EF-9812-40CE-9221-F1A1319FD10B@kth.se> <20090901181307.fe1d4efa.miallen@ioplex.com> <98F14484-1B48-45A1-86E7-5E78383F5109@kth.se> <20090901214059.17a309e6.miallen@ioplex.com> <4A9E22D9.9050405@samba.org> <20090902153241.GJ1033@Sun.COM> <24246_1251926735_n82LPYA9008569_20090902172015.da056c19.miallen@ioplex.com> <21582_1252004057_n83IsGex029266_20090903111749.267187da.miallen@ioplex.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: kitten@ietf.org, Love@core3.amsl.com, Volker Lendecke , Nicolas Williams , jhutz@cmu.edu X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 21:43:02 -0000 --On Thursday, September 03, 2009 11:17:49 AM -0400 Michael B Allen wrote: > On Thu, 03 Sep 2009 10:38:49 -0400 > Jeffrey Hutzelman wrote: >> > There is another model: >> > >> >> > while (1) { >> > gss_process_events(&minor, ...); >> >> > >> >> > ret = gss_call(&minor, GSS_C_NOWAIT, ...); >> >> > if (ret != 0 && minor == EAGAIN) { >> >> > continue; >> >> > } >> >> > ... >> >> > break; >> >> > } >> >> That's not another model. That's equivalent to using the synchronous >> form of the call, if gss_process_events() blocks until the mech is >> ready to be called, or to polling, if it eventually times out. > > But there only needs to be one caller of gss_process_events for any > number of NOWAIT calls. So you can build event loops with it. No, you really can't. Sure, if your goal is to establish six contexts simultaneously and then go on to something else, you can do that. But if your goal is to establish one context while still allowing PalmOS to interact with the user, this doesn't cut it. In fact, that's not entirely fair, because in that model you can't have threads _or_ asynchronous callbacks -- the library's only choice would be to send the application an event when its ready for another call. But the point still holds -- if you give me an interface that blocks until it's ready, then I can't run my own event loop, and if you give me an interface that I have to poll, then I'm polling, not running an event loop. A proper event loop blocks until there is an event (_any_ event), then does some work. Polling is not an event loop. Polling wastes cycles and can result in serious increases in power use besides. Not to mention all of the points Nico has made with respect to the complexities of an API trying to impose an event model on an application with several intermediate libraries in between. -- Jeffrey T. Hutzelman (N3NHS) Carnegie Mellon University - Pittsburgh, PA From Volker.Lendecke@SerNet.DE Thu Sep 3 13:10:02 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 356CD3A67FB for ; Thu, 3 Sep 2009 13:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4mt6Djmi8MK for ; Thu, 3 Sep 2009 13:10:01 -0700 (PDT) Received: from mail.SerNet.de (mail1.SerNet.de [193.175.80.2]) by core3.amsl.com (Postfix) with ESMTP id 30F923A67C2 for ; Thu, 3 Sep 2009 13:10:00 -0700 (PDT) Received: from intern.SerNet.DE by mail.SerNet.DE with esmtp (Exim 4.63 #1) id 1MjESq-0001XY-Al; Thu, 03 Sep 2009 17:43:08 +0200 Received: by intern.SerNet.DE id 1MjESp-003YOF-Vu; Thu, 03 Sep 2009 17:43:08 +0200 Received: by intern.SerNet.DE id 1MjESp-003YNh-P9; Thu, 03 Sep 2009 17:43:07 +0200 Date: Thu, 3 Sep 2009 17:43:11 +0200 From: Volker Lendecke To: Jeffrey Hutzelman Subject: Re: KITTEN: IETF 75 - 76 References: <396484EF-9812-40CE-9221-F1A1319FD10B@kth.se> <20090901181307.fe1d4efa.miallen@ioplex.com> <98F14484-1B48-45A1-86E7-5E78383F5109@kth.se> <20090901214059.17a309e6.miallen@ioplex.com> <4A9E22D9.9050405@samba.org> <20090902153241.GJ1033@Sun.COM> <20090902172015.da056c19.miallen@ioplex.com> <20090902212652.GX1033@Sun.COM> <395_1251953035_n834hs6R012125_20090902211200.8a2dd378.miallen@ioplex.com> <0AB8FDC38BE7B55EB358D7FA@minbar.fac.cs.cmu.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline In-Reply-To: <0AB8FDC38BE7B55EB358D7FA@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.5.18 (2008-05-17) Message-Id: Organization: SerNet GmbH, Goettingen, Germany X-Mailman-Approved-At: Thu, 03 Sep 2009 21:45:32 -0700 Cc: kitten@ietf.org, Love@core3.amsl.com, Volker Lendecke , Nicolas Williams X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Volker.Lendecke@SerNet.DE List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 21:37:37 -0000 --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Sep 03, 2009 at 10:45:01AM -0400, Jeffrey Hutzelman wrote: > 1) Assume POSIX threads(*). > 2) Assume POSIX threads(*), but allow the existence of an implementation > dependent means of indicating use of some other threading model. > 3) Recognize that there is no sane way to provide an portable async API > without either a portable threading model or a portable event model, > and give up. Applications which want to call the GSS-API in an > asynchronous manner can simulate it by running the GSS-API call in > its own thread (under a platform-specific thread model). Sorry to step in here, but there's tons of example for portable async APIs. One that I just adapted Samba to is the API used in the avahi libs. You hand the avahi libs a set of callback functions like "listen on this fd for read" and so on, and you are called back by avahi when something interesting happens. This is definitely doable without the requirement for threads. It may be a complex API, but async programming never has been easy. Volker --bg08WKrSYDhXBjb5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqf5A4ACgkQbsgDfmnSbrbohwCeM1Jh6Uo5bcN5xRySkvVzt9wq +a4AoIsG2fM/0ag86z33kzvxpTkOtI4t =X2zg -----END PGP SIGNATURE----- --bg08WKrSYDhXBjb5-- From Volker.Lendecke@SerNet.DE Thu Sep 3 15:08:54 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7516128C120 for ; Thu, 3 Sep 2009 15:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.215 X-Spam-Level: X-Spam-Status: No, score=-6.215 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3w+DiilVLXC for ; Thu, 3 Sep 2009 15:08:53 -0700 (PDT) Received: from mail.SerNet.de (mail1.SerNet.de [193.175.80.2]) by core3.amsl.com (Postfix) with ESMTP id 6A78228C11F for ; Thu, 3 Sep 2009 15:08:52 -0700 (PDT) Received: from intern.SerNet.DE by mail.SerNet.DE with esmtp (Exim 4.63 #1) id 1MjJhZ-0002hm-8O; Thu, 03 Sep 2009 23:18:41 +0200 Received: by intern.SerNet.DE id 1MjJhY-003ouY-EN; Thu, 03 Sep 2009 23:18:41 +0200 Received: by intern.SerNet.DE id 1MjJhY-003ou0-7X; Thu, 03 Sep 2009 23:18:40 +0200 Date: Thu, 3 Sep 2009 23:18:34 +0200 From: Volker Lendecke To: Jeffrey Hutzelman Subject: Re: KITTEN: IETF 75 - 76 References: <396484EF-9812-40CE-9221-F1A1319FD10B@kth.se> <20090901181307.fe1d4efa.miallen@ioplex.com> <98F14484-1B48-45A1-86E7-5E78383F5109@kth.se> <20090901214059.17a309e6.miallen@ioplex.com> <4A9E22D9.9050405@samba.org> <20090902153241.GJ1033@Sun.COM> <24246_1251926735_n82LPYA9008569_20090902172015.da056c19.miallen@ioplex.com> <21582_1252004057_n83IsGex029266_20090903111749.267187da.miallen@ioplex.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Message-Id: Organization: SerNet GmbH, Goettingen, Germany X-Mailman-Approved-At: Thu, 03 Sep 2009 21:46:02 -0700 Cc: kitten@ietf.org, Love@core3.amsl.com, Volker Lendecke , Nicolas Williams X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Volker.Lendecke@SerNet.DE List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 22:08:54 -0000 --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 03, 2009 at 04:55:54PM -0400, Jeffrey Hutzelman wrote: > A proper event loop blocks until there is an event (_any_ event), then=20 > does some work. Polling is not an event loop. Polling wastes cycles and= =20 > can result in serious increases in power use besides. Not to mention all= =20 > of the points Nico has made with respect to the complexities of an API=20 > trying to impose an event model on an application with several=20 > intermediate libraries in between. That's why I pointed at the avahi libs. Samba internally has its own version of an event loop, and it would be outright impossible to adapt that to an event loop from an external lib. Adapting to those avahi libs was really easy for me, given that I have done quite a bit of async programming inside Samba before. There are other samples out there, but many of those (I've looked at some async DNS libs) assume select(2) as the blocking call. This won't work in modern systems anymore that use epoll other more efficient mechanisms. I'm not saying that avahi is the last word in this, but it worked pretty well for me. Internally the libs would use the async calls only, the sync wrappers would then provide a stub event loop around the async calls. That's at least what we do in the native Samba async code. Volker --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkqgMqkACgkQbsgDfmnSbrYXxgCfYIDWAOT2ZzDNB/S7YUvoEDUL ygQAnRajV2yJqIYcQkrjkx2d+cbBBfvH =pXd6 -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs-- From lha@kth.se Sun Sep 13 12:41:33 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E548D3A67EB for ; Sun, 13 Sep 2009 12:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.782 X-Spam-Level: X-Spam-Status: No, score=-3.782 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_40=-0.185, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRWF4q1g7LB1 for ; Sun, 13 Sep 2009 12:41:31 -0700 (PDT) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by core3.amsl.com (Postfix) with ESMTP id AD7433A6868 for ; Sun, 13 Sep 2009 12:41:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 89E7514DC54; Sun, 13 Sep 2009 21:41:43 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([127.0.0.1]) by localhost (smtp-2.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0G6QBAkTI6kt; Sun, 13 Sep 2009 21:41:42 +0200 (CEST) X-KTH-Auth: lha [2002:6334:ca6c:0:21e:c2ff:fec5:249f] Received: from [IPv6:2002:6334:ca6c::21e:c2ff:fec5:249f] (unknown [IPv6:2002:6334:ca6c:0:21e:c2ff:fec5:249f]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 595C514D7CB; Sun, 13 Sep 2009 21:41:40 +0200 (CEST) From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Subject: comments draft-ietf-kitten-gssapi-naming-exts-05.txt Date: Sun, 13 Sep 2009 12:41:08 -0700 Message-Id: To: kitten@ietf.org Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Cc: Leif Johansson , Nicolas Williams X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2009 19:41:33 -0000 name_is_MN is an output variable, the c-bindings define it as an "int" which provides little chance of "out-ness" I really dislike the modifying name attributes, why is that interface needed (usecase ?) The *more trick sucks but I can live with it, it assumes names do no change and that items are iteratable, it also makes mech glue life hard. GSS_Map_name_to_any, the type should be an OID, strings are not used anywhere else and its painful to use, its if really a strings, make it a "const char *" in the c bindings. same goes for gss_get_name_attribute() Most functions does not talk about memory management, is buffers released or not ? Love From lha@kth.se Sun Sep 13 15:44:50 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BB0B3A6838 for ; Sun, 13 Sep 2009 15:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5sCppSJTDqQ for ; Sun, 13 Sep 2009 15:44:49 -0700 (PDT) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by core3.amsl.com (Postfix) with ESMTP id 54D533A6358 for ; Sun, 13 Sep 2009 15:44:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-2.sys.kth.se (Postfix) with ESMTP id B1DC414DC55; Mon, 14 Sep 2009 00:24:53 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([127.0.0.1]) by localhost (smtp-2.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BRQgPsEnni8E; Mon, 14 Sep 2009 00:24:52 +0200 (CEST) X-KTH-Auth: lha [65.106.72.229] Received: from [10.2.3.74] (unknown [65.106.72.229]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 3C3EE14D7CB; Mon, 14 Sep 2009 00:24:48 +0200 (CEST) From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Subject: GSS_Inquire_name() Date: Sun, 13 Sep 2009 15:24:04 -0700 Message-Id: To: kitten@ietf.org Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Cc: Leif Johansson , Nicolas Williams X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2009 22:44:50 -0000 GSS_Inquire_name does not describe the relationship between all, asserted and authenticated names. Love From Nicolas.Williams@sun.com Sun Sep 13 22:21:47 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 666CA3A6861 for ; Sun, 13 Sep 2009 22:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ltew6IViFJaY for ; Sun, 13 Sep 2009 22:21:46 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id BE3193A6806 for ; Sun, 13 Sep 2009 22:21:44 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8E5MRqE023546 for ; Mon, 14 Sep 2009 05:22:27 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n8E5MRPY005241 for ; Sun, 13 Sep 2009 23:22:27 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n8E5BQNx016227; Mon, 14 Sep 2009 00:11:26 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n8E5BOgX016226; Mon, 14 Sep 2009 00:11:24 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 14 Sep 2009 00:11:24 -0500 From: Nicolas Williams To: Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= Subject: Re: comments draft-ietf-kitten-gssapi-naming-exts-05.txt Message-ID: <20090914051124.GY1033@Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.7i Cc: kitten@ietf.org, Leif Johansson X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 05:21:47 -0000 On Sun, Sep 13, 2009 at 12:41:08PM -0700, Love Hörnquist Åstrand wrote: > name_is_MN is an output variable, the c-bindings define it as an "int" > which provides little chance of "out-ness" A typo. Thanks. > I really dislike the modifying name attributes, why is that interface > needed (usecase ?) It's not about modifying names but about making assertions (or asking that an authority vouch for them). You first import a name, then set the name attributes corresponding to the assertions you wish to make, then you acquire a credential, then you use the credential. > The *more trick sucks but I can live with it, it assumes names do no We can always add more set types. I'm not fond of the idea of adding set types, but now that gss_buffer_set_t seems to be here to stay, I think I'd give in. > change and that items are iteratable, it also makes mech glue life hard. Can you explain the last part? The *more thing is not thread-safe, that's for sure (though it fails in safe ways). > GSS_Map_name_to_any, the type should be an OID, strings are not used > anywhere else and its painful to use, its if really a strings, make it > a "const char *" in the c bindings. I'd be happy with a const char *. I'd also be happy dropping this API. (I'd rather OSes have APIs like our gsscred_name_to_unix_cred, where the compiler can check types, than that we defeat type checking.) > same goes for gss_get_name_attribute() What same? > Most functions does not talk about memory management, is buffers > released or not ? All buffers must be released. Nico -- From leifj@sunet.se Mon Sep 14 00:37:45 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAE2D3A68AB for ; Mon, 14 Sep 2009 00:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yahurw+Mx1HH for ; Mon, 14 Sep 2009 00:37:44 -0700 (PDT) Received: from smtp.su.se (smtp3.su.se [130.237.93.228]) by core3.amsl.com (Postfix) with ESMTP id A9E503A67B5 for ; Mon, 14 Sep 2009 00:37:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.su.se (Postfix) with ESMTP id 275853BF75; Mon, 14 Sep 2009 09:38:26 +0200 (CEST) Received: from smtp.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 26868-01-66; Mon, 14 Sep 2009 09:38:25 +0200 (CEST) Received: from klapautius.localnet (norducph-gw.nordu.net [193.10.254.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.su.se (Postfix) with ESMTP id 9878A3C5B1; Mon, 14 Sep 2009 09:38:24 +0200 (CEST) From: Leif Johansson Organization: SUNET To: Love =?iso-8859-1?q?H=F6rnquist_=C5strand?= Subject: Re: GSS_Inquire_name() Date: Mon, 14 Sep 2009 09:38:25 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.28-15-generic; KDE/4.2.2; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200909140938.26528.leifj@sunet.se> X-Virus-Scanned: by amavisd-new at smtp.su.se X-Mailman-Approved-At: Mon, 14 Sep 2009 00:40:48 -0700 Cc: kitten@ietf.org, Nicolas Williams X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 07:37:45 -0000 On Monday 14 September 2009 00.24.04 Love H=F6rnquist =C5strand wrote: > GSS_Inquire_name does not describe the relationship between all, > asserted and authenticated names. > > Love I sortof think I may understand but feel free to expand on your thoughts :-) Cheers Leif From leifj@sunet.se Mon Sep 14 00:42:32 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0F2C3A69D0 for ; Mon, 14 Sep 2009 00:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.17 X-Spam-Level: X-Spam-Status: No, score=-5.17 tagged_above=-999 required=5 tests=[AWL=1.079, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lf6KMCB-6H-W for ; Mon, 14 Sep 2009 00:42:31 -0700 (PDT) Received: from smtp.su.se (smtp3.su.se [130.237.93.228]) by core3.amsl.com (Postfix) with ESMTP id 8591F28C12B for ; Mon, 14 Sep 2009 00:42:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.su.se (Postfix) with ESMTP id 1DB0B3C5BD; Mon, 14 Sep 2009 09:43:15 +0200 (CEST) Received: from smtp.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 27169-01-68; Mon, 14 Sep 2009 09:43:14 +0200 (CEST) Received: from klapautius.localnet (norducph-gw.nordu.net [193.10.254.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.su.se (Postfix) with ESMTP id B15D43C57F; Mon, 14 Sep 2009 09:43:14 +0200 (CEST) From: Leif Johansson Organization: SUNET To: Nicolas Williams Subject: Re: comments draft-ietf-kitten-gssapi-naming-exts-05.txt Date: Mon, 14 Sep 2009 09:43:16 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.28-15-generic; KDE/4.2.2; i686; ; ) References: <20090914051124.GY1033@Sun.COM> In-Reply-To: <20090914051124.GY1033@Sun.COM> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200909140943.16921.leifj@sunet.se> X-Virus-Scanned: by amavisd-new at smtp.su.se Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 07:42:32 -0000 On Monday 14 September 2009 07.11.24 Nicolas Williams wrote: > On Sun, Sep 13, 2009 at 12:41:08PM -0700, Love H=F6rnquist =C5strand wrot= e: =46irst of all: thanks for the review which you obviously did! > > name_is_MN is an output variable, the c-bindings define it as an "int" > > which provides little chance of "out-ness" > > A typo. Thanks. > > > I really dislike the modifying name attributes, why is that interface > > needed (usecase ?) > > It's not about modifying names but about making assertions (or asking > that an authority vouch for them). You first import a name, then set > the name attributes corresponding to the assertions you wish to make, > then you acquire a credential, then you use the credential. > > > The *more trick sucks but I can live with it, it assumes names do no > > We can always add more set types. I'm not fond of the idea of adding > set types, but now that gss_buffer_set_t seems to be here to stay, I > think I'd give in. gss_buffer_set_t it is then unless people scream bloody murder at it fairly soon > > > change and that items are iteratable, it also makes mech glue life hard. > > Can you explain the last part? The *more thing is not thread-safe, > that's for sure (though it fails in safe ways). > > > GSS_Map_name_to_any, the type should be an OID, strings are not used > > anywhere else and its painful to use, its if really a strings, make it > > a "const char *" in the c bindings. > > I'd be happy with a const char *. I'd also be happy dropping this API. > (I'd rather OSes have APIs like our gsscred_name_to_unix_cred, where the > compiler can check types, than that we defeat type checking.) > I've never been comfortable with this API - it feels difficult to specify=20 property. I'd be in favor of dropping it. > > same goes for gss_get_name_attribute() > > What same? +1 > > > Most functions does not talk about memory management, is buffers > > released or not ? > > All buffers must be released. I guess it doesn't hurt for us to say so explicitly though. Chers Leif From lha@kth.se Mon Sep 14 00:51:50 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EBE828C11C for ; Mon, 14 Sep 2009 00:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.948 X-Spam-Level: X-Spam-Status: No, score=-4.948 tagged_above=-999 required=5 tests=[AWL=1.001, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuWqNP9-z+ZD for ; Mon, 14 Sep 2009 00:51:49 -0700 (PDT) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by core3.amsl.com (Postfix) with ESMTP id 5BC4C28C124 for ; Mon, 14 Sep 2009 00:51:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 678EF14E0F0; Mon, 14 Sep 2009 09:52:02 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([127.0.0.1]) by localhost (smtp-2.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id aILjJkq8jIXm; Mon, 14 Sep 2009 09:52:01 +0200 (CEST) X-KTH-Auth: lha [2002:6334:ca6c:0:21e:c2ff:fec5:249f] Received: from [IPv6:2002:6334:ca6c::21e:c2ff:fec5:249f] (unknown [IPv6:2002:6334:ca6c:0:21e:c2ff:fec5:249f]) by smtp-2.sys.kth.se (Postfix) with ESMTP id C8E6114E10A; Mon, 14 Sep 2009 09:51:59 +0200 (CEST) Subject: Re: GSS_Inquire_name() Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-Reply-To: <200909140938.26528.leifj@sunet.se> Date: Mon, 14 Sep 2009 00:51:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <200909140938.26528.leifj@sunet.se> To: Leif Johansson X-Mailer: Apple Mail (2.1076) Cc: "kitten@ietf.org" , Nicolas Williams X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 07:51:50 -0000 14 sep 2009 kl. 00:38 skrev Leif Johansson: > On Monday 14 September 2009 00.24.04 Love H=F6rnquist =C5strand wrote: >> GSS_Inquire_name does not describe the relationship between all, >> asserted and authenticated names. >> >> Love > > I sortof think I may understand but feel free to expand on your =20 > thoughts :-) Are all names in all or just the one that are not in asserted/=20 authenticaticated names ? Love From leifj@mnt.se Mon Sep 14 01:03:59 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3EE63A6866 for ; Mon, 14 Sep 2009 01:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDnBmw-UdIKA for ; Mon, 14 Sep 2009 01:03:59 -0700 (PDT) Received: from mail-fx0-f217.google.com (mail-fx0-f217.google.com [209.85.220.217]) by core3.amsl.com (Postfix) with ESMTP id BCF123A67B8 for ; Mon, 14 Sep 2009 01:03:58 -0700 (PDT) Received: by fxm17 with SMTP id 17so654263fxm.37 for ; Mon, 14 Sep 2009 01:04:39 -0700 (PDT) Received: by 10.204.21.4 with SMTP id h4mr4864913bkb.58.1252915478696; Mon, 14 Sep 2009 01:04:38 -0700 (PDT) Received: from klapautius.localnet (norducph-gw.nordu.net [193.10.254.194]) by mx.google.com with ESMTPS id c28sm512374fka.44.2009.09.14.01.04.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Sep 2009 01:04:38 -0700 (PDT) To: Nicolas Williams Subject: Re: comments draft-ietf-kitten-gssapi-naming-exts-05.txt Content-Disposition: inline From: Leif Johansson Organization: mnt.se Date: Mon, 14 Sep 2009 10:04:39 +0200 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200909141004.39686.leifj@mnt.se> Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: leifj@mnt.se List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 08:04:00 -0000 On Monday 14 September 2009 07.11.24 Nicolas Williams wrote: > On Sun, Sep 13, 2009 at 12:41:08PM -0700, Love H=F6rnquist =C5strand wrot= e: =46irst of all: thanks for the review which you obviously did! > > name_is_MN is an output variable, the c-bindings define it as an "int" > > which provides little chance of "out-ness" > > A typo. Thanks. > > > I really dislike the modifying name attributes, why is that interface > > needed (usecase ?) > > It's not about modifying names but about making assertions (or asking > that an authority vouch for them). You first import a name, then set > the name attributes corresponding to the assertions you wish to make, > then you acquire a credential, then you use the credential. > > > The *more trick sucks but I can live with it, it assumes names do no > > We can always add more set types. I'm not fond of the idea of adding > set types, but now that gss_buffer_set_t seems to be here to stay, I > think I'd give in. gss_buffer_set_t it is then unless people scream bloody murder at it fairly soon > > > change and that items are iteratable, it also makes mech glue life hard. > > Can you explain the last part? The *more thing is not thread-safe, > that's for sure (though it fails in safe ways). > > > GSS_Map_name_to_any, the type should be an OID, strings are not used > > anywhere else and its painful to use, its if really a strings, make it > > a "const char *" in the c bindings. > > I'd be happy with a const char *. I'd also be happy dropping this API. > (I'd rather OSes have APIs like our gsscred_name_to_unix_cred, where the > compiler can check types, than that we defeat type checking.) > I've never been comfortable with this API - it feels difficult to specify=20 property. I'd be in favor of dropping it. > > same goes for gss_get_name_attribute() > > What same? +1 > > > Most functions does not talk about memory management, is buffers > > released or not ? > > All buffers must be released. I guess it doesn't hurt for us to say so explicitly though. Chers Leif From leifj@mnt.se Mon Sep 14 01:04:09 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F00B63A68AB for ; Mon, 14 Sep 2009 01:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2n79o4Ne2zRq for ; Mon, 14 Sep 2009 01:04:08 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id F2A1C3A67B8 for ; Mon, 14 Sep 2009 01:04:07 -0700 (PDT) Received: by bwz19 with SMTP id 19so1901268bwz.37 for ; Mon, 14 Sep 2009 01:04:46 -0700 (PDT) Received: by 10.204.3.220 with SMTP id 28mr4878546bko.4.1252915486113; Mon, 14 Sep 2009 01:04:46 -0700 (PDT) Received: from klapautius.localnet (norducph-gw.nordu.net [193.10.254.194]) by mx.google.com with ESMTPS id k29sm5560150fkk.25.2009.09.14.01.04.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Sep 2009 01:04:45 -0700 (PDT) To: Love =?iso-8859-1?q?H=F6rnquist_=C5strand?= Subject: Re: GSS_Inquire_name() Content-Disposition: inline From: Leif Johansson Organization: mnt.se Date: Mon, 14 Sep 2009 10:04:47 +0200 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200909141004.47465.leifj@mnt.se> Cc: kitten@ietf.org, Nicolas Williams X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: leifj@mnt.se List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 08:04:09 -0000 On Monday 14 September 2009 00.24.04 Love H=F6rnquist =C5strand wrote: > GSS_Inquire_name does not describe the relationship between all, > asserted and authenticated names. > > Love I sortof think I may understand but feel free to expand on your thoughts :-) Cheers Leif From leifj@mnt.se Mon Sep 14 01:06:38 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92E583A68FA for ; Mon, 14 Sep 2009 01:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxH99HuzyoRG for ; Mon, 14 Sep 2009 01:06:38 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id A11193A681F for ; Mon, 14 Sep 2009 01:06:36 -0700 (PDT) Received: by bwz19 with SMTP id 19so1902439bwz.37 for ; Mon, 14 Sep 2009 01:07:20 -0700 (PDT) Received: by 10.204.7.75 with SMTP id c11mr4834997bkc.119.1252915640212; Mon, 14 Sep 2009 01:07:20 -0700 (PDT) Received: from klapautius.localnet (norducph-gw.nordu.net [193.10.254.194]) by mx.google.com with ESMTPS id 35sm4104465fkt.16.2009.09.14.01.07.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Sep 2009 01:07:19 -0700 (PDT) From: Leif Johansson Organization: mnt.se To: Love =?iso-8859-1?q?H=F6rnquist_=C5strand?= Subject: Re: GSS_Inquire_name() Date: Mon, 14 Sep 2009 10:07:20 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.28-15-generic; KDE/4.2.2; i686; ; ) References: <200909140938.26528.leifj@sunet.se> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200909141007.20611.leifj@mnt.se> Cc: "kitten@ietf.org" , Nicolas Williams X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: leifj@mnt.se List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 08:06:38 -0000 On Monday 14 September 2009 09.51.26 Love H=F6rnquist =C5strand wrote: > 14 sep 2009 kl. 00:38 skrev Leif Johansson: > > On Monday 14 September 2009 00.24.04 Love H=F6rnquist =C5strand wrote: > >> GSS_Inquire_name does not describe the relationship between all, > >> asserted and authenticated names. > >> > >> Love > > > > I sortof think I may understand but feel free to expand on your > > thoughts :-) > > Are all names in all or just the one that are not in asserted/ > authenticaticated names ? > > Love Do you mean "are there attributes that are neither asserted nor=20 authenticated?" Cheers Leif From lha@kth.se Mon Sep 14 09:33:56 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 278643A6A9E for ; Mon, 14 Sep 2009 09:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZYArWBEmmDT for ; Mon, 14 Sep 2009 09:33:55 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 5DD243A686E for ; Mon, 14 Sep 2009 09:33:55 -0700 (PDT) Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out3.apple.com (Postfix) with ESMTP id 53754720871B for ; Mon, 14 Sep 2009 09:34:40 -0700 (PDT) X-AuditID: 11807137-b7b35ae000001836-ff-4aae70a00225 Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay16.apple.com (Apple SCV relay) with SMTP id 65.A7.06198.0A07EAA4; Mon, 14 Sep 2009 09:34:40 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes Received: from nutcracker.apple.com (nutcracker.apple.com [17.201.21.139]) by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0KPY000T9ZDR1Y00@gertie.apple.com> for kitten@ietf.org; Mon, 14 Sep 2009 09:34:40 -0700 (PDT) Subject: Re: GSS_Inquire_name() From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-reply-to: <200909141007.20611.leifj@mnt.se> Date: Mon, 14 Sep 2009 09:34:38 -0700 Content-transfer-encoding: quoted-printable Message-id: <05D82C6A-A495-4436-BAE2-3AC11AB28668@kth.se> References: <200909140938.26528.leifj@sunet.se> <200909141007.20611.leifj@mnt.se> To: "leifj@mnt.se" X-Mailer: Apple Mail (2.1076) X-Brightmail-Tracker: AAAAAQAAAZE= Cc: "kitten@ietf.org" , Nicolas Williams X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 16:33:56 -0000 14 sep 2009 kl. 01:07 skrev Leif Johansson: > On Monday 14 September 2009 09.51.26 Love H=F6rnquist =C5strand wrote: >> 14 sep 2009 kl. 00:38 skrev Leif Johansson: >>> On Monday 14 September 2009 00.24.04 Love H=F6rnquist =C5strand = wrote: >>>> GSS_Inquire_name does not describe the relationship between all, >>>> asserted and authenticated names. >>>> >>>> Love >>> >>> I sortof think I may understand but feel free to expand on your >>> thoughts :-) >> >> Are all names in all or just the one that are not in asserted/ >> authenticaticated names ? >> >> Love > > Do you mean "are there attributes that are neither asserted nor > authenticated?" I mean is all =3D asserted + authenticate or all =3D asserted + =20 authenticated + other or all =3D other - asserted - authenticated all =3D something else, why is there an all and asserted, and authenticated, and why no =20 complete too Just remove asserted and authenticated and just have an "all". Love From lukeh@padl.com Tue Sep 15 13:06:34 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15A853A6B44 for ; Tue, 15 Sep 2009 13:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.572 X-Spam-Level: X-Spam-Status: No, score=-1.572 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsZpntZXw+vQ for ; Tue, 15 Sep 2009 13:06:32 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 8932C28C1EC for ; Tue, 15 Sep 2009 13:06:32 -0700 (PDT) Received: by us.padl.com with ESMTP id n8FK6m2L014097; Tue, 15 Sep 2009 16:06:52 -0400 Message-Id: <9A980EBA-02D0-430F-A273-285685D61C8B@padl.com> From: Luke Howard To: leifj@mnt.se In-Reply-To: <200909141007.20611.leifj@mnt.se> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: GSS_Inquire_name() Date: Tue, 15 Sep 2009 22:06:47 +0200 References: <200909140938.26528.leifj@sunet.se> <200909141007.20611.leifj@mnt.se> X-Mailer: Apple Mail (2.936) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.1 Cc: "kitten@ietf.org" , Nicolas Williams X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 20:06:34 -0000 >> Are all names in all or just the one that are not in asserted/ >> authenticaticated names ? >> >> Love > > Do you mean "are there attributes that are neither asserted nor > authenticated?" As an implementer this left me completely confused too. BTW, see: http://k5wiki.kerberos.org/wiki/Projects/VerifyAuthData for actual implementation experience. -- Luke From Nicolas.Williams@sun.com Tue Sep 15 13:41:41 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D34C83A6B99 for ; Tue, 15 Sep 2009 13:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubSrJSJp2zFg for ; Tue, 15 Sep 2009 13:41:39 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 505AE3A6B61 for ; Tue, 15 Sep 2009 13:41:39 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8FKgPQh006581 for ; Tue, 15 Sep 2009 20:42:26 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n8FKgPwg015591 for ; Tue, 15 Sep 2009 14:42:25 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n8FKVNJA018033; Tue, 15 Sep 2009 15:31:23 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n8FKVLha018032; Tue, 15 Sep 2009 15:31:21 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 15 Sep 2009 15:31:21 -0500 From: Nicolas Williams To: Luke Howard Subject: Re: GSS_Inquire_name() Message-ID: <20090915203120.GG1033@Sun.COM> References: <200909140938.26528.leifj@sunet.se> <200909141007.20611.leifj@mnt.se> <9A980EBA-02D0-430F-A273-285685D61C8B@padl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9A980EBA-02D0-430F-A273-285685D61C8B@padl.com> User-Agent: Mutt/1.5.7i Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 20:41:41 -0000 On Tue, Sep 15, 2009 at 10:06:47PM +0200, Luke Howard wrote: > >>Are all names in all or just the one that are not in asserted/ > >>authenticaticated names ? > >> > >>Love > > > >Do you mean "are there attributes that are neither asserted nor > >authenticated?" > > As an implementer this left me completely confused too. > > BTW, see: > > http://k5wiki.kerberos.org/wiki/Projects/VerifyAuthData > > for actual implementation experience. I can't quite remember what I had intended :( I think I must have meant 'all_attrs' to be the union of the other two purely for conviennce. But on second (or third) thought I can't see why an app might care for attrs without caring as to whether they are authenticated or asserted. (Also, there is the more general problem of what entity authenticated a given attribute. But for now I think GSS_Inquire_name() is plenty good enough, minus the all_attrs argument anyways.) Nico -- From lha@kth.se Tue Sep 15 13:59:32 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7F343A6875 for ; Tue, 15 Sep 2009 13:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cnw6X9LtkrO6 for ; Tue, 15 Sep 2009 13:59:32 -0700 (PDT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 3CED23A657C for ; Tue, 15 Sep 2009 13:59:32 -0700 (PDT) Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out4.apple.com (Postfix) with ESMTP id 1329D7756F93; Tue, 15 Sep 2009 14:00:20 -0700 (PDT) X-AuditID: 11807137-b7b35ae000001836-77-4ab00063e445 Received: from hummel.apple.com (hummel.apple.com [17.201.21.134]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id 88.5A.06198.46000BA4; Tue, 15 Sep 2009 14:00:20 -0700 (PDT) Subject: Re: GSS_Inquire_name() Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-Reply-To: <20090915203120.GG1033@Sun.COM> Date: Tue, 15 Sep 2009 14:00:19 -0700 Content-Transfer-Encoding: 7bit Message-Id: <32A3B617-61AC-40EE-9F79-D2A4E1FD09C0@kth.se> References: <200909140938.26528.leifj@sunet.se> <200909141007.20611.leifj@mnt.se> <9A980EBA-02D0-430F-A273-285685D61C8B@padl.com> <20090915203120.GG1033@Sun.COM> To: Nicolas Williams X-Mailer: Apple Mail (2.1076) X-Brightmail-Tracker: AAAAAQAAAZE= Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 20:59:32 -0000 > I can't quite remember what I had intended :( > > I think I must have meant 'all_attrs' to be the union of the other two > purely for conviennce. But on second (or third) thought I can't see > why > an app might care for attrs without caring as to whether they are > authenticated or asserted. > > (Also, there is the more general problem of what entity > authenticated a > given attribute. But for now I think GSS_Inquire_name() is plenty > good > enough, minus the all_attrs argument anyways.) So when should applications care about the name exists w/o checking content ? I think there should only be an "all" and caller have to call get-name- attribute to get the attribute. Love From Nicolas.Williams@sun.com Tue Sep 15 14:11:01 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 880B63A6918 for ; Tue, 15 Sep 2009 14:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.705 X-Spam-Level: X-Spam-Status: No, score=-5.705 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVBU--29dFx9 for ; Tue, 15 Sep 2009 14:11:00 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 108E73A6831 for ; Tue, 15 Sep 2009 14:11:00 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n8FLBiHY026357 for ; Tue, 15 Sep 2009 21:11:44 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n8FLBiew043726 for ; Tue, 15 Sep 2009 15:11:44 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n8FL0fPf018043; Tue, 15 Sep 2009 16:00:41 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n8FL0ebt018042; Tue, 15 Sep 2009 16:00:40 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 15 Sep 2009 16:00:40 -0500 From: Nicolas Williams To: Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= Subject: Re: GSS_Inquire_name() Message-ID: <20090915210040.GH1033@Sun.COM> References: <200909140938.26528.leifj@sunet.se> <200909141007.20611.leifj@mnt.se> <9A980EBA-02D0-430F-A273-285685D61C8B@padl.com> <20090915203120.GG1033@Sun.COM> <32A3B617-61AC-40EE-9F79-D2A4E1FD09C0@kth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <32A3B617-61AC-40EE-9F79-D2A4E1FD09C0@kth.se> User-Agent: Mutt/1.5.7i Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 21:11:01 -0000 On Tue, Sep 15, 2009 at 02:00:19PM -0700, Love Hörnquist Åstrand wrote: > So when should applications care about the name exists w/o checking > content ? ? > I think there should only be an "all" and caller have to call get-name- > attribute to get the attribute. That works for me. I like it. Nico -- From lukeh@padl.com Tue Sep 15 14:48:35 2009 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1EFF3A6864 for ; Tue, 15 Sep 2009 14:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OVlIcCac236 for ; Tue, 15 Sep 2009 14:48:34 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 99AEB3A6ACE for ; Tue, 15 Sep 2009 14:48:34 -0700 (PDT) Received: by us.padl.com with ESMTP id n8FLmwfY017971; Tue, 15 Sep 2009 17:49:02 -0400 Message-Id: <79FE6893-CFBA-427B-B32E-D8FB52F8F139@padl.com> From: Luke Howard To: Nicolas Williams In-Reply-To: <20090915210040.GH1033@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: GSS_Inquire_name() Date: Tue, 15 Sep 2009 23:48:57 +0200 References: <200909140938.26528.leifj@sunet.se> <200909141007.20611.leifj@mnt.se> <9A980EBA-02D0-430F-A273-285685D61C8B@padl.com> <20090915203120.GG1033@Sun.COM> <32A3B617-61AC-40EE-9F79-D2A4E1FD09C0@kth.se> <20090915210040.GH1033@Sun.COM> X-Mailer: Apple Mail (2.936) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.1 Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 21:48:35 -0000 On 15/09/2009, at 11:00 PM, Nicolas Williams wrote: > On Tue, Sep 15, 2009 at 02:00:19PM -0700, Love H=F6rnquist =C5strand =20= > wrote: >> So when should applications care about the name exists w/o checking >> content ? > > ? > >> I think there should only be an "all" and caller have to call get-=20 >> name- >> attribute to get the attribute. > > That works for me. I like it. Likewise. Checked in. -- Luke