Thanks John. Perhaps you can add the discussion to the security consideration.
I understand the issue with mobile clients inability to get a good random but the shift of key generation point would have a large impact on the liability shift as well so I would probably profile it down always to require keys to be generated by the client. >From editorial point of view, I would appreciate if you can put sub-headings to each topics dealt in 7. Security Considerations. Best, Nat On Fri, Mar 3, 2017 at 1:07 PM John Bradley <ve7...@ve7jtb.com> wrote: > The private key is encrypted to the client. If the attacker has the > symmetric key then it would get the proof key. > > I prefer the client to always provide the key, however some people believe > that mobile devices can't reliably create secure key, and it is better to > have the server create the keypair. > > In both cases you are relying on the client authentication or PKCE to bind > to the correct client. > > They are more or less equivalent. I prefer the private key to never > leave the device personally. > > This has been debated several times. > > John B. > > On Mar 3, 2017 12:15 AM, "Nat Sakimura" <sakim...@gmail.com> wrote: > > +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 <ve7...@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.h...@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.h...@oracle.com > > > > > > > > On Feb 24, 2017, at 1:58 PM, John Bradley <ve7...@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-dra...@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-annou...@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 > > > -- Nat Sakimura Chairman of the Board, OpenID Foundation
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
