Re: [OAUTH-WG] Proof of Possession Tokens: Next Steps

Justin Richer <jricher@mit.edu> Fri, 05 February 2016 01:06 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 C6E221B2B86 for <oauth@ietfa.amsl.com>; Thu, 4 Feb 2016 17:06:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 z57faer6UDXL for <oauth@ietfa.amsl.com>; Thu, 4 Feb 2016 17:06:09 -0800 (PST)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6FB51B2B85 for <oauth@ietf.org>; Thu, 4 Feb 2016 17:06:08 -0800 (PST)
X-AuditID: 1209190c-513ff7000000165e-2a-56b3f57d0403
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id F9.B6.05726.D75F3B65; Thu, 4 Feb 2016 20:06:05 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u15164Rx009150; Thu, 4 Feb 2016 20:06:05 -0500
Received: from [192.168.128.48] (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 u15163cD009763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Feb 2016 20:06:04 -0500
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/signed; boundary="Apple-Mail=_5C993350-54C6-4032-BFE4-C2A6C0541ADA"; protocol="application/pgp-signature"; micalg=pgp-sha256
X-Pgp-Agent: GPGMail 2.5.2
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <56B3A313.9000006@gmx.net>
Date: Thu, 4 Feb 2016 20:06:02 -0500
Message-Id: <29C42711-63CA-4E12-98CB-6B8FBDFA106F@mit.edu>
References: <569E21DA.30002@gmx.net> <840D6473-8F4D-4843-9CFB-97E4AA1AC8CB@mit.edu> <56B3A313.9000006@gmx.net>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEKsWRmVeSWpSXmKPExsUixCmqrVv7dXOYQdtHBYulO++xWpx8+4rN gclj8ab9bB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4+OwuU0GbZcXK+8+ZGxi/63UxcnJICJhI vN0/k62LkYtDSKCNSWLC36nMEM4GRomFR89DObeYJB6u/s8G0iIsYCdx+VE/O4jNK6An8erW ZVYQm1lgCqPE/Jm6XYwcQGOlJGbsFwAJswmoSkxf08IEEuYUUJf4/TsaJMwioCKxcOEjRpAw M1C4/aQLxEAric2PtoEtEhLIkzh26xsziC0iYChxfeZ0VoibZSV2/37ENIFRYBaSG2YhuQHC 1pZYtvA1M4StKbG/ezkLhC0vsf3tHKi4pcTimTeg4rYSt/oWMEHYdhKPpi1iXcDIsYpRNiW3 Sjc3MTOnODVZtzg5MS8vtUjXUC83s0QvNaV0EyM4OiR5djC+Oah0iFGAg1GJhzdj9eYwIdbE suLK3EOMkhxMSqK8vneAQnxJ+SmVGYnFGfFFpTmpxYcYVYB2Pdqw+gKjFEtefl6qkgjvlrtA dbwpiZVVqUX5MGXSHCxK4rxG/JvChATSE0tSs1NTC1KLYLIyHBxKErwZX4AaBYtS01Mr0jJz ShDSTBychxglOHiAhl/5DDK8uCAxtzgzHSJ/ilFRSpzXBaRZACSRUZoH1wtKaglvD5u+YhQH ekuYdw1IFQ8wIcJ1vwIazAQ0+DQj2OCSRISUVAPjruiGlBtsZataDX4/+57MYLrJStouNv28 nFLEoidv3tm1bWjf03wsUTTbVM76zaNpRhdjnOXueqpMzRJnEWuf8aTll83lnQWF2szRq9Wt mec6b3IJvfUv7W/01C36T2ZzNnVG6BzYYnDq4+rjJ3elvHqj3P770q+XWgKmn1pOvWO/67w0 bv4rJZbijERDLeai4kQA+NgrVkUDAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/-zHlLpjPWgqhuoJGUk3V17ULkPU>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Proof of Possession Tokens: Next Steps
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: Fri, 05 Feb 2016 01:06:11 -0000

Hannes, thanks for your clarification.

I believe what we need is more working group involvement and feedback and not more authors on the document. As I’ve explained off-list and on several times, the document didn’t move forward in the last year because there hadn’t been any discussion or reason to move it forward. Now I have a reason to move it forward on my own, so I’ve contributed the implementation and updated text.

I’m of course happy to have additional authors if they’re interested in contributing to the draft text itself and helping to edit it. I’m surprised that there are people willing to edit the document when there haven’t been any public discussions of it to date, so I would suggest that as a WG we start there.

 — Justin

> On Feb 4, 2016, at 2:14 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
> 
> Hi Justin,
> 
> you have not been removed from the author list of the HTTP signing
> draft. Unfortunate wording in my mail below may have given you that
> impression but I would like to bring some additional people on board who
> expressed interest.
> 
> As you know, it is also great if we get new people to volunteer to do
> work when we get stuck.
> 
> Since there needs to be "space" on the author list I would at least
> remove myself from the author list of the HTTP signing document.
> 
> Ciao
> Hannes
> 
> PS: I saw your post regarding the PoP implementation. Thanks for doing
> that work. It is highly appreciated!
> 
> On 01/19/2016 05:34 PM, Justin Richer wrote:
>> Well that’s interesting: I was unaware I was being removed as the author
>> of the HTTP signing draft. This is especially surprising after the
>> presentation I gave at Yokohama about this topic. The draft hasn’t been
>> updated because there’s not really been any discussion on it here in the
>> group to drive an update, and I’m not one to artificially publish a new
>> draft with the same content and a new date just to avoid the “expired”
>> tag in the repository.
>> 
>> To see the direction I proposed that we go in at Yokohama, check my
>> slides here:
>> 
>> https://www.ietf.org/proceedings/94/slides/slides-94-oauth-3.pdf
>> 
>> Again, I got no real feedback on this and there was no discussion on the
>> list. Even so, I’m implementing this in a Node.js application anyway
>> that I plan to post back to the group here when it’s done.
>> 
>> — Justin
>> 
>>> On Jan 19, 2016, at 6:45 AM, Hannes Tschofenig
>>> <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>> wrote:
>>> 
>>> Hi all,
>>> 
>>> I wanted to drop a high level message about possible next steps for the
>>> PoP work.
>>> 
>>> As you have seen from my status update, see
>>> http://www.ietf.org/mail-archive/web/oauth/current/msg15327.html, the
>>> PoP architecture document was already in IESG processing but I have had
>>> asked Kathleen to delay the publication given that we ran into scoping
>>> issues, as discussed on the list. See
>>> http://www.ietf.org/mail-archive/web/oauth/current/msg15177.html
>>> 
>>> The change of scope related to desire to not just binding a key to the
>>> access token but also to other parts of the OAuth system to avoid cases
>>> where an attacker can just obtain attack other parts of the system
>>> instead (for example, by obtaining an bearer-based refresh token to then
>>> obtain a new PoP access token).
>>> 
>>> The recently discovered security problems tell us that we need to
>>> simplify our solutions a bit as well to ensure that we get the security
>>> analysed properly. More options means more time to analyse all the
>>> different options.
>>> 
>>> What does this mean to simplify when I talk about expanding the scope in
>>> the earlier paragraph?
>>> 
>>> I am suggesting to
>>> 
>>> * to consider focusing on a public key-based only solution for the
>>> web/smart phone app space. (The ACE working group will have to develop a
>>> symmetric key-based version on their own, if desired.)
>>> 
>>> * to extend the support of PoP token functionality throughout the entire
>>> solution. This means that we have to include support for a asymmetric
>>> version of PKCE into account (which had been discussed in the group
>>> already earlier already).
>>> 
>>> * to define at least a TLS-based security security solution for the
>>> communication between the client and the resource server.
>>> 
>>> * to rethink the work on the application layer security solution. The
>>> HTTP signing draft, which defines the application layer security
>>> solution for use between the client and the resource server, has expired
>>> and we will have to find new authors. I believe we got stuck a bit.
>>> Luckily new persons came along and volunteered to help, namely Fredrik
>>> Ljunggren and Jakob Schlyter. Nevertheless, the group will have to judge
>>> whether a newly developed application layer security solution is
>>> promising. My impression is that it is a very difficult to come up with
>>> a solution that satisfies the security requirements and, at the same
>>> time, also takes the deployment status of proxies and other middleware
>>> into account.
>>> 
>>> * to make a decision about other extensions. Nat and Kepeng submitted
>>> the Sender Constrained JWT for OAuth2 2.0 document, see
>>> https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-06
>>> We asked the working group for feedback during IETF #93 and we couldn't
>>> get enough feedback at that time. Please give us feedback whether you
>>> are interested in exploring that solution direction as part of this
>>> process. Today, we don't have enough indication of interest for working
>>> on that solution direction.
>>> 
>>> Before making any changes to the PoP document set we would like to hear
>>> your thoughts.
>>> 
>>> Ciao
>>> Hannes
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>