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