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
- [kitten] WGLC on draft-ietf-kitten-sasl-oauth-12 Shawn M Emery
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Matt Miller (mamille2)
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Bill Mills
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Bill Mills
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Matt Miller (mamille2)
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Bill Mills
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Matt Miller (mamille2)
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Bill Mills
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Ryan Troll
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Bill Mills
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Bill Mills
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Ryan Troll
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Bill Mills
- [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-s… Shawn M Emery
- Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hm… Benjamin Kaduk
- Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hm… Peck, Michael A
- Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hm… Benjamin Kaduk
- Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hm… Simon Josefsson
- Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hm… Benjamin Kaduk
- Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hm… Greg Hudson
- [kitten] WGLC on draft-ietf-krb-wg-cammac-08 Shawn M Emery
- Re: [kitten] WGLC on draft-ietf-krb-wg-cammac-08 Zheng, Kai
- Re: [kitten] WGLC on draft-ietf-krb-wg-cammac-08 Tom Yu
- Re: [kitten] WGLC on draft-ietf-krb-wg-cammac-08 Zheng, Kai
- [kitten] WGLC on draft-ietf-kitten-sasl-oauth-15 Shawn M Emery
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Benjamin Kaduk
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Bill Mills
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Benjamin Kaduk
- Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth… Bill Mills