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

Bill Mills <wmills@yahoo-inc.com> Wed, 18 December 2013 18:25 UTC

Return-Path: <wmills@yahoo-inc.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 936B41AE052 for <kitten@ietfa.amsl.com>; Wed, 18 Dec 2013 10:25:56 -0800 (PST)
X-Quarantine-ID: <WZV49kJMgSXm>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BANNED, message contains text/plain,.exe
X-Spam-Flag: NO
X-Spam-Score: -16.919
X-Spam-Level:
X-Spam-Status: No, score=-16.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15, WEIRD_QUOTING=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 WZV49kJMgSXm for <kitten@ietfa.amsl.com>; Wed, 18 Dec 2013 10:25:51 -0800 (PST)
Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by ietfa.amsl.com (Postfix) with ESMTP id DAD071AE03B for <kitten@ietf.org>; Wed, 18 Dec 2013 10:25:51 -0800 (PST)
Received: from BF1-EX10-CAHT14.y.corp.yahoo.com (bf1-ex10-caht14.corp.bf1.yahoo.com [10.74.226.58]) by mrout3.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id rBIIORGh082895 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <kitten@ietf.org>; Wed, 18 Dec 2013 10:24:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1387391068; bh=wcpmjtRYQQueM4jum4S2k0Zy9jQMDEWw629GGED4ZJ8=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=Gj5NWCMtYipU54VLTSoBeWLNrNYoZsvbdF0gmn0TVIlAYbu9JOEQycizoza9wVGWF STClC6vPL4mqQPNx8luzvStTiAY5I9eqCTXzZerVdF4f0H4PKIJybh9D7f6eHNQ8+m QxYs85SOGZqDL2GjZhKNAnucwifpfgc1z3SyHmNg=
Received: from omp1019.mail.ne1.yahoo.com (98.138.89.163) by BF1-EX10-CAHT14.y.corp.yahoo.com (10.74.209.170) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 18 Dec 2013 13:25:10 -0500
Received: (qmail 57853 invoked by uid 1000); 18 Dec 2013 18:24:25 -0000
Received: (qmail 48854 invoked by uid 60001); 18 Dec 2013 18:24:25 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1387391065; bh=xhMN6y/BPBlZA/QP/PCoh2tJEBsiLpdZCOHziUZ/RAU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=lZExJ/2tZqLxVkRC9wC5uBOirg4X2Z0LDWWsfhLLn6PfwxqUkLLnFlZa04rA3ebfxBYPZqCiXHLTIgpb0V/i3MxJH3FxIijywLShwqpsSkMzsU4OIrRNlJmmV5wSIkCgw+s/3sFtXa+JgPUKARMm5pOumqg32oRz/OthCLGKMos=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Pt7L4gyzY6idlZ6J98DFvF+EHoXwhX4OSnRwOSE7oj67kRgBa7tKkudcllRHcpZS/gtOQ7GcHkKenzBWlJsRCipo8F4mF/2CclNDAaj9WCHOzyvxJVGCmk+KJq046JBiVuT/06yCc8wkzFvytNYj867ShSC5qLQGD7GsutMq9lw=;
X-YMail-OSG: no_2p8QVM1kp4qNDwI9GUDIcPrvBS.DdmPjQ_.yaNbnjlfK FjIcU_LCzSS6kenM6HKehnmd8MuP41iGlownFMcHABQfLYQXjUip6qKcvoVa ZosEvtH2WgbGcBVHr5PjsYRrdlDsCPYBZXBkUZGu9NA4WEQ1T8Es6LQCcIPd MCBXVXbZNVzch28qO4d14iupbnxp8wCobldzml39tVYpYUv6qwS2678iTmO7 _82aqvj8UpmXy65gM9MfOGKyVrQgOJjap5volFUapwHRChFNlB3wxoirXXJK .e5ZtFShgUaEeyLqess7ilcUFrKANCLeIsCk-
Received: from [209.131.62.115] by web125601.mail.ne1.yahoo.com via HTTP; Wed, 18 Dec 2013 10:24:25 PST
X-Rocket-MIMEInfo: 002.001, CldlIHdlbnQgYXJvdW5kIGEgbnVtYmVyIG9mIHRpbWVzIG9uIHRoZSBTQVNMIGlkZW50aXRpZXMuwqAgVGhlIHByb2JsZW0gSSBzZWUgaXMgdGhhdCB0aGUgYXNzZXJ0aW9uIG9mIGF1dGh6LWlkIGlmIGl0J3Mgc3BlY2lmaWVkIHNlcGFyYXRlbHkgaW4gcHJvdG9jb2wganVzdCBoYXMgdG8gYmUgbWF0Y2hlZC9jb25maXJtZWQgYnkgdGhlIHRva2VuIGFueXdheSBzbyB0aGUgdmFsdWUgc2hvdWxkIGp1c3QgYmUgZGVyaXZlZCBmcm9tIHRoYXQuCgoKTm90IHN1cmUgd2h5IHRoZSBNQUMgdG9rZW4gZHJhZnQgbnUBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.170.612
References: <52AE9A65.1010700@oracle.com> <C2752600-AC7C-4839-8BD0-3D850ECB19EB@cisco.com> <1387329873.35383.YahooMailNeo@web125604.mail.ne1.yahoo.com> <24FDB425-20B7-42F3-BD64-B23DEDBA6356@cisco.com>
Message-ID: <1387391065.73288.YahooMailNeo@web125601.mail.ne1.yahoo.com>
Date: Wed, 18 Dec 2013 10:24:25 -0800
From: Bill Mills <wmills@yahoo-inc.com>
To: "Matt Miller (mamille2)" <mamille2@cisco.com>
In-Reply-To: <24FDB425-20B7-42F3-BD64-B23DEDBA6356@cisco.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-1981468715-1467257001-1387391065=:73288"
X-Milter-Version: master.31+4-gbc07cd5+
X-CLX-ID: 391068000
Cc: "kitten@ietf.org" <kitten@ietf.org>
Subject: Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth-12
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills <wmills@yahoo-inc.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: Wed, 18 Dec 2013 18:25:56 -0000

We went around a number of times on the SASL identities.  The problem I see is that the assertion of authz-id if it's specified separately in protocol just has to be matched/confirmed by the token anyway so the value should just be derived from that.


Not sure why the MAC token draft number is wrong.  I'm using the xml2rfc format and referring to <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-oauth-v2-http-mac.xml' ?> so I'm not sure what to fix.

On scopes, I'm not liking your changes but see the problem.  The current text is:

"An OAuth scope which is valid to access the service. This may be empty which implies that unscoped tokens are required, or a space separated list. Use of a space separated list is NOT RECOMMENDED."

I propose:

"An OAuth scope which is valid to access the service. This may be empty which implies that unscoped tokens are required, or a scope value.  If a scope is specified then a single scope is preferred, use of a space separated list of scopes is NOT RECOMMENDED."
 
-bill

P.S. Nits...  "erk" is actually a sound made when you drop something on your foot, "irk" is indicative of the reaction to excessive pedantry. :)


--------------------------------
William J. Mills
"Paranoid" Yahoo!





On Wednesday, December 18, 2013 8:25 AM, Matt Miller (mamille2) <mamille2@cisco.com> wrote:
 
Thanks for the rapid turnover!

One additional item I just noticed: the reference to [I-D.draft-ietf-oauth-v2-http-mac] is out of date. It should be draft-ietf-oauth-v2-http-mac-04, not -01.

More inline, stripping all but what I'm responding to:

On Dec 17, 2013, at 6:24 PM, Bill Mills <wmills@yahoo-inc.com> wrote:

> MAJOR:
> 
> * Removing the GS2-header (which was done in revision -11) also removed the ability for the client to specify an authorization identity.  If the lack of an authorization identity is acceptable (and I suspect it is not for some), then the document needs to state these mechanisms do not support authz-id.
> 
> [wmills] This is addressed in 3.2.1 of -12  authz-id is possible in some OAuth schemes.
> 

Section 3.2.1. talks about authentication identities (authn-id), not authorization identities (authz-id).  The two are different: authn-id is who holds the credentials (such as they are in OAuth) and authz-id is whom the authn-id is acting as.

The more I read that section, the less convinced I am that it meets the requirements for SASL mechanisms (RFC 4422 § 5).  Identities (at least authn-id, and often authzid) are provided for all other SASL mechanisms, and all of the SASL-using protocols I'm familiar with rely on an identity coming out of the SASL exchange.

I understand that the access token itself is not guaranteed to contain this information, but at some level the resource server needs to be able to associate the SASL authentication credentials (OAuth access token) with an authentication and/or authorization identity.  From what I've seen of existing OAuth software, there is some way to determine an identity -- if not encoded directly in the access token, then by agreement between the resource server and the authorization server (e.g., REST APIs specific to the authorization server).

I suppose one possible transposition is for the authn-id to be the OAuth client identity and the authz-id to be the OAuth resource owner identity.  I personally don't find this mapping interesting or appropriate, and doesn't account for the resource owner acting as a different identity within the context of the SASL-using application.

A possible starting point for text (not sure where in 3.2.1. to place it):

""""
The authentication identity is determined by the resource server using information associated with the access token. This information might be encoded within the access token itself, or the resource server might obtain the information from the authorization server through other means. The specific method is outside the scope of this work.
""""

This still doesn't account for the authorization identity. This could be handled by adding a new kvpair (e.g., "authzid") and maybe some language about how the resource server might validate/verify its use against the provided credentials.

Or, I'm just tilting at windmills.

> * In section 3.2.2. Server Response to Failed Authentication, returning a space-separated list for the "scope" field is NOT RECOMMENDED, but also says the lack of a "scope" (value or field) implies the client SHOULD request tokens that are unscoped (empty list of scopes).  However, RFC 6749 § 3.3 does not permit unscoped tokens; the ABNF does not allow for "scope=" (i.e., the empty list), and the text regarding the lack of scope means the authorization server uses a default scope value (or fails authorization outright).  To me, this seems like a contradiction that would lead to interoperability problems.
> 
> [wmills] "scope" is an optional parameter, so if you want an empty value you don't send scope at all.
> 

My apologies for not being clear.

As I read the document, there are two ways I can see how to interpret the term "unscoped":

1. scope of "" during the authorization request
2. omit the scope from the authorization request

The first is clearly in violation of RFC 6749 (the ABNF requires at least one scope-token, and the scope-token requires at least one printable non-whitespace ACII character).  The second, however, seems to invite failure because the authorization server MUST either use the default scope (if it has one) or fail authorization.

According to this document, the resource server providing a scope of something other than "" is NOT RECOMMENDED.  That means (as I interpret from RFC 2119) that "I can try to return a non-empty scope, but it will likely cause problems in most cases".

This document states that clients that receive an error response with an empty scope (or no scope at all) SHOULD omit the scope from the authorization request (since, again, specifying a scope of "" violates RFC 6749).  SHOULD means (as I interpret from RFC 2119) that "I can try to specify a scope anyway, but it will likely cause problems in most cases".

I am then balancing all this against what I've experienced with already deployed OAuth frameworks: not specifying a scope results in a failure from the authorization server.  Many -- if not most -- OAuth client libraries won't send an authorization request with a scope specified.

This is the interoperability problem I see in this document.  It seems (to me) that it is destined to cause confusion and at best, and non-functioning (if following the SHOULDs and NOT RECOMMENDEDs) or non-compliant (ignoring the SHOULDs and NOT RECOMMENDEDs) code at worst.

I think this could be fixed by either removing the NOT RECOMMENDED about presenting a space-separated list for scope, or by changing the SHOULD to a MAY regarding what the client sends for the authorization request. I think it would also help to define what unscoped means, or not use the term at all.

Suggested starting point for text (replacing all of section 3.2.2):

""""
For a failed authentication the server returns a JSON [RFC4627] formatted error result, and fails the authentication. The error result consists of the following values:

    status (REQUIRED):
        The authorization error code. Valid error codes are defined in the IANA "OAuth Extensions Error Registry" specified in the OAuth 2 core specification. 
    scope (OPTIONAL):
        An OAuth scope which is valid to access the service. This may be empty or a space separated list. Use of a space separated list is NOT RECOMMENDED. 

If the resource server provides a scope value that is not the empty string then the client MUST always request scoped tokens from the token endpoint. If the resource server provides no scope to the client then the client MAY omit the scope from the authorization request.
""""

> * In section 1. Introduction, SMTP is mentioned with a citation but without a definition (unlike SASL and IMAP immediately preceding).
> 
> [wmills] I see "SMTP [RFC5321]" there
> 

What I see:

* Simple Authentication and Security Layer (SASL) [RFC4422]
* Internet Message Access Protocol (IMAP) [RFC3501]
* SMTP [RFC5321]

One of these things is not like the others (-:

This is very clearly a nit.  The lack of consistency erks me somewhat, but I doubt it truly matters.



- m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.