Dear Sir/Madam: Attached below, please find the comment in response to the Last Call: <draft-ietf-oauth-v2-23.txt> (The OAuth 2.0 Authorization Protocol) to Proposed Standard. These comments are on the changes between rev.22 and rev.23. Yours faithfully, Nat Sakimura =============================== Comment on Section 10.10 =============================== Title: "constructed from" vague ================================ Comment -------- The current text goes as: The authorization server MUST prevent attackers from guessing access tokens, authorization codes, refresh tokens, resource owner passwords, and client credentials. Generated tokens and other credentials not intended for handling by end-users MUST be constructed from a cryptographically strong random or pseudo-random number sequence ([RFC4086]) generated by the authorization server. (Note: 1750 was modifed to be 4086) It is unclear from this sentence if it only allows the sequence that is compliant to Section 6.2 of RFC4086. It is also unclear whether it could be a string that included such random string during the generation, or has to be the prn sequence. I believe the former is the case. Clarification is desired. Title: Only allowing the construction from PRN sequence too limiting ==================================================================== Comment ------- An alternative measure would be to use digital signatures. The current text seem to only allow PRN sequence. Other measures should be allowed as well. Title: Probability requirement needs refinement ================================================ Comment -------- The current text goes: The probability of any two values being identical MUST be less than or equal to 2^(-128) and SHOULD be less than or equal to 2^(-160). This seems to be simply stating the randomness requirement. What we would like to do to control the credentials guessing attacks depends on the kind of token in question. Title: Last para 10.10 is normative yet undefined =================================================== Comment -------- It goes: The authorization server MUST utilize other means to protect credentials intended for end-user usage. Since it has a "MUST", it is a normative language. Yet it only requires "other means", which is undefined. It also excludes the possibility of using server generated PRN sequece as the user password. ======== Proposal ======== 10.10. Credentials Guessing Attacks The authorization server MUST prevent attackers from guessing access tokens, authorization codes, refresh tokens, resource owner passwords, and client credentials. The appropriate probability of the success of the attack during the lifetime of the tokens and credentials depends on the risk profile of the application in question. The application SHOULD set the policy requiring the probability of the success of the attack during the lifetime of each type of tokens and credentials and implementations MUST adhere to such policy. For the generated tokens and other credentials that are not intended for handling by end-users, one way to achieve it is to construct them including a cryptographically strong random or pseudo-random number sequence described in Section 6.2 of [RFC4086] generated by the authorization server. Typically, the probability of any two values being identical is set to be less than or equal to 2^(-128) and often considered desirable to be less than or equal to 2^(-160). Other possible control measures includes: - Progressive slow down and token revocation on the failed attempts - Pattern analysis of failed token and credential usage For the credentials intended for end-user usages, typical controls includes: - Progressive slow down and other mechanisms such as captcha on the failed attempts to thwart brute force - Pattern analysis of failed token and credential usage - Enforce the use of strong passwords (e.g., complex, non-dictionary strings that contain mixtures of upper case, lower case, numeric, and special characters) - Enforce the use of Multi-Factor authentication and other strong authentication mechanisms END _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf