Re: KITTEN: IETF 75 - 76

Nicolas Williams <Nicolas.Williams@sun.com> Tue, 01 September 2009 21:49 UTC

Return-Path: <Nicolas.Williams@sun.com>
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 <kitten@core3.amsl.com>; 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 <kitten@core3.amsl.com>; 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 <kitten@ietf.org>; 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 <kitten@ietf.org>; 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 <kitten@ietf.org>; 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, 01 Sep 2009 16:38:53 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Love Hörnquist Åstrand <lha@kth.se>
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" <kitten@ietf.org>
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=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
--