[OAUTH-WG] Fwd: Comments on Section 10.10 of OAuth 2.0

[Nat Sakimura <[e-mail]>]

Forgot to cc the oauth list on this, so here it goes!

=nat

---------- Forwarded message ----------
From: Nat Sakimura <[e-mail]>
Date: Tue, Feb 7, 2012 at 12:46 PM
Subject: Comments on Section 10.10 of OAuth 2.0
To: [e-mail]


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



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en