Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth-15
Benjamin Kaduk <kaduk@MIT.EDU> Fri, 05 September 2014 17:05 UTC
Return-Path: <kaduk@mit.edu>
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 A2FFD1A0B08 for <kitten@ietfa.amsl.com>; Fri, 5 Sep 2014 10:05:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.469
X-Spam-Level:
X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, 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 63wnzlNO-sVD for <kitten@ietfa.amsl.com>; Fri, 5 Sep 2014 10:05:11 -0700 (PDT)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BD401A0AE2 for <kitten@ietf.org>; Fri, 5 Sep 2014 10:05:11 -0700 (PDT)
X-AuditID: 1209190c-f795e6d000006c66-a3-5409ed46a624
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id E9.73.27750.64DE9045; Fri, 5 Sep 2014 13:05:10 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s85H594E027245 for <kitten@ietf.org>; Fri, 5 Sep 2014 13:05:10 -0400
Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s85H57Ci000581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <kitten@ietf.org>; Fri, 5 Sep 2014 13:05:09 -0400
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s85H569N026751; Fri, 5 Sep 2014 13:05:06 -0400 (EDT)
Date: Fri, 05 Sep 2014 13:05:06 -0400
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: kitten@ietf.org
In-Reply-To: <53F53D1F.7010305@oracle.com>
Message-ID: <alpine.GSO.1.10.1409042219260.21571@multics.mit.edu>
References: <52AE9A65.1010700@oracle.com> <53F53D1F.7010305@oracle.com>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMIsWRmVeSWpSXmKPExsUixG6nouv2ljPEYM19QYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEr48Tlm2wF66wqDnWuYG5g/K/XxcjJISFgIrHr11R2CFtM4sK9 9WxdjFwcQgKzmSTu7fvMCuEcY5RoP72FHcK5ziRx+norK0iLkEC9xJTG52A2i4CWxP4Ln5lA bDYBFYmZbzaygdgiAsISu7e+YwaxhQVsJY6vawOr5wSqfzFjGdhqXgFHiXtHb0HNdJf49nIl WL2ogI7E6v1TWCBqBCVOznwCZjMD9S6fvo1lAqPALCSpWUhSCxiZVjHKpuRW6eYmZuYUpybr Ficn5uWlFuka6uVmluilppRuYgSFH6ckzw7GNweVDjEKcDAq8fAu+MwRIsSaWFZcmXuIUZKD SUmUd+trzhAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrzHLgHleFMSK6tSi/JhUtIcLErivG+t rYKFBNITS1KzU1MLUotgsjIcHEoSvDZvgBoFi1LTUyvSMnNKENJMHJwgw3mAhluD1PAWFyTm FmemQ+RPMepyrOv81s8kxJKXn5cqJc57EuQ6AZCijNI8uDmwtPGKURzoLWFeLpBRPMCUAzfp FdASJqAl5ulgS0oSEVJSDYxTovJunpvRlR1qtPnrj5rfQTdsy1bePlKy5/c6Fe+J6SkMhQJa /1Vft1pyRlXXz7+7+H3PlbrMdeaPT6mb1NRJmV5xOV43N+9MbTT/hmureN6eydXIcvtgLOac um1+BFup4aMTZUsfStWENKjmit77mFJy4r7WYte2EgP7XDntngTLO1ktXUosxRmJhlrMRcWJ AF+fOOr2AgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/RCNKuTIbDa84ByPz1MGi-RcGBPo
Subject: Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth-15
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Fri, 05 Sep 2014 17:05:18 -0000
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. 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. 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. 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. 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. 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. 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. 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". 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? 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. 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. 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. 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. 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? 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. 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. 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 [...]". 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. 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". Please insert a comma before "Figure" in the first sentence of the fourth paragraph of section 1. On page 5, in the large paragraph, "a discovery mechanisms" is a singular/plural mismatch. In section 3.1, replace "or may be empty" with "which may be empty". In section 3.2, I would replace "per the specification" with "according to the specification". 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". -Ben
- [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