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

Weijun Wang <weijun.wang@oracle.com> Fri, 06 February 2015 00:04 UTC

Return-Path: <weijun.wang@oracle.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 3F6BC1A006F for <kitten@ietfa.amsl.com>; Thu, 5 Feb 2015 16:04:30 -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 vRq_37gii0-Y for <kitten@ietfa.amsl.com>; Thu, 5 Feb 2015 16:04:22 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73D161A700B for <kitten@ietf.org>; Thu, 5 Feb 2015 16:04:22 -0800 (PST)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t1604Llo027761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Feb 2015 00:04:21 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id t1604KD6012204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Feb 2015 00:04:21 GMT
Received: from ubhmt110.oracle.com (ubhmt110.oracle.com [156.151.24.15]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t1604KJ2000452; Fri, 6 Feb 2015 00:04:20 GMT
Received: from [192.168.10.107] (/123.122.155.79) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 05 Feb 2015 16:04:20 -0800
Message-ID: <54D404FE.8010009@oracle.com>
Date: Fri, 06 Feb 2015 08:04:14 +0800
From: Weijun Wang <weijun.wang@oracle.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Greg Hudson <ghudson@mit.edu>, 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> <54D39523.5070700@mit.edu>
In-Reply-To: <54D39523.5070700@mit.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/RTRyTu6iSUG_NuakTjSwUf0zFW8>
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: Fri, 06 Feb 2015 00:04:30 -0000


On 2/6/2015 0:06, Greg Hudson wrote:
> 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.

I was wrong about that.

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

It should not break. The peer might have been a non-Java app and is 
already sending that token.

One problem is that if the app "have already written extra code to 
generate that token and send it", now it will send it twice.

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

Stream methods are not used by many. So most people would have to 
rewrite their apps to make use of this feature.

Thanks
Max

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