Re: [OAUTH-WG] AD Review of draft-ietf-oauth-par-07

[Brian Campbell <[e-mail]>]

I went ahead and pushed an -08 that hopefully addresses all your feedback
and suggestions.

https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-par-08

https://datatracker.ietf.org/doc/draft-ietf-oauth-par/





On Fri, May 14, 2021 at 2:55 PM Brian Campbell <[e-mail]>
wrote:

> Thanks for the review Roman! Responses from me are inline below. And I'll
> endeavor to get a new draft published soon that addresses your feedback.
>
>
> On Fri, May 14, 2021 at 1:17 PM Roman Danyliw <[e-mail]> wrote:
>
>> Hi!
>>
>> I performed my AD review of draft-ietf-oauth-par-07.  Thanks for the
>> effort to produce this document.  See my feedback below:
>>
>> ** Section 1.1.  Per the first POST example, please provide a bit more
>> text to explain the presence of the Authorization header.
>>
>
> Makes sense and will do.
>
>
>
>>
>> ** Section 2.1.  Per step #1, "Authenticate the client in the same way as
>> at the token endpoint." Would it be appropriate to cite Section 2.3.1 of
>> RFC6749 as the reference for "the same way"?
>>
>
> I think a reference here would be good but Section 2.3 of RFC6749 is
> probably more appropriate as any of the defined/supported client
> authentication methods (e.g., RFC8705 or RFC7523) could be used. It's not
> limited to client password/secret, which is what Section 2.3.1 of RFC6749
> is about.
>
>
>
>>
>> ** Section 2.1. Typo.  s/the the/the/
>>
>
> Doh! Will fix.
>
>
>
>>
>> ** Section 2.2.  "The format of the "request_uri" value is at the
>> discretion of the authorization server ...", it would be helpful to remind
>> implementers (via reference) that the constraints of Section 10.10 of
>> RFC6749 apply.
>>
>>    The authorization server MUST prevent attackers from guessing access
>>    tokens, authorization codes, refresh tokens, resource owner
>>    passwords, and client credentials.
>>
>>    The probability of an attacker guessing generated tokens (and other
>>    credentials not intended for handling by end-users) MUST be less than
>>    or equal to 2^(-128) and SHOULD be less than or equal to 2^(-160).
>>
>
> I'll add that reference around the current text saying it has to be
> "computationally infeasible to predict or guess a valid value".
>
>
>
>> ** Section 2.2.  "The string representation of a UUID as a URN per
>> [RFC4122] is also an option for authorization servers to construct
>> "request_uri" values" suggests that a UUID could be used as the
>> "cryptographically strong pseudorandom algorithm such that it is
>> computationally infeasible to predict or guess a valid value" for the
>> random part of the request_uri.  However, a few bits of the 128-bit UUID
>> are in fact not random.  Hence, this UUID construct would seem to violate
>> the guidance of Section 10.10 of RFC6749 noted above.  Likewise, the
>> Section 10.2 of draft-ietf-oauth-jwsreq-34 referenced in Security
>> Considerations also suggest 128-bits.
>>
>
> Good catch, if not a touch pedantic :)  Honestly, my thinking was that
> creating UUIDs is made pretty easy in a lot of environments and that the
> not-quite-128-bits from a UUID was probably good enough for the purpose.
> But you are right and, under a strict reading, this amounts to the PAR
> draft suggesting something that is in violation of a normative MUST in
> RFC6749. I think the best path forward is that the sentence that suggests
> UUIDs should just be removed.
>
>
>
>> ** Section 2.4.  This section relaxes exact matching of the redirect_uri
>> specified in the current text of the security BCP and OAuth 2.1.  Not
>> relevant to this document, but would it make sense to acknowledge this
>> relaxation in the BCP or caveat language about strict requirements in the
>> v2.1 draft?
>>
>
> Yeah, it might make sense to do so perhaps along with some rationale or
> explanation about the conditions that make relaxation acceptable.
>
>
>
>> ** Section 6.  Typo. s/reqired/required/
>>
>
> Ugh. Will fix. And thanks.
>
>
>
>> ** Section 7.5.  Per "Clients SHOULD make use of PKCE, a unique "state"
>> parameter, or the OIDC "nonce" parameter" are good advice.  Can the text
>> provide references to each of these.
>>
>
> Yup, I can add references for those.
>
>
>
>> ** Section 8.  Wouldn't some of the privacy considerations of
>> draft-ietf-oauth-jwsreq-34/Section 11 apply?
>>
>
> I read through that section again and honestly don't see anything that is
> applicable or isn't already constrained or made irrelevant by the specifics
> of the PAR draft. Please let me know if you think I'm overlooking something
> though.
>
>
> Thanks,
>> Roman
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> 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._