Subject: [OAUTH-WG] Comments on ietf-oauth-dpop

From: Rohan Mahy <[email-masked]>
Date: Tue, 22 Mar 2022 08:24:03 -0700

Hi,
Here are some comments on draft-ietf-oauth-dpop-06:

1) With such a significant attack possible as DPoP proof pre-generation,
why isn't using the server nonce a SHOULD? Preventing a significant attack
and making lifetime handling sane are two excellent reasons to use a server
nonce. If an implementation has a good reason to not use a server nonce, we
can give guidance about what additional steps the implementation needs to
take.

2) The handling of lifetimes of DPoP proofs is vague: "acceptable
timeframe" (Section 4.3), "relatively brief period" (Section 11.1). Is that
1 day,15 minutes, or 30 seconds?
The normative text in the two sections seem contradictory.
I think you need a lifetime parameter if a server nonce isn't included, or
just pick a number (5 minutes?).

3) I had a similar thought to Nicolas Mora about including other
assertions/tokens. There should be a way to chain, include, or reference
other OAuth assertions and bind them somehow with the DPoP. This will be a
common and important model.

4. Right now you describe the access token hash before describing the
access token itself. I think it would be very useful to show the a worked
example of an access token and then its hash used subsequently. Also
Section 4.3 step 11 feels like a circular description. Please rewrite more
verbosely to be clearer:
Currently:
"when presented to a protected resource in conjunction with an access
token, ensure that the value of the ath claim equals the hash of that
access token and confirm that the public key to which the access token is
bound matches the public key from the DPoP proof."

5. Re: IANA registration of the MIME type. TL;DR: Just register
application/dpop+jwt.
Long version: The semantics of the thing you want to register is
application/dpop. The first syntax you are defining is jwt. For example,
iCalendar has three formats: text/calendar (iCal),
application/calendar+json (jCal), and application/calendar+xml (xCal).

NITS:
- Spell out first use of acronyms: JWT, JWK, JWS, TLS, JOSE, PKCE,
- Add reference to TLS, XSS, Crime/Heartbleed/BREACH/etc., HTTP, JOSE, on
first use
- First sentence of Section 2 (Objectives): add a comma (access tokens_,_
by binding) to make it clear that "binding a token" is doing the preventing
instead of the stealing in the sentence.
- Section 2 para 5: s/XXS/XSS/
- Maybe mention why you are using ASCII (7-bit) when the charset in the
examples is UTF-8.

I hope these comments are useful.
Many thanks,
-rohan

*Rohan Mahy  *l  Vice President Engineering, Architecture

Chat: @rohan_wire on Wire

Wire <https://wire.com/en/download/> - Secure team messaging.

*Zeta Project Germany GmbH  *l  Rosenthaler Straße 40,
<https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>10178
Berlin,
<https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>
Germany
<https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>

Geschäftsführer/Managing Director: Morten J. Broegger

HRB 149847 beim Handelsregister Charlottenburg, Berlin

VAT-ID DE288748675

---

From: "Nicolas Mora" <[email-masked]>
Date: Tue, 22 Mar 2022 19:03:04 +0000

Hello,

I would like to add some minor comments to this draft, based on what I've seen so far.

- Resource Server-Provided Nonce
Since a client may have to add different nonces for different RS in the DPoP token, it would be useful to add the issuer in the RS error response, so the client can differntiate nonces more easily.
There may be different RS using the same domain, the client might not know it, and therefore switch nonces again and again between the RS.
Instead, if the RS error response looks like this, there will be no ambiguity:

 HTTP/1.1 400 Bad Request
 DPoP-Nonce: eyJ7S_zG.eyJH0-Z.HX4w-7v

 {
  "error": "use_dpop_nonce",
  "error_description":
    "Authorization server requires nonce in DPoP proof",
  "iss": "https://resource.tld/person/"
 }

- iat and not synced servers
In addition to Rohan's question about the reasonable lifetime to expect for a DPoP token, I'm wondering what is reasonable to accept concerning iat in the future, where the client's clock may be out of sync. The paragraph 11.1 says "the server MAY accept DPoP proofs that carry an iat time in the reasonably near future". Could we add what a reasonably near future might be? In my implementation there is no gap allowed, so I'm wondering.

/Nicolas

---

From: Joseph Heenan <[email-masked]>
Date: Wed, 23 Mar 2022 12:28:01 +0000

Hi Rohan,

> On 22 Mar 2022, at 15:24, Rohan Mahy <rohan.mahy=[email-masked]> wrote:
> 
> 1) With such a significant attack possible as DPoP proof pre-generation, why isn't using the server nonce a SHOULD? Preventing a significant attack and making lifetime handling sane are two excellent reasons to use a server nonce. If an implementation has a good reason to not use a server nonce, we can give guidance about what additional steps the implementation needs to take. 

I think this is a good question, and I’ve been wondering about it myself.

The argument I see for not more strongly requiring nonces is that it pushes additional and non-trivial implementation complexity onto clients (and arguably also onto resource servers).

There are situations where I am not sure a nonce adds much value - for example in the case of a confidential client, an attacker with access to pre-generate DPoP proofs can likely also pre-generate private_key_jwt client authentication assertions and likely also has access to any refresh token. I believe this would allow them to obtain access tokens bound to a DPoP key of their choosing, and a nonce then seems to provide no additional protection.

(There are also cases where the nonce clearly does add a lot of value, particularly when considering public clients, and there may well be an argument for a ’should’ in those cases. Conversely I think there’s a potential argument for saying you should not use nonces in the confidential client situation I outlined, as it adds little other than complexity.)

Thanks

Joseph

---

From: Brian Campbell <[email-masked]>
Date: Wed, 23 Mar 2022 16:17:15 +0100

Thanks Rohan,

Pre-generating a proof requires the ability to execute code on the client,
which is already a problematic situation where other (arguably more)
serious attacks are possible. Such as driving a whole attack directly from
the client. The draft aims to give servers the option to use a nonce but
not push it too much or overstate its protections.

The vagueness around lifetimes is somewhat intentional. At one point the
document (maybe aspirationally) had something like 'no more than a few
seconds' but there was some push-back that it was unrealistically short to
accommodate real world client clock skew. I'm not sure the draft can make a
much more concrete recommendation as I think it really is something that
has tradeoffs and will be implementation/deployment specific. Perhaps
something like, "(on the order of seconds or minutes)" could be added as a
qualifier around lifetime leniency? That maybe gives a general idea of what
is acceptable and/or relatively brief without being overly prescriptive.
I'm quite hesitant to say anything more specific.

An access token and its "ath" hash value are shown as part of the examples
https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-06.html#figure-12 and
https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-06.html#figure-13
respectively. Perhaps it'd be worthwhile to more explicitly mention the
relationship between the two examples? I think I did the calculations
correctly but anyone double checking that work would be welcome. The
sentence in sec 4.3 step 11 is already pretty darn verbose - probably too
much so. I think breaking it up would probably be a better way to make it
more clear.

The MIME type registration will be in the next revision
https://mailarchive.ietf.org/arch/msg/oauth/Vj24ZXU4UuG6Rr04U1Cdrz2rx3o/

I'll work those nits and fix things up as appropriate.

On Tue, Mar 22, 2022 at 4:24 PM Rohan Mahy <rohan.mahy=
[email-masked]> wrote:

> _______________________________________________
> 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: Rohan Mahy <[email-masked]>
Date: Wed, 23 Mar 2022 09:01:09 -0700

Hi Brian,

To be clear, for pre-generated proofs, I am not worried about an attack
against the client; I am worried about a malicious client. Imagine a
malicious client which pre-generates proofs during a brief window while it
has access to a private key stored on the iOS secure enclave, or on a
Yubikey, or a non-extractable WebCryptoAPI CryptoKey. The ability to
pre-generate proofs with no lifetime effectively makes these
non-extractable key protections meaningless for some fixed number of
proofs. If the WG does not want to make server nonces a SHOULD, then I
suggest the following:
"Server implementations need some protection against arbitrary
pre-generation. Servers MUST require all client proofs to contain either a
server-provided nonce, or a server-provided explicit expiration time, or
both."

Adding "(on the order of seconds or minutes)" would already be a big
improvement to what is in the document.

The linkage between Figure 12 and Figure 13 is clear. I was talking about
the linkage between Figure 5 (or the refresh response to Figure 6) and the
token hash in Figure 12.

Many Thanks,
-rohan

VAT-ID DE288748675

On Wed, Mar 23, 2022 at 8:17 AM Brian Campbell <bcampbell=
[email-masked]> wrote:

>> I think you need a lifetime parameter if a server nonce isn't included,
>> or just pick a number (5 minutes?).
>>
> *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: Brian Campbell <[email-masked]>
Date: Thu, 24 Mar 2022 10:48:47 +0100

Hello Nicolas,

The situation you describe of nonce switching with different RSs using the
same domain is possible. But I believe in practice it's rather unlikely to
occur and is self correcting even if it does occur (though kinda
chatty/inefficient). I don't believe it's worthwhile to add stuff to the
protocol to optimize for the situation (of course, the WG should chime-in
if I'm off base from rough consensus here) . The name "iss" is rather
overloaded and would probably not be appropriate, even in the case
something was added. Also - the realm parameter
<https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-06.html#section-7.1-10.2>,
which may "be included to indicate the scope of protection" seems to me
like it could serve the purpose. And, I realize it's a bit pedantic, but
note that the discussion is about RS-provided nonce but the example shows
what would be an AS response.

With respect to "iat" and out-of-sync clocks - some leeway (on the order of
a few seconds or minutes) in both directions to accommodate reasonable and
likely clock skew is probably a good idea. As mentioned to Rohan in a prior
reply, I'll look to qualify this a bit better in the next revision of the
draft.

On Tue, Mar 22, 2022 at 8:03 PM Nicolas Mora <[email-masked]> wrote:

> Since a client may have to add different nonces for different RS in the
> DPoP token, it would be useful to add the issuer in the RS error response,
> so the client can differntiate nonces more easily.
> There may be different RS using the same domain, the client might not know
> it, and therefore switch nonces again and again between the RS.
> In addition to Rohan's question about the reasonable lifetime to expect
> for a DPoP token, I'm wondering what is reasonable to accept concerning iat
> in the future, where the client's clock may be out of sync. The paragraph
> 11.1 says "the server MAY accept DPoP proofs that carry an iat time in the
> reasonably near future". Could we add what a reasonably near future might
> be? In my implementation there is no gap allowed, so I'm wondering.
>
> /Nicolas
>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 24 Mar 2022 11:23:11 +0100

On Wed, Mar 23, 2022 at 5:01 PM Rohan Mahy <rohan.mahy=
[email-masked]> wrote:

> non-extractable key protections meaningless for some fixed number of proofs.
>

Direct usage of everything is also possible during that brief window. Yes,
a nonce helps protect against usage after the window has closed. But it's
not a panacea of protection. Which is, again, why it's an option provided
by the draft to server implementations/deployments that need or want it.
But not more.

> If the WG does not want to make server nonces a SHOULD, then I suggest the
> following:

I'm not sure what, other than a nonce, a "server-provided explicit
expiration time" would be in the context of DPoP? Any
recommendations/requirements the document makes need to be rooted in actual
existing pieces of the protocol defined by that document.

> improvement to what is in the document.

Will do. Thanks.

> the linkage between Figure 5 (or the refresh response to Figure 6) and the

The access token returned in Fig 5 is the same one used in Fig 12. But that
it's in Fig 5 is not really meaningful to the ath or much else. I'm not
sure what could be clarified or better linked?

>> Pre-generating a proof requires the ability to execute code on the
>> client, which is already a problematic situation where other (arguably
>> more) serious attacks are possible. Such as driving a whole attack directly
>> from the client. The draft aims to give servers the option to use a nonce
>> but not push it too much or overstate its protections.
>>
>>> - Add reference to TLS, XSS, Crime/Heartbleed/BREACH/etc., HTTP, JOSE,
>>> on first use
>>> - First sentence of Section 2 (Objectives): add a comma (access
>>> tokens_,_ by binding) to make it clear that "binding a token" is doing the
>>> preventing instead of the stealing in the sentence.

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 24 Mar 2022 16:19:06 -0700

Hi Brian,
1) Re: requiring a nonce or an expiration time, I'll propose some specific
text.
Section 4.2
insert after "* iat: Time at which the JWT was created (REQUIRED)."

"The DPoP proof MUST include either one or both of the following:
 * exp: time after which the proof is no longer valid.

* nonce: an Authorization Server-provided nonce as defined in Section 8."

Section 4.3, insert between steps 9 and 10:
"10.  if an exp claim is present, verify that it is in the future and that
the resulting
duration is acceptable to the server. A proof which contains neither an exp
claim nor a server-provided nonce is invalid;"

Renumber step 10 -> 11 and 11 -> 12.

2) Regarding linking Figure 5 and Figure 12, perhaps the simplest way to
make this linkage clear would be to move Section 7 and Section 7.1 in front
of Section 5.1, and then show the calculation of the hash:

"In our example, we take the value of the access_token in Figure 5:
   Kz~8mXK1EalYznwH-LC-1fBAo.4Ljp~zsPE_NeO.gxU
and calculate the base64 encoding of the SHA256:
   fUHyO2r2Z3DZ53EsNrWBb0xWXoaNy59IiKCAqksmQE "

One specific question which I could not find the answer to is if the token
has been refreshed, is the ath the hash of the original token or the
most-recent token?

Thanks,
-rohan

VAT-ID DE288748675

On Thu, Mar 24, 2022 at 3:23 AM Brian Campbell <bcampbell=
[email-masked]> wrote:

>> If the WG does not want to make server nonces a SHOULD, then I suggest
>> the following:
> The access token returned in Fig 5 is the same one used in Fig 12. But
> that it's in Fig 5 is not really meaningful to the ath or much else. I'm
> not sure what could be clarified or better linked?
>
>
>
>> Many Thanks,
>> -rohan
>>
>>
>>>> 1) With such a significant attack possible as DPoP proof
>>>> pre-generation, why isn't using the server nonce a SHOULD? Preventing a
>>>> significant attack and making lifetime handling sane are two excellent
>>>> reasons to use a server nonce. If an implementation has a good reason to
>>>> not use a server nonce, we can give guidance about what additional steps
>>>> the implementation needs to take.
>>>>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 25 Mar 2022 10:26:27 +0100

Hello Rohan,

The ath claim value in the proof is always the hash of the access token
sent in the same request.

A decision was made fairly early on to not use `exp` in the proof but
rather to rely on the proof's `iat` and give the server some discretion
around the window of acceptance.
https://github.com/danielfett/draft-dpop/issues/38 has some of the
discussion around that. There'd need to be a very compelling reason with WG
agreement to change something fundamental like that at this stage in the
document lifecycle. Note also that, in the context of the proof, the `exp`
value would be something that's set by the client. So it wouldn't be a
"server-provided explicit expiration time" that was in the prior suggested
text.

Similarly, reorganizing the document is not to be undertaken lightly
especially at this point.

On Fri, Mar 25, 2022 at 12:19 AM Rohan Mahy <rohan.mahy=
[email-masked]> wrote:

>> Direct usage of everything is also possible during that brief window.
>> Yes, a nonce helps protect against usage after the window has closed. But
>> it's not a panacea of protection. Which is, again, why it's an option
>> provided by the draft to server implementations/deployments that need or
>> want it. But not more.
>>
>>
>>
>>> The linkage between Figure 12 and Figure 13 is clear. I was talking
>>> about the linkage between Figure 5 (or the refresh response to Figure 6)
>>> and the token hash in Figure 12.
>>>
>>
>>>> The vagueness around lifetimes is somewhat intentional. At one point
>>>> the document (maybe aspirationally) had something like 'no more than a few
>>>>> I think you need a lifetime parameter if a server nonce isn't
>>>>> included, or just pick a number (5 minutes?).
>>>>>
>>>>> - Maybe mention why you are using ASCII (7-bit) when the charset in
>>>>> the examples is UTF-8.
>>>>>

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 25 Mar 2022 03:06:06 -0700

Hi,
Sorry, I meant to type server-provided nonce or *server-validated*
expiration.

Thank you for the pointer to the discussion about exp. Skimming the
comments, the discussion seems oriented at what would be easy for the
client, rather than a balance of implementable for both client and server.
I will raise my concern that requiring the server to remember iat values
for an ambiguous period of time is a security concern (resource
exhaustion/DoS). I don't think this is wise, but if you still want to allow
no server-nonce, and no exp, please include this attack in the security
considerations.

Thanks,
-rohan

VAT-ID DE288748675

On Fri, Mar 25, 2022 at 2:27 AM Brian Campbell <bcampbell=
[email-masked]> wrote:

>> 1) Re: requiring a nonce or an expiration time, I'll propose some
>> specific text.
>> Section 4.2
>> "10.  if an exp claim is present, verify that it is in the future and
>> that the resulting
>> One specific question which I could not find the answer to is if the
>> token has been refreshed, is the ath the hash of the original token or the
>> most-recent token?
>>
>> Thanks,
>> -rohan
>>
>>>>>> - Add reference to TLS, XSS, Crime/Heartbleed/BREACH/etc., HTTP,
>>>>>> JOSE, on first use