Re: [kitten] RFC2743 errata 4251
Benjamin Kaduk <kaduk@MIT.EDU> Tue, 20 January 2015 21:25 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 A97611A000D for <kitten@ietfa.amsl.com>; Tue, 20 Jan 2015 13:25:39 -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 B2STfictLZP3 for <kitten@ietfa.amsl.com>; Tue, 20 Jan 2015 13:25:37 -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 F271F1A000C for <kitten@ietf.org>; Tue, 20 Jan 2015 13:25:36 -0800 (PST)
X-AuditID: 12074423-f797b6d000000cfe-3a-54bec7cf341c
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (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 C6.D6.03326.FC7CEB45; Tue, 20 Jan 2015 16:25:35 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t0KLPYkE031061; Tue, 20 Jan 2015 16:25:35 -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 t0KLPWok028276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Jan 2015 16:25:34 -0500
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t0KLPWmg001902; Tue, 20 Jan 2015 16:25:32 -0500 (EST)
Date: Tue, 20 Jan 2015 16:25:32 -0500
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: kitten@ietf.org
In-Reply-To: <1421269970.18482.184.camel@minbar.fac.cs.cmu.edu>
Message-ID: <alpine.GSO.1.10.1501201620290.23489@multics.mit.edu>
References: <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> <20141217230505.GD9443@localhost> <20141220001633.GD12662@localhost> <1421269970.18482.184.camel@minbar.fac.cs.cmu.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+NgFnrPIsWRmVeSWpSXmKPExsUixG6nonv++L4Qg0X3dS2Obl7FYnHq2hE2 ByaPl6fOMXosWfKTKYApissmJTUnsyy1SN8ugSvj671ZjAVNqhULp79jbWDslu1i5OSQEDCR uLn1HTOELSZx4d56ti5GLg4hgcVMEl92XGCEcDYySmxf+BTKOcQkceTiGmYIp4FR4ue+bjaQ fhYBbYkNnxtZQGw2ARWJmW82gsVFBIQldkPtYBbQlNjY1Q5mCwPZO7/eYgWxOQXsJfZ1LWAH sXkFHCVOPfwJteA3s8SOhRPBEqICOhKr909hgSgSlDg58wkLxFAtieXTt7FMYBSchSQ1C0lq ASPTKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl0zvdzMEr3UlNJNjOBwdVHewfjnoNIhRgEORiUe 3per9oYIsSaWFVfmHmKU5GBSEuV9M2lfiBBfUn5KZUZicUZ8UWlOavEhRgkOZiURXt3DQDne lMTKqtSifJiUNAeLkjjvph98IUIC6YklqdmpqQWpRTBZGQ4OJQne/mNAjYJFqempFWmZOSUI aSYOTpDhPEDDN4HU8BYXJOYWZ6ZD5E8xKkqJ83aDJARAEhmleXC9sHTyilEc6BVh3l6QKh5g KoLrfgU0mAlosNiuPSCDSxIRUlINjE6fXFzNHR45JV75/Vn57KPeIFdjg9h9pd21z96+PzZP XDgnnT+wUjxRoeqkcOativvHXgu81/j3xK70sHO22u5HAXGbptVsm/n2xK5uKaa6Zx2zOHun 8pyOvLbig1iOUNHsxgOMfjqFakvzRU6wPvbX2O87Zbb71P/xURMkq82MSrtXpc88pMRSnJFo qMVcVJwIAFt0fnoCAwAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/ECWz55lZcsM0lvcFgF6aBf3rKP8>
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, 20 Jan 2015 21:25:39 -0000
On Wed, 14 Jan 2015, Jeffrey Hutzelman wrote: > On Fri, 2014-12-19 at 18:16 -0600, Nico Williams wrote: > > On further thought, since context deletion tokens are obsoleted, and > > have been for a long time, we might as well say nothing about > > GSS_S_COMPLETE implying that the peer is done using its side of the > > security context. The GSS_S_FAILURE case, however, still kinda leads to > > the caller being done. > > > > OLD PROPOSED TEXT > > | 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. > > > > NEW: > > | Applications should generally call GSS_Delete_sec_context() when > > | GSS_Process_context_token() returns GSS_S_FAILURE. > > FWIW, I agree with Greg that it's not reasonable to assume, or suggest > that applications assume, that all asynchronous context tokens are > deletion tokens or mean that the context is now dead. So, the above > change is an improvement. > > However, after reading this thread, I'm not convinced we need to give > applications any guidance about calling GSS_Delete_sec_context after > processing a context token. Nico thinks that saying "generally" makes > it OK, but I disagree. The word "generally" here isn't an effective > weasel word; it's a particle. If you describe what the exceptions are, > you don't need it, and if you don't, then it doesn't do you any good. > Implementors are going to read the text as if the word wasn't there. > > > I think it is worth noting that if we start giving new implementation > guidance to applications in an erratum, people who read it will assume > it must be important and start doing that, because otherwise, why did we > go out of our way to publish an erratum? Thank you for the input, Jeff. I think this point has not really been mentioned yet in our discussions, and is an important one. > The purpose of errata is to fix technical or editorial errors and > omissions in the existing spec. They are not for changing the spec or > offering new guidance. We should stick to doing the former, and leave > the latter for a new or updated document, if it's necessary. I think this makes the current proposal under consideration (removing entirely the paragraph which attempted to give applications guidance on when to call GSS_Delete_sec_context()): ====================================================== 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. In the case of successful processing of error tokens, the minor status code provides information from the input token. The display string outputs of GSS_Display_status() as applied to such minor status codes should indicate that the error originated on the remote peer, along with the nature of the error. Note that there is no way to distinguish failures of GSS_Process_context_token() from error token information other than to read the human-readable status display strings. In practice, an unexpected security context token that imediately follows full security context establishment is very likely a context token conveying error information rather than a security context deletion token, especially since the latter are obsoleted. Applications using transports that may deliver messages out of order may continue to attempt to process per-message tokens between calling GSS_Process_context_token() and GSS_Delete_sec_context(), though there is no guarantee that processing per-message tokens will then succeed. ====================================================== I will send my thoughts in a separate message. -Ben
- [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Martin Rex
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Greg Hudson
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Greg Hudson
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Greg Hudson
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Martin Rex
- Re: [kitten] RFC2743 errata 4251 Martin Rex
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Martin Rex
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Stephen Farrell
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Martin Rex
- Re: [kitten] RFC2743 errata 4251 Stephen Farrell
- Re: [kitten] RFC2743 errata 4251 Greg Hudson
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Jeffrey Hutzelman
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Greg Hudson
- Re: [kitten] RFC2743 errata 4251 Jeffrey Hutzelman