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

Justin Richer <jricher@mit.edu> Wed, 25 November 2015 17:33 UTC

Return-Path: <jricher@mit.edu>
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 0E81D1A6FDE for <oauth@ietfa.amsl.com>; Wed, 25 Nov 2015 09:33:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.775
X-Spam-Level:
X-Spam-Status: No, score=-4.775 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] 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 argu9hKnGl4k for <oauth@ietfa.amsl.com>; Wed, 25 Nov 2015 09:33:39 -0800 (PST)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECE801A6FCD for <oauth@ietf.org>; Wed, 25 Nov 2015 09:33:31 -0800 (PST)
X-AuditID: 12074425-f793c6d000006975-21-5655f0e92c79
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 04.98.26997.9E0F5565; Wed, 25 Nov 2015 12:33:29 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id tAPHXSYL017412; Wed, 25 Nov 2015 12:33:29 -0500
Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tAPHXQf9016583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Nov 2015 12:33:28 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_F4EC4F39-AD6A-451B-A42F-7BFEEFABCA9E"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <CA+k3eCT1+=2zysgbaKEmWCkQmsKyjr9KbghgmOVYUSC1qLfjbg@mail.gmail.com>
Date: Wed, 25 Nov 2015 12:33:26 -0500
Message-Id: <D8D36156-8BA6-43C5-8016-94A4CAE5FB45@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>
To: Brian Campbell <bcampbell@pingidentity.com>
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHKsWRmVeSWpSXmKPExsUixCmqrPvyQ2iYwfxjmhar/99ktDj59hWb xYL5jewOzB5Llvxk8vj49BaLx92jF1kCmKO4bFJSczLLUov07RK4Ms6v+MFe0PuHsaJzz3a2 BsY7txm7GDk5JARMJJ5+fssMYYtJXLi3nq2LkYtDSGAxk8S1ff0sEM5GRokpnfuZIJyHTBKr 5r9lB2lhFkiQWN+ziAXE5hXQk3h16zIriC0s4CNx8fQTMJtNQFVi+poWJhCbUyBQovv8YjYQ mwUofmXzZSaIOZ4Sn6ZPh5pjJfG7YSrU5vVMEku7WsAaRAT0JW4/ncMOcausxO7fj5gmMArM QnLHLCR3QMS1JZYtfM0MYWtK7O9ezoIpriHR+W0i6wJGtlWMsim5Vbq5iZk5xanJusXJiXl5 qUW6Fnq5mSV6qSmlmxhB0cDuorqDccIhpUOMAhyMSjy8Ex6FhAmxJpYVV+YeYpTkYFIS5W27 EBomxJeUn1KZkVicEV9UmpNafIhRgoNZSYT3dy1QjjclsbIqtSgfJiXNwaIkzjv3i2+YkEB6 YklqdmpqQWoRTFaGg0NJgjfkPVCjYFFqempFWmZOCUKaiYMTZDgP0PBgkBre4oLE3OLMdIj8 KUZFKXHe+SAJAZBERmkeXC8oWSW8PWz6ilEc6BVhXmGQKh5gooPrfgU0mAlocEQO2OCSRISU VAOj8CruveeWyd7x3iq/uLbs+kKTOGGzOev6ZwZ5bY6szGTRrlpbpq8rPGGTqtdV3w/G9W87 Ow8F5y42CAsw36d4+pUJy7zQCVXs7Fuf6H7maPA9a9WhHd4ayML4wonBWt5hRwvPYaGzkjmW WvpP+1bK/50c9bthc3ZsKKN6vkHa06nHH/9xkFJiKc5INNRiLipOBACbGWAtMQMAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/_by8Uu9SwTJdc8sQWv4aISnhxcA>
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 17:33:43 -0000

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 <mailto: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 <mailto: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 <mailto: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 <http://www.independentid.com/>
>> phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
>> 
>> > On Nov 24, 2015, at 12:05 PM, internet-drafts@ietf.org <mailto: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/ <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 <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 <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 <http://tools.ietf.org/>.
>> >
>> > Internet-Drafts are also available by anonymous FTP at:
>> > ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>> >
>> > _______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org <mailto:OAuth@ietf.org>
>> > https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>> 
>> 
>> -- 
>>  <https://www.pingidentity.com/> 				
>> Brian Campbell
>> Distinguished Engineer
>> Ping Identity
>> @	bcampbell@pingidentity.com <mailto:bcampbell@pingidentity.com>
>> 	+1 720.317.2061 <tel:%2B1%20720.317.2061>
>> 	@pingidentity
>> Connect with us!
>>  <https://www.pingidentity.com/> <https://www.pingidentity.com/>
>>  <https://ping.force.com/Support/PingIdentityCommunityHome> <https://ping.force.com/Support/PingIdentityCommunityHome> <http://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>  <https://twitter.com/pingidentity>  <https://www.youtube.com/user/PingIdentityTV>  <https://www.linkedin.com/company/21870>  <https://www.facebook.com/pingidentitypage>  <https://plus.google.com/u/0/114266977739397708540>  <http://www.slideshare.net/PingIdentity>  <http://flip.it/vjBF7>  <https://www.pingidentity.com/blogs/>
> 
> 
> -- 
>  <https://www.pingidentity.com/> 				
> Brian Campbell
> Distinguished Engineer
> Ping Identity
> @	bcampbell@pingidentity.com <mailto:bcampbell@pingidentity.com>
> 	+1 720.317.2061
> 	@pingidentity
> Connect with us!
>  <https://www.pingidentity.com/> <https://www.pingidentity.com/>
>  <https://ping.force.com/Support/PingIdentityCommunityHome> <https://ping.force.com/Support/PingIdentityCommunityHome> <http://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>  <https://twitter.com/pingidentity>  <https://www.youtube.com/user/PingIdentityTV>  <https://www.linkedin.com/company/21870>  <https://www.facebook.com/pingidentitypage>  <https://plus.google.com/u/0/114266977739397708540>  <http://www.slideshare.net/PingIdentity>  <http://flip.it/vjBF7>  <https://www.pingidentity.com/blogs/>_______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth