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

[Neil Madden <[e-mail]>]

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 <[e-mail]> 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 <[e-mail] <mailto:[e-mail]>> 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=[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> 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 <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 <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: <[e-mail] <mailto:[e-mail]>>
>>> Date: Fri, Jul 10, 2020 at 1:21 PM
>>> Subject: New Version Notification for draft-ietf-oauth-par-02.txt
>>> To: Filip Skokan <[e-mail] <mailto:[e-mail]>>, Torsten Lodderstedt <[e-mail] <mailto:[e-mail]>>, Brian Campbell <[e-mail] <mailto:[e-mail]>>, Dave Tonge <[e-mail] <mailto:[e-mail]>>, Nat Sakimura <[e-mail] <mailto:[e-mail]>>
>>> 
>>> 
>>> 
>>> 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 <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:
>>>    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 <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
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> -- 
>> Vladimir Dzhuvinov
>> _______________________________________________
>> OAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> 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._______________________________________________
>> OAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> 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.