Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth-15

Bill Mills <wmills_92105@yahoo.com> Sat, 06 September 2014 00:15 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 E77581A06CB for <kitten@ietfa.amsl.com>; Fri, 5 Sep 2014 17:15:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.167
X-Spam-Level:
X-Spam-Status: No, score=-2.167 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] 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 u_y7Syqc7hdu for <kitten@ietfa.amsl.com>; Fri, 5 Sep 2014 17:14:59 -0700 (PDT)
Received: from nm39-vm1.bullet.mail.bf1.yahoo.com (nm39-vm1.bullet.mail.bf1.yahoo.com [72.30.239.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ECA91A06A6 for <kitten@ietf.org>; Fri, 5 Sep 2014 17:14:59 -0700 (PDT)
Received: from [66.196.81.172] by nm39.bullet.mail.bf1.yahoo.com with NNFMP; 06 Sep 2014 00:14:58 -0000
Received: from [98.139.212.247] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 06 Sep 2014 00:14:58 -0000
Received: from [127.0.0.1] by omp1056.mail.bf1.yahoo.com with NNFMP; 06 Sep 2014 00:14:58 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 255235.15894.bm@omp1056.mail.bf1.yahoo.com
Received: (qmail 57284 invoked by uid 60001); 6 Sep 2014 00:14:58 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1409962498; bh=VSjY15EN2NBHrMeUsh/teCC3+5gdrSTgYya62gRmjjE=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=RmThjI0V6FHBu7T50O18gtGpeel+LRYBIR7GGJz6u5GsJXv+XPAyYH87Cd0vxMPMl5kjvRBkxfcaInMP7i1M+BLLIwo2A5juOuNUaDEagjS1yw4Mo5+6ShWNcHwY1NhhOOX+NE9kZoVwqT4Qq49D1MumNmlJyW5FzwVpMLIysfY=
X-YMail-OSG: Br8_Zm0VM1kGOTNTM_EAdhhrzBv04YoIQtVmZ0387gKC2BT eHpN0K0y9fZBFOL6yJb4YAhymJA5qjMjFt7Hb7qnoLj5AAko9NBMGniEPlfV taLaKwt7iab1HDdVPIVwebWFW1kUI.rEOLlMJv457LBkrxbSRU_P.N2Xjkoj 8lHtgzUuKS.ukG46qJ4oFjwHOhzeUvSRqZs0hLbmTcPxmyiaWLILgY1Qv_G4 ILLa5bOqWLxBjaM.K.DNYsMn6mCNX4pGIXHY0m4hzTGag92rJBaPnTvkfrv4 4u9FXi8AGOoiTz0j6zbS4Mdb562yZVGb80xPrMQINhqxlTURIZsQKrEeE_Aq OBNLbvwHDwCIUURpaFhB67eP98b1rcj9rFJMB_5x3fiVm.u1k4uupuNsYQfF Rn.sn69RLdbvmExmutS8pVQGNuWK_.g6OHAc9W1B6mYgPM9dsWKvrTic.VRm AW4FalwXCQWRKiV6IbhlSJW4lTNglqf5wMl2ShJXHuEPesOQXutXZUGfteJA U4X7cH44bb0ARr9bRPtO26tu0CZfnMp4DlLLeHI0SaFtRr_ZJF8zYKcrLdxM F_mwxlDT6K9hBzh2LH8e0yuSA7_mzxjGGuSA3ROmJWcfmSuQQav5SvnmM8u0 bLwcRLz.UVy0.WnUDnD20K0f.6TKzf4yy9x6wbsi9E4WF_R.YdETxfngolhT s21Ygu1vsNcSZhWsBD3upxI8-
Received: from [167.220.24.57] by web142804.mail.bf1.yahoo.com via HTTP; Fri, 05 Sep 2014 17:14:58 PDT
X-Rocket-MIMEInfo: 002.001, CgpDb21tZW50cy9yZXNwb25zZXMgaW5saW5lIGJlbG93LgoKVXBkYXRlZCAgcHJlIC0xNiBjb3B5IGF2YWlsYWJsZSBhdCAKCnRleHQ6IGh0dHBzOi8vZHJpdmUuZ29vZ2xlLmNvbS9maWxlL2QvMEI5OVlTa3hTNlplZmRIRktUVWhvZHpZM2NqQS9lZGl0P3VzcD1zaGFyaW5nCmh0bWw6IGh0dHBzOi8vZHJpdmUuZ29vZ2xlLmNvbS9maWxlL2QvMEI5OVlTa3hTNlplZmVqRlNMVTkzVDFObGRtYy9lZGl0P3VzcD1zaGFyaW5nCgpZb3UnbGwgbmVlZCB0byBkb3dubG9hZCB0aGUgSFRNTCB0byB2aWV3IGl0IGluIGEBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.203.696
References: <52AE9A65.1010700@oracle.com> <53F53D1F.7010305@oracle.com> <alpine.GSO.1.10.1409042219260.21571@multics.mit.edu>
Message-ID: <1409962498.54315.YahooMailNeo@web142804.mail.bf1.yahoo.com>
Date: Fri, 05 Sep 2014 17:14:58 -0700
From: Bill Mills <wmills_92105@yahoo.com>
To: Benjamin Kaduk <kaduk@MIT.EDU>, "kitten@ietf.org" <kitten@ietf.org>
In-Reply-To: <alpine.GSO.1.10.1409042219260.21571@multics.mit.edu>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-2129327256-357860453-1409962498=:54315"
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/blfY1akHpDt9Ntb5nYqy7Tq8jyI
Subject: Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth-15
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, 06 Sep 2014 00:15:09 -0000


Comments/responses inline below.

Updated  pre -16 copy available at 

text: https://drive.google.com/file/d/0B99YSkxS6ZefdHFKTUhodzY3cjA/edit?usp=sharing
html: https://drive.google.com/file/d/0B99YSkxS6ZefejFSLU93T1Nldmc/edit?usp=sharing

You'll need to download the HTML to view it in a browser.





On Friday, September 5, 2014 10:05 AM, Benjamin Kaduk <kaduk@MIT.EDU> wrote:
 


On Wed, 20 Aug 2014, Shawn M Emery wrote:

> This message officially starts the 3rd kitten Working Group Last Call
> for the following document:
>
> A set of SASL Mechanisms for OAuth
> http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-15
>
> The Working Group Last Call for this document starts today on Wednesday,
> August 20th and will end on Wednesday, September 3rd.

Oops, I'm late.  Sorry.


***
[bill] no worries

***
I'm neither a SASL expert nor an OAuth one, but I think I can get the
general sense of things here.  OAuth is already well established for
webapps, and there's a desire to repurpose it for authorizing access to
resources over non-http protocols, in particular protocols using SASL for
authentication.  This document, then, specifies how to represent the OAuth
messages inside SASL mechanisms, for messages between the parties
described in the OAuth terminology as the "client" and "resource server".
Since the OAuth messages are already specified, this is mostly just a
translation, along with specifying which pieces are required.

The most significant comment I have concerns section 3.2.2, the server
response to failed authentication.  I fear that it is under-specified, and
inconsistent with the example in section 4.3:

Section 3.2.2 leaves me wishing there was more detail.  I see that section
4.3 includes an example of this JSON object, but I think that more detail
is appropriate in a protocol specification.  Are all of the values always
going to be strings?  (Is the "OAuth 2 core specification" just RFC 6749?
If so, it's better to cite it by number.)  The IANA OAuth Extensions Error
Registry seems to give errors by name, e.g., "invalid_token".  Pulling up
RFC 6750, it seemse that when invalid_token is used, "the resource SHOULD
respond with the HTTP 401 (Unauthorized) status code".  But the example in
section 4.3 uses the string "401", not the JSON number, nor the string
form of the name!  This is very confusing.


***
[bill] Yep, this was wrong and 401 is being changed to "invalid_token" in the example.

***

Likewise, for the 'scope' named value, what are valid values?  Is there a
list of them somewhere?  Are they arbitrary, chosen by the application?
This needs to be specified.
The oauth-configuration named value is in better shape, as a URL is pretty
inherently a string, but that could still be made explicit.


***
[bill] Scope is defined in OAuth 2.0 and is a string, and it may be a list of space separated 
scope names.  There are no predefined scopes other than the blank/empty one..

***

My other comments are largely editorial; I have placed the more important
ones first and the stuff that's probably very minor at the end (after a
note).

However, it's a fairly significant issue that all of the IMAP examples do
not actually indicate they are for IMAP.  The SMTP exchanges are indicated
as such, which makes me suspect that originally only IMAP examples were
present, with the SMTP examples added later and the IMAP examples not
adjusted to reflect that they are only one class of example.  In
particular, this affects the top of sections 4.1, and 4.3.



***
[bill]  yep.  fixing.
***
I see that the notation "%x01" is used throughout to indicate the octet
with value 0x01, and this is used without comment in RFC 7159 (the JSON
spec).  I guess this is standard in ABNF-land, but section 2 doesn't
mention that we assume familiarity with such terminology.

***
[bill] that's actually HTTP (URI?) entity encoding.
***

The C/S exchanges in section 4.3 seems to have lost the "Server Ready" and
"t0 CAPABILITY" lines that are present in the previous examples.


***
[bill]  yep.  fixing.
***
At the end of section 4.3, I would clarify that the required dummy
response (as seen in the example as "AQ==") is the base64 encoding of
%x01, which was mentioned earlier in the text.   This happens again at the
end of section 4.4, but may not need the additional clarification at the
second occurrence.


***
[bill]  yep.  fixing.
***
In section 5, under "Access tokens have a lifetime", I think that "The

client may request a new access token" should use the RFC 2119 "MAY".


***
[bill]  OK
***

In section 6, the example is given of "when SASL is used in the context of
IMAP the resource server may assert the resource owner's email address to
the IMAP server for usage in an email-based application.".  But isn't the
IMAP server the resource server here?  Maybe it is the authorization
server which is making this assertion?


***
[bill]  it's the client asserting the email address, this now reads "in the context of IMAP the client may assert the resource owner's email address".
***
In section 3.1, for 'host', can we be more specific?  Is this a DNS name?
The name that would have been presented in an HTTP header if this was
being carried out over HTTP?  Vague text like this could lead to
interoperability issues.


***
[bill]  Changed to: "Contains the host name to which the client connected, in an HTTP context this is the value of the HTTP Host header.
***

Also in 3.1, the sentence mandating that the server MUST fail requests
that do not have host and port values but use keyed message digests could
be made more clear.  I'm uncertain which sort of requests do require keyed
message digests, so I don't really have any suggestions.


***[bill]  Changed to: "For OAuth token types such as OAuth 1.0a that use keyed message digests"
***

The first sentence of section 3.1.1 mentions the query string, which is
covered in the previous section (3.1); I think one should be moved so they
are in the same place.


***
[bill]  moved qs to the "reserved for future use section 3.1.1
***

In 3.2.1, I would be more comfortable if the second paragraph gave me some
reason to think that doing so is possible.  Is there prior art, or some
other specification for a similar thing that gives an example?  We don't
need to enumerate every way it could be done, but it seems useful to give
an indication that this is not going to end up dropping a heraculean task
on the developer.


***
[bill]  OAuth 1.0a tokens may well (and commonly have in some implementations) either carried or has access to the client identity.

For the question of whether both identities can be communicated to the app, it would be a new capability you'd have to add to the SASL implementation you're using.  Not herculean, but not trivial if you're going to patch something like Cyrus SASL and keep it in sync with current releases.
***

Editorial minutiae:

The phrase "or by allowing the third-party application to obtain access on
its own behalf", used in both the abstract and introduction, seems a
little confusing to me.  Is this just supposed to be differentiating
between flows where the user sees a prompt page from the authorization
server and flows where the user does not?



***
[bill] the difference is whether you're allowing FaceBook to access your mailbox, or whether its a desktop app like Thunderbird.
***
The first paragraph of page 4 has the sentence "The framework also
provides a protocol for security subsequent protocol exchanges within a
data security layer.", which uses the word 'protocol' twice with two
different usages.  It is probably best to add a qualifier to at least one
occurrence.


***
[bill] IIRC this is lifted from the SASL spec itself.  That said, deleting the second usage seems to do the trick, " The framework also provides a protocol for securing subsequent exchanges within a data security layer."
***
The end of section 1 notes that "In band discovery is not tenable if
clients support the OAuth 2.0 password grant."  It would be nice to say
something about why.


***
[bill] Now there's a fun topic.  There are folks that assert that allowing in band discovery if the password grant is in play might lead to an effective phishing attack.  Other's disagree.  No one hated the current language.  I'm really tempted to leave it alone.
***
The text in the first paragraph of 3.1 about "carry the equivalent values
from an HTTP context [...]" could be more clear.  I might say that these
key/value pairs "take the place of the corresponding HTTP headers and
values to convey the information necessary to complete [...]".


***
[bill]  OK
***
I would probably replace "The following key/value pairs are defined in the
client response" with "The following keys and corresponding values are
defined in the client response", since the list is not of key/value pairs
but rather a list of keys, with the text content for each item being a
description of the value to be used for that key.


***
[bill]  sure, why not.
***
For 'auth', "for an equivalent HTTP OAuth authorization" is an awkward
phrasing, since "equivalent" is not really specified; I might use
something like "The payload that would be in the HTTP Authorization header
if this OAuth exchange was being carried out over HTTP".


***
[bill]  OK
***
Please insert a comma before "Figure" in the first sentence of the fourth
paragraph of section 1.


***
[bill]  and in the XML it's 'environment, <xref target="overview"/>'
***


On page 5, in the large paragraph, "a discovery mechanisms" is a
singular/plural mismatch.


***
[bill]  OK
***
In section 3.1, replace "or may be empty" with "which may be empty".


***
[bill]  no, because the empty client response containing only the 0x01 has no GS2 header, now reads, "header followed by zero or more key/value pairs, or may be empty."
***

In section 3.2, I would replace "per the specification" with "according to
the specification".


***
[bill]  OK
***
In section 3.2.2 (last sentence), "presume an empty scope (unscoped token)
is needed" is a little odd; it might be better to say "should be used"
instead of "is needed".


***
[bill]  Now reads, "If the resource server provides no scope to the client then the client SHOULD presume an empty scope (unscoped token) is required to access the resource."
***

-Ben


***
[bill]  Many thanks!
***

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