Re: [kitten] RFC2743 errata 4251

Benjamin Kaduk <kaduk@MIT.EDU> Wed, 10 December 2014 18:58 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 A82D51A8A9B for <kitten@ietfa.amsl.com>; Wed, 10 Dec 2014 10:58:01 -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 kzUn0p4ftnTp for <kitten@ietfa.amsl.com>; Wed, 10 Dec 2014 10:57:55 -0800 (PST)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 263581A8A87 for <kitten@ietf.org>; Wed, 10 Dec 2014 10:57:55 -0800 (PST)
X-AuditID: 12074424-f791c6d000000d25-f1-548897b1c388
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-7.mit.edu (Symantec Messaging Gateway) with SMTP id 84.43.03365.2B798845; Wed, 10 Dec 2014 13:57:54 -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 sBAIvrHU006976; Wed, 10 Dec 2014 13:57:53 -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 sBAIvpeF010768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Dec 2014 13:57:52 -0500
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sBAIvpLh020336; Wed, 10 Dec 2014 13:57:51 -0500 (EST)
Date: Wed, 10 Dec 2014 13:57:50 -0500
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: Nico Williams <nico@cryptonector.com>
In-Reply-To: <20141210002441.GP12979@localhost>
Message-ID: <alpine.GSO.1.10.1412101349030.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>
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+NgFnrDIsWRmVeSWpSXmKPExsUixG6nortpekeIwd1mZoujm1exWJy6doTN gcnj5alzjB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq4cHQzc8FskYonC/6wNDDe4u9i5OCQEDCR uNDr1sXICWSKSVy4t56ti5GLQ0hgMZPE8vP/WSGcjYwSv3bvYYJwDjFJzP1zGCrTwCjx7eh1 ZpBRLALaEreOuIOMYhNQkZj5ZiMbiC0ioClxfd5SMJtZQFhi/bkZzCC2MFB859dbrCCtnAL6 Eotu1oOEeQUcJb7/Pwy1q5tZYuutw2D1ogI6Eqv3T2GBKBKUODnzCQvETC2J5dO3sUxgFJyF JDULSWoBI9MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXXO93MwSvdSU0k2M4EB1UdnB2HxI6RCj AAejEg9vwOX2ECHWxLLiytxDjJIcTEqivLundoQI8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuE9 Mxkox5uSWFmVWpQPk5LmYFES5930gy9ESCA9sSQ1OzW1ILUIJivDwaEkwWs6DahRsCg1PbUi LTOnBCHNxMEJMpwHaHg6SA1vcUFibnFmOkT+FKOilDjvX5CLBEASGaV5cL2wRPKKURzoFWHe DJB2HmASgut+BTSYCWjwi8RWkMEliQgpqQZGNddMpn1d15j25qcWSkhXHXOUPOXR1vtBP7f+ 5F6PpY13K5uWromdZ8nzsVT85Vkn61jHPzFzJCOsF+6S7J5zfeckdx9LsW9v+tQm/p1+xj/m 7fmAZ11fxacV62Y5HWIQL/PeGtuU+FUgi/HdPxYLp1mvzG94i5VYnt0euu29WtQbblX95AdK LMUZiYZazEXFiQDlL6O+/wIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/OZ_0cWG5Yw6ZgJSGWezJToxJU4w
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, 10 Dec 2014 18:58:01 -0000

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.

     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.

     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.

     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.

======================================================

It would be good to hear comments from people other than Nico and I.
(Martin?  Greg?)

-Ben