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

Justin Richer <jricher@mit.edu> Wed, 25 November 2015 20:35 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 23DA31B2F8E for <oauth@ietfa.amsl.com>; Wed, 25 Nov 2015 12:35:01 -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 0m57LYQlqo22 for <oauth@ietfa.amsl.com>; Wed, 25 Nov 2015 12:34:57 -0800 (PST)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECD3B1B2F19 for <oauth@ietf.org>; Wed, 25 Nov 2015 12:34:56 -0800 (PST)
X-AuditID: 1209190e-f79046d0000036c0-1d-56561b6eaf9d
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-3.mit.edu (Symantec Messaging Gateway) with SMTP id 0F.85.14016.F6B16565; Wed, 25 Nov 2015 15:34:55 -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 tAPKYsCW010495; Wed, 25 Nov 2015 15:34:54 -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 tAPKYqA4015378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Nov 2015 15:34:53 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_F39AB13D-5D31-426E-ACC5-0F5878FC4E1D"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <C30EA0BD-8E3D-42BB-AF83-744D89A61813@ve7jtb.com>
Date: Wed, 25 Nov 2015 15:34:51 -0500
Message-Id: <64BFC277-5966-4B02-8EE2-D23CD1390766@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> <C9F8F669-E091-4E81-82B6-B5AF1A52F922@ve7jtb.com> <FD46B414-EEEA-44AF-BEDC-F4F1DA425EBA@oracle.com> <C08B852F-3B42-4EBE-B64A-740F723BF040@mit.edu> <C30EA0BD-8E3D-42BB-AF83-744D89A61813@ve7jtb.com>
To: John Bradley <ve7jtb@ve7jtb.com>
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNKsWRmVeSWpSXmKPExsUixCmqrJsvHRZmcOMvq8XJt6/YLBbMb2S3 WH33L5sDs8eSJT+ZPD4+vcXicfv2RpYA5igum5TUnMyy1CJ9uwSujONTPApmfmKsePjmAksD 498LjF2MnBwSAiYSp7svMEHYYhIX7q1n62Lk4hASWMwkMX/5dShnI6PE699/mCGch0wS566t BspwcDALJEj8XSYN0s0roCfx6tZlVhBbWMBH4uLpJ2A2m4CqxPQ1LWAbOAXsJLZO2cgMYrMA xSfsPskCYjMLeEp8mj6dBWKOlcSrN/9ZIHatZ5Z4fuUiG0hCREBFYt++R1Bny0rs/v2IaQKj wCyEM2YhOWMW2FhtiWULXzND2JoS+7uXs2CKa0h0fpvIuoCRbRWjbEpulW5uYmZOcWqybnFy Yl5eapGusV5uZoleakrpJkZwHEjy7WD8elDpEKMAB6MSD++ERyFhQqyJZcWVuYcYJTmYlER5 LTnCwoT4kvJTKjMSizPii0pzUosPMUpwMCuJ8G77EBomxJuSWFmVWpQPk5LmYFES5537xTdM SCA9sSQ1OzW1ILUIJivDwaEkwRsqBTRUsCg1PbUiLTOnBCHNxMEJMpwHaHgQSA1vcUFibnFm OkT+FKOilDivEkhCACSRUZoH1wtKUwlvD5u+YhQHekWYtwikigeY4uC6XwENZgIaHJEDcnVx SSJCSqqB0Wb7G3PVXPsz0nOO7l8fd+12sdqCr/8uJ/p08Z2+73aZYw1zSbK4U1kF5wOxbqfk 44Kv5Pmz7nTM1fr4efr/e/+2yHxOF3lTw2deLX69M3q+TP+SC49eH7u16n9i3nZttqi1arfb mH6HSG0TbbNZK60kv3mOfqzK1viNN7ROil/59cjV/ckfXyWW4oxEQy3mouJEACR6hk0uAwAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/q8trsVsA9M__kfLnAONN8aeM8xs>
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 20:35:01 -0000

Well not only is it a non-starter, it’s completely unnecessary to begin with. Issues are getting conflated here. I never read that section in the way that it apparently was, so that needs to be backed out.

 — Justin

> On Nov 25, 2015, at 3:31 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
> 
> Yes all access tokens bearer or PoP are audienced to the RS, Integrity protected in a way the RS can verify, and if required encrypted to the RS.
> 
> I would guess that a majority of deployments I know of want introspection or encrypted AT to protect the confidentiality of the attributes passed in the access token.
> There is commonly user and or role info that they want to protect.   If PoP required the tokens to be readable/verifiable by the client then it would be a non starter for privacy reasons lots of places.
> 
> John B.
> 
> 
>> On Nov 25, 2015, at 5:21 PM, Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
>> 
>> The only actual requirement is opacity. Section 6 should be more clearly called out as an example instead, which is what it is.
>> 
>> Perhaps we should also re-state that access tokens remain opaque to the client in the introductory text.
>> 
>>  — Justin
>> 
>>> On Nov 25, 2015, at 3:19 PM, Phil Hunt <phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>> wrote:
>>> 
>>> Thats not what I am on about. 
>>> 
>>> Kathleen objected to the signed requirement in sec 6 without making it clear in sec 5. 
>>> 
>>> We can't have it both ways. Be both opaque and signed for the client to verify.  
>>> 
>>> If I restore the requirements than the threat mitigation assumption of signed tokens must also be removed. 
>>> 
>>> Phil
>>> 
>>> On Nov 25, 2015, at 12:02, John Bradley <ve7jtb@ve7jtb.com <mailto:ve7jtb@ve7jtb.com>> wrote:
>>> 
>>>> The token is opaque to the client.  It’s format is a matter between the RS and the AS. 
>>>> 
>>>> Where do we require the client verify the token?    The RS is the only party that needs to verify the access token.
>>>> 
>>>> The information that the client needs about the token is in additional meta-data delivered with but not in the AT.
>>>> 
>>>> I agree with Brian that is wrong on two counts.
>>>> 
>>>> 1) the token is opaque to the client.
>>>> 2) one method of delivering the key to the RS is in a signed JWT.  It is however also possible (if not ideal) for the AT to be a reference, and introspected by the RS to get the key.
>>>> 
>>>> So 
>>>> "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 are also opaque to OAuth 2.0 clients but may be parsed and verified, or introspected by OAuth 2.0 Resource Servers. When token endpoints issue “PoP” tokens they provide the OAuth Client additional parameters with information on what key material to use for the proof.”
>>>> 
>>>> Or given that they are both opaque that part of the statement could be dropped.
>>>> 
>>>> John B. 
>>>> 
>>>> 
>>>>> On Nov 25, 2015, at 12:44 PM, 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
>>>>>> 	@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 <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>
>> 
>