Re: [kitten] RFC2743 errata 4251

Benjamin Kaduk <kaduk@MIT.EDU> Wed, 31 December 2014 22:34 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 77ECF1A1A52 for <kitten@ietfa.amsl.com>; Wed, 31 Dec 2014 14:34:17 -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 bb8nsWGojAF6 for <kitten@ietfa.amsl.com>; Wed, 31 Dec 2014 14:34:16 -0800 (PST)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id D56C01A1A4D for <kitten@ietf.org>; Wed, 31 Dec 2014 14:34:15 -0800 (PST)
X-AuditID: 12074422-f79476d000000d9e-93-54a479e7501a
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-5.mit.edu (Symantec Messaging Gateway) with SMTP id 93.2D.03486.7E974A45; Wed, 31 Dec 2014 17:34:15 -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 sBVMYEL8002273; Wed, 31 Dec 2014 17:34:14 -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 sBVMYCIZ015379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Dec 2014 17:34:13 -0500
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sBVMYB6A015648; Wed, 31 Dec 2014 17:34:11 -0500 (EST)
Date: Wed, 31 Dec 2014 17:34:11 -0500
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: Nico Williams <nico@cryptonector.com>
In-Reply-To: <20141220001633.GD12662@localhost>
Message-ID: <alpine.GSO.1.10.1412311730080.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>
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+NgFnrNIsWRmVeSWpSXmKPExsUixG6nrvu8ckmIwa87vBZHN69isTh17Qib A5PHy1PnGD2WLPnJFMAUxWWTkpqTWZZapG+XwJXR+eM1S8FH7opDi+MbGA9ydjFyckgImEgc 7tnGBmGLSVy4tx7I5uIQEljMJNH28BcLSEJIYCOjRMf2aIjEISaJn03v2CGcBkaJ1/37mbsY OThYBLQlriwUAWlgE1CRmPlmI9hUEQFNievzlrKBlDALGElc+JUBEhYGCu/8eosVxOYU0Jf4 M/8pmM0r4Chx/vAdqCOOMUusONTPDJIQFdCRWL1/CgtEkaDEyZlPwGxmAS2J5dO3sUxgFJyF JDULSWoBI9MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXVO93MwSvdSU0k2M4DB1UdrB+POg0iFG AQ5GJR7eBpvFIUKsiWXFlbmHGCU5mJREeTWSl4QI8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuHt kwPK8aYkVlalFuXDpKQ5WJTEeTf94AsREkhPLEnNTk0tSC2CycpwcChJ8K6oAGoULEpNT61I y8wpQUgzcXCCDOcBGi5cCTK8uCAxtzgzHSJ/ilFRSpz3KUizAEgiozQPrheWRl4xigO9Iszb ClLFA0xBcN2vgAYzAQ3O37QYZHBJIkJKqoHRd8FN3Xt3z/YwNs8JOm/VUXpB59nEFxv9imX3 fL6rzqjNqaBvzjyT+61uw37F2foh76NmhpZs5sxkWPjwlJDswtsuZ47ev/9S9McmK8MXLdfe LcnmCNG48WhF+w2NZtWAysX3Z1XVTWhczTjd7lzCkei6bP7tZ5/Zbfe+Y1morvd4ncKV8zPK lFiKMxINtZiLihMBc8xCbP4CAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/qQicNbX3yVQTQb_AFhdaRBx-IDg
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: Wed, 31 Dec 2014 22:34:17 -0000

On Fri, 19 Dec 2014, 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.

I suppose I could live with this, but I still don't see how it's actually
adding enough to merit inclusion in an erratum.

That is, the application is going to be calling GSS_Delete_sec_context()
eventually anyway, so we're just saying that failures of
Process_context_token() should (generally) fail the whole context
(immediately).  Would application authors (generally) do anything else
upon presented with a GSS_S_FAILURE from Process_context_token()?  It
seems like it is just calling out a specific case of what people should
already be doing, which is not tied to the key component of the erratum.

-Ben