Re: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23

Eran Hammer <eran@hueniverse.com> Thu, 08 March 2012 00:01 UTC

Return-Path: <eran@hueniverse.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E7A11E809A; Wed, 7 Mar 2012 16:01:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.525
X-Spam-Level:
X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7waSW-F0lhGY; Wed, 7 Mar 2012 16:01:52 -0800 (PST)
Received: from p3plex2out01.prod.phx3.secureserver.net (p3plex2out01.prod.phx3.secureserver.net [184.168.131.12]) by ietfa.amsl.com (Postfix) with ESMTP id 845FD11E808C; Wed, 7 Mar 2012 16:01:52 -0800 (PST)
Received: from P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id io1q1i05F0SoFT401o1sN3; Wed, 07 Mar 2012 17:01:52 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 7 Mar 2012 17:01:51 -0700
From: Eran Hammer <eran@hueniverse.com>
To: Songhaibin <haibin.song@huawei.com>, Justin Richer <jricher@mitre.org>
Date: Wed, 7 Mar 2012 17:01:43 -0700
Thread-Topic: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23
Thread-Index: AczrxK1m0Cmrx5G1TqO2SHCpS5Hjof//wGMA//yqX4D/2ndaEA==
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFCD4079@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <E33E01DFD5BEA24B9F3F18671078951F156D8F4B@szxeml534-mbx.china.huawei.com> <4F3BB6B8.1030501@mitre.org> <E33E01DFD5BEA24B9F3F18671078951F156D9D56@szxeml534-mbx.china.huawei.com>
In-Reply-To: <E33E01DFD5BEA24B9F3F18671078951F156D9D56@szxeml534-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "draft-ietf-oauth-v2@tools.ietf.org" <draft-ietf-oauth-v2@tools.ietf.org>, "tsv-ads@tools.ietf.org" <tsv-ads@tools.ietf.org>, "tsv-dir@ietf.org" <tsv-dir@ietf.org>, "oauth@ietf.org" <oauth@ietf.org>, Martin Stiemerling <Martin.Stiemerling@neclab.eu>
Subject: Re: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2012 00:01:53 -0000

> -----Original Message-----
> From: Songhaibin [mailto:haibin.song@huawei.com]
> Sent: Friday, February 17, 2012 12:53 AM
> To: Justin Richer
> Cc: tsv-ads@tools.ietf.org; draft-ietf-oauth-v2@tools.ietf.org; Martin
> Stiemerling; oauth@ietf.org; tsv-dir@ietf.org
> Subject: RE: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23
> 
> Hi Justin,
> 
> Thank you for the clarification. See in line.
> 
> > -----Original Message-----
> > From: Justin Richer [mailto:jricher@mitre.org]
> > Sent: Wednesday, February 15, 2012 9:44 PM
> > To: Songhaibin
> > Cc: tsv-ads@tools.ietf.org; draft-ietf-oauth-v2@tools.ietf.org; Martin
> > Stiemerling; oauth@ietf.org; tsv-dir@ietf.org
> > Subject: Re: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23
> >
> > On 02/15/2012 04:33 AM, Songhaibin wrote:
> > > I've reviewed this document as part of the transport area
> > > directorate's ongoing
> > effort to review key IETF documents. These comments were written
> > primarily for the transport area directors, but are copied to the
> > document's authors for their information and to allow them to address
> > any issues raised. The authors should consider this review together with
> any other last-call comments they receive.
> > Please always CC tsv-dir@ietf.org if you reply to or forward this review.
> > >
> > > First, I should apologize for the delay in this review, I should
> > > have finished it two
> > days ago. I have some common security knowledge but not an expert.
> > >
> > > Summary
> > >
> > > This draft is basically ready for publication, but has nits that
> > > should be fixed
> > before publication.
> > >
> > > General issues need discussion:
> > >
> > > 1. Section 1.3.3 and 1.3.4 discuss two authorization grant type:
> > > resource owner
> > password credentials, and client credentials. These two have the same
> > flow and many in common, and they are significantly different than the
> > authorization code grant type and implicit grant type described in
> > previous sections. And in section 1.3.4, it also says " Client
> > credentials are used as an authorization grant typically when the
> > client is acting on its own behalf (the client is also the resource
> > owner),...". Is it better to combine these two grant types as one "client
> credentials" grant type where the client can be the resource owner?
> >
> > No, they are quite distinct -- It all comes down to what you're
> > authenticating. The Resource Owner Password Credentials flow *also*
> > includes client credentials which are distinct from the resource
> > owner's own credentials. The client's credentials are going to be the
> > same for a given client across many different users, while the
> > Resource Owner's credentials are going to be different across
> > different users, but the same across different clients (for the same
> > resource owner). In most flows, the client's credentials identify just
> > the client, and the resource owner is identified through some other
> > means (a direct password, a redirected login to the authz endpoint).
> > In the Client Credentials flow, the client's credentials are the only ones that
> you have.
> >
> 
> Okay, in the Resource Owner Password Credentials flow, it adds client
> credentials, but any client who was issued credentials from the authorization
> server can pass. How much security does the client credential in this flow
> add?

It can allow the server to enforce policies, but more importantly, client authentication is part of every access token request make to this endpoint as part of the overall architecture.

> > > 2. Two concepts confused me in section 2.4, I don't know if I am the
> > > only person
> > who is confusing here. One is user-agent-based application and another
> > is native application, why are they executed on the device used by the
> > resource owner? I think they can run on any device used by resource
> > consumer instead of resource owner. Resource owner is only used to grant
> access to resources.
> >
> > OAuth's main 3-legged pattern allows what's called "Alice-to-Alice
> > sharing", in that the Client is consuming on behalf of the resource
> > owner. In cases where you have an in-user-agent app or a native app,
> > the end user (resource owner) is going to be the one running it, and
> > the one authorizing it.
> >
> 
> Yes, I understand that. But the document seems like resource owner is the
> "only" one who can run the UA app or native app? Or I missed something?

It is the only one. Only the resource owner can grant access.

EH

> 
> Thanks,
> -Haibin
> 
> >
> > Thanks for your feedback, and I hope this can help clear up the intent
> > of the working group here. If you can suggest language that will
> > solidify these points further, it can help make sure this doesn't
> > further confuse people.
> >
> >   -- Justin