Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt

Brian Campbell <bcampbell@pingidentity.com> Wed, 25 November 2015 18:49 UTC

Return-Path: <bcampbell@pingidentity.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 8E67E1A8BB6 for <oauth@ietfa.amsl.com>; Wed, 25 Nov 2015 10:49:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.368
X-Spam-Level:
X-Spam-Status: No, score=-1.368 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=no
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 Ria0spFF-xoK for <oauth@ietfa.amsl.com>; Wed, 25 Nov 2015 10:49:01 -0800 (PST)
Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20B781A0011 for <oauth@ietf.org>; Wed, 25 Nov 2015 10:49:01 -0800 (PST)
Received: by igcph11 with SMTP id ph11so99378556igc.1 for <oauth@ietf.org>; Wed, 25 Nov 2015 10:49:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2s5EUeIiLh4I9Yi9gTic+VsjLCNxIkTdFxu6ZyoGZP8=; b=lZ8OjKB+wsn2k1IgfwDTlrBIj2Fp/cfurCxXDIwp7ntDGqOSV5xB0wflmzvFZ6a4PW LZP/SErOZPat1GF1PObSu4y7kNzVjsYdpFT3jTVapWfRiZbOd5XG9bWpAklYgTvtPddX Dc+GncUqd6CFnqfkOfOI4oXj6eTszd5o5zYZg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2s5EUeIiLh4I9Yi9gTic+VsjLCNxIkTdFxu6ZyoGZP8=; b=L4BQb6fPUGhiyESCkEHYSfA66UyLlkWnzlE9cZ1MmN6MO8O3eSL78+s7BL4UX2xLkU 9DhweCmwqLAKexq3OVoYWLIBLyPAmGozWtNAQKPX5TWfePIe3osx1bkXsbSPH5FLnMx/ gfWptP3al3/5gYy63ffs4gWc8oEqcYWvfHr1maG4jyMg8gsvOA+SGYKdT9QhVRrNiele +TdOLhTghJVceVTWw+mi3/33VdSXQE7X+aJpcsHrDVYW/1wE4dHp6eMO5u8TbFvfLAXo ZZ1aETd5B3iN8iA1D/fKDC3RxAOvj2gr98AH1KIagC+etv2fnRbgcAbXhCaaC0SN6qVM 58cA==
X-Gm-Message-State: ALoCoQnYZmicd53+j45hb8fgnzpmYOCS7X/yzWAc+x7R2rNwWwAWeppRereptGLLGuIWaN1JskoG
X-Received: by 10.50.143.5 with SMTP id sa5mr1491915igb.77.1448477340316; Wed, 25 Nov 2015 10:49:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.23.133 with HTTP; Wed, 25 Nov 2015 10:48:30 -0800 (PST)
In-Reply-To: <38555799-721C-4A2F-AAAA-24D9B69EB72E@mit.edu>
References: <20151124200512.20833.28463.idtracker@ietfa.amsl.com> <F787FB76-5C8D-45F5-8A81-E430E75A0455@oracle.com> <CA+k3eCSeOyc2HMY+sK9rSjxkSAvNPWqwKyJNjDZAaCu2Stqk=w@mail.gmail.com> <16FAD3AC-CFB8-46D5-A12E-436E902EA439@oracle.com> <CA+k3eCT1+=2zysgbaKEmWCkQmsKyjr9KbghgmOVYUSC1qLfjbg@mail.gmail.com> <D8D36156-8BA6-43C5-8016-94A4CAE5FB45@mit.edu> <6015EE15-1FEE-43DC-930C-68ACAEDC083E@oracle.com> <38555799-721C-4A2F-AAAA-24D9B69EB72E@mit.edu>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 25 Nov 2015 11:48:30 -0700
Message-ID: <CA+k3eCSJPCnawTjbByPcj+mmcK+vvQ_0Cxzs=24kT-irGETi7w@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Content-Type: multipart/alternative; boundary=001a1134c2e655d3af052561e913
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/ok0-qoigL97sfMYm-oJ2AifrHwc>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 25 Nov 2015 18:49:04 -0000

While I can't say I disagree with the deeper existential questions about
the draft that Justin raises, I was trying not to go there and rather just
point out concerns with the newly added text.

The text Phil cites from Sec 6 doesn't say the client must be able to parse
and verify the token. It's an assumption to simplify the examples that
follow and still the token is opaque to the client. I reread the whole
draft (reluctantly) and there's nothing that says the token has to be
non-opaque to the client. And it does talk about reference style tokens and
encrypted tokens, both of which rely on the opaqueness to the client.

On Wed, Nov 25, 2015 at 11:27 AM, Justin Richer <jricher@mit.edu> wrote:

> Right, I read that as text for describing the examples and not for
> describing requirements.
>
> The token itself doesn’t have to be signed at all.
>
>  — Justin
>
> On Nov 25, 2015, at 1:05 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
>
> Ok. Well this was requested by Kathleen because of this paragraph in Sec
> 6.…
>
>
>    To simplify the subsequent description we assume in the PoP architecture
>
>    that the token itself is digitally signed by the authorization server
>
>    and therefore cannot be modified.
>
>
> Please
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
> On Nov 25, 2015, at 9:33 AM, Justin Richer <jricher@mit.edu> wrote:
>
> The token doesn’t have to be signed and the client doesn’t have to verify
> the signature on the token. That’s not PoP. The request has to be signed in
> a way that includes the token. The token itself can still be opaque. The
> *key* material can’t be opaque to the client, but the *token* material
> still is.
>
> I agree with Brian that this statement is misleading.
>
> The examples use a signed token but that is absolutely not a requirement.
> Maybe the examples shouldn’t all use one style.
>
> What’s most difficult about this particular spec is that it’s very
> hand-wavy, saying “this is kinda a thing that kinda works like this”
> without saying how to actually do it. I’m honestly not sure it’s worth
> publishing as an RFC in its own right but I’m not going to stand in its way.
>
>  — Justin
>
> On Nov 25, 2015, at 12:14 PM, Brian Campbell <bcampbell@pingidentity.com>
> wrote:
>
> Where does it say that?
>
>
>
> On Wed, Nov 25, 2015 at 8:44 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
>
>> Except that later on we require the token be signed and the client verify
>> that signed token. IOW mutual pop.
>>
>> Phil
>>
>> On Nov 25, 2015, at 07:30, Brian Campbell <bcampbell@pingidentity.com>
>> wrote:
>>
>> Looking at the diff I noticed the following new text, which seems to
>> conflate bearer/PoP and opaqueness to the client. A client demonstrating
>> proof-of-possession of some key is orthogonal to the client being able to
>> parse and understand the access token itself.
>>
>> "In contrast to bearer tokens [RFC6750] which call for tokens that are
>> opaque to OAuth 2.0 clients, this specification defines the requirements
>> for proof-of-possession ("PoP") tokens that may be parsed and verified by
>> OAuth 2.0 clients and relying parties."
>>
>> On Tue, Nov 24, 2015 at 1:07 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
>>
>>> This draft addresses review comments from Kathleen and Erik raised since
>>> the last draft.
>>>
>>> It may not include some of the discussion from yesterday/today.  I will
>>> add that as the group decides.
>>>
>>> Cheers,
>>>
>>> Phil
>>>
>>> @independentid
>>> www.independentid.com
>>> phil.hunt@oracle.com
>>>
>>> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org wrote:
>>> >
>>> >
>>> > A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> > This draft is a work item of the Web Authorization Protocol Working
>>> Group of the IETF.
>>> >
>>> >        Title           : OAuth 2.0 Proof-of-Possession (PoP) Security
>>> Architecture
>>> >        Authors         : Phil Hunt
>>> >                          Justin Richer
>>> >                          William Mills
>>> >                          Prateek Mishra
>>> >                          Hannes Tschofenig
>>> >       Filename        : draft-ietf-oauth-pop-architecture-06.txt
>>> >       Pages           : 23
>>> >       Date            : 2015-11-24
>>> >
>>> > Abstract:
>>> >   The OAuth 2.0 bearer token specification, as defined in RFC 6750,
>>> >   allows any party in possession of a bearer token (a "bearer") to get
>>> >   access to the associated resources (without demonstrating possession
>>> >   of a cryptographic key).  To prevent misuse, bearer tokens must be
>>> >   protected from disclosure in transit and at rest.
>>> >
>>> >   Some scenarios demand additional security protection whereby a client
>>> >   needs to demonstrate possession of cryptographic keying material when
>>> >   accessing a protected resource.  This document motivates the
>>> >   development of the OAuth 2.0 proof-of-possession security mechanism.
>>> >
>>> >
>>> > The IETF datatracker status page for this draft is:
>>> > https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-architecture/
>>> >
>>> > There's also a htmlized version available at:
>>> > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-06
>>> >
>>> > A diff from the previous version is available at:
>>> > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-architecture-06
>>> >
>>> >
>>> > Please note that it may take a couple of minutes from the time of
>>> submission
>>> > until the htmlized version and diff are available at tools.ietf.org.
>>> >
>>> > Internet-Drafts are also available by anonymous FTP at:
>>> > ftp://ftp.ietf.org/internet-drafts/
>>> >
>>> > _______________________________________________
>>> > OAuth mailing list
>>> > OAuth@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/oauth
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>>
>>
>> --
>> [image: Ping Identity logo] <https://www.pingidentity.com/>
>> Brian Campbell
>> Distinguished Engineer
>> Ping Identity
>> @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 [image:
>> twitter] @pingidentity Connect with us!
>> <https://www.pingidentity.com/>[image: pingidentity.com]
>> <https://www.pingidentity.com/>
>> <https://ping.force.com/Support/PingIdentityCommunityHome>[image:
>> pingidentity.com]
>> <https://ping.force.com/Support/PingIdentityCommunityHome>
>> [image: twitter logo]
>> <http://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm> [image:
>> twitter logo] <https://twitter.com/pingidentity> [image: youtube logo]
>> <https://www.youtube.com/user/PingIdentityTV> [image: LinkedIn logo]
>> <https://www.linkedin.com/company/21870> [image: Facebook logo]
>> <https://www.facebook.com/pingidentitypage> [image: Google+ logo]
>> <https://plus.google.com/u/0/114266977739397708540> [image: slideshare
>> logo] <http://www.slideshare.net/PingIdentity> [image: flipboard logo]
>> <http://flip.it/vjBF7> [image: rss feed icon]
>> <https://www.pingidentity.com/blogs/>
>>
>>
>
>
> --
> [image: Ping Identity logo] <https://www.pingidentity.com/>
> Brian Campbell
> Distinguished Engineer
> Ping Identity
> @ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 [image:
> twitter] @pingidentity Connect with us!
> <https://www.pingidentity.com/>[image: pingidentity.com]
> <https://www.pingidentity.com/>
> <https://ping.force.com/Support/PingIdentityCommunityHome>[image:
> pingidentity.com]
> <https://ping.force.com/Support/PingIdentityCommunityHome>
> [image: twitter logo]
> <http://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm> [image:
> twitter logo] <https://twitter.com/pingidentity> [image: youtube logo]
> <https://www.youtube.com/user/PingIdentityTV> [image: LinkedIn logo]
> <https://www.linkedin.com/company/21870> [image: Facebook logo]
> <https://www.facebook.com/pingidentitypage> [image: Google+ logo]
> <https://plus.google.com/u/0/114266977739397708540> [image: slideshare
> logo] <http://www.slideshare.net/PingIdentity> [image: flipboard logo]
> <http://flip.it/vjBF7> [image: rss feed icon]
> <https://www.pingidentity.com/blogs/>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>


-- 
[image: Ping Identity logo] <https://www.pingidentity.com/>
Brian Campbell
Distinguished Engineer
Ping Identity
@ bcampbell@pingidentity.com [image: phone] +1 720.317.2061 [image: twitter]
@pingidentity Connect with us!
<https://www.pingidentity.com/>[image: pingidentity.com]
<https://www.pingidentity.com/>
<https://ping.force.com/Support/PingIdentityCommunityHome>[image:
pingidentity.com] <https://ping.force.com/Support/PingIdentityCommunityHome>
[image: twitter logo]
<http://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>
[image:
twitter logo] <https://twitter.com/pingidentity> [image: youtube logo]
<https://www.youtube.com/user/PingIdentityTV> [image: LinkedIn logo]
<https://www.linkedin.com/company/21870> [image: Facebook logo]
<https://www.facebook.com/pingidentitypage> [image: Google+ logo]
<https://plus.google.com/u/0/114266977739397708540> [image: slideshare logo]
<http://www.slideshare.net/PingIdentity> [image: flipboard logo]
<http://flip.it/vjBF7> [image: rss feed icon]
<https://www.pingidentity.com/blogs/>