Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-03.txt

+1

Token binding is good, but there are infrastructures that cannot deploy it
while they still need HoK in some manner.
It could be a short term thing -- perhaps 3 years, but they have to do it
now so...

I have a question about the draft.

In section 5.1, `key` is optional and when it is omitted, the server
creates a ephemeral key pair for the client.
My question is: how do you send the ephemeral private key securely to the
client?
I suppose it is returned in the similar fashion as in the case of the
symmetric, but it is not clear from my read.

Also, at that point, the authorization server has everything needed to
impersonate the client, which may not be desirable.
Is it not simpler and better to REQUIRE the `key` parameter?

Nat

On Sat, Feb 25, 2017 at 8:51 AM John Bradley <ve7jtb@ve7jtb.com> wrote:

> The European banks are interested in mutual TLS for server to server
> connections as part of PSD2/Open Banking.
>
> They have been thinking that they would have central CA and directly use
> CA certificates for all the legs.
>
> I sent them this to get them thinking that they could perhaps secure the
> token endpoint with cert based mutual TLS but allow clients to specify
> there own keys for access tokens to make key rotation and deployment easier.
>
> I was also think ing that they could protect a jwks_uri with the CA
> certificate using OCSP stapling and then use mutual TLS to the token
> endpoint based on keyid and/or fingerprint. allowing for rotation of keys
> to token endpoint and better support clusters with multiple keys.
>
> I don’t think this has much interest outside of some verticals like
> financials.
>
> John B.
>
> On Feb 24, 2017, at 8:33 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
>
> I have been wondering about that myself. Interest seems to wained with the
> TOKBIND work emerging. Maybe I am wrong about that?
>
> Phil
>
> Oracle Corporation, Identity Cloud Services & Identity Standards
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
>
>
>
>
>
> On Feb 24, 2017, at 1:58 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>
> I updated the references but haven't made any other changes.
>
> I had some questions about it so though it was worth keeping alive
> at-least for discussion.
>
> There have been some other questions and proposed changes.
>
> I will take a look through them and see if what may be worth updating.
>
> John B.
>
> Begin forwarded message:
>
> *From: *internet-drafts@ietf.org
> *Subject: **[OAUTH-WG] I-D Action:
> draft-ietf-oauth-pop-key-distribution-03.txt*
> *Date: *February 24, 2017 at 6:55:25 PM GMT-3
> *To: *<i-d-announce@ietf.org>
> *Cc: *oauth@ietf.org
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Web Authorization Protocol of the IETF.
>
>        Title           : OAuth 2.0 Proof-of-Possession: Authorization
> Server to Client Key Distribution
>        Authors         : John Bradley
>                          Phil Hunt
>                          Michael B. Jones
>                          Hannes Tschofenig
> Filename        : draft-ietf-oauth-pop-key-distribution-03.txt
> Pages           : 18
> Date            : 2017-02-24
>
> Abstract:
>   RFC 6750 specified the bearer token concept for securing access to
>   protected resources.  Bearer tokens need to be protected in transit
>   as well as at rest.  When a client requests access to a protected
>   resource it hands-over the bearer token to the resource server.
>
>   The OAuth 2.0 Proof-of-Possession security concept extends bearer
>   token security and requires the client to demonstrate possession of a
>   key when accessing a protected resource.
>
>   This document describes how the client obtains this keying material
>   from the authorization server.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-key-distribution-03
>
>
> 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
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 

Nat Sakimura

Chairman of the Board, OpenID Foundation