[kitten] Barry Leiba's No Objection on draft-ietf-kitten-sasl-oauth-22: (with COMMENT)
"Barry Leiba" <barryleiba@computer.org> Tue, 26 May 2015 15:57 UTC
Return-Path: <barryleiba@computer.org>
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 698C41A9054; Tue, 26 May 2015 08:57:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 eqkkNLMnu2Vg; Tue, 26 May 2015 08:57:34 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D011A9048; Tue, 26 May 2015 08:57:34 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Barry Leiba <barryleiba@computer.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150526155734.22570.6165.idtracker@ietfa.amsl.com>
Date: Tue, 26 May 2015 08:57:34 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/LEqLuqIJJVBrX8kIinlqsTtf_Gw>
Cc: kitten-chairs@ietf.org, draft-ietf-kitten-sasl-oauth.shepherd@ietf.org, kitten@ietf.org, draft-ietf-kitten-sasl-oauth@ietf.org, draft-ietf-kitten-sasl-oauth.ad@ietf.org
Subject: [kitten] Barry Leiba's No Objection on draft-ietf-kitten-sasl-oauth-22: (with COMMENT)
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 26 May 2015 15:57:36 -0000
Barry Leiba has entered the following ballot position for draft-ietf-kitten-sasl-oauth-22: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Another excellent, informative shepherd writeup, which helped with my review of the document. (And, I'll say, most of the really useful writeups, as this one, seem to use the "essay" format, rather than the Q&A format.) Thanks, Ben, for the writeup. -- Section 1 -- way to use the Simple Authentication and Security Layer (SASL) [RFC4422] to gain access to resources when using non-HTTP-based protocols, such as the Internet Message Access Protocol (IMAP) [RFC3501] and the Simple Mail Transfer Protocol (SMTP) [RFC5321], which is what this memo uses in the examples. When I first read this, I thought the last phrase was bound to SMTP... but then I see that both IMAP and SMTP are used in the examples. So, a small thing, but I'd end the sentence after the 5321 reference, and make the last phrase into another sentence, like, "This document gives examples of use in IMAP and SMTP." -- Section 2 -- Note that the IMAP SASL specification requires base64 encoding, see Section 4 of [RFC4648], not this memo. Nit: That seems kind of an odd way to put it, in addition to its having a comma splice. Why not this?: NEW Note that the IMAP SASL specification requires base64 encoding, as specified in Section 4 of [RFC4648]. END -- Section 3.2 -- Nit: "vaialble" -> "available" -- Section 3.2.2 -- scope (OPTIONAL): An OAuth scope which is valid to access the service. This may be omitted which implies that unscoped tokens are required. If a scope is specified then a single scope is preferred, use of a space separated list of scopes is NOT RECOMMENDED. Why is it "NOT RECOMMENDED"? What interoperability or security issue is in play here that makes this "SHOULD NOT"? The server MAY return different URLs for users in different domains and the client SHOULD NOT cache a single returned value and assume it applies for all users/domains that the server suports. The returned discovery document SHOULD have all data elements required by the OpenID Connect Discovery specification populated. Similar questions for the SHOULD NOT and SHOULD here. In this case, I don't understand why they aren't "MUST NOT" and "MUST": for the first, I don't understand how a client can interoperate with a server if it violates this, and for the second, if they data elements are "required", why isn't including them a "MUST"? (Nit: The "if available" at the end of the paragraph is unnecessary; if one is not available, it certainly can't be used.) -- Section 4.1 -- The underlying TLS establishment is not shown but is required for using Bearer Tokens per that specification. S: * OK IMAP4rev1 Server Ready C: t0 CAPABILITY S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR S: t0 OK Completed The problem with this is that if the underlying TLS establishment is done through STARTTLS on port 143, that would come between the first line ("S: * OK IMAP4rev1 Server Ready") and the second. And that makes the example a bit odd. The easiest way out of that is simply to remove the first line. Or, better, to replace the first line with something like "[Initial connection and TLS establishment...]". (This applies to the subsequent sections as well.) I wonder why you don't wrap the decoded payload here the same way you do in Section 4.2 (or there the same as here). I suggest that there'd be less room for any confusion if you did them all (4.3 also) the same way (I don't care which way you choose). In the SMTP part, you say this: Note that line breaks are inserted for readability, and that the SMTP protocol terminates lines with CR and LF characters (ASCII values 0x0D and 0x0A), these are not displayed explicitly in the example. The same is true for the IMAP protocol and example, but you don't say this there. Actually, I don't think you need to say it in either place, and suggest simply removing it here (and in Section 4.4). -- Section 4.4 -- In the SMTP protocol, you should have "[Negotiate TLS...]" before the SMTP AUTH command, as you do in Section 4.1.
- [kitten] Barry Leiba's No Objection on draft-ietf… Barry Leiba
- Re: [kitten] Barry Leiba's No Objection on draft-… Benjamin Kaduk
- Re: [kitten] Barry Leiba's No Objection on draft-… Bill Mills
- Re: [kitten] Barry Leiba's No Objection on draft-… Bill Mills
- Re: [kitten] Barry Leiba's No Objection on draft-… Barry Leiba
- Re: [kitten] Barry Leiba's No Objection on draft-… Bill Mills
- Re: [kitten] Barry Leiba's No Objection on draft-… Barry Leiba