Re: [kitten] proposed RFC 6680 erratum for GSS_Getname_attribute() network interaction

Nico Williams <nico@cryptonector.com> Fri, 17 April 2015 19:02 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C161B2E7E for <kitten@ietfa.amsl.com>; Fri, 17 Apr 2015 12:02:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level:
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kU0oKT7JfYun for <kitten@ietfa.amsl.com>; Fri, 17 Apr 2015 12:02:36 -0700 (PDT)
Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id AB80D1B2F8E for <kitten@ietf.org>; Fri, 17 Apr 2015 12:02:34 -0700 (PDT)
Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 67F162200; Fri, 17 Apr 2015 12:02:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=tt21s/06Oo8vrK kW3uOAIOy/h6o=; b=ZyCRb/3Jg1RyC8ug+jt9+lDndSDgH4r26JiAT1XILrqvt8 MgxG4ddV059yOhYXmvmjgtfo2unEJ9tOkiogDMPQyOMBlEuq7+mkAqMqOEdMYTGq Xn+y2fkpXLRyXa8AYACnixnQb71IpMFedFlHikAovvZQQerR397KF+Nqs8Khw=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPA id D5EA11601; Fri, 17 Apr 2015 12:02:33 -0700 (PDT)
Date: Fri, 17 Apr 2015 14:02:32 -0500
From: Nico Williams <nico@cryptonector.com>
To: Benjamin Kaduk <kaduk@MIT.EDU>
Message-ID: <20150417190232.GG13041@localhost>
References: <alpine.GSO.1.10.1504171339540.22210@multics.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.GSO.1.10.1504171339540.22210@multics.mit.edu>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/TInHUI4lgYBAryXJUMmX4ktAEbA>
Cc: kitten@ietf.org
Subject: Re: [kitten] proposed RFC 6680 erratum for GSS_Getname_attribute() network interaction
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Fri, 17 Apr 2015 19:02:38 -0000

On Fri, Apr 17, 2015 at 01:56:26PM -0400, Benjamin Kaduk wrote:
> It was unclear if there was actually support for an erratum for this, so
> let me throw out some text and see what response it gets.
> 
> In section 7.5.  GSS_Get_name_attribute()
> 
> OLD:
>    This function outputs the value(s) associated with a given GSS name
>    object for a given name attribute.
> 
> NEW:
>    This function outputs the value(s) associated with a given GSS name
>    object for a given name attribute.  It is permitted to block pending
>    network interactions when the attr input is not an attribute which
>    would be included in the attrs output of a call to GSS_Inquire_name()
>    on the same name input.

I'm OK with this.

Perhaps we should publish draft-williams-kitten-generic-naming-
attributes-02 and make it update RFC6680 (since that I-D deals with
blocking already).

> COMMENT:
>    RFC 6680 makes no mention of blocking or not blocking on network
>    interaction, though RFC 2743 does.  This seems like the most reasonable
>    interpretation of what is currently in RFC 6680.  Calls which are not
>    explicitly permitted to block are assumed to be not permitted to block.

I agree with the gist of this, but GSS in general is a bit wishy-washy
as to all sorts of things related to programming language run-times.
What is "blocking"?  A good definition is hard to come by.  Is CPU bound
and long-running "blocking"?  What if such a task task could be handed
to a task queue?

Ideally we'd have async I/O extensions for functions that can block...
But this is difficult to do if we cannot assume threading (so that GSS
mechanisms can run their event loops in separate threads).

Which reminds me: we should do that (add async interfaces that depend on
threading rather than adding interfaces to applications' event loops).

Nico
--