Re: [kitten] RFC2743 errata 4251

Benjamin Kaduk <kaduk@MIT.EDU> Wed, 21 January 2015 01:20 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 0935A1A00FB for <kitten@ietfa.amsl.com>; Tue, 20 Jan 2015 17:20:46 -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 y0VNmw37W8Qs for <kitten@ietfa.amsl.com>; Tue, 20 Jan 2015 17:20:43 -0800 (PST)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBD911A00FA for <kitten@ietf.org>; Tue, 20 Jan 2015 17:20:40 -0800 (PST)
X-AuditID: 1209190d-f79006d000000cfe-80-54befee7ecb1
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-2.mit.edu (Symantec Messaging Gateway) with SMTP id 82.1E.03326.7EEFEB45; Tue, 20 Jan 2015 20:20:39 -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 t0L1Kdj7020613 for <kitten@ietf.org>; Tue, 20 Jan 2015 20:20:39 -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 t0L1KbLE001778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <kitten@ietf.org>; Tue, 20 Jan 2015 20:20:38 -0500
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t0L1Kadt003922; Tue, 20 Jan 2015 20:20:36 -0500 (EST)
Date: Tue, 20 Jan 2015 20:20:36 -0500
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: kitten@ietf.org
In-Reply-To: <alpine.GSO.1.10.1501201620290.23489@multics.mit.edu>
Message-ID: <alpine.GSO.1.10.1501201908540.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> <alpine.GSO.1.10.1501201620290.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+NgFrrBIsWRmVeSWpSXmKPExsUixG6nrvv8374QgxvLNSyObl7F4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujFkv/zAVbJKqmPJ9KVMD402RLkZODgkBE4me9ldsELaYxIV7 68FsIYHFTBL3F8p3MXIB2ccZJa729jNBODeYJJrOL2eBcBoYJQ4+/8MM0sIioC3xZs0hRhCb TUBFYuabjWCjRASEJXZvfQdWIyygKbHz6y1WEJtTwEni4/29YDavgKPE5vtLmCGGbmSR6Jjz HmyQqICOxOr9U1ggigQlTs58AmYzC2hJLJ++jWUCo8AsJKlZSFILGJlWMcqm5Fbp5iZm5hSn JusWJyfm5aUW6Rrp5WaW6KWmlG5iBAUgpyTvDsZ3B5UOMQpwMCrx8Dqs3RsixJpYVlyZe4hR koNJSZQ36+++ECG+pPyUyozE4oz4otKc1OJDjBIczEoivH0fgHK8KYmVValF+TApaQ4WJXHe TT/4QoQE0hNLUrNTUwtSi2CyMhwcShK810CGChalpqdWpGXmlCCkmTg4QYbzAA3PAanhLS5I zC3OTIfIn2JUlBLnXQySEABJZJTmwfXCEsQrRnGgV4R594FU8QCTC1z3K6DBTECDxXbtARlc koiQkmpgXPBOROrLcl/H9A1WzsILulW3db/y/Bovdu12dbDP3HYGxy1V/BLXDPXi8jQrfS+d bVX/ziQs7PT93YvV94/0x2iFRkQEmzgWCO7h9zjgu2ZmjsOukjou4xUebVpXctc+mcsxoT/v 9CWj5N0M8kEHb58s3Lvh4oXAmVtEVl8O/zaFv3bHpb42JZbijERDLeai4kQAI60WkusCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/iw9rhGlIFgjhtW9eSY_1-m5cwD0>
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, 21 Jan 2015 01:20:46 -0000

On Tue, 20 Jan 2015, Benjamin Kaduk wrote:

> 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

"had an error" feels slightly informal; I might prefer "experienced an
error" or something like that.

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

Given what Jeff pointed out about new statements in errata being taken as
indicating important (new) changes, I wonder if this paragraph should also
be removed.  I believe it to be a true statement, but perhaps including it
in the erratum at all will give it more weight than is appropriate.  It is
also the first mention of deletion tokens in section 2.2.4 (another
mention does occur later on), so it comes in somewhat abruptly without
introduction.

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

This also may be too much information for the erratum.  (Again, I believe
it is basically a correct statement, but that including it in the erratum
may cause it to be given too much weight.)

What do other people think?

-Ben

> ======================================================
>
> I will send my thoughts in a separate message.
>
> -Ben
>
> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten
>