From: Eran Hammer <eran@hueniverse.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Date: Sat, 17 Mar 2012 09:25:23 -0700
Thread-Topic: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The
 OAuth 2.0	Authorization Protocol: Bearer Tokens) to Proposed Standard
Thread-Index: Acz9Rmgmn7QNqLoOT1OzbE+KGkQxzgHFBRcA
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFF08C1D@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <20120123154643.16223.44509.idtracker@ietfa.amsl.com>
 <4F1D8391.3080009@gmx.de> <4F1F3D84.1030300@gmx.de>
 <90C41DD21FB7C64BB94121FBBC2E723453AAB9682E@P3PW5EX1MB01.EX1.SECURESERVER.NET>
 <7D4DB9C9-7194-42A0-A573-4243FE27E512@ve7jtb.com>
 <90C41DD21FB7C64BB94121FBBC2E723453AFCD4072@P3PW5EX1MB01.EX1.SECURESERVER.NET>
 <A7D328CF-C7E5-4A78-A60C-BE34FC65B2BD@ve7jtb.com>
In-Reply-To: <A7D328CF-C7E5-4A78-A60C-BE34FC65B2BD@ve7jtb.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Julian Reschke <julian.reschke@gmx.de>, "oauth@ietf.org" <oauth@ietf.org>,
 "ietf@ietf.org" <ietf@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The
 OAuth 2.0	Authorization Protocol: Bearer Tokens) to Proposed Standard
Precedence: list

I am treating this issue as closed, unless someone wants to proposed langua=
ge changes based on John's analysis below.

EH

> -----Original Message-----
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> Sent: Thursday, March 08, 2012 8:13 AM
> To: Eran Hammer
> Cc: Julian Reschke; ietf@ietf.org; The IESG; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (T=
he
> OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard
>=20
> Thanks that is better.
>=20
> Without knowing the lifetime of the token these are per guess probabiliti=
es.
> Effectively 128bits for a random value and 256bits for a HMAC or other
> signature.
>=20
> For tokens intended for handling by end-users it may be useful to give so=
me
> advice.
> In general you don't want an attacker having more than a one in 2^14 chan=
ce
> of guessing a valid code for a AS during the lifetime of the code(NIST Lo=
A 2).
>=20
> For a code randomly generated from a 94 character code set 4 characters
> gets you 26.3 bits of entropy.
> 5 characters requires limiting an attacker to 2^12.3 (5,042) guesses per =
token
> lifetime.
>=20
> For a code randomly generated from a 94 character code set 5 characters
> gets you 32.9 bits of entropy.
> 5 characters requires limiting an attacker to 2^18.9 (489,178) guesses pe=
r
> token lifetime.
>=20
> If the token is single use and the client uses it right away that is easy=
,
> however in a worst case scenario the token might live 10min?
> That would be 8.4 attempts per second as a max for a 4 character code or =
815
> per second for 5 characters.
>=20
> That is all way too much to explain however I would recommend as a genera=
l
> rule:
>=20
> Credentials intended for handling by end users SHOULD be a minimum of 5
> randomly generated charters from a set of 94 or otherwise contain a
> minimum entropy of 2^32.9.
>=20
> That is probably high enough that the AS will notice an attack,  lower en=
tropy
> may pass under the radar.
> Also the chances of an attacker being successful go up proportionally to =
the
> number simultaneous codes in flight at any point (it becomes a non target=
ed
> attack).
>=20
> It isn't something that I will loose sleep over,  It gives me something e=
lse to
> profile:)
>=20
> Thanks
> John B.
>=20
> On 2012-03-07, at 8:18 PM, Eran Hammer wrote:
>=20
> > New text:
> >
> >          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).
> >
> > Removed reference to RFC 1750.
> >
> > EH
> >
> >> -----Original Message-----
> >> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> >> Sent: Monday, February 06, 2012 5:07 PM
> >> To: Eran Hammer
> >> Cc: Julian Reschke; ietf@ietf.org; The IESG; oauth@ietf.org
> >> Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt>
> (The
> >> OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard
> >>
> >> RE new text in Draft 23
> >>
> >> http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-10.10
> >>
> >> 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 ([RFC1750]) generated by the
> >>   authorization server.
> >>
> >> Given that many implementations may elect to use signed tokens, such a=
s
> >> SAML or JWT (JOSE) this should not be a MUST.
> >>
> >> Giving people sensible defaults such as the probability of an attacker
> >> guessing a valid access token for the protected resource should be les=
s
> than
> >> 2^(-128).
> >>
> >> The probability of generating hash colisions randomly is a odd metric,=
  2^(-
> >> 128) for a SHA256 as I recall.
> >> Many factors play into what is secure, token lifetime etc.
> >>
> >> I don't mind some reasonable defaults but adding a requirement for
> >> unstructured tokens is a bit much.
> >>
> >> Regards
> >> John B.
> >>
> >>
> >