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-----