Re: [kitten] Use of GSS_Get_name_attribute() to obtain further attributes

Benjamin Kaduk <kaduk@mit.edu> Mon, 13 April 2015 15:55 UTC

Return-Path: <kaduk@MIT.EDU>
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 011CC1ACDF1 for <kitten@ietfa.amsl.com>; Mon, 13 Apr 2015 08:55:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.245
X-Spam-Level:
X-Spam-Status: No, score=-1.245 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665, T_RP_MATCHES_RCVD=-0.01] 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 WoqAbQhpKi5o for <kitten@ietfa.amsl.com>; Mon, 13 Apr 2015 08:55:50 -0700 (PDT)
Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 014F61ACD29 for <kitten@ietf.org>; Mon, 13 Apr 2015 08:55:49 -0700 (PDT)
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t3DFhxmv021165; Mon, 13 Apr 2015 11:43:59 -0400 (EDT)
Date: Mon, 13 Apr 2015 11:43:59 -0400 (EDT)
From: Benjamin Kaduk <kaduk@mit.edu>
To: Simo Sorce <simo@redhat.com>
In-Reply-To: <1428933722.810.52.camel@willson.usersys.redhat.com>
Message-ID: <alpine.GSO.1.10.1504131120270.22210@multics.mit.edu>
References: <552B7D5F.3000006@um.es> <1428933722.810.52.camel@willson.usersys.redhat.com>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/MBkqXVChMZ0_nbJF_zknn2eCEgQ>
Cc: kitten@ietf.org
Subject: Re: [kitten] Use of GSS_Get_name_attribute() to obtain further attributes
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: Mon, 13 Apr 2015 15:55:55 -0000

On Mon, 13 Apr 2015, Simo Sorce wrote:

> On Mon, 2015-04-13 at 10:25 +0200, Alejandro Perez Mendez wrote:
>
> The advantage of a new API is that applications can use
> GSS_Get_name_attribute() with the implicit knowledge that the call will
> not block or generate traffic, however I guess that apps can list all
> known names ahead and then call the function only if the name is listed.
> So perhaps 1) is fine.

Let's see what sort of context we can put things in.

RFC 2743 explicitly calls out that the context-establishment and -deletion
calls may block pending network interactions, and the credential
management calls are also permitted to block on the network.  In contrast,
per-message calls are explicitly declared to not block pending network
interactions.

The word "block" does not appear anywhere in RFC 6680.  It would be nice
to hear from some of the original authors of 6680 about whether this was a
question they had considered.

I do not think I am opposed to (1) (i.e., letting GSS_Get_name_attribute()
block on network interaction), but if we proceed down that route, I think
we should file an erratum against 6880 to that effect.

-Ben