[OAUTH-WG] PoP Key Distribution

Justin Richer <jricher@MIT.EDU> Sun, 14 February 2016 18:29 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 []) by ietfa.amsl.com (Postfix) with ESMTP id B82CC1B2BC8 for <oauth@ietfa.amsl.com>; Sun, 14 Feb 2016 10:29:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.507
X-Spam-Status: No, score=-1.507 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id VvH74u94p53d for <oauth@ietfa.amsl.com>; Sun, 14 Feb 2016 10:29:34 -0800 (PST)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu []) (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 B35ED1B2BCC for <oauth@ietf.org>; Sun, 14 Feb 2016 10:29:30 -0800 (PST)
X-AuditID: 12074424-727ff70000000fca-73-56c0c789973a
Received: from mailhub-auth-2.mit.edu ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 27.5A.04042.987C0C65; Sun, 14 Feb 2016 13:29:29 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu []) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u1EITSYI027381 for <oauth@ietf.org>; Sun, 14 Feb 2016 13:29:29 -0500
Received: from [] (static-96-237-195-53.bstnma.fios.verizon.net []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u1EITQIn010728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <oauth@ietf.org>; Sun, 14 Feb 2016 13:29:28 -0500
From: Justin Richer <jricher@MIT.EDU>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <5FBA28B8-77AB-4909-B915-27E0C43101CD@mit.edu>
Date: Sun, 14 Feb 2016 13:29:26 -0500
To: "<oauth@ietf.org>" <oauth@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPIsWRmVeSWpSXmKPExsUixG6nott5/ECYwbu9AhYn375ic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqy29SwF66QqWlfcYGlgbBXtYuTkkBAwkbjVt4y5i5GLQ0ig jUniybyPjBDOMUaJ5j+tUM4HJol5K9axgLSwCahKzF95iwnEZhZQl/gz7xIzhK0tsWzhazBb WEBWouPNBDCbV8BK4tnpz2D1LEC9116dBpsjAtS75vxPJogaPYlXty6zQpwkK7H79yOmCYy8 s5CsmIVkxSwkLQsYmVcxyqbkVunmJmbmFKcm6xYnJ+blpRbpmuvlZpbopaaUbmIEh5OLyg7G 5kNKhxgFOBiVeHh3rNwfJsSaWFZcmXuIUZKDSUmU12z7gTAhvqT8lMqMxOKM+KLSnNTiQ4wS HMxKIrx3NgDleFMSK6tSi/JhUtIcLErivI9+7QwTEkhPLEnNTk0tSC2CycpwcChJ8MYdA2oU LEpNT61Iy8wpQUgzcXCCDOcBGt4PUsNbXJCYW5yZDpE/xagoJc5bBpIQAElklObB9YLiPeHt YdNXjOJArwjzLgSp4gGmCrjuV0CDmYAGV9zeBzK4JBEhJdXAKPr8qLsrR/sprUj3HWq3wyLX 52V8dcv8JrJ906b7retcf6ifjJma0scl0MX2bcnFZ7pfdusm+1TEG4UtF3DhuryyIrZkpZ+o seQbqb3xEQp8wRXl/fIxJY8j9lyum3xlljWXSVNv89NmhvPme1aobX+vUtwd8Szs70Mzq66j v7TiT1szvHFQYinOSDTUYi4qTgQA1k93atICAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/DgLW-rMv83YWX9BbkuEJpTYBCyc>
Subject: [OAUTH-WG] PoP Key Distribution
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: Sun, 14 Feb 2016 18:29:35 -0000

In PoP Key Distribution, I’m trying to figure out the full set of expectations that the client and AS will need to handle across different systems. From what I gather, we’ve got at least these:

Client provides public key:
	- Client stores keypair
	- Server stores public key
	- Server returns public key
	- Client makes sure the public key matches the request (?)

Client provides shared key:
	- Client stores shared key
	- Server stores shared key
	- Server returns shared key
	- Client makes sure the shared key matches (?)

Server provides public key:
	- Server generates keypair
	- Server stores public key (and promises to not store the private key?)
	- Server returns the keypair
	- Client stores the keypair

Server provides shared key:
	- Server generates shared key
	- Server stores shared key
	- Server returns shared key
	- Client stores shared key

First, I think it would be helpful to have this all laid out in the document. Second, a few of these are confusingly non-parallel. If the client sends the key, the server returns the public key. If the client doesn’t send the key, the server returns the keypair (public and private together). It makes sense why the responses are different, but it’s strange to me that we’re asking client developers to expect different things in the same field. 

And then we have error conditions. What happens if the client provides a key but the server rejects that key and creates its own to send to the client? Does the client need to accept this key instead of its own? What if the client sends a shared key and the server returns a keypair? Should the server accept the same key from the client for multiple token requests? I think all of these conditions (and likely a lot more) will need to be covered in the document before it can be really useful for implementors.

The document has a few other editorial and technical problems, like describing the access_token field as a JWT with an encoded key. That’s one of the options for the access token, but hardly the only. It’s fine if it’s used in one of the examples, but we shouldn’t confuse people that they need to use encrypted key wrapping for PoP to work.

Additionally, the use of the “audience” parameter is tied up with key management. The use is really pretty separate, since depending on my setup I can manage the keys just fine without an audience parameter, or require an audience parameter with no key management. It’s really the same problem that we have with Bearer tokens today: how does the RS get the info it needs about the token? Audience parameters help with that but aren’t required for functionality. To me this actually begs a larger question of how scopes get overloaded in OAuth 2. I proposed a while back that we look at three categories of scope-like things sent in parallel: time-based things (token lifetime, do I get a refresh token, etc), target based things (audience, resource), and access based things (the kind of stuff that we thought scope was for in the first place, read/write/delete/etc.). This is all for targeting the token and not tied to PoP itself.

 — Justin