Re: [kitten] RFC2743 errata 4251

Nico Williams <nico@cryptonector.com> Wed, 17 December 2014 23:05 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 B53C51A002F for <kitten@ietfa.amsl.com>; Wed, 17 Dec 2014 15:05:15 -0800 (PST)
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 4Bbok8HMJrus for <kitten@ietfa.amsl.com>; Wed, 17 Dec 2014 15:05:13 -0800 (PST)
Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2601A0019 for <kitten@ietf.org>; Wed, 17 Dec 2014 15:05:12 -0800 (PST)
Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id E8EE520047D12; Wed, 17 Dec 2014 15:05:11 -0800 (PST)
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=vFryukp1v50LpI Mcg5Fv0KFLACI=; b=lnpQwObkSvBEBJ5EtTLoQh3JOgreOg6OAt4BMxwO7pE6u8 kImv04lSHOvMEZyrfxd2GqG50PXNhr73VUhPE8yGS8JgQxGIJFoBsRcJzPnjCSKS vEtH6CJ38VWmc0HHZM6zDQd3bxS+GTEOjWd7LloOMsN+VApPuoLUTl0EKYNDA=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPA id 9708920046913; Wed, 17 Dec 2014 15:05:11 -0800 (PST)
Date: Wed, 17 Dec 2014 17:05:11 -0600
From: Nico Williams <nico@cryptonector.com>
To: Greg Hudson <ghudson@mit.edu>
Message-ID: <20141217230505.GD9443@localhost>
References: <20141110162504.GA3412@localhost> <alpine.GSO.1.10.1411241330400.19231@multics.mit.edu> <20141124185114.GM3200@localhost> <alpine.GSO.1.10.1412091618550.23489@multics.mit.edu> <20141209215519.GI12979@localhost> <alpine.GSO.1.10.1412091856160.23489@multics.mit.edu> <20141210002441.GP12979@localhost> <alpine.GSO.1.10.1412101349030.23489@multics.mit.edu> <548F185E.70701@mit.edu> <5492032F.9050607@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <5492032F.9050607@mit.edu>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/wHCKO2kN3yx8qOeW_GW0XB9mAd4
Cc: kitten@ietf.org
Subject: Re: [kitten] RFC2743 errata 4251
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: Wed, 17 Dec 2014 23:05:24 -0000

On Wed, Dec 17, 2014 at 05:26:55PM -0500, Greg Hudson wrote:
> On 12/15/2014 12:20 PM, Greg Hudson wrote:
> > On 12/10/2014 01:57 PM, Benjamin Kaduk wrote:
> >>      Though future GSS-API extensions may add new uses of asynchronous
> >>      security context tokens and ways to process them, applications
> >>      using the GSS-API version 2, update 1, should generally call
> >>      GSS_Delete_sec_context() after calling GSS_Process_context_token(),
> >>      when the latter returns GSS_S_COMPLETE or GSS_S_FAILURE.
> > 
> > I don't like the wording of this part.  Encouraging applications to
> > assume that context tokens destroy the context essentially closes the
> > door to specifying context tokens which don't.
> 
> Let me rephrase this objection:
> 
> I think the scope of this erratum should be limited to making it
> possible for conforming gss_process_context_token implementations to
> convey peer error token information to callers.  As Ben said yesterday,
> the inability to do so is a clear defect in the spec, which makes it
> appropriate fodder for an erratum.

This rationale for excluding the above is less objectionable to me than
the original.  I would rather say what the application should do in the
GSS_S_COMPLETE/FAILURE cases, and I thought (and still thing) that
"should generally" or some such weasel verbiage ought to be an
acceptably non-normative way to do this.  But if this is the only way to
make progress on this erratum, I'll accept it.

> The proposed text goes beyond that scope by giving guidance on how to
> respond to GSS_S_COMPLETE.  That guidance assumes that async context
> token types are limited to the ones mentioned in section 2.2.4:
> (deletion tokens and error tokens resulting from the final synchronous
> token).  Because this assumption does not match my reading of the
> existing text, I don't think providing such additional guidance about
> GSS_S_COMPLETE is appropriate for an erratum.  I also don't think
> clarifying this point is important enough to justify a document revision.

I think that the [mostly implied, in the base GSS RFCs and our work
since then] that the extensibility model for the GSS-API (the API _and_
the protocol pattern it sets out) is such that the door to the sorts of
extensions you had in mind is closed without negotiation of their use.

That means that the possible unexpected context tokens can only be error
and context deletion tokens unless the application (and mechanism)
negotiate the availability of new unexpected context token types (e.g.,
via a req_flag/ret_flag).

If there's no consensus as to the GSS extensibility model then I think
it's fair to say that there's no consensus to include the above text in
the erratum, but if there is consensus as to the GSS extensibility model
then I don't see much reason to reject the above text -- just a question
of expediency.  I do think it's better to give guidance here -even the
opposite of that which I'd give- than none.

Finally, if there's no consensus as to the GSS extensibility model then
we're going to have more problems in the future.  I don't know what we
can do about that without more (and more active) participants to help
define a consensus about a GSS extensibility model in a future RFC.

Nico
--