Re: [kitten] RFC2743 errata 4251

Benjamin Kaduk <kaduk@MIT.EDU> Tue, 16 December 2014 19:53 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 6EF331A873C for <kitten@ietfa.amsl.com>; Tue, 16 Dec 2014 11:53:33 -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 KxH_UY8P4zO6 for <kitten@ietfa.amsl.com>; Tue, 16 Dec 2014 11:53:31 -0800 (PST)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FE5F1A873E for <kitten@ietf.org>; Tue, 16 Dec 2014 11:53:31 -0800 (PST)
X-AuditID: 12074425-f798e6d000000d1a-4b-54908dba75cd
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-8.mit.edu (Symantec Messaging Gateway) with SMTP id 98.D5.03354.ABD80945; Tue, 16 Dec 2014 14:53:30 -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 sBGJrTYk018377; Tue, 16 Dec 2014 14:53:29 -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 sBGJrQ9b026143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Dec 2014 14:53:28 -0500
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sBGJrQKD028232; Tue, 16 Dec 2014 14:53:26 -0500 (EST)
Date: Tue, 16 Dec 2014 14:53:26 -0500
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
In-Reply-To: <549082D6.9060000@cs.tcd.ie>
Message-ID: <alpine.GSO.1.10.1412161443400.23489@multics.mit.edu>
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> <alpine.GSO.1.10.1412161057050.23489@multics.mit.edu> <20141216164426.GU3241@localhost> <20141216165018.GW3241@localhost> <549082D6.9060000@cs.tcd.ie>
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+NgFvrGIsWRmVeSWpSXmKPExsUixG6nrrurd0KIwc/T3BZHN69isTh17Qib xfS919gdmD1enjrH6LG2+yqbx5IlP5kCmKO4bFJSczLLUov07RK4Mp4dySn4xlvx4IF9A+NU 7i5GTg4JAROJI4sPs0HYYhIX7q0Hsrk4hAQWM0m8eNTPBOFsZJSY3n+PEcI5xCTR/vgQlNPA KNHz/QsrSD+LgLbEmh/PwWaxCahIzHyzEcwWEdCX2Lv5HDuIzSxgJdH4uxUsLiygKbHz6y2g Xg4OTiD7SHsxSJhXwFFiyokfrBDz21gkDux5zgySEBXQkVi9fwoLRJGgxMmZT1ggZmpJLJ++ jWUCo+AsJKlZSFILGJlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Vro5WaW6KWmlG5iBAevi+oO xgmHlA4xCnAwKvHwBhT2hwixJpYVV+YeYpTkYFIS5V3QMyFEiC8pP6UyI7E4I76oNCe1+BCj BAezkggvcyNQjjclsbIqtSgfJiXNwaIkzrvpB1+IkEB6YklqdmpqQWoRTFaGg0NJgvczyFDB otT01Iq0zJwShDQTByfIcB6g4ZNAaniLCxJzizPTIfKnGBWlxHk1gOlBSAAkkVGaB9cLSy6v GMWBXhHmrQVp5wEmJrjuV0CDmYAGT/7cDzK4JBEhJdXAWLaQ2UtUI2+9go7nejEHA51GzSVu Ndky7UnrtkXk2QQ/vxt4TPOigNHVT3Oc5Bcc/f/jvsWhLwWzlfJ+387+Fn/3opVR0U79U2+C C9/OsgnwdA3dx6K7xe/tPkVvG+GFxnWrM6XZT0QkWnqsF5nMkitg/iUi9c80xwfKb7mXOsow /rz1tZlLiaU4I9FQi7moOBEAKsWCPAkDAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/aTL1HrLFq70orr7jZ29tRl8LKcg
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 19:53:33 -0000

On Tue, 16 Dec 2014, Stephen Farrell wrote:

>
> Meta question: if it requires so much discussion is this
> really suited as an erratum? Just wondering:-)

Well, I think the crux of it is that the thing which is inspiring so many
words is not really suited as an erratum, but that's only a small part of
the actual proposed text.

The main goal is to fix the broken behavior of
GSS_Process_context_token(), which as written in RFC 2743 does not allow a
caller to obtain information from a processed error token.  (If that's the
case, there's no reason to specify error tokens, so it's clearly a bug.)

However, the proposed text also adds this paragraph:

     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.

which is adding new text which attempts to clarify how applications
consume the GSS-API.  It is this paragraph which is controversial, and it
is perhaps not appropriate for an erratum.  We may be better off both
consensus-wise and process-wise if we eliminate this paragraph and leave
the current description of how to call GSS_Process_conetxt_token() as it
is in RFC 2743.  (Nico will probably say that "generally" is wiggle room
so this is not actually normative, but even with that, it's not clear that
this paragraph adds enough to merit inclusion in an erratum.)

Skipping that paragraph would allow us to move forward and fix the clear
brokenness in the spec, without being bogged down trying to resolve a
different apparent ambiguity.

-Ben