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

Greg Hudson <> Thu, 05 February 2015 16:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 110261A884C for <>; Thu, 5 Feb 2015 08:07:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.211
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Bvo4NSGeWQbM for <>; Thu, 5 Feb 2015 08:07:10 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4A8C91A88DC for <>; Thu, 5 Feb 2015 08:07:09 -0800 (PST)
X-AuditID: 1209190c-f79e46d000000eb2-26-54d3952b7acc
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 9B.E1.03762.C2593D45; Thu, 5 Feb 2015 11:07:08 -0500 (EST)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id t15G71FC028039; Thu, 5 Feb 2015 11:07:02 -0500
Received: from [] ( []) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by (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: <>
Date: Thu, 05 Feb 2015 11:06:59 -0500
From: Greg Hudson <>
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 <>, Benjamin Kaduk <>,
References: <> <> <> <> <> <>
In-Reply-To: <>
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: <>
Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00
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: 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.)