Re: [kitten] RFC2743 errata 4251

Nico Williams <nico@cryptonector.com> Mon, 24 November 2014 18:51 UTC

Return-Path: <nico@cryptonector.com>
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 EFB361A879C for <kitten@ietfa.amsl.com>; Mon, 24 Nov 2014 10:51:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.034
X-Spam-Level: *
X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 ncZPQfZtAnea for <kitten@ietfa.amsl.com>; Mon, 24 Nov 2014 10:51:33 -0800 (PST)
Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B18BC1A87AE for <kitten@ietf.org>; Mon, 24 Nov 2014 10:51:17 -0800 (PST)
Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 8E7AD163E; Mon, 24 Nov 2014 10:51:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Hi4O3a3mSRXsH+ F6pV4svecx2/Y=; b=MLi/wttgOyvNDvj8vxKPrrKzFmx8WkPKeH7IolBxL1EdbP mGQ2zDT/W2hm6lKUH1BG5ODCsebUKhvv8zzOh8OPoYGIqj0S4NEPLrnahvZubwqi hawY3SWZif+YEdPvPFiebMKaVATJIO1XFRCNZNgw1EEZYjp72IbKyGQEJLKuA=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPA id 46B65161E; Mon, 24 Nov 2014 10:51:17 -0800 (PST)
Date: Mon, 24 Nov 2014 12:51:16 -0600
From: Nico Williams <nico@cryptonector.com>
To: Benjamin Kaduk <kaduk@MIT.EDU>
Message-ID: <20141124185114.GM3200@localhost>
References: <20141104204714.GI7913@localhost> <20141108014820.3278A1AFAB@ld9781.wdf.sap.corp> <20141110162504.GA3412@localhost> <alpine.GSO.1.10.1411241330400.19231@multics.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.GSO.1.10.1411241330400.19231@multics.mit.edu>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/2LmHDhi_OSjlmIVlxYGlfft4Ehs
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: Mon, 24 Nov 2014 18:51:35 -0000

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
     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
     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.

     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
     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.

Nico
--