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

Bill Mills <> Sat, 25 April 2015 18:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8402E1B2EBB for <>; Sat, 25 Apr 2015 11:14:54 -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 lCJW2DDa1waN for <>; Sat, 25 Apr 2015 11:14:51 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 196E21B2EB9 for <>; Sat, 25 Apr 2015 11:14:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1429985690; bh=Q5WzZVMmZksyGCUrcBUx1LdCcAIge0urL2H8qsFRbSY=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=JOXqzZVy97VV33UfofAXev56Xk0ovp7/Q0Jjjz6yCTMOLYfC/N36y1WYWaapPRvRIFqiZR6e297zQB1ZYgNC6DftsySzIS2HvDDvL7SwC8+RKfzfB81DKWpVe5L3smRnrUrjkcjoVOELBLFZTGjHllUb8tim7GKwnhIBmpS1rz2zsNMMuRj+s36YE1/8WpbVE+AbRXqWYYUDti4alIWz3QIj657qoKVpyR7bjtncpjBPAmBi6KD/QtKTNg1+txbTHlc6zbB+eYLJxU///pB4IoCgYLJ/RlB/4pXJ4khMP5aqVle1sEH43NoKm05Q/1CUY/SDEVM1y50KOxGGVac7SQ==
Received: from [] by with NNFMP; 25 Apr 2015 18:14:50 -0000
Received: from [] by with NNFMP; 25 Apr 2015 18:14:50 -0000
Received: from [] by with NNFMP; 25 Apr 2015 18:14:50 -0000
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: pe0JsT8VM1m3IPg2LZeNOjJYHcVRBkqiw.LknIi0Nf8s90X_WJOWZu_HW03b0qn 8RQasNgfQm49.h0_eBjDO_mUHM5HrJQIIZEH.3BEKXz9S6dGDvPGCrRPaVTdipBM.NTgMkOKs6nY pHozEa3g3M2CEhj4MU5WQAfnw3.EyfoEfgsoCtfjNrQmPF7XM8C1IF5AmZUuwkj39RnHj58M.2dW cxGSDsqQzbXilDqsTYmFo1FUKICuN8aJWJAqKmnEhlez1dOYpvuTU0zeWMNba1UINAbFWVWT_Npf KbhdnpNXtzeN2HW4sCyVvsL3cAvuCQgiibaH0kw3lC8NlP81G8RUyl7gimJa0CD7INVak6sNGw0m Pn4fex5mk12edCt_bU251rAW7z.wv0WcQeODDSL71vNRQ.oB8UEhBRRDrJEC_30vMuGGi1x20EM7 A6Bnm6XR7mu5aSLGRytSYuFVXZGNmnfOB_a1NsEoY1fV6sRdsGPdbMAddsfM.vUka4QyL4MZmMuj w6b9Ee9n3eroBsKhNzEzOouIVmkd7cmhbYpniuAaoLyR2LblJYTZfbw--
Received: by; Sat, 25 Apr 2015 18:14:49 +0000
Date: Sat, 25 Apr 2015 18:14:49 +0000 (UTC)
From: Bill Mills <>
To: Stephen Farrell <>, "" <>
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_5175869_1445947949.1429985689389"
Archived-At: <>
Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-oauth-21
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: Sat, 25 Apr 2015 18:14:54 -0000

Inline again... 

     On Saturday, April 25, 2015 10:47 AM, Stephen Farrell <> wrote:

On 25/04/15 18:25, Bill Mills wrote:
> Responses inline...
> On Saturday, April 25, 2015 7:06 AM, Stephen Farrell <> 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. 

In principle the client might use a hostname that the server
doesn't know about, or can't determine. However, were it the
case that the SASL mechanism has to tell the server, then the
application protocol would not work for multiple server
identities with other SASL mechanisms, right? In which case
the server has to know already or is broken. Or can you provide
me with the details of a protocol that uses SASL where this is
a real issue?

[wmills]  Yes the server might validate for known hostnames, asHTTP servers can but it you specify an unknown host in the hostheader it falls through to default.   This is specific to the case wherethe mechanism supporting OAuth 1.0a requires hostname, so Idon't see how this would break some other SASL mechanism?

I also don't see any case where the server does not know on
which port it received data.

[wmills] at ${previousjob} there were IMAP servers that had a TLSaccellerator in front of them and the back end IMAP server lived on the same port whether it got a direct connect or a proxied one.Not ideal perhaps, but an example.

And if the client could use authorization information for
server1 at what the server thinks is server2 then that would seem
to raise some significant vulnerabilities that are not discussed
at all.

[wmills] OAuth tokens might or might not be bound ot a singledomain and certainly cane be used at N hostnames withing a given TLD.  Where/how tokens might be valid is outside this scope.

Perhaps we're trying too hard to cover the issues faced when
OAuth1.0a was used over http without tls? Nowadays, that is
handled via SNI within TLS.

[wmills] I completely disagree given that SNI is not pervasive, less than 70% of browsers/clients support it last I knew.  SNI doesn't solve for why OAuth 1.0a uses hostname either.
> (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.

All of that is fine, but does not explain why section 3 doesn't
clearly say when TLS must be used, nor why sections 4 and 5 are
not quite saying the same thing about that. So I think my question
isn't really answered yet, sorry.
[wmills] Section 3 defines this per mechanism and says:
"OAUTHBEARER: OAuth 2.0 bearer tokens, as described in [RFC6750].         RFC 6750 uses Transport Layer Security (TLS) [RFC5246] to
         secure the protocol interaction between the client and the
         resource server."
This is derived from the explicit requirements in the Bearer spec, but there was a problem there in that there was an existing Bearer implementation (FB) that didn't use TLS and they didn't want to be declared out of spec so I think the language isSHOULD instead of MUST.  We were aware of a possible mismatch and didn't want be in conflict with the language from there.  
Do we need something clearer than that?  Do we need to add something explicit about new mechanisms being required to define whether encryption is required?   [/wmills]

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