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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf