Subject: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-par-02.txt

From: Brian Campbell <[email-masked]>
Date: Fri, 10 Jul 2020 13:36:20 -0600

WG,

A new -02 draft of "OAuth 2.0 Pushed Authorization Requests" has been
published. A summary of the changes, taken from the document history, is
included below for ease of reference.

   -02

   *  Update Resource Indicators reference to the somewhat recently
      published RFC 8707 <https://datatracker.ietf.org/doc/html/rfc8707>

   *  Added metadata in support of pushed authorization requests only
      feature

   *  Update to comply with draft-ietf-oauth-jwsreq-21
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-21>,
which requires
      "client_id" in the authorization request in addition to the
      "request_uri"

   *  Clarified timing of request validation

   *  Add some guidance/options on the request URI structure

   *  Add the key used in the request object example so that a reader
      could validate or recreate the request object signature

   *  Update to draft-ietf-oauth-jwsreq-25
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-25> and
added note regarding
      "require_signed_request_object"

---------- Forwarded message ---------
From: <[email-masked]>
Date: Fri, Jul 10, 2020 at 1:21 PM
Subject: New Version Notification for draft-ietf-oauth-par-02.txt
To: Filip Skokan <[email-masked]>, Torsten Lodderstedt <
[email-masked]>, Brian Campbell <[email-masked]>, Dave
Tonge <[email-masked]>, Nat Sakimura <[email-masked]>

A new version of I-D, draft-ietf-oauth-par-02.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:           draft-ietf-oauth-par
Revision:       02
Title:          OAuth 2.0 Pushed Authorization Requests
Document date:  2020-07-10
Group:          oauth
Pages:          18
URL:
https://www.ietf.org/internet-drafts/draft-ietf-oauth-par-02.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-oauth-par/
Htmlized:       https://tools.ietf.org/html/draft-ietf-oauth-par-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-oauth-par
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-par-02

Abstract:
   This document defines the pushed authorization request endpoint,
   which allows clients to push the payload of an OAuth 2.0
   authorization request to the authorization server via a direct
   request and provides them with a request URI that is used as
   reference to the data in a subsequent authorization request.

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.

The IETF Secretariat

-- 
_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: Vladimir Dzhuvinov <[email-masked]>
Date: Sun, 19 Jul 2020 20:54:49 +0200

Thanks for the update. With the "require PAR" AS and client metadata the
spec is now "policy complete". I can't think of what else there is to add.

I have two comments about -02:

https://tools.ietf.org/html/draft-ietf-oauth-par-02#section-2

I didn't see a mention of https / TLS being required for the PAR
endpoint. The reader could assume http is fine.

https://tools.ietf.org/html/draft-ietf-oauth-par-02#section-2.2

>    Since the request URI can be replayed, its lifetime SHOULD be short
>    and preferably limited to one-time use.
The SHOULD is ambiguous here - does it apply to the lifetime only, or to
the lifetime and the single use.

Vladimir

On 10/07/2020 21:36, Brian Campbell wrote:
> published. A summary of the changes, taken from the document history,
> is included below for ease of reference. 
>
>    -02
>
>    *  Update to comply with draft-ietf-oauth-jwsreq-21 <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-21>, which requires
>    *  Update to draft-ietf-oauth-jwsreq-25 <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-25> and added note regarding
> From: <[email-masked] <mailto:[email-masked]>>
> To: Filip Skokan <[email-masked] <mailto:[email-masked]>>,
> Torsten Lodderstedt <[email-masked]
> <mailto:[email-masked]>>, Brian Campbell
> <[email-masked] <mailto:[email-masked]>>, Dave
> Tonge <[email-masked] <mailto:[email-masked]>>, Nat Sakimura
> <[email-masked] <mailto:[email-masked]>>
>
>
>
> Htmlized:       https://tools..ietf.org/html/draft-ietf-oauth-par-02
> <https://tools.ietf.org/html/draft-ietf-oauth-par-02>
> until the htmlized version and diff are available at tools.ietf.org
> <http://tools.ietf.org>.
>
> The IETF Secretariat
>
>
>
> /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./
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Vladimir Dzhuvinov

---

From: Brian Campbell <[email-masked]>
Date: Wed, 22 Jul 2020 16:13:35 -0600

Thanks Vladimir, both comments should be easy to address in -03 (HTTPS/TLS
required and SHOULD on short lifetime *and* single use).

On Sun, Jul 19, 2020 at 12:55 PM Vladimir Dzhuvinov <[email-masked]>
wrote:

> I didn't see a mention of https / TLS being required for the PAR endpoint.
> The reader could assume http is fine.
>
>
> [email-masked]>, Brian Campbell <[email-masked]>,
> Dave Tonge <[email-masked]>, Nat Sakimura <[email-masked]>
>
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> 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.*
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
> --
> Vladimir Dzhuvinov
>

---

From: Neil Madden <[email-masked]>
Date: Thu, 23 Jul 2020 08:53:50 +0100

Can you expand on the risks of replay? It seems like if the request can be replayed an attacker can also block the original request and inject the URI into a different request - ie no replay. 

(Shouldn’t state and/or PKCE and/or nonce prevent replay already?)

In general the draft could do with some discussion of why an attacker being able to modify an authorization request is a risk. I might just be lacking enough coffee this morning to understand the risk here. 

— Neil

> On 22 Jul 2020, at 23:14, Brian Campbell <bcampbell=[email-masked]> wrote:
> 
> 
> Thanks Vladimir, both comments should be easy to address in -03 (HTTPS/TLS required and SHOULD on short lifetime *and* single use). 
> 
>> On Sun, Jul 19, 2020 at 12:55 PM Vladimir Dzhuvinov <[email-masked]> wrote:
>> Thanks for the update. With the "require PAR" AS and client metadata the spec is now "policy complete". I can't think of what else there is to add.
>> 
>> 
>> 
>> I didn't see a mention of https / TLS being required for the PAR endpoint. The reader could assume http is fine.
>> 
>> 
>> 
>> The SHOULD is ambiguous here - does it apply to the lifetime only, or to the lifetime and the single use.
>> 
>> 
>> Vladimir
>> 
>> 
>> 
>>> A new -02 draft of "OAuth 2.0 Pushed Authorization Requests" has been published. A summary of the changes, taken from the document history, is included below for ease of reference.  
>>> 
>>>    -02
>>> 
>>>       published RFC 8707
>>>    *  Update to comply with draft-ietf-oauth-jwsreq-21, which requires
>>>    *  Update to draft-ietf-oauth-jwsreq-25 and added note regarding
>>> To: Filip Skokan <[email-masked]>, Torsten Lodderstedt <[email-masked]>, Brian Campbell <[email-masked]>, Dave Tonge <[email-masked]>, Nat Sakimura <[email-masked]>
>>> 
>>> 
>>> 
>>> URL:            https://www.ietf.org/internet-drafts/draft-ietf-oauth-par-02.txt
>>> 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. 
>>> 
> 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._______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Brian Campbell <[email-masked]>
Date: Fri, 24 Jul 2020 15:13:41 -0600

Hi Neil,

Torsten added this issue
https://github.com/oauthstuff/draft-oauth-par/issues/53 from your
questions/comments, which touches on some things, and maybe he can provide
more thoughts. But I'll make an attempt here too.

In my mind, the one-time use suggestion on the request_uri came about less
from the risks of replay and more from the fact that the contents of a
particular auth request are unique to the one request. So it just kinda
made sense to similarly limit the reference to the data in a request. A
specific request can only be made once so it's suggested (though not
required) that a request_uri that represents that request also be usable
only once.

I believe state and/or PKCE and/or nonce can prevent replay already but
those take effect at different points in the whole dance and to catch
replay of different artifacts.

Agreed that it'd be good for the draft to have some more discussion about
the risks of modification and disclosure of the request content. Torsten
also agreed yesterday at a brief discussion during OSW so I'm hopeful he
can add some good content to the draft :) Thinking about richer
authorization requests that might have transaction data like payee account
numbers or amounts or similar etc. gives some idea of requests where
integrity and confidentiality would be good. And even more basic requests,
preventing control or modification of something like code_challenge seems
useful.

On Thu, Jul 23, 2020 at 1:53 AM Neil Madden <[email-masked]>
wrote:

> Can you expand on the risks of replay? It seems like if the request can be
> replayed an attacker can also block the original request and inject the URI
> into a different request - ie no replay.
>
> In general the draft could do with some discussion of why an attacker
> being able to modify an authorization request is a risk. I might just be
> lacking enough coffee this morning to understand the risk here.
>
> — Neil
>
> On 22 Jul 2020, at 23:14, Brian Campbell <bcampbell=
> [email-masked]> wrote:
>
> 
>> <https://tools.ietf...org/html/draft-ietf-oauth-par-02>
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-par
>> <https://datatracker..ietf.org/doc/html/draft-ietf-oauth-par>
>>    which allows clients to push the payload of an OAuth 2..0
>> until the htmlized version and diff are available at tools.ietf.org..
>>
>> The IETF Secretariat
>>
>>
>>
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Neil Madden <[email-masked]>
Date: Sun, 26 Jul 2020 14:36:24 +0100

Thanks Brian,

That sounds reasonable.

My main concern is that we don’t mislead people into the security properties provided by PAR. I’ve seen multiple cases where people assume that e.g. because they sent an OIDC request with a particular acr_values and got back a successful response that the user must have been successfully authenticated in the intended way. There are multiple ways that assumption can be violated; tampering with the request being just one of them. In those kinds of cases, the best thing is to strictly validate the response you get back (e.g., the “acr” claim in the ID token in this example), which you’d generally still want to do even with PAR.

Obviously PAR can catch some of these things much earlier in the flow, which is great, but I just wanted to be clear whether the PAR draft is saying that there are either (a) some attacks that PAR catches that otherwise aren’t mitigated, or (b) there are specific attacks against PAR (e.g., replay) that don’t apply to existing flows, or (c) some checks you can skip if you use PAR.

Cheers,

— Neil

> On 24 Jul 2020, at 22:13, Brian Campbell <[email-masked]> wrote:
> 
> Hi Neil, 
> 
> Torsten added this issue https://github.com/oauthstuff/draft-oauth-par/issues/53 <https://github.com/oauthstuff/draft-oauth-par/issues/53> from your questions/comments, which touches on some things, and maybe he can provide more thoughts. But I'll make an attempt here too. 
> 
> In my mind, the one-time use suggestion on the request_uri came about less from the risks of replay and more from the fact that the contents of a particular auth request are unique to the one request. So it just kinda made sense to similarly limit the reference to the data in a request. A specific request can only be made once so it's suggested (though not required) that a request_uri that represents that request also be usable only once. 
> 
> I believe state and/or PKCE and/or nonce can prevent replay already but those take effect at different points in the whole dance and to catch replay of different artifacts. 
> 
> Agreed that it'd be good for the draft to have some more discussion about the risks of modification and disclosure of the request content. Torsten also agreed yesterday at a brief discussion during OSW so I'm hopeful he can add some good content to the draft :) Thinking about richer authorization requests that might have transaction data like payee account numbers or amounts or similar etc. gives some idea of requests where integrity and confidentiality would be good. And even more basic requests, preventing control or modification of something like code_challenge seems useful. 
> 
> 
> 
> 
> 
> On Thu, Jul 23, 2020 at 1:53 AM Neil Madden <[email-masked] <mailto:[email-masked]>> wrote:
>> On 22 Jul 2020, at 23:14, Brian Campbell <bcampbell=[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> On Sun, Jul 19, 2020 at 12:55 PM Vladimir Dzhuvinov <[email-masked] <mailto:[email-masked]>> wrote:
>> https://tools.ietf.org/html/draft-ietf-oauth-par-02#section-2 <https://tools.ietf.org/html/draft-ietf-oauth-par-02#section-2>
>> https://tools.ietf.org/html/draft-ietf-oauth-par-02#section-2.2 <https://tools.ietf.org/html/draft-ietf-oauth-par-02#section-2.2>
>> 
>>> To: Filip Skokan <[email-masked] <mailto:[email-masked]>>, Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>>, Brian Campbell <[email-masked] <mailto:[email-masked]>>, Dave Tonge <[email-masked] <mailto:[email-masked]>>, Nat Sakimura <[email-masked] <mailto:[email-masked]>>
>>> 
>>> 
>>> 
>>> URL:            https://www.ietf.org/internet-drafts/draft-ietf-oauth-par-02.txt <https://www.ietf.org/internet-drafts/draft-ietf-oauth-par-02.txt>
>>> Status:         https://datatracker.ietf.org/doc/draft-ietf-oauth-par/ <https://datatracker.ietf.org/doc/draft-ietf-oauth-par/>
>>> Htmlized:       https://tools..ietf.org/html/draft-ietf-oauth-par-02 <https://tools.ietf...org/html/draft-ietf-oauth-par-02>
>>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-oauth-par <https://datatracker..ietf.org/doc/html/draft-ietf-oauth-par>
>>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-par-02 <https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-par-02>
>>> 
>>> Abstract:
>>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>..
>>> 
>>> The IETF Secretariat
>>> 
>>> 
>>> 
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> -- 
>> Vladimir Dzhuvinov
>> [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>
> 
> 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.