Hi Brian! Thanks for the clarifications below and the -08. I’ve pushed the document to IETF Last Call.
Regards, Roman From: Brian Campbell <bcampb...@pingidentity.com> Sent: Friday, May 14, 2021 6:05 PM To: Roman Danyliw <r...@cert.org> Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] AD Review of draft-ietf-oauth-par-07 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 <bcampb...@pingidentity.com<mailto:bcampb...@pingidentity.com>> 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 <r...@cert.org<mailto:r...@cert.org>> 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 OAuth@ietf.org<mailto: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
