Re: [kitten] RFC2743 errata 4251

Benjamin Kaduk <kaduk@MIT.EDU> Tue, 16 December 2014 16:02 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 88B5A1A1BC0 for <kitten@ietfa.amsl.com>; Tue, 16 Dec 2014 08:02:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 7t89q6fDQol2 for <kitten@ietfa.amsl.com>; Tue, 16 Dec 2014 08:02:06 -0800 (PST)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 503461A1BB4 for <kitten@ietf.org>; Tue, 16 Dec 2014 08:02:06 -0800 (PST)
X-AuditID: 12074423-f79b86d000000cf5-0c-5490577dd516
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 6D.A6.03317.D7750945; Tue, 16 Dec 2014 11:02:05 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id sBGG24iM018232; Tue, 16 Dec 2014 11:02:04 -0500
Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sBGG21Wh011528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Dec 2014 11:02:04 -0500
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sBGG2163029177; Tue, 16 Dec 2014 11:02:01 -0500 (EST)
Date: Tue, 16 Dec 2014 11:02:00 -0500
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: Nico Williams <nico@cryptonector.com>
In-Reply-To: <alpine.GSO.1.10.1412101349030.23489@multics.mit.edu>
Message-ID: <alpine.GSO.1.10.1412161057050.23489@multics.mit.edu>
References: <20141104204714.GI7913@localhost> <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>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixG6nrlsbPiHEYHo7n8XRzatYLE5dO8Lm wOTx8tQ5Ro8lS34yBTBFcdmkpOZklqUW6dslcGUsn/mRtWCpaMXuc71sDYy3BLoYOTgkBEwk nnwx7mLkBDLFJC7cW8/WxcjFISSwmEni1OM/LBDORkaJzistrCBVQgKHmCQu/zKEsBsYJf48 4AKxWQS0JaZNuMEIYrMJqEjMfLORDcQWEdCUuD5vKZjNLCAssf7cDGYQWxgovvPrLbCZnAJO Ej2PvoD18go4Sizu62GBmH+QWaLxtSCILSqgI7F6/xQWiBpBiZMzn7BAzNSSWD59G8sERsFZ SFKzkKQWMDKtYpRNya3SzU3MzClOTdYtTk7My0st0jXTy80s0UtNKd3ECA5TF+UdjH8OKh1i FOBgVOLhDSjsDxFiTSwrrsw9xCjJwaQkymvhPyFEiC8pP6UyI7E4I76oNCe1+BCjBAezkghv kDJQjjclsbIqtSgfJiXNwaIkzrvpB1+IkEB6YklqdmpqQWoRTFaGg0NJglcvDKhRsCg1PbUi LTOnBCHNxMEJMpwHaHgaSA1vcUFibnFmOkT+FKOilDhvNkhCACSRUZoH1wtLI68YxYFeEebt B6niAaYguO5XQIOZgAZP/twPMrgkESEl1cDIWdScwd9sfzxr7Z2QCd+nTz7VeVbX/reS4qqj N/aHX9tv/nfu8ujOrLk9M46siOv79Vg1Yc6GmJTGfjnP+wI/80JPxq0NO9nOue/7hocrPlZt CLad2qbP0+/8iDOqeiX7+szYyUsu73jtf+fIvVfK/zbIvd/BVc966pmUYUHY/wXH1oZP6Hn0 SYmlOCPRUIu5qDgRAKtAyVz+AgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/beEKtjdmWD1IfuZMsYZqbTHlFE4
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:02:19 -0000

On Wed, 10 Dec 2014, Benjamin Kaduk wrote:

> On Tue, 9 Dec 2014, Nico Williams wrote:
>
> > Sold.
>
> Okay, so now we're looking at:
>
> ======================================================
>
>   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.

[...]

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

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.

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.

-Ben