Skip to main content

Last Call Review of draft-ietf-oauth-v2-
review-ietf-oauth-v2-secdir-lc-johansson-2012-03-01-00

Request Review of draft-ietf-oauth-v2
Requested revision No specific revision (document currently at 31)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-02-07
Requested 2012-01-27
Authors Dick Hardt
I-D last updated 2012-03-01
Completed reviews Secdir Early review of -?? by Leif Johansson
Secdir Last Call review of -?? by Leif Johansson
Tsvdir Last Call review of -?? by Haibin Song
Assignment Reviewer Leif Johansson
State Completed
Request Last Call review on draft-ietf-oauth-v2 by Security Area Directorate Assigned
Completed 2012-03-01
review-ietf-oauth-v2-secdir-lc-johansson-2012-03-01-00
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This is a "re-visit" of a review I did of -22 of this specification
and so I'm only focusing on significant differences:

- - Overall -23 adds clarifications throughout the text and -23 is
the better for it. Breaking out TLS requirements to a separate
section makes the text more readable too.

- - The new section on interoperability talks about future work and
profiling but doesn't constrain future profiles in any way. To me
this only punts on the issue of interoperability. I understand this
is a hard problem. I suggest at least adding a list of parameters
and other elements subject to profiling and if possible list any
constraints on such profiles.

- - Several of the comments I made in my earlier review have been
addressed, specifically those dealing with consistent use of terms
and normative language.

- - I like the text in 10.10 giving advice on generating tokens and
credentials. However the text gives specific entropy constraints
but doesn't talk about using rate-limiting as protection against
online guessing attacks. A good source for this is NIST SP 800-63
Appendix A. Also I'm not sure entropy constraints are appropriate
for a protocol specification but barring the introduction of
identity assurance for OAuth I don't have a better idea. I suggest
noting that these constraints are subject to revision with state of
the art in online guessing so implementors don't get too married
to these particular numbers.

	Best
	Leif Johansson

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - 

http://enigmail.mozdev.org/



iEYEARECAAYFAk9KmX4ACgkQ8Jx8FtbMZncBzwCfV0NOmp+I+PQI1n6vdvtZM8/X
HSQAoL2wz8DOCAbMCXwHa4zwUjsMBZon
=Jx3y
-----END PGP SIGNATURE-----