Re: [kitten] RFC2743 errata 4251

Benjamin Kaduk <kaduk@MIT.EDU> Wed, 10 December 2014 00:03 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 74B851A6EF2 for <kitten@ietfa.amsl.com>; Tue, 9 Dec 2014 16:03:00 -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 tEe18ylNuuVN for <kitten@ietfa.amsl.com>; Tue, 9 Dec 2014 16:02:58 -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 887B11A6EF1 for <kitten@ietf.org>; Tue, 9 Dec 2014 16:02:58 -0800 (PST)
X-AuditID: 12074424-f791c6d000000d25-10-54878db1bcad
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (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 16.2A.03365.1BD87845; Tue, 9 Dec 2014 19:02:57 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id sBA02uCh025349; Tue, 9 Dec 2014 19:02:57 -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 sBA02sUU023506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Dec 2014 19:02:56 -0500
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sBA02src017056; Tue, 9 Dec 2014 19:02:54 -0500 (EST)
Date: Tue, 09 Dec 2014 19:02:54 -0500
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: Nico Williams <nico@cryptonector.com>
In-Reply-To: <20141209215519.GI12979@localhost>
Message-ID: <alpine.GSO.1.10.1412091856160.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>
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+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrLuxtz3E4OABEYujm1exWJy6doTN gcnj5alzjB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4/iauYIV0xY9eywbG18JdjJwcEgImEl3n v7FD2GISF+6tZ+ti5OIQEljMJHFjwjFmCGcDo8T1q2uhnINMEosO/QFrERKol9jw6AYziM0i oCXx9dFURhCbTUBFYuabjWwgtoiApsT1eUvBbGYBYYn152aA1QsDxXd+vcUKYnMK6Etce3ke zOYVcJT41byWFWLZJiaJvZ86mEASogI6Eqv3T2GBKBKUODnzCQvEUC2J5dO3sUxgFJyFJDUL SWoBI9MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXXO93MwSvdSU0k2MoEBld1HZwdh8SOkQowAH oxIPr4ZlW4gQa2JZcWXuIUZJDiYlUd4rNe0hQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR417IA 5XhTEiurUovyYVLSHCxK4rybfvCFCAmkJ5akZqemFqQWwWRlODiUJHhX9AA1ChalpqdWpGXm lCCkmTg4QYbzAA13BqnhLS5IzC3OTIfIn2JUlBLnNQJJCIAkMkrz4HphieQVozjQK8K81iBV PMAkBNf9CmgwE9DgF4mtIINLEhFSUg2MFeo/LNaKtqoF/Vlwq3wbj96EOe9D11Y1cRkfu/0u w6jaujDoxTQnqalq/ILOj0uTGwSC5fRTFzFtd1y45t9lLVXeAm+7nescFd5fNXPZdfgH2/m+ Q07MD95eVynZ8LtFY0bZs2DG388i3r0vZPcSnjlDbMa+Ou3Wm4pfVOK6Zjyx5Bc6uLhBiaU4 I9FQi7moOBEAFjxu0v8CAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/wIn550aKzUv2Mn3ko9hcU4JuQLs
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 00:03:00 -0000

On Tue, 9 Dec 2014, Nico Williams wrote:

> On Tue, Dec 09, 2014 at 04:36:41PM -0500, Benjamin Kaduk wrote:
> > On Mon, 24 Nov 2014, Nico Williams wrote:
> > >   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 (when the
> >
> > I might make the parenthentical be a new sentence,
>
> Maybe.
>
> >                                             [...], and reword it slightly
> > to:
>
> This is just the re-write of the parenthetical?

Correct.  (It's a bit long for such a re-write.)

> > In order for errors from the peer to be conveyed as input context tokens
> > to GSS_Process_context_token() (as opposed to one of the
> > context-establishment calls GSS_Init_sec_context() or
> > GSS_Accept_sec_context()), the local side must already have been fully
> > established but the remote peer's side not established.
>
> How about:
>                                                     [...], or the peer
>    had an error consuming the last context token sent to it.  [insert here]
>
>                                                               The latter
>    occurs when the local side became fully established upon producing
>    one last context token that then triggered an error on the remote
>    peer.  In either case the minor status code...

That's better than mine, but probably still has some room for tweaking.
Just throwing something out there:

The latter occurs when the local side became fully established and
produced one last context token which was sent to the peer, but the peer
encountered an error while processing that last context token.


> > >      local side must have been fully established but the peer hadn't yet
> > >      been).  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 this, but note that there is no way to
> >
> > "this" is vague.  How about "that the error originated on the remote peer,
> > along with the nature of the error"?
>
> Agreed.
>
> > At this point, the sentence is getting a bit long, so breaking before "but
> > note" and just starting a new sentence with "Note" may be in order.
>
> Agreed.
>
> > >      distinguish failures of GSS_Process_context_token() from error
> > >      token information other than to read the human-readable status
> > >      display strings.  Since status display strings are not machine-
> > >      readable, there is no way to programmatically make this
> > >      distinction.
> >
> > Again about "this".
>
> Well, the following word ('distinction') relates to the previous
> sentence's 'distinguish', so I think it's safe.  We could just... remove
> that last sentence and be done: it adds nothing[*].

I think I would be okay with that.

> [*] So why did I write it in the first place?

I don't know :)


Once we nail down the text about why the peer would be producing an error
token, I can turn this into a new erratum candidate text.

-Ben