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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sat, 25 April 2015 14:05 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 B2B121B2CB8 for <kitten@ietfa.amsl.com>; Sat, 25 Apr 2015 07:05:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.81
X-Spam-Level:
X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, 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 fAuhwVG14X3z for <kitten@ietfa.amsl.com>; Sat, 25 Apr 2015 07:05:57 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A25C11B2CC3 for <kitten@ietf.org>; Sat, 25 Apr 2015 07:05:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DF717BE4D for <kitten@ietf.org>; Sat, 25 Apr 2015 15:05:55 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXNi1UB-22Xf for <kitten@ietf.org>; Sat, 25 Apr 2015 15:05:54 +0100 (IST)
Received: from [10.87.48.73] (unknown [86.42.29.198]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C14D0BE47 for <kitten@ietf.org>; Sat, 25 Apr 2015 15:05:54 +0100 (IST)
Message-ID: <553B9F3D.9070104@cs.tcd.ie>
Date: Sat, 25 Apr 2015 15:05:49 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "kitten@ietf.org" <kitten@ietf.org>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/uqSxjx4RW3b1BQoC-lj_YL_NxVw>
Subject: [kitten] AD review of draft-ietf-kitten-sasl-oauth-21
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: Sat, 25 Apr 2015 14:05:59 -0000

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?

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

nitty nits:

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

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

- 3.1 kvsep with a value of 0x01 - is that commonly used?
But it might be quite common for all I know:-)

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

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

Cheers,
Stephen.