Re: [OAUTH-WG] Misplaced Resource Owner in PKCE

John Bradley <ve7jtb@ve7jtb.com> Thu, 29 January 2015 22:36 UTC

Return-Path: <ve7jtb@ve7jtb.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5412B1A6FF6 for <oauth@ietfa.amsl.com>; Thu, 29 Jan 2015 14:36:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Reu51ZY1mp0T for <oauth@ietfa.amsl.com>; Thu, 29 Jan 2015 14:36:00 -0800 (PST)
Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A8471A012D for <oauth@ietf.org>; Thu, 29 Jan 2015 14:36:00 -0800 (PST)
Received: by mail-qg0-f53.google.com with SMTP id a108so35345262qge.12 for <oauth@ietf.org>; Thu, 29 Jan 2015 14:35:59 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=6c/XwMLebQsvAjrgY734+2YmcWSkHUyYoCGvFV/GHFY=; b=YO2ZS7OP6SF96cnD9U44boAXNXwG0xaQF7qap3aPrLPf7x//1EJwVKwr4jILrHa9zk 5PTChMyRkCcP/FFnf5ufpTUfnd+gt6/WxtUS1Q9Jj4zwF18iszQQM/0Mra+P6wl5jNG6 L5FTOWngcR1QWRhin8HhwZELgH90nFLEmKwAqeXoiGUzsdEGTAd2YTXaGkYBIESMAeoo SQoJilvr85I89naFKi4o0U51B8FB4/srmL4MQIeygfj5dEVoLTeW8DEGGyQ6FRziJvoy GN89TgRps/zw7qoQ1J/j07SdRIn8Ied2WIiNHyOAcR1ztm08fBvYMbDNw5ym5fUO5sa9 mFJA==
X-Gm-Message-State: ALoCoQm/lYJSFZfKYQY5c+DVLnf/TT50ua22z9808Uvmc0jrSeAsCPnrqWGc1UKXJKAX/Pyc2ZJN
X-Received: by 10.140.37.39 with SMTP id q36mr2512508qgq.89.1422570959421; Thu, 29 Jan 2015 14:35:59 -0800 (PST)
Received: from [192.168.8.101] ([181.202.1.158]) by mx.google.com with ESMTPSA id q10sm7035581qaq.9.2015.01.29.14.35.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Jan 2015 14:35:58 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_4DEB8145-5498-4A08-A493-DC82A9AEF63E"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <CA+k3eCRrkExQk2Rkjq2aZaEUQW4k8jPZA50C3aO2nAHCBDry-g@mail.gmail.com>
Date: Thu, 29 Jan 2015 19:35:53 -0300
Message-Id: <3E4FF4CB-DEF4-4C3A-A09C-7B157DDEE2E2@ve7jtb.com>
References: <CA+k3eCS0BP5se-nbhw6bpCWH9HSe_4afQRXrS8fL8vYm3+LGmA@mail.gmail.com> <DE5F6289-144D-4002-85F0-34DCF3F783E6@ve7jtb.com> <CA+k3eCRrkExQk2Rkjq2aZaEUQW4k8jPZA50C3aO2nAHCBDry-g@mail.gmail.com>
To: Brian Campbell <bcampbell@pingidentity.com>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/y3GTRe5TlST6IrAfOH02PFs16rs>
Cc: oauth <oauth@ietf.org>, Naveen Agarwal <naa@google.com>
Subject: Re: [OAUTH-WG] Misplaced Resource Owner in PKCE
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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, 29 Jan 2015 22:36:03 -0000


       +--------+                                  +---------------+
       |        |--(A)-- Authorization Request --->|               |
       |        |        + t(code_verifier), t     | Authorization |
       |        |                                  |    Endpoint   |
       |        |<-(B)---- Authorization Code -----|               |
       |        |                                  +---------------+
       | Client |                                     Authz Server
       |        |                                  +---------------+
       |        |--(C)--- Access Token Request --->|               |
       |        |          + code_verifier         |    Token      |
       |        |                                  |   Endpoint    |
       |        |<-(D)------ Access Token ---------|               |
       +--------+                                  +---------------+

                     Figure 2: Abstract Protocol Flow





Sakimura, et al.         Expires August 2, 2015                 [Page 4]

Internet-Draft                 oauth_pkce                   January 2015


   This specification adds additional parameters to the OAuth 2.0
   Authorization and Access Token Requests, shown in abstract form in
   Figure 1.

   A. The client creates and records a secret named the "code_verifier",
      and derives a transformed version "t(code_verifier)" (referred to
      as the "code_challenge") which is sent in the OAuth 2.0
      Authorization Request, along with the transformation method "t".
   B. The Authorization Endpoint responds as usual, but records
      "t(code_verifier)" and the transformation method.
   C. The client then sends the code in the Access Token Request as
      usual, but includes the "code_verifier" secret generated at (A).
   D. The authorization server transforms "code_verifier" and compares
      it to "t(code_verifier)" from (B).  Access is denied if they are
      not equal.

> On Jan 29, 2015, at 7:16 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
> 
> Works for me. The text below needs to be fixed up to match too.
> 
> On Thu, Jan 29, 2015 at 3:14 PM, John Bradley <ve7jtb@ve7jtb.com <mailto:ve7jtb@ve7jtb.com>> wrote:
> How about
> 
>     +--------+                                  +---------------+
>     |        |--(A)-- Authorization Request --->|               |
>     |        |        + t(code_verifier), t     | Authorization |
>     |        |                                  |    Endpoint   |
>     |        |<-(B)- Authorization Code Grant --|               |
>     |        |                                  +---------------+
>     | Client |  
>     |        |                                  +---------------+
>     |        |--(C)--- Access Token Request --->|               |
>     |        |          + code_verifier         |    Token      |
>     |        |                                  |   Endpoint    |
>     |        |<-(D)------ Access Token ---------|               |
>     +--------+                                  +---------------
> 
> 
> 
>> On Jan 29, 2015, at 7:01 PM, Brian Campbell <bcampbell@pingidentity.com <mailto:bcampbell@pingidentity.com>> wrote:
>> 
>> In SPOP/PKCE §1.1 [1] the figure and explanation have the authorization request going to the "Resource Owner" and goes on to say that 'the resource owner responds as usual, but records "t(code_verifier)" and the transformation method.' That's not what the resource owner does.
>> 
>> I know the protocol flow in RFC 6749 tries to have authorization grants be these abstract things that sorta come from the resource owner but, in the context of the the authorization request and authorization code grant type, it really doesn't work like that. The content in §1.1 seems, at best, to be  more abstract and complicated than it needs to be and is bordering on being just kinda wrong.
>> 
>> The RO and AS boxes should probably be consolidated into just the AS. The RO could be omitted from the diagram, I think. Or stick it over with the client, if you really want it in there, and have it authenticating and approving authorization though an interaction with the AS. Or something like that...
>> 
>> 
>> 
>> [1] https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-1.1 <https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-1.1>
>> 1.1 <https://tools.ietf.org/html/draft-ietf-oauth-spop-06#section-1.1>.  Protocol Flow
>> 
>> 
>> 
>>        +--------+                                  +---------------+
>>        |        |--(A)-- Authorization Request --->|               |
>>        |        |        + t(code_verifier), t     |   Resource    |
>>        |        |                                  |     Owner     |
>>        |        |<-(B)--- Authorization Grant -----|               |
>>        |        |                                  +---------------+
>>        | Client |
>>        |        |                                  +---------------+
>>        |        |--(C)--- Access Token Request --->|               |
>>        |        |          + code_verifier         | Authorization |
>>        |        |                                  |     Server    |
>>        |        |<-(D)------ Access Token ---------|               |
>>        +--------+                                  +---------------+
>> 
>>                      Figure 2: Abstract Protocol Flow
>> 
>> 
>>    This specification adds additional parameters to the OAuth 2.0
>>    Authorization and Access Token Requests, shown in abstract form in
>>    Figure 1.
>> 
>>    A. The client creates and records a secret named the "code_verifier",
>>       and derives a transformed version "t(code_verifier)" (referred to
>>       as the "code_challenge") which is sent in the OAuth 2.0
>>       Authorization Request, along with the transformation method "t".
>>    B. The resource owner responds as usual, but records
>>       "t(code_verifier)" and the transformation method.
>>    C. The client then sends the code to the Access Token Request as
>>       usual, but includes the "code_verifier" secret generated at (A).
>>    D. The authorization server transforms "code_verifier" and compares
>>       it to "t(code_verifier)" from (B).  Access is denied if they are
>>       not equal.
>> 
> 
>