Re: GSS-APIv3 sketch

Andrew Bartlett <abartlet@samba.org> Wed, 11 November 2009 22:59 UTC

Return-Path: <abartlet@samba.org>
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 672AD3A6890 for <kitten@core3.amsl.com>; Wed, 11 Nov 2009 14:59:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.449
X-Spam-Level:
X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, 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 D0Fd9c6RP4Al for <kitten@core3.amsl.com>; Wed, 11 Nov 2009 14:59:03 -0800 (PST)
Received: from lists.samba.org (fn.samba.org [216.83.154.106]) by core3.amsl.com (Postfix) with ESMTP id 23B8B3A6B62 for <kitten@ietf.org>; Wed, 11 Nov 2009 14:59:01 -0800 (PST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by lists.samba.org (Postfix) with ESMTP id A385AAD21A; Wed, 11 Nov 2009 15:57:13 -0700 (MST)
Subject: Re: GSS-APIv3 sketch
From: Andrew Bartlett <abartlet@samba.org>
To: Nicolas Williams <Nicolas.Williams@sun.com>
In-Reply-To: <20091111184726.GD10501@Sun.COM>
References: <20091111181140.GC10501@Sun.COM> <C111F570-A844-4782-B561-08B6685D7E09@apple.com> <20091111184244.GN1105@Sun.COM> <20091111184726.GD10501@Sun.COM>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-d8uYpG+vdxVUYuOH/tzb"
Date: Thu, 12 Nov 2009 09:59:26 +1100
Message-Id: <1257980366.2759.41.camel@naomi.s4.naomi.abartlet.net>
Mime-Version: 1.0
X-Mailer: Evolution 2.26.3 (2.26.3-1.fc11)
Cc: "kitten@ietf.org" <kitten@ietf.org>, vl <vl@samba.org>, Love Hörnquist Åstrand <lha@apple.com>
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: Wed, 11 Nov 2009 22:59:04 -0000

On Wed, 2009-11-11 at 12:47 -0600, Nicolas Williams wrote:
> On Wed, Nov 11, 2009 at 12:42:44PM -0600, Nicolas Williams wrote:
> > On Wed, Nov 11, 2009 at 10:40:50AM -0800, Love Hörnquist Åstrand wrote:
> > > 
> > > I have so many comments that I don't know where to start.
> > > 
> > > First out: any work that doesn't include async is dead in the water.
> > 
> > Oh, I forgot to mention that.  It does include async.
> 
> I should describe it:
> 
>  - The simplest way to do async is:
> 
>     - add a new return code, S_ASYNC_CONTINUE_NEEDED
>     - add a callback, to be set on a call context handle, that will be
>       called (on a different thread) when the suspended function is
>       ready to make progress
> 
>    This requires threads.  I don't mind that at all.  Any alternative
>    based on poll(2)/select(2)/libevent/kevent/event ports/whatever is
>    going to either be OS-specific or will require a third party event
>    library (e.g., libevent), neither of which seems more appropriate
>    than just requiring threads (note: not POSIX threads, specifically,
>    nor any other specific thread implementation).
> 
> The same approach of associating callbacks with the call context works
> for prompter callbacks for dealing with initial credential acquisition.

I'm hoping that Volker or Metze (CC'ed async experts on the Samba Team)
can fill out some more detail, but I'll start by nothing that anything
that requires threads, or causes the library to start threads is a
non-starter for Samba.  

Creating threads behind the applications' back is a really bad idea. 

We really need a proper state machine, with integration available into
our event library (or any other the event library the caller
provides).  

As to portability, if no event lib is provided by the caller, then just
block like GSSAPI does at the moment.  

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.