Re: [kitten] RFC2743 errata 4251

Nico Williams <nico@cryptonector.com> Tue, 16 December 2014 16:44 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 D37921A1BA3 for <kitten@ietfa.amsl.com>; Tue, 16 Dec 2014 08:44:36 -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 qrV3Qcbw6dS5 for <kitten@ietfa.amsl.com>; Tue, 16 Dec 2014 08:44:35 -0800 (PST)
Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A4CB61A1BE3 for <kitten@ietf.org>; Tue, 16 Dec 2014 08:44:33 -0800 (PST)
Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 81E9F163D; Tue, 16 Dec 2014 08:44:33 -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=Cdo9XhYCXOQcCa h40x2hXlsQ+ZE=; b=yFwnsV1hN9mqL3Blg8BBeYok4Zk7wBAxNMiB59Fh3+fpfM /NaW0ecVNf0A5j8TIrXCK4loSWb69nx2jtBElxUSDz3l4TJB/y8lxw55P9NA1Ydm Q6fEH7gYjjJr5hqKiwgr/ShoUrbN2DUIHsZd4VyJH0mEQbeGFACPBXnulx8RE=
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 A3ADF163B; Tue, 16 Dec 2014 08:44:32 -0800 (PST)
Date: Tue, 16 Dec 2014 10:44:31 -0600
From: Nico Williams <nico@cryptonector.com>
To: Benjamin Kaduk <kaduk@MIT.EDU>
Message-ID: <20141216164426.GU3241@localhost>
References: <20141108014820.3278A1AFAB@ld9781.wdf.sap.corp> <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> <alpine.GSO.1.10.1412161057050.23489@multics.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.GSO.1.10.1412161057050.23489@multics.mit.edu>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/w0NlwctV6HKUxyM5lQUdwbj4ZoM
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: Tue, 16 Dec 2014 16:44:37 -0000

On Tue, Dec 16, 2014 at 11:02:00AM -0500, Benjamin Kaduk wrote:
> On Wed, 10 Dec 2014, Benjamin Kaduk wrote:
> > On Tue, 9 Dec 2014, Nico Williams wrote:
> > ======================================================
> >
> >   Section 2.2.4 says:
> >
> >      o  GSS_S_FAILURE indicates that the context is recognized, but that
> >      the GSS_Process_context_token() operation could not be performed
> >      for reasons unspecified at the GSS-API level.
> >
> >   It should say:
> >
> >      o  GSS_S_FAILURE indicates that the context is recognized, but
> >      either the GSS_Process_context_token() operation could not be
> >      performed for reasons unspecified at the GSS-API level, or the peer
> >      had an error consuming the last context token sent to it.  The latter
> >      occurs when the local side became fully established and produced one
> >      last token which was sent to the peer, but the peer encountered an
> >      error while processing that last context token.  In either case the
> >      minor status code provides additional information.
> 
> Thinking about things a bit more with a clearer head, I would like to
> replace "last context token" with "last context establishment token" in
> this paragraph, since error and deletion tokens are still context-level
> tokens, and the one which we thought was last isn't actually last if
> there's an error token in reply to it, so calling it the "last
> context(-level) token" is strange.

The problem is "last" then.  The addition of "establishment" doesn't
cure the problem.  IMO it's a non-problem.

> [...]
> 
> >      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.
> 
> [peeking ahead in the thread, since I'm replying to an early message]
> 
> I think the disagreement between Greg and Nico can be distilled to: how
> likely are we to require that future extensions using async context tokens
> are implemented in a backwards-compatible way?

Sort of.  But the key is that we shouldn't REQUIRE that the next step be
getting into a state that leads inexorably to calling
GSS_Delete_sec_context().

We don't, as this RFC doesn't use RFC2119.  Greg things that "...should
generally call GSS_Delete_sec_context()..." is too strong.

It's a bit of an angels on a headpin argument... if we assume that all
properly function applications will inexorably end up calling
GSS_Delete_sec_context() anyways (they should, if they succeed as
establishing a security context).

I believe the "generally" weasel word is good enough.  I don't think the
entire paragraph should be excised.  I'd like to see alternative text
from Greg.

> Taking the rekey example as a strawman (even though we know that there are
> other ways to do it not involving async context tokens), this would just
> mean that a GSSv2u3 app would try to do the rekey, and if it was talking
> to a GSSv2u1 app, the rekey would fail, and the old key would
> transparently continue to be used.

Or the v2u1 app would end up calling GSS_Delete_sec_context().  It's not
at all clear to me that we want a v2u1 app to continue in the case of a
re-key attempt that fails because it (the app) doesn't know that that's
what the context token was about (or how to respond to it).

Of course, the thought occurs that a re-key context token would elicit a
GSS_S_DEFECTIVE_TOKEN major status code from GSS_Process_context_token(),
so maybe there's no real problem here (since the "should generally" text
above does not apply in that case).

> So, it is certainly possible to be backwards compatible, at least in some
> cases.  Greg's argument that there should also be application-level error
> handling which could discover that the context is unusable and tear things
> down rings true to me, so I agree with Greg that we should not close the
> door prematurely.

I believe the above text does not do this.  See above comment about
GSS_S_DEFECTIVE_TOKEN.

Nico
--