Re: KITTEN: IETF 75 - 76

Nicolas Williams <Nicolas.Williams@sun.com> Mon, 17 August 2009 00:02 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 088513A6842 for <kitten@core3.amsl.com>; Sun, 16 Aug 2009 17:02:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.888
X-Spam-Level:
X-Spam-Status: No, score=-5.888 tagged_above=-999 required=5 tests=[AWL=0.158, 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 7zpOcQzoFFT4 for <kitten@core3.amsl.com>; Sun, 16 Aug 2009 17:01:59 -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 40CE13A6851 for <kitten@ietf.org>; Sun, 16 Aug 2009 17:01:59 -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 n7H023e4017389 for <kitten@ietf.org>; Mon, 17 Aug 2009 00:02:03 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 n7H023KJ009208 for <kitten@ietf.org>; Sun, 16 Aug 2009 18:02:03 -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 n7GNpM4S002664; Sun, 16 Aug 2009 18:51:22 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7GNpMqF002663; Sun, 16 Aug 2009 18:51:22 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Sun, 16 Aug 2009 18:51:22 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Shawn M Emery <Shawn.Emery@sun.com>
Subject: Re: KITTEN: IETF 75 - 76
Message-ID: <20090816235122.GP1043@Sun.COM>
References: <4A87A69A.3050408@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4A87A69A.3050408@sun.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 <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: Mon, 17 Aug 2009 00:02:00 -0000

On Sun, Aug 16, 2009 at 12:26:34AM -0600, Shawn M Emery wrote:
> 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

(1) is a complex matter as it requires interaction with users and needs
to cover such things as principal name, password, new password, PIN, PIN
change and other prompts.  A design is certainly possible.

(2) is really listing of principal names for which the caller has
credentials (we can already list mechanisms for which the caller has
credentials).  This is likely a difficult thing to design since we will
want to be able to control what principals GSS_Accept_sec_context() can
accept sec contexts for, and that means a significant revamp of the
semantics of CREDENTIAL HANDLEs _or_ a replacement for
GSS_Accept_sec_context().

>    4. error message reporting

Yes.  (I still believe in the "PGSSAPI" idea where, in the C bindings,
we change the semantics and type of the minor_status argument, though in
a binary backwards compatible way.  I can expand if desired.)

>    5. asynchronous calls

Developers can use threads to work around the lack of these, so it seems
to me that these should be a lower priority.

> ...along with Alexey's recent request for policy/encryption strength.

Yes.  This should be, IMO, a high priority.

> 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.

I'll edit, but I need co-authors who'll contribute text, API designs,
and energy to the list.

Nico
--