Re: [kitten] Cancel message Re: Alexey's comments Re: WGLC of draft-ietf-kitten-sasl-oauth-18

Bill Mills <wmills_92105@yahoo.com> Thu, 08 January 2015 16:05 UTC

Return-Path: <wmills_92105@yahoo.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 E7A201A8702 for <kitten@ietfa.amsl.com>; Thu, 8 Jan 2015 08:05:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.191
X-Spam-Level: *
X-Spam-Status: No, score=1.191 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 MvpSrDoGISIr for <kitten@ietfa.amsl.com>; Thu, 8 Jan 2015 08:05:43 -0800 (PST)
Received: from nm7.bullet.mail.bf1.yahoo.com (nm7.bullet.mail.bf1.yahoo.com [98.139.212.166]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B2751A8546 for <kitten@ietf.org>; Thu, 8 Jan 2015 08:05:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1420733140; bh=fDIclCs/YHJjamE2gOLU1RkTjhXif9HqcQhRC8v1qcU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=loyZHQxhjC1vboCETlolp3UWK5EItlwCyr3NUvNo8XY3Vy/PRxy/KdL8yeohw9kGFgms9jVuuL/8wH86iUlLJjV2MvyWTAgFFqYdYeDoDQ6Qj6lWXmQOlqCiVsDwxLWXREKQoTlWtjE6hsXlQgzGZFfjXww4IDOV1VJALlFTx6MMiJx81BcesRGD2msk0qrrvXKM4FZDLzHw8XRgC1Toya9EYxeEm9Aym3i2OT3+LGNkQ52+FsD7azShUZEXH0WoVlk7a6rAAeQO+7liAzUSto09Naj7+1t5uT4xc7GNLz3H9KwyBSEhwl+2/ltJpGs7+mHV8SQ+uCUV6vN55UjP5A==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=sqB1rX6pc66O6llByrHBUgrdY7vadO/1S+RU019kvWlxSmjljw7treIer3LpUA1hqSGlbQnLsWppTzozpIn/91XZYZHvbeEuy6aXwy+4mlBWdlEdVLv/ZbismCMAVfZ3LZSuu5AvpnWiqV8zVoActndOo82iL35rWWrXnjKlzCrUz/6GclBUCr0ww7QF5YPz0G0l/aH3W8dxZF9PifECxGYYjeoZF4YbFyNu83J13j2b9XtA9LvDaiO045YMs8tVttXlxUfY0d/42ThJArQ+hJEf+GrR7SLpmjNZu2EHDpCejSIQ+awz8NBAAntfsz0+6KFp0wvpTZmBxVNhzRiBIw==;
Received: from [98.139.215.141] by nm7.bullet.mail.bf1.yahoo.com with NNFMP; 08 Jan 2015 16:05:40 -0000
Received: from [98.139.212.215] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 08 Jan 2015 16:05:40 -0000
Received: from [127.0.0.1] by omp1024.mail.bf1.yahoo.com with NNFMP; 08 Jan 2015 16:05:40 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 451472.34517.bm@omp1024.mail.bf1.yahoo.com
X-YMail-OSG: PPzuEIsVM1n4cr9vvqt8_YygVMSoa2U1KA6e3pwSMYkJhBsV7rpurpXFH8YkZZe EuG5WmISZwYJz26Fjre.Gj7p.rSymNflRwOf86YJeR2y9VI_n6mVpA2oahNNLM5IzW7G8kxJH37P _0ylxqcmZEVRdaArFbB9z8qjDvgcrO2EdCRkRXul8PKcD7i75GPM20rwlyG3gW65O.pw8ymRIPQU ybs8aSLiEwY5A75jcEHHaEKTA7UMH3yur9b1jF9GCXXN3VLvWdZLn3XbuTFjKpertwYcX0SxfySe Xnw3Ub8.XfMw640loEEEk_K39PdgtfFvObeJx8ZDBnQY4ompzVXZtZF5a6Z4QAJyhGzKnvtPz3iQ y6xFjnpVLMCnkgNcPMZBvW8mcSC6QPhgBPQMr5PG.dj7LiWzzRtw8UlBlmbhQVPZBxQKcj088xeS OpC.tCXSYG3.fBe9NNe2z5UI3oOH56gMkCRRa6JdAhbG8ttyY.50eYK95wUbrLPhEkRC9mKHCxpD HzdlTVErf1cVsNJHP35ZR9x.0ViSA7ONLZZ9Se_qlPCOiSH0LkrdS59iWE_IUiOGWwBJcYToMBUS vbeoMyPKTjakWaieeT52_MQ4CpkFtoIiQVieFtKFlubhIw0bmT_oPXdUYR.FAePetQbi8CA--
Received: by 66.196.80.115; Thu, 08 Jan 2015 16:05:40 +0000
Date: Thu, 08 Jan 2015 16:05:38 +0000
From: Bill Mills <wmills_92105@yahoo.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <333970036.3242875.1420733138671.JavaMail.yahoo@jws10602g.mail.bf1.yahoo.com>
In-Reply-To: <6CF6884C-C9A7-440D-BC8A-7B6A7F0EECBB@isode.com>
References: <6CF6884C-C9A7-440D-BC8A-7B6A7F0EECBB@isode.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_3242874_795511151.1420733138667"
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/ZYGAHu9dcSYMC8oMSntCLk42g9o>
Cc: "kitten@ietf.org" <kitten@ietf.org>
Subject: Re: [kitten] Cancel message Re: Alexey's comments Re: WGLC of draft-ietf-kitten-sasl-oauth-18
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills <wmills_92105@yahoo.com>
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, 08 Jan 2015 16:05:45 -0000

You're talking about 3.5 in 4422?  To me it looks like the single kvsep message looks exactly like the abort message that needs to be defined by the protocol? 

     On Thursday, January 8, 2015 1:49 AM, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
   

 Hi Bill,

On 6 Jan 2015, at 21:36, Bill Mills <wmills_92105@yahoo.com> wrote:


" The client MUST then send either an additional client response consisting of a single %x01 (control A) character to the server in order to allow the server to finish the exchange or send a SASL cancellation token as defined in ACAP[RFC2244] section 6.3.1."

Actually I meant RFC 4422 (SASL). ACAP has cancellation token, but so does IMAP, SMTP, LDAP,...
If you like, I send you an IMAP example.

 

     On Sunday, January 4, 2015 3:37 AM, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
   

 Hi Bill,

> On 3 Jan 2015, at 00:56, Bill Mills <wmills_92105@yahoo.com> wrote:
> 
> 3.2.3 and an explicit message:  Long ago in the life of this doc I was told that some implementations may not support an empty message, so we put the single character message there to have an explicit payload.  I'm a bit leery of changing this now since there are implementations in play that use it this way.

I didn't suggest you should be sending empty message. I said you should be using SASL cancellation token, which is a mandatory RFC 4422 feature.

Any implementation would have to support this mode of operation anyway, because a SASL client can cancel any exchange.