Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00

Greg Hudson <ghudson@mit.edu> Thu, 05 February 2015 16:07 UTC

Return-Path: <ghudson@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 110261A884C for <kitten@ietfa.amsl.com>; Thu, 5 Feb 2015 08:07:12 -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 Bvo4NSGeWQbM for <kitten@ietfa.amsl.com>; Thu, 5 Feb 2015 08:07:10 -0800 (PST)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A8C91A88DC for <kitten@ietf.org>; Thu, 5 Feb 2015 08:07:09 -0800 (PST)
X-AuditID: 1209190c-f79e46d000000eb2-26-54d3952b7acc
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-1.mit.edu (Symantec Messaging Gateway) with SMTP id 9B.E1.03762.C2593D45; Thu, 5 Feb 2015 11:07:08 -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 t15G71FC028039; Thu, 5 Feb 2015 11:07:02 -0500
Received: from [18.101.8.163] (vpn-18-101-8-163.mit.edu [18.101.8.163]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t15G6xIr032308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Feb 2015 11:07:01 -0500
Message-ID: <54D39523.5070700@mit.edu>
Date: Thu, 05 Feb 2015 11:06:59 -0500
From: Greg Hudson <ghudson@mit.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Weijun Wang <weijun.wang@oracle.com>, Benjamin Kaduk <kaduk@mit.edu>, kitten@ietf.org
References: <alpine.GSO.1.10.1501201753140.23489@multics.mit.edu> <54CE9F5B.9070808@mit.edu> <54CEE8E5.5080701@oracle.com> <54D2FCD5.6060404@oracle.com> <54D3190D.8080003@mit.edu> <54D31FD0.9030508@oracle.com>
In-Reply-To: <54D31FD0.9030508@oracle.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixG6noqsz9XKIwYduNoujm1exWHxduoHZ gcljyZKfTB4fn95iCWCK4rJJSc3JLEst0rdL4Mp4+VSnYIlAxelrSxgbGNt4uxg5OSQETCSO rf7NCGGLSVy4t56ti5GLQ0hgMZPEuQXLmCCcDYwSK1d/hMocZpKYN/cCkMPBwSugJvFlkTZI N4uAqsS1jv9gk9gElCXW79/KAlIiKhAmcb4ZLMwrIChxcuYTFhBbRCBJoq15Cdh8YYGZjBKd Z5qhll1klHix9AIrSBWngJZE479nbCA2s4CexI7rv1ghbHmJ5q2zmScwCsxCMngWkrJZSMoW MDKvYpRNya3SzU3MzClOTdYtTk7My0st0jXUy80s0UtNKd3ECApUTkmeHYxvDiodYhTgYFTi 4X2w+1KIEGtiWXFl7iFGSQ4mJVFen8mXQ4T4kvJTKjMSizPii0pzUosPMUpwMCuJ8N5pBsrx piRWVqUW5cOkpDlYlMR5N/3gCxESSE8sSc1OTS1ILYLJynBwKEnwKk4BahQsSk1PrUjLzClB SDNxcIIM5wEaPgGkhre4IDG3ODMdIn+KUVFKnDcOJCEAksgozYPrhSWSV4ziQK8I83qDVPEA kxBc9yugwUxAg2UvXgAZXJKIkJJqYAwQbtdojS9hVU/c9rg6v3zO2tCIT5n7pulslrmqu89q yvIvnB/OxveUfl589wPXul9e6TNL8stWfnjL8vhx77bgIOWUxp3Ll8zmNCyaVpzeO2k/q3D3 K6OuwHrOHY7h1XdOFH2+y/qA+2fIrqLpk/lmXGzS+rrsX6NE6R2l6d8WWDz7psXtK6vEUpyR aKjFXFScCACFM3C5/wIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/fC2fOLZuNCWBC1H-iAFjbtUmOBY>
Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00
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: Thu, 05 Feb 2015 16:07:12 -0000

On 02/05/2015 02:46 AM, Weijun Wang wrote:
>> As I said, I don't have a strong opinion either way, but I'm not sure
>> why it would be important or useful to give the caller a chance to
>> decline to send an error token.
> 
> The current implementation does not send the error token (This is not
> precisely specified although the doc does mention that a token generated
> by initSecContext/acceptSecContext is meant to be consumed by
> acceptSecContext/initSecContext by the peer).  Either a caller does not
> want to send the token at all, or one should have already written extra
> code to generate that token and send it.

Error tokens are usually consumed by accept/init on the peer.  The
exception is if the peer is already in the GSS_S_COMPLETE state, in
which case it needs to be consumed by gss_process_context_token.

I don't think it's legitimate for a GSS application to decide to discard
a token simply because it came with an error return.  If the application
knows that the other peer is in GSS_S_COMPLETE state and the protocol
has no way of framing a context token to a peer in that state, then it
has no choice to discard the token.  But absent that specific knowledge,
the token should always be sent.

> If we now silently send the token, it will be a big behavior change and
> a surprise for everyone.

As an implementor I certainly understand wanting to be conservative
about surprising applications.  I don't know how likely it is that Java
applications would break if tokens started showing up in the output
stream when init/accept raises an error.

On the flip side, making the caller explicitly retrieve the token is
likely to result in a lot of applications which don't bother.  That's
unavoidable for the byte array methods, but not for the stream methods.

(As an aside, I believe the Python bindings plan to solve this by
raising an exception for the GSS_S_CONTINUE case as well as for errors,
so an application needs code to extract a token from an exception in
order to work for anything more than a single hop.)