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> Thu, 05 February 2015 07:46 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 E8DF11A017C for <kitten@ietfa.amsl.com>; Wed, 4 Feb 2015 23:46:39 -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 LvQBvo3SCI7y for <kitten@ietfa.amsl.com>; Wed, 4 Feb 2015 23:46:38 -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 8EEAB1A0130 for <kitten@ietf.org>; Wed, 4 Feb 2015 23:46:38 -0800 (PST)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t157ka12007186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Feb 2015 07:46:37 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t157kaZo012160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 5 Feb 2015 07:46:36 GMT
Received: from ubhmt116.oracle.com (ubhmt116.oracle.com [156.151.24.21]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t157kZ73008454; Thu, 5 Feb 2015 07:46:35 GMT
Received: from [192.168.10.107] (/123.122.155.79) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 04 Feb 2015 23:46:35 -0800
Message-ID: <54D31FD0.9030508@oracle.com>
Date: Thu, 05 Feb 2015 15:46:24 +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>
In-Reply-To: <54D3190D.8080003@mit.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/2Lp_eTY100nxWKv2v6kOlmxI4ew>
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 07:46:40 -0000


On 2/5/2015 15:17, Greg Hudson wrote:
> On 02/05/2015 12:17 AM, Weijun Wang wrote:
>> On 2/2/2015 11:03, Weijun Wang wrote:
>>>>> http://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-01
>>>>
>>> The main reason I preferred the current design is to be consistent with
>>> the byte array forms of the methods, which gives the caller the chance
>>> to determine whether the error token should be sent or not.
>>
>> Are you OK with this reason?
>
> 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.

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

Thanks
Weijun