After spending some time over the last few months looking into OAuth assurance issues, I decided that I'll propose a panel on the topic next week at IIW. My initial take on the proposed session is described in the blog post at this link<http://security-architect.blogspot.com/2013/10/proposed-oauth-assurance-session-at-iiw.html> and is summarized below as well. As I've written in several related articles, OAuth 2.0 has some significant assurance issues. And while the community did an excellent job documenting these issues in RFC 6819 on security considerations, to my knowledge there hasn't been much discussion on how the assurance of an implementation should be tested or on how customers or relying parties are supposed to know whether a given implementation has been implemented in a robust manner.
With all the work on OAuth 2.0 interoperability testing, I sense an opportunity to inject some assurance testing into the process. Not full penetration testing or vulnerability testing by any, but perhaps some basic robustness testing. I would be interested in how we could define that and whether interest is there in creating more intensive assurance tests separately from basic interoperability ones. *Title: *OAuth 2.0 Assurance * * *Outline* * * *Problem statement: *Provide an introduction to OAuth assurance based on my blogs and RFC 6819 *General recommendations: *Also part of intro presentation, explain that its necessary to address issues through profiling, testing and secure implementation and operations *Scope: *Focus on the basic OAuth 2.0 specification, not getting into unresolved issues related to the many proposed extensions, such as token contents, or semantics *Discussion topic 1: *What would be a reasonable framework for OAuth 2.0 assurance levels, and how might those map to NIST Levels of Assurance (LOAs) 1 or 2? *Discussion topic 2:* What are "10 commandments" for Secure OAuth 2.0 (or "10 deadly sins to avoid") and how would we test for them? *Discussion topic 3:* Future plans - how can we carry the output of this session forward? Is there a home somewhere for an OAuth 2.0 assurance standards group? Would some organization (or group) be willing to work on standing up a test server to look for the 10 deadly sins? Would some organization (or group) be willing to work developing secure, open source OAuth libraries validated to follow the 10 commandments? I already have a few folks interested in this panel and contributing ideas but would welcome a lot more. If you're attending IIW 17 and interested in contributing, please let me know via one of my communications channels such as @danblumSS or the comments thread on this post. *Related posts* - REST Uneasy: Do we Need to Worry about OAuth 2.0?<http://security-architect.blogspot.com/2013/06/rest-uneasy-do-we-need-to-worry-about.html> - OAuth 2.0 Assurance Issues<http://security-architect.blogspot.com/2013/07/oauth-20-assurance-issues.html> - Mitigating OAuth Security Issues with Good Profiling<http://security-architect.blogspot.com/2013/07/mitigating-oauth-20-security-issues.html> - OAuth 2.0 and RESTful Protocol Security Testing Challenges<http://security-architect.blogspot.com/2013/08/oauth-20-and-restful-protocol-security.html> - Piling on OAuth<http://security-architect.blogspot.com/2013/09/piling-on-oauth.html> *Information on Internet Identity Workshop (IIW) * - http://iiw.idcommons.net/Main_Page - http://iiw.idcommons.net/images/1/13/IIW16_Book_of_Proceedings.PDF Best regards, Dan Blum Respect Network Principal Consultant and Chief Architect http://security-architect.blogspot.com
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
