Re: [kitten] RFC2743 errata 4251
Benjamin Kaduk <kaduk@MIT.EDU> Tue, 09 December 2014 21:36 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 13E721A8A76 for <kitten@ietfa.amsl.com>; Tue, 9 Dec 2014 13:36:59 -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 i0QXOcGTvFdL for <kitten@ietfa.amsl.com>; Tue, 9 Dec 2014 13:36:56 -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 5BB3E1A8A78 for <kitten@ietf.org>; Tue, 9 Dec 2014 13:36:46 -0800 (PST)
X-AuditID: 12074424-f791c6d000000d25-25-54876b6dfea2
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 DC.50.03365.D6B67845; Tue, 9 Dec 2014 16:36:45 -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 sB9LaiW5009330; Tue, 9 Dec 2014 16:36:44 -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 sB9LagSb004562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Dec 2014 16:36:43 -0500
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id sB9LafwC023763; Tue, 9 Dec 2014 16:36:41 -0500 (EST)
Date: Tue, 09 Dec 2014 16:36:41 -0500
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: Nico Williams <nico@cryptonector.com>
In-Reply-To: <20141124185114.GM3200@localhost>
Message-ID: <alpine.GSO.1.10.1412091618550.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>
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+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrJub3R5i0LGL2+Lo5lUsFqeuHWFz YPJ4eeoco8eSJT+ZApiiuGxSUnMyy1KL9O0SuDKuPn3DVrBYuuL26vPsDYyzRLsYOTkkBEwk pl15wQZhi0lcuLceyObiEBJYzCSx7MgXRghnA6PEyt/v2CGcg0wS247dZgZpERKolzhx9gIL iM0ioCWxZe0xRhCbTUBFYuabjWBjRQQ0Ja7PWwpmMwsIS6w/NwOsVxgovvPrLdYuRg4OTgE9 iTl9mSBhXgFHif7We1BXXGeUOPfyPitIQlRAR2L1/iksEEWCEidnPmGBmKklsXz6NpYJjIKz kKRmIUktYGRaxSibklulm5uYmVOcmqxbnJyYl5dapGuul5tZopeaUrqJERSq7C4qOxibDykd YhTgYFTi4dWwbAsRYk0sK67MPcQoycGkJMr7PLk9RIgvKT+lMiOxOCO+qDQntfgQowQHs5II 71oWoBxvSmJlVWpRPkxKmoNFSZx30w++ECGB9MSS1OzU1ILUIpisDAeHkgTvyiygRsGi1PTU irTMnBKENBMHJ8hwHqDhK0BqeIsLEnOLM9Mh8qcYFaXEebtBEgIgiYzSPLheWCp5xSgO9Iow 771MoCoeYBqC634FNJgJaPCLxFaQwSWJCCmpBkZb87mujl9kDL5OyT3PeLt6y99Dkv7GJi83 vte9fKrdTVzI32rW4qW8nk6fv/E1i037fEPq5v01h/NvX9Y9NSmP6dyL2b5e4mzBrxb0f5nU +Sj4v/+myE3VZY/P7tTbqu9XdybDiX3jRy3D9TW739Rsy9+45M1219erDk/8FDb1ldjFJ8bT 2n5vVGIpzkg01GIuKk4EACMzbSIAAwAA
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/SYxmNAltFhyHn2qeamR_U7i88NA
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, 09 Dec 2014 21:36:59 -0000
Some potential tweaks. On Mon, 24 Nov 2014, Nico Williams wrote: > New proposal: > > 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 (when the I might make the parenthentical be a new sentence, and reword it slightly to: 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. > 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"? 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. > 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". Perhaps "programmatically distinguish between an error internal to GSS_Process_context_token() and a supplied error token"? > 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's no guarantee that processing per-message tokens will I have a marginal preference for avoiding contractions in formal documents (i.e., "there is"). > then succeed. > > I hope this addresses all concerns, both Martin's and those arising from > the loop I-D. > > Feel free to propose alternative text. How do you feel about the tidbits above? -Ben
- [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Martin Rex
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Greg Hudson
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Greg Hudson
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Greg Hudson
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Martin Rex
- Re: [kitten] RFC2743 errata 4251 Martin Rex
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Martin Rex
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Stephen Farrell
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Martin Rex
- Re: [kitten] RFC2743 errata 4251 Stephen Farrell
- Re: [kitten] RFC2743 errata 4251 Greg Hudson
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Jeffrey Hutzelman
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Greg Hudson
- Re: [kitten] RFC2743 errata 4251 Jeffrey Hutzelman