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

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 <neil.madden@forgerock.com>
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.
>
> (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=
> 40pingidentity.com@dmarc.ietf.org> 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 <
> vladimir@connect2id.com> 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 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:
>>
>> 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: <internet-drafts@ietf.org>
>> Date: Fri, Jul 10, 2020 at 1:21 PM
>> Subject: New Version Notification for draft-ietf-oauth-par-02.txt
>> To: Filip Skokan <panva.ip@gmail.com>, Torsten Lodderstedt <
>> torsten@lodderstedt.net>, Brian Campbell <bcampbell@pingidentity.com>,
>> Dave Tonge <dave@tonge.org>, Nat Sakimura <nat@sakimura.org>
>>
>>
>>
>> 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
>> <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
>>
>> 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.*
>>
>> _______________________________________________
>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>
>> --
>> Vladimir Dzhuvinov
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> 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.*_______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> 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._