Re: [kitten] AD review of draft-ietf-kitten-sasl-oauth-21

Bill Mills <wmills_92105@yahoo.com> Sat, 25 April 2015 17:25 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 A13831B2DCB for <kitten@ietfa.amsl.com>; Sat, 25 Apr 2015 10:25:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.51
X-Spam-Level:
X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, 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 FJ0IzC7Uje9t for <kitten@ietfa.amsl.com>; Sat, 25 Apr 2015 10:25:11 -0700 (PDT)
Received: from nm22-vm1.bullet.mail.bf1.yahoo.com (nm22-vm1.bullet.mail.bf1.yahoo.com [98.139.212.127]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CFDB1B2DCA for <kitten@ietf.org>; Sat, 25 Apr 2015 10:25:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1429982710; bh=dacOAU1V/wpG1LDQine8EfKpNam1wLl0KGQDnIRY8+8=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=AYRnIo+r0l53/P2+6quiARHuB+HmaGW0cSR3ecSZ0atUzIeIy8zM5jfsTVZeabOjZszejNJy1bZsBIv8UBBMQ1avEgXfVWZt28xDCj7ZYxLip1vnxzJRahF8j32qbV5tO2qBvN2r5/hzRkii/6TkHqbcTIbkSvrwkM3+cf0ytMijv0dtRY0k4vLu0iq+AOYKew3WLf42TXP5lzI2bDxQyTLgKRYsnQwk0c+zc1MH2fyDlcj3Htzl9nqYj3pXBgZsjsvReTw0RBgg88br6So2wzieR4lxRdBCy88O8vjxsZHb6T88PUbH3oaRngkYAB7lVmTodQedgcCoS5HmFheg3w==
Received: from [98.139.214.32] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; 25 Apr 2015 17:25:10 -0000
Received: from [98.139.212.195] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 25 Apr 2015 17:25:10 -0000
Received: from [127.0.0.1] by omp1004.mail.bf1.yahoo.com with NNFMP; 25 Apr 2015 17:25:10 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 894556.88044.bm@omp1004.mail.bf1.yahoo.com
X-YMail-OSG: WJ7ZnjsVM1kJgFBMrDgtRaAwWBCkoeuDmWj0VNXuzyTDt3z8Sbn152mn3y6l.Xz zmsiaZKOOrAgtlcKlxQqISnJJsILQ.7GpSxfcmlUspZAQV7mvfmu5qlJm65qZQamMvTiJiuU.l.Q nIaX04McTE6dtdw7L.fMM2jO1dCPIaAeYfrX_2EO.rrF7e6ZrjvyHyxnC9jVA8_5gpH_WqUg_Hh5 pHef_a.uuzmlXvobiqgHX7pwFGxXkm3E1upjU4QeVsz796gVxz3HBJRyMvaWHoVzsuBmRUNOgGhV dEEuJMbfZai6RIr5mayRuJkfDJkj.5kXG.fqw8M5gzKisxliTdMuClKpXhcj7p2rsRsNbdn3A9CO O0SvVvMI50WzYKq9mWzE.8aGn.q54Jhp85SRTxJ60698vmMGwS5_v_XJVAdJntRTbjxSJ1upjbK_ gEDysOslox4zl7mFkZoehmM8eGZick1.iCpUvoZq3o3ciXxepMNuRKzzyIPBbgeI0_iltqnKUA7q rQf4pgPwHouPS9kCoFnUhgE0oQGViiCWAqndumZrYoIbXlZR7wclxog--
Received: by 66.196.80.193; Sat, 25 Apr 2015 17:25:10 +0000
Date: Sat, 25 Apr 2015 17:25:10 +0000 (UTC)
From: Bill Mills <wmills_92105@yahoo.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "kitten@ietf.org" <kitten@ietf.org>
Message-ID: <315224591.5091319.1429982710161.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <553B9F3D.9070104@cs.tcd.ie>
References: <553B9F3D.9070104@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/6DZiiwj7H4nXOttreT7_ZDVF980>
Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-oauth-21
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: Sat, 25 Apr 2015 17:25:13 -0000

Responses inline...


On Saturday, April 25, 2015 7:06 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


Hiya,

Sorry for the bit of delay here but I've done my AD evaluation
of this. I have to questions I'd like to understand the answers
for before starting IETF LC. I'm not sure if those will or will
not cause any revisions to be needed before LC. Please consider
the other nits along with any IETF LC comments that turn up.

My questions:

(1) 3.1 - I'm not getting why the host and port number are
needed - won't the server know those anyway? (At least the
port number for sure.) And if not, then I'm not clear what's
going on, or it at least needs more explanation. Can you

explain?

[wmills] To allow support of things like OAuth 1.0a that need
the host and port to construct the signature base string.  No
the host may not know what name the client used to connect to
it given that the same IMAP server (for example) might have N
different names if it's a provider serving multiple companies
each with their own domain name. 

(2) MUST TLS be provided or used? Section 4 said STARTTLS
MUST be used, in section 5 you say provided. Either way, I
think you should include a definitive statement in section 3

about that. (And I'd prefer MUST use of course:-)

[wmills] The must here is because it's Bearer tokens which require 
TLS.  "The Bearer Token examples assume 
encrypted transport; if the underlying connection is not already TLS 
then STARTTLS MUST be used as TLS is required in the Bearer Token 
specification."  OAuth 1.0a may be used safely without TLS, but of
course the underlying data should probably have TLS for privacy etc.

nitty nits:


- ID nits gets a few reference things wrong, but it's ok

[wmills] happy to fix them if needed.  Will RFC Ed. do it anyway?

- 3.1 (and elsewhere probably) I'm assuming the ABNF
has been cross-checked, is that a safe assumption?


[wmills]  I believe so.  I'm aware of multiple interoperable 
implementations, Google and Outlook.com are major providers who
have implemented.
- 3.1 kvsep with a value of 0x01 - is that commonly used?
But it might be quite common for all I know:-)


[wmills] Control character separators are common in many systems.
I chose it because we're handling things that might otherwise be
in HTTP headers and 0x01 isn't valid there so we don't have to 
worry about escaping.

- 3.1, is there a real privacy benefit in omitting the
authzid (where it works to omit that)? If not, this
question is probably moot. But if there is, I wonder if
the way you've stated the MAY there will result in people
always including that if they can, which might not be what
we want. In any case, the guidance here is a bit vague
(and maybe it has to be) so would it be possible to be
more concrete about in/ex-clusion of authzid?


[wmills] In the end whether authzid is required is based on 
server policy.  I suspect you are right that clients will 
include it even when it's not needed because servers might
require it and a generic client won't know.  The existing 
implementations all have data in the protocol (IMAP, SMTP) that 
mirror the authzid anyway.


- Section 4, I also assume the examples have been checked.(Good set of examples though.)


[wmills] Ben did make me fix several as iteration happened
so they have had at least one review..


Cheers,
Stephen.

_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten