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

From: Nat Sakimura <[email-masked]>
Date: Fri, 03 Mar 2017 03:15:33 +0000

+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 <[email-masked]> 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 <[email-masked]> 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
> [email-masked]
>
>
>
>
>
>
>
> On Feb 24, 2017, at 1:58 PM, John Bradley <[email-masked]> 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: [email-masked]
> *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: *<[email-masked]>
> *Cc: [email-masked]
>
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 

Nat Sakimura

Chairman of the Board, OpenID Foundation

---

From: John Bradley <[email-masked]>
Date: Fri, 3 Mar 2017 01:07:11 -0300

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" <[email-masked]> wrote:

+1

Nat

-- 

Nat Sakimura

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 03 Mar 2017 09:18:16 +0000

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 <[email-masked]> wrote:

> They are more or less equivalent.   I prefer the private key to never
> leave the device personally.
>

Nat Sakimura

---

From: Ludwig Seitz <[email-masked]>
Date: Fri, 3 Mar 2017 13:10:41 +0100

> I will take a look through them and see if what may be worth updating.

Question about the 'aud' parameter: Wouldn't it be useful to allow other 
values than URIs for that one?

One could easily imagine a group identifier as value of that field, 
where the RS internally resolves whether it is part of that group and 
therefore the target audience of that token.

Regards,

Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE ICT/SICS
Phone +46(0)70-349 92 51

---

From: Anthony Nadalin <[email-masked]>
Date: Fri, 3 Mar 2017 19:48:03 +0000

I also think that this can be useful outside of Token Binding as this we have been looking at use cases for offline access tokens (or ID Tokens), and this sort of forms the basis for this approach

From: OAuth [mailto:[email-masked]] On Behalf Of Nat Sakimura
Sent: Thursday, March 2, 2017 7:16 PM
To: John Bradley <[email-masked]>; Phil Hunt <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: 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...

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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.independentid.com%2F&data=02%7C01%7Ctonynad%40microsoft.com%7Ca66d0b3d54d247111dc808d461e39980%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636241077561026937&sdata=WdNY8UBy5lYNF7Lmi9ryxxRg4P%2BgPOTXoAQlcZVE%2FU0%3D&reserved=0>
[email-masked]<mailto:[email-masked]>

On Feb 24, 2017, at 1:58 PM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:

I had some questions about it so though it was worth keeping alive at-least for discussion.

John B.

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
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: <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>

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:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-oauth-pop-key-distribution%2F&data=02%7C01%7Ctonynad%40microsoft.com%7Ca66d0b3d54d247111dc808d461e39980%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636241077561026937&sdata=hu6Vig%2F9GTVDuQoy9Wk7wlTamxQwQTsJJqhtUJnVLkE%3D&reserved=0>

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-pop-key-distribution-03&data=02%7C01%7Ctonynad%40microsoft.com%7Ca66d0b3d54d247111dc808d461e39980%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636241077561026937&sdata=1AyBrKFxeypPNRhi9KNOS4f%2FjwbZ%2Bx2QX2LtKk7zusw%3D&reserved=0>

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-key-distribution-03<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-oauth-pop-key-distribution-03&data=02%7C01%7Ctonynad%40microsoft.com%7Ca66d0b3d54d247111dc808d461e39980%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636241077561026937&sdata=nbBRocKxUgfGc5UG9cJyvPTzAOv%2BOMSBocPBes9ysXE%3D&reserved=0>

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<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftools.ietf.org&data=02%7C01%7Ctonynad%40microsoft.com%7Ca66d0b3d54d247111dc808d461e39980%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636241077561026937&sdata=Wtts0UG8f5HTb9G8YM4pTufGP6rFvnfnIHvi1Asnahs%3D&reserved=0>.

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7Ctonynad%40microsoft.com%7Ca66d0b3d54d247111dc808d461e39980%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636241077561026937&sdata=uTKQATJVoX%2FRvCBkGJOv44KmXMuq0z3GvOgio%2BPNA4E%3D&reserved=0>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7Ctonynad%40microsoft.com%7Ca66d0b3d54d247111dc808d461e39980%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636241077561026937&sdata=uTKQATJVoX%2FRvCBkGJOv44KmXMuq0z3GvOgio%2BPNA4E%3D&reserved=0>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7Ctonynad%40microsoft.com%7Ca66d0b3d54d247111dc808d461e39980%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636241077561026937&sdata=uTKQATJVoX%2FRvCBkGJOv44KmXMuq0z3GvOgio%2BPNA4E%3D&reserved=0>
--

Nat Sakimura

---

From: John Bradley <[email-masked]>
Date: Fri, 3 Mar 2017 18:52:44 -0300

We rethought aud in https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators

We wanted it to work with bearer tokens so that the AS could put a audience in the token that could not be faked by a malicious RS. 
For the bearer token use case it needs to be a URI to avoid the client being tricked.

For a PoP token it could be logical if the token proof presentment mechanism is secure against RS spoofing.

Presentment mechanisms that are bound to TLS by a EKM or via mutual TLS are OK.
At the application layer the presentment would need sign over the resource URI to prevent forwarding.
Something that used only a signature over a challenge would still rely on there being a unspoofable  audience in the AT itself.

You could securely do a secure logical resource for bearer.

It could be something like the RS would provide its logical resource URI as part of a authenticate response along with the scopes required.

The client could de-refrence the logical scope URI to retrieve a JSON object containing back pointers to the physical resource URI covered by that logical audience.
It could also contain other RS meta-data.

We do something like that in connect to allow multiple redirect URI to generate the same pairwise identifier. 
http://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation <http://openid.net/specs/openid-connect-registration-1_0.html#SectorIdentifierValidation>

RS discovery has been shuffled aside in the WG foe the moment.

I would be OK with res/aud being a logical identifier if it points to meta-data like aud in id_tokens points to meta-data for the AS.

I think making res/aud a free form string would come back and bite us on the ass.

John B.

> On Mar 3, 2017, at 9:10 AM, Ludwig Seitz <[email-masked]> wrote:
> 
> Question about the 'aud' parameter: Wouldn't it be useful to allow other values than URIs for that one?
> 
> One could easily imagine a group identifier as value of that field, where the RS internally resolves whether it is part of that group and therefore the target audience of that token.
> 
> Regards,
> 
> Ludwig
> 
> -- 
> Ludwig Seitz, PhD