Telechat Review of draft-ietf-oauth-assertions-10
review-ietf-oauth-assertions-10-secdir-telechat-emery-2013-02-07-00
| Request | Review of | draft-ietf-oauth-assertions |
|---|---|---|
| Requested revision | No specific revision (document currently at 18) | |
| Type | Telechat Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2013-02-05 | |
| Requested | 2013-01-25 | |
| Authors | Brian Campbell , Chuck Mortimore , Michael B. Jones , Yaron Y. Goland | |
| I-D last updated | 2018-12-20 (Latest revision 2014-10-21) | |
| Completed reviews |
Genart IETF Last Call review of -08
by Vijay K. Gurbani
(diff)
Genart Telechat review of -09 by Vijay K. Gurbani (diff) Genart Telechat review of -10 by Vijay K. Gurbani (diff) Secdir IETF Last Call review of -08 by Shawn M Emery (diff) Secdir Telechat review of -10 by Shawn M Emery (diff) Opsdir IETF Last Call review of -17 by Mehmet Ersue (diff) |
|
| Assignment | Reviewer | Shawn M Emery |
| State | Completed | |
| Request | Telechat review on draft-ietf-oauth-assertions by Security Area Directorate Assigned | |
| Reviewed revision | 10 (document currently at 18) | |
| Result | Ready | |
| Completed | 2013-02-07 |
review-ietf-oauth-assertions-10-secdir-telechat-emery-2013-02-07-00
A new version of this draft has been made, 10, which implicitly
addresses the concerns that I had brought up during the secdir
review.
Shawn.
--
On 12/30/12 12:07 AM, Shawn Emery wrote:
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 internet-draft describes an assertion framework for the OAuth 2.0 protocol. Given that
that this is a framework, subsequent drafts would be needed for a deployed mechanism.
The security considerations section does exist and outlines various issues including
impersonation, replay, and privacy. The section then suggests ways of mitigating these
threats. This seems sufficient, but can there be more guidance on the Assertion ID to
avoid collision or replay (e.g. length, roll-over, etc.)?
General comments:
None.
Editorial comments:
Redundant wordings, suggested fix:
Old:
An IEFT URN for use as the "XXXX" value can be requested using
the template in An IETF URN Sub-Namespace for OAuth [
RFC6755
].
New:
An IEFT URN for use as the "XXXX" value can be requested using
the template in [
RFC6755
].
Shouldn't urn:ietf:params:oauth:grant_type:* be
urn:ietf:params:oauth:grant-type:*?
s/included yet all/included, yet all/
Shawn.
--
_______________________________________________
secdir mailing list
secdir at ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wiki:
http://tools.ietf.org/area/sec/trac/wiki/SecDirReview