Re: [kitten] RFC2743 errata 4251

Benjamin Kaduk <kaduk@MIT.EDU> Wed, 25 February 2015 16:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D1EFD1A03A1 for <>; Wed, 25 Feb 2015 08:40:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.312
X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pGA7dzO6MOWm for <>; Wed, 25 Feb 2015 08:40:17 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0A4E51A0366 for <>; Wed, 25 Feb 2015 08:40:16 -0800 (PST)
X-AuditID: 12074425-f79846d0000054e1-d1-54edfaeff758
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id F6.F2.21729.FEAFDE45; Wed, 25 Feb 2015 11:40:15 -0500 (EST)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id t1PGeEm6029206 for <>; Wed, 25 Feb 2015 11:40:15 -0500
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id t1PGeDIq014686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <>; Wed, 25 Feb 2015 11:40:14 -0500
Received: (from kaduk@localhost) by ( id t1PGeCah013739; Wed, 25 Feb 2015 11:40:12 -0500 (EST)
Date: Wed, 25 Feb 2015 11:40:12 -0500 (EST)
From: Benjamin Kaduk <kaduk@MIT.EDU>
In-Reply-To: <>
Message-ID: <>
References: <> <20141124185114.GM3200@localhost> <> <20141209215519.GI12979@localhost> <> <20141210002441.GP12979@localhost> <> <> <> <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+NgFrrOIsWRmVeSWpSXmKPExsUixCmqrfv+19sQg47Z6hZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsMF11kLGqUqNvxpZmtgXCvSxcjJISFgInFo/XxWCFtM4sK9 9WwgtpDAYiaJ9T9Kuxi5gOzjjBITP55gg3BuMEncuPyNHcJpYJSYcnUJcxcjBweLgLbE5yd+ IN1sAioSM99sBJskIiAssXvrO2YQW1hAU2Ln11tg2zgFnCR+bm5lAbF5BRwkvnT+h1rwnEVi 8+3dYEWiAjoSq/dPgSoSlDg58wmYzSygJbF8+jaWCYwCs5CkZiFJLWBkWsUom5JbpZubmJlT nJqsW5ycmJeXWqRroZebWaKXmlK6iREUfuwuqjsYJxxSOsQowMGoxMN7QOZNiBBrYllxZe4h RkkOJiVR3oqfb0OE+JLyUyozEosz4otKc1KLDzFKcDArifC2vQLK8aYkVlalFuXDpKQ5WJTE eTf94AsREkhPLEnNTk0tSC2CycpwcChJ8F4EGSpYlJqeWpGWmVOCkGbi4AQZzgM0/ApIDW9x QWJucWY6RP4Uo6KUOO9ckIQASCKjNA+uF5YeXjGKA70izPsUpIoHmFrgul8BDWYCGrzn8SuQ wSWJCCkpYJoInj6Ja+eG7gnH/4u3lNxy1PPoWSEX7bCMs6Gt3GjKhFOOPvc03hRXvPohkf3B ivGpjpSx6rdFXU8t0i/I3ZA89WSH+AH/u7GvXqakWWW3BGcbLJ3Pr3S+89REw0C3rSy7XyjZ zahjzqy4unev0JPFlo7Pbv59Kx1k49OWUfomXcE/pDJypxJLcUaioRZzUXEiAB1o6knqAgAA
Archived-At: <>
Subject: Re: [kitten] RFC2743 errata 4251
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Feb 2015 16:40:19 -0000

On Tue, 20 Jan 2015, Benjamin Kaduk wrote:

> On Tue, 20 Jan 2015, Benjamin Kaduk wrote:
> >      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?

This doesn't seem to have received any replies, so let me rephrase in the
form of a new proposed erratum text:


  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.


Removing the last paragraph ("Applications using transports ...") removes
the only text implying that callers of GSS_Process_context_token() are
still required to eventually call GSS_Delete_sec_context().  Do we think
that text to that effect is needed in this erratum (as opposed to a
separate one)?