Subject: Re: [OAUTH-WG] draft-fett-oauth-dpop-00

From: Brian Campbell <[email-masked]>
Date: Tue, 2 Apr 2019 10:35:06 -0500

Except that the jwk header is more appropriate in the given context
https://tools.ietf.org/html/rfc7515#section-4.1.3 - it is the public key
that corresponds to the key used to digitally sign the JWS.  Which is what
it is.

On Thu, Mar 28, 2019, 6:32 AM Mike Jones <Michael.Jones=
[email-masked]> wrote:

> Good observation, Ludwig.  We should do that.
>
>                                 -- Mike
>
> -----Original Message-----
> From: OAuth <[email-masked]> On Behalf Of Ludwig Seitz
> Sent: Thursday, March 28, 2019 12:05 PM
> To: [email-masked]
> Subject: Re: [OAUTH-WG] draft-fett-oauth-dpop-00
>
> On 28/03/2019 11:17, Daniel Fett wrote:
> > Hi all,
> >
> > I published the first version of the DPoP draft at
> > https://tools.ietf.org/html/draft-fett-oauth-dpop-00
> >
> > Abstract
> >
> >     This document defines a sender-constraint mechanism for OAuth 2.0
> >     access tokens and refresh tokens utilizing an application-level
> >     proof-of-possession mechanism based on public/private key pairs.
> >
> >
> > Thanks for the feedback I received so far from John, Mike, Torsten,
> > and others during today's session or before!
> >
> > If you find any errors I would welcome if you open an issue in the
> > GitHub repository at https://github.com/webhamster/draft-dpop
> >
> > - Daniel
> >
> >
>
> A quick nit:
>
> in figure 3 you seem to be using the "jwk" claim to include the pop-key in
> the token. Any reason for not using the "cnf" claim from RFC 7800?
>
> /Ludwig
>
>
> --
> Ludwig Seitz, PhD
> Security Lab, RISE
> Phone +46(0)70-349 92 51
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 3 Apr 2019 08:28:11 +0200

On 02/04/2019 17:35, Brian Campbell wrote:
> that corresponds to the key used to digitally sign the JWS.  Which is 
> what it is.
> 
> 

>     A quick nit:
> 
>     in figure 3 you seem to be using the "jwk" claim to include the
>     pop-key in the token. Any reason for not using the "cnf" claim from
>     RFC 7800?
> 
>     /Ludwig
> 

My bad, figure 3 is not a token (although it looks like one) it's the 
token request (encapsulated in a JWS).

/Ludwig

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

---

From: George Fletcher <[email-masked]>
Date: Wed, 3 Apr 2019 11:28:18 -0400

A quick question regarding...

    o  "http_uri": The HTTP URI used for the request, without query and
       fragment parts (REQUIRED).

Is 'without' supposed to be 'with' ? The example shows the http_uri 
*with* the query parameters :)

---

From: Daniel Fett <[email-masked]>
Date: Wed, 3 Apr 2019 17:39:46 +0200

This is fixed in -01:

https://tools.ietf.org/html/draft-fett-oauth-dpop-01

-Daniel

---

From: George Fletcher <[email-masked]>
Date: Wed, 3 Apr 2019 12:01:34 -0400

Perfect! Thank you! A couple comments on version 01...

    POST /token HTTP/1.1
    Host: server.example.com
    Content-Type: application/x-www-form-urlencoded;charset=UTF-8
    DPoP-Binding: eyJhbGciOiJSU0ExXzUi ...

    grant_type=authorization_code
    &code=SplxlOBeZQQYbYS6WxSbIA
    &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
    (remainder of JWK omitted for brevity)

I believe the "(remainder of JWK..." should be moved to the DPoP-Binding 
header...

Also, there is no discussion of the DPoP-Binding header outside of the 
token request, but I suspect that is the desired way to communicate the 
DPoP-Proof to the RS.

Possibly an example in the session for presenting the token to the RS 
would help.

Thanks,
George

---

From: Phil Hunt <[email-masked]>
Date: Mon, 8 Apr 2019 16:23:36 -0700

Question. One of the issues that Justin Richer’s signing draft tried to address was url modification by tls terminators/load balencers/proxies/api gateways etc. 

How do you see this issue in dpop? Is it a problem? 

Phil

> On Apr 3, 2019, at 9:01 AM, George Fletcher <gffletch=[email-masked]> wrote:
> 
> I believe the "(remainder of JWK..." should be moved to the DPoP-Binding header...
> 
> Also, there is no discussion of the DPoP-Binding header outside of the token request, but I suspect that is the desired way to communicate the DPoP-Proof to the RS.
> 
> Possibly an example in the session for presenting the token to the RS would help.
> 
> Thanks,
> George
> 
>>> Is 'without' supposed to be 'with' ? The example shows the http_uri *with* the query parameters :)
>>> 
>>>> I published the first version of the DPoP draft at https://tools.ietf.org/html/draft-fett-oauth-dpop-00
>>>> 
>>>> Abstract
>>>> 
>>>> Thanks for the feedback I received so far from John, Mike, Torsten, and others during today's session or before!
>>>> 
>>>> If you find any errors I would welcome if you open an issue in the GitHub repository at https://github.com/webhamster/draft-dpop
>>>> 
>>>> - Daniel    
>>>> 
>>>> 
>>>> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II&s=8LDvfTYESi1fDeRK7mQrHFeo9okoJ4NTZU4OHyeRJWk&e=

---

From: Justin Richer <[email-masked]>
Date: Mon, 8 Apr 2019 23:40:40 +0000

Corollary to this, are there thoughts of header protection under this method, and the associated issue of header modification?

— Justin

On Apr 8, 2019, at 7:23 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Phil

On Apr 3, 2019, at 9:01 AM, George Fletcher <gffletch=[email-masked]<mailto:gffletch=[email-masked]>> wrote:

   POST /token HTTP/1.1
   Host: server.example.com<http://server.example.com/>
   Content-Type: application/x-www-form-urlencoded;charset=UTF-8
   DPoP-Binding: eyJhbGciOiJSU0ExXzUi ...

Thanks,
George

https://tools.ietf.org/html/draft-fett-oauth-dpop-01<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dfett-2Doauth-2Ddpop-2D01&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II&s=TEa5Vgb3rAzxbIuavB1lN65fnkTxKoMp7F2rw1AjuEY&e=>

-Daniel

Hi all,

I published the first version of the DPoP draft at https://tools.ietf.org/html/draft-fett-oauth-dpop-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dfett-2Doauth-2Ddpop-2D00&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II&s=eeMGKZq5R86dv0XgrBsIijzuI8OzQqnE-vmUEZ836hY&e=>

Abstract

If you find any errors I would welcome if you open an issue in the GitHub repository at https://github.com/webhamster/draft-dpop<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_webhamster_draft-2Ddpop&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II&s=RR3u82IhN7whr8LgXMWM2fWN7EKH6GO-Bs-HRxEwKHE&e=>

- Daniel

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II&s=8LDvfTYESi1fDeRK7mQrHFeo9okoJ4NTZU4OHyeRJWk&e=>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II&s=8LDvfTYESi1fDeRK7mQrHFeo9okoJ4NTZU4OHyeRJWk&e=
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Tue, 9 Apr 2019 17:05:21 -0600

The thought/intent is that it's really about proof-of-possession rather
than protecting the request. So the signature is over a minimal set of
information.

On Mon, Apr 8, 2019 at 5:41 PM Justin Richer <[email-masked]> wrote:

> Corollary to this, are there thoughts of header protection under this
> method, and the associated issue of header modification?
>
> — Justin
>
> On Apr 8, 2019, at 7:23 PM, Phil Hunt <[email-masked]> wrote:
>
> Question. One of the issues that Justin Richer’s signing draft tried to
> address was url modification by tls terminators/load balencers/proxies/api
> gateways etc.
>
> On Apr 3, 2019, at 9:01 AM, George Fletcher <
> gffletch=[email-masked]> wrote:
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dfett-2Doauth-2Ddpop-2D01&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II&s=TEa5Vgb3rAzxbIuavB1lN65fnkTxKoMp7F2rw1AjuEY&e=>
>
> -Daniel
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dfett-2Doauth-2Ddpop-2D00&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II&s=eeMGKZq5R86dv0XgrBsIijzuI8OzQqnE-vmUEZ836hY&e=>
>
> Abstract
>
> If you find any errors I would welcome if you open an issue in the GitHub
> repository at https://github.com/webhamster/draft-dpop
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_webhamster_draft-2Ddpop&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II&s=RR3u82IhN7whr8LgXMWM2fWN7EKH6GO-Bs-HRxEwKHE&e=>
>
> - Daniel
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II&s=8LDvfTYESi1fDeRK7mQrHFeo9okoJ4NTZU4OHyeRJWk&e=>
>
>
>
>

---

From: Justin Richer <[email-masked]>
Date: Wed, 10 Apr 2019 02:36:35 +0000

Then why include the request at all? Simpler to just sign a nonce and send those, then.

— Justin

On Apr 9, 2019, at 7:05 PM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:

The thought/intent is that it's really about proof-of-possession rather than protecting the request. So the signature is over a minimal set of information.

On Mon, Apr 8, 2019 at 5:41 PM Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
Corollary to this, are there thoughts of header protection under this method, and the associated issue of header modification?

— Justin

Phil

   POST /token HTTP/1.1

Thanks,
George

-Daniel

Hi all,

Abstract

- Daniel

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

---

From: David Waite <[email-masked]>
Date: Tue, 9 Apr 2019 21:56:10 -0600

My understanding:

The proof-of-possession needs to have a limited destination to prevent replay against other resources. Similar to resource indicators and to distributed OAuth, the client is expected to use a resource URL view of the world rather than an access-token-specific audience or scoped view of the world. (And method, because thats cheap to do.)

HTTP request signing has a high degree of complexity, and has had several iterations each with their own strengths and weaknesses (which I know you are intimately familiar with!)

There is nothing currently to prevent other specification(s) adding extra key/values corresponding to a header set and hash, query hash, body hash, and so on. If that holds true in the final specification, then an environment could require those keys to be present, and then leverage DPoP for both proof-of-possession and non-repudiation. 

-DW

> On Apr 9, 2019, at 8:36 PM, Justin Richer <[email-masked]> wrote:
> 
>> On Apr 9, 2019, at 7:05 PM, Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> On Mon, Apr 8, 2019 at 5:41 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>>> On Apr 8, 2019, at 7:23 PM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> On Apr 3, 2019, at 9:01 AM, George Fletcher <gffletch=[email-masked] <mailto:gffletch=[email-masked]>> wrote:
>>> 
>>>>    Host: server.example.com <http://server.example.com/>
>>>>> https://tools.ietf.org/html/draft-fett-oauth-dpop-01 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dfett-2Doauth-2Ddpop-2D01&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II&s=TEa5Vgb3rAzxbIuavB1lN65fnkTxKoMp7F2rw1AjuEY&e=>
>>>>> 
>>>>> -Daniel
>>>>> 
>>>>>>> I published the first version of the DPoP draft at https://tools.ietf.org/html/draft-fett-oauth-dpop-00 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dfett-2Doauth-2Ddpop-2D00&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II&s=eeMGKZq5R86dv0XgrBsIijzuI8OzQqnE-vmUEZ836hY&e=>
>>>>>>> Abstract
>>>>>>> 
>>>>>>> If you find any errors I would welcome if you open an issue in the GitHub repository at https://github.com/webhamster/draft-dpop <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_webhamster_draft-2Ddpop&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II&s=RR3u82IhN7whr8LgXMWM2fWN7EKH6GO-Bs-HRxEwKHE&e=>
>>>>>>> - Daniel    
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> [email-masked] <mailto:[email-masked]>
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II&s=8LDvfTYESi1fDeRK7mQrHFeo9okoJ4NTZU4OHyeRJWk&e=>
>>>>>> 
>>>>> 
>>>> 
>>>> [email-masked] <mailto:[email-masked]>
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II&s=8LDvfTYESi1fDeRK7mQrHFeo9okoJ4NTZU4OHyeRJWk&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=eQpusEFY7fROXNfEJmh0QzkejgdgaVnILpbm2q8x9II&s=8LDvfTYESi1fDeRK7mQrHFeo9okoJ4NTZU4OHyeRJWk&e=>
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>

---

From: Simon Moffatt <[email-masked]>
Date: Thu, 11 Apr 2019 09:30:02 +0100

Hi Daniel

I couldn't see on the thread if this has already been discussed, so
apologies if it has, but is there any value in checking the PoP JWT
freshness?  Eg validating an *iat* claim  - probably more likely on the RS?

Eg I see the *jti* claim is useful for replay protection (assuming
storage of that on the AS/RS side) do you think it might be good to also
to know how fresh the token is? 

I guess this falls under
https://tools.ietf.org/html/draft-fett-oauth-dpop-01#section-6

Regards

Simon.

-- 
ForgeRock <https://www.forgerock.com/> 	*Simon Moffatt* CISSP, CEH
Technical Director - IAM Core | Product Management | ForgeRock
*t* (44) 7903 347 240  |  *e* [email-masked]
<mailto:[email-masked]>
*twitter* @simonmoffatt  |  *web* www.forgerock.com
<https://www.forgerock.com/>

NOTICE: This message, including any attachments, may contain
confidential information. If you are not the intended recipient, please
advise the sender immediately and destroy all copies of this message and
any attachments. ForgeRock Ltd may monitor email traffic data and also
the content of email transmitted over its network for security purposes.
No employee or agent is authorized to conclude any binding agreement on
behalf of ForgeRock Ltd by means of e-mail communication. ForgeRock Ltd
is a limited company registered in England and Wales; its registered
address is 60 Queen Square, Bristol, BS1 4JZ; and its registration
number is 7227664.

Nashville 2018 <https://www.forgerock.com/identity-live/nashville>