Re: [kitten] Barry Leiba's No Objection on draft-ietf-kitten-sasl-oauth-22: (with COMMENT)

Bill Mills <> Tue, 26 May 2015 20:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C48801ACE70 for <>; Tue, 26 May 2015 13:55:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.509
X-Spam-Status: No, score=-1.509 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 84nE6xjPtxYC for <>; Tue, 26 May 2015 13:55:54 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 583C41B318B for <>; Tue, 26 May 2015 13:53:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1432673588; bh=tk6cwbTZmLirTvWonPaZMo2NCmmVw3yWK/YkT8r3noM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=SinB2cXY5RsvtKIw7BVR/xx4wqHI478MnoDvslxY7eWtO3qWpOQGaAIk374BmLZ8UeE6oQDSYQ82y6EOn1jEm2olImFDdLCbNdK8dvpSobVSEHL0GtJxboGNrEfNLEquxMlJ2/H0eRBdqL2zU2Q/eFJLMVom5RA7ESBNWMQDT7DwgqkNsewQPyHDwaOWPiDqwDEZfSEomlf1OMVMrSsLq2O4DjSH8WTbOtfljE2rVkvQADouOjrBADrIBjloOzON8q8BzwifzzQRr1wS0seErO1kwZOMUJLIUwDEhi1ydo5LbeD5bObJeggUMeBCmO2FBwKRgKmk3kmVmNZKXRpGfA==
Received: from [] by with NNFMP; 26 May 2015 20:53:08 -0000
Received: from [] by with NNFMP; 26 May 2015 20:50:23 -0000
Received: from [] by with NNFMP; 26 May 2015 20:50:23 -0000
Received: from [] by with NNFMP; 26 May 2015 20:50:23 -0000
Received: from [] by with NNFMP; 26 May 2015 20:50:23 -0000
X-Yahoo-Newman-Property: ymail-4
X-YMail-OSG: .CWoxzUVM1lygTAnYIrgY_E2n9kQu0O29ojSTuLxr9XDEvi._LHFouE7MwkM9vq oKy8t5D9iRzhGz10CI0KJnaW9k2Jv2ljULInifc7LOXiLSfLLPfMz7miuJeLWt2GtN4pFCxlSn_7 YNBtFRIrjlBacLpn67zU1fgIRQehC3S_IL4ua_JX9N3Ig6vluSNHdvhQq.f9fL3lgn7rgBQSVKXz ChS3Nk8SF5h.U9sjyJHLCnzFHSblyvVwqJUIVdZcCeXChwIJwJJPABuBoKwwHMQjbRDCMU8v.mY6 XsI7eawaeuKBPdZvIaYmcK36edlWg6czxLj1yCvAXhvwmpMea1Lk5t_zMkIIZGVxFAeMWCGFpRIQ 8GX98QVbatkO.FNqobzcQwhXOX7F_JJpePqoRW9fbrXyd2Wt20ZMx.S0QXGnHMcwPNxzT489P0vG qdM_CZ_E6sfQLcASy
Received: by; Tue, 26 May 2015 20:50:22 +0000
Date: Tue, 26 May 2015 20:50:22 +0000 (UTC)
From: Bill Mills <>
To: Benjamin Kaduk <kaduk@MIT.EDU>, Barry Leiba <>
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_2397909_1524357971.1432673422151"
Archived-At: <>
Cc: "" <>, "" <>, "" <>, The IESG <>, "" <>, "" <>
Subject: Re: [kitten] Barry Leiba's No Objection on draft-ietf-kitten-sasl-oauth-22: (with COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills <>
List-Id: Common Authentication Technologies - Next Generation <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 May 2015 20:55:56 -0000

Replied to Barry's just now, but hadn't seen this yet.  I think everything here is addressed in the other mail.

     On Tuesday, May 26, 2015 1:41 PM, Benjamin Kaduk <kaduk@MIT.EDU> wrote:

 Hi Barry,

On Tue, 26 May 2015, Barry Leiba wrote:

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

You're welcome :)

> -- 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."

"which is what this memo uses" is certainly wrong, since 'is' is singular
but should be plural to apply to both IMAP and SMTP.  But I think your
version is better, maybe with the addition of "both" before "IMAP and
SMTP" in the last sentence.

> -- 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?:
>    Note that the IMAP SASL specification requires base64 encoding, as
>    specified in Section 4 of [RFC4648].

I think I had noted the comma splice in a previous review but it slipped
through the cracks.  Your version looks fine.

> -- 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
> Why is it "NOT RECOMMENDED"?  What interoperability or security issue is
> in play here that makes this "SHOULD NOT"?

I am a little hazy on this, but I seem to recall that some deployed
software assumes that only a single scope will be used, so this is for
interoperability.  (Bill, please jump in if I'm confused.)

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

This section was one of the repeated areas of contention over the last
calls, so I am somewhat reluctant to bring it back to the WG for
discussion.  I think there would be somewhat more support for SHOULD NOT
--> MUST NOT; the SHOULD for discovery is, IIRC, something of a
compromise, since some parties did not want to bring in a hard dependency
on OpenID Connect's choices.  The only reason I can come up for the SHOULD
NOT, off the top of my head, is if some vendor distributed a mail client
that was only ever going to talk to that same vendor's server.

> (Nit: The "if available" at the end of the paragraph is unnecessary; if
> one is not available, it certainly can't be used.)

That's true, but I like the flow of the sentence with the extra
redundancy better than without it.

> -- 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
>    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 would be fine with "[Initial connection and TLS establishment...]".

> 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).

The examples were added at different times, so keeping them in sync has
been a bit tough.  Hopefully we can enlist the help of the RFC Editor in
ensuring consistency of formatting.

> 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).

Hmm, it is probably okay to not mention this, as you propose.  Anyone
implementing SMTP or IMAP will need to be conversant with the relevant

> -- Section 4.4 --
> In the SMTP protocol, you should have "[Negotiate TLS...]" before the
> SMTP AUTH command, as you do in Section 4.1.

The running text does have "TLS negotiation is not shown but as noted
above it is required for the use of Bearer Tokens", but I support making
the examples consistent (and explicit about the use of TLS).


Kitten mailing list