Subject: [OAUTH-WG] [DPoP] Protected resource access and invalid DPoP proofs

From: Dmitry Telegin <[email-masked]>
Date: Thu, 5 Aug 2021 17:49:57 +0300

Hello,

When a protected resource is accessed using DPoP proof + DPoP-bound access
token, either of those could be invalid. Should we make distinction between
these two cases? I.e. should the response always be a 401 Unauthorized with
WWW-Authenticate: DPoP ... error="invalid_token"? or could we use
error="invalid_dpop_proof", similar to token request? or maybe even 400 Bad
Request?

Regards,
Dmitry

---

From: Brian Campbell <[email-masked]>
Date: Mon, 9 Aug 2021 15:58:22 -0600

Hi Dmitry,

I think you are right that it's probably worthwhile to allow for a
distinction in a protected resource error response. I'm inclined to say
that a new error code such as "invalid_dpop_proof" to use with the 401
response containing the DPoP WWW-Authenticate header is the most
straightforward way to accommodate it in the document. I'll look to add
that, probably somewhere in section 7
<https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.html#name-protected-resource-access>,
in the next draft revision.

On Thu, Aug 5, 2021 at 8:50 AM Dmitry Telegin <dmitryt=
[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: Dmitry Telegin <[email-masked]>
Date: Thu, 12 Aug 2021 00:02:54 +0300

Hi Brian, thanks for the response,

On a related note, chapter 7.2 allows for protected resources supporting
Bearer and DPoP schemes simultaneously. Is it implied that such resources
should advertise both schemes when challenging user agents with
WWW-Authenticate?

The HTTP 1.1 Authentication spec, section 4.1
<https://datatracker.ietf.org/doc/html/rfc7235#section-4.1> does allow for
multiple challenges sent as a single WWW-Authenticate header, for example:

    WWW-Authenticate: Newauth realm="apps", type=1,
                       title="Login to \"apps\"", Basic realm="simple"

which in our case would look like this:

    WWW-Authenticate: DPoP realm="WallyWorld", algs="ES256 PS256",
                       Basic realm="WallyWorld"

or, in the case of error,

    WWW-Authenticate: DPoP realm="WallyWorld", error="invalid_token",
error_description="Invalid DPoP key binding", algs="ES256",
                       Basic realm="WallyWorld"

The HTTP 1.1 spec, section 4.2
<https://www.rfc-editor.org/rfc/rfc2616.html#section-4.2> also allows for
multiple headers with the same name, but only under very strict conditions;
I'm not yet sure if those apply to WWW-Authenticate.

Is this worth mentioning in the DPoP spec?

Regards,
Dmitry

On Tue, Aug 10, 2021 at 12:58 AM Brian Campbell <bcampbell=
[email-masked]> wrote:

>> When a protected resource is accessed using DPoP proof + DPoP-bound
>> access token, either of those could be invalid. Should we make distinction
>> between these two cases? I.e. should the response always be a 401
>> Unauthorized with WWW-Authenticate: DPoP ... error="invalid_token"? or
>> could we use error="invalid_dpop_proof", similar to token request? or maybe
>> even 400 Bad Request?
>>
>> Regards,
>> Dmitry
>>
> *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: Dmitry Telegin <[email-masked]>
Date: Thu, 12 Aug 2021 00:05:46 +0300

Sorry, "Basic" should be "Bearer" obviously.
Dmitry

On Thu, Aug 12, 2021 at 12:02 AM Dmitry Telegin <[email-masked]>
wrote:

> <https://datatracker.ietf.org/doc/html/rfc7235#section-4.1> does allow
> for multiple challenges sent as a single WWW-Authenticate header, for
> example:
>
>     WWW-Authenticate: DPoP realm="WallyWorld", error="invalid_token", error_description="Invalid DPoP key binding", algs="ES256",
>                        Basic realm="WallyWorld"
>
>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 12 Aug 2021 14:17:24 -0600

It might be worth a mention but I'm always a little hesitant about
potentially repeating content from other specs (and maybe even getting it
wrong!). Maybe a very brief mention along with a pointer to that section in
RFC 7235 would be appropriate? I'm curious what other WG folk think about
this though?

FWIW, https://datatracker.ietf.org/doc/html/rfc7235#section-4.1 does say
"the [WWW-Authenticate] header field itself can occur multiple times."

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 12 Aug 2021 15:31:17 -0700

> RFC 7235 would be appropriate? I'm curious what other WG folk think about

Brief mention + reference seems good to me.

> "the [WWW-Authenticate] header field itself can occur multiple times."

Yes, both this and the implication to offer both challenges should be
unsurprising to people fully steeped in the workings of HTTP (which one
assumes does not cover anywhere close to all people that will be looking at
DPoP).

-Ben

P.S. If you want to become a person steeped in the workings of HTTP,
https://datatracker.ietf.org/doc/draft-ietf-httpbis-semantics/ is a pretty
good place to start.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 12 Aug 2021 15:33:10 -0700

It's not immediately obvious to me that making the distinction is good (but
I'm also basically devoid of the context in which this exchange will
occur).

With security protocols there can be risks from overly descriptive errors,
which might (e.g.) leak information that "this is a valid token" vs "this
is a bogus token" that an attacker who came upon something token-shaped
might not otherwise be able to ascertain.

-Ben

---

From: Brian Campbell <[email-masked]>
Date: Thu, 12 Aug 2021 17:05:03 -0600

Indeed but this case would be only distinguishing between which of the two
things (token & proof) the client sent was invalid. It seems like a
reasonable amount of information to disclose that might be helpful in
troubleshooting while not giving actionable info to would-be attackers.

On Thu, Aug 12, 2021 at 4:33 PM Benjamin Kaduk <[email-masked]> wrote:

> > <
> https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-03.html#name-protected-resource-access
> >,
> access

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 12 Aug 2021 16:16:24 -0700

> troubleshooting while not giving actionable info to would-be attackers.

Agreed on what information is conveyed here.
My thinking may be shaped from work on 2FA for Kerberos, where we go to
great lengths to not reveal whether the password or second-factor code was
incorrect, to avoid a "divide-and-conquer" type attack on human-selected
passwords.  The situation is, admittedly, different here.

-Ben