Re: [kitten] Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02

Simon Josefsson <simon@josefsson.org> Fri, 08 April 2011 08:25 UTC

Return-Path: <simon@josefsson.org>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFAC63A68CB for <kitten@core3.amsl.com>; Fri, 8 Apr 2011 01:25:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.126
X-Spam-Level:
X-Spam-Status: No, score=-103.126 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UDZm883I3Su for <kitten@core3.amsl.com>; Fri, 8 Apr 2011 01:25:14 -0700 (PDT)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id C14893A68B5 for <kitten@ietf.org>; Fri, 8 Apr 2011 01:25:00 -0700 (PDT)
Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p388QPPJ007741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 8 Apr 2011 10:26:27 +0200
From: Simon Josefsson <simon@josefsson.org>
To: "William J. Mills" <wmills@yahoo-inc.com>
References: <20110408070506.12ECB3A6A4C@core3.amsl.com> <416848.75882.qm__16525.0710481361$1302247955$gmane$org@web32314.mail.mud.yahoo.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:110408:wmills@yahoo-inc.com::Fw3tcSSnbiQG8POK:0RQx
X-Hashcash: 1:22:110408:kitten@ietf.org::ByXgFFkHGnH2CDXN:ATsl
X-Hashcash: 1:22:110408:timshow@yahoo-inc.com::1mC22ABIPnvjtVtf:CBvc
Date: Fri, 08 Apr 2011 10:26:25 +0200
In-Reply-To: <416848.75882.qm__16525.0710481361$1302247955$gmane$org@web32314.mail.mud.yahoo.com> (William J. Mills's message of "Fri, 8 Apr 2011 00:32:13 -0700 (PDT)")
Message-ID: <87hba9b13i.fsf@latte.josefsson.org>
User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.97 at yxa-v
X-Virus-Status: Clean
Cc: "kitten@ietf.org" <kitten@ietf.org>, Tim Showalter <timshow@yahoo-inc.com>
Subject: Re: [kitten] Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 08 Apr 2011 08:25:42 -0000

"William J. Mills" <wmills@yahoo-inc.com> writes:

> All,
>
> I have added channel binding to OAUTH mechanism draft.  I would very
> much appreciate someone that knows CB giving it a read to make sure
> I'm on the right track.  Significant changes in this draft:

This is great!

   Channel binding [RFC5056] in this mechanism is defined in order to
   allow satisfying the security requirements of the authorization
   schemes used.  This document defines the "OAUTH-SSL" mechanism to
   provide TLS channel binding [RFC5929] to the OAUTH mechanim, and
   specifically the "tls-unique" type of channel binding.

The intention is that tls-server-end-point is not permitted at all,
right?  Perhaps it is clearer to have the last sentence say

   This document defines the "OAUTH-SSL" mechanism to provide the
   "tls-unique" TLS channel binding [RFC5929] to the OAUTH mechanim.

      cbdata (REQUIRED):  Contains the base64 encoded first TLS Finished
         message sent.

Don't mention the Finished message here, people have gotten the details
wrong before and the gory details (including people's mistakes) are in
RFC 5929.  Say instead:

      cbdata (REQUIRED):  Contains the base64 encoded "tls-unique"
         channel binding data.

Otherwise it looks good.  I'm tempted to have a go at implementing this
in GNU SASL actually. :-)

/Simon