[OAUTH-WG] Proposed OAuth 2.0 Assurance Panel at IIW next week
Dan Blum <dan@respectnetwork.net> Tue, 15 October 2013 01:32 UTC
Return-Path: <dan@respectnetwork.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0DF11E8170 for <oauth@ietfa.amsl.com>; Mon, 14 Oct 2013 18:32:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G01D2SjL2SO9 for <oauth@ietfa.amsl.com>; Mon, 14 Oct 2013 18:32:33 -0700 (PDT)
Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by ietfa.amsl.com (Postfix) with ESMTP id E7AB511E8131 for <oauth@ietf.org>; Mon, 14 Oct 2013 18:32:30 -0700 (PDT)
Received: by mail-ie0-f171.google.com with SMTP id tp5so6228ieb.30 for <oauth@ietf.org>; Mon, 14 Oct 2013 18:32:30 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=5VGEuav8Z0ZfSjJ2cRkllSmNO/glIhWwePo+1CuPofA=; b=Sw6gt2KnabxVJOGM/VLQ9Ud94cUuPFqcMXMaDwL70wFvnkkKQsSOX+INVqK2Z6qAJE HPGBxyG3blp2OzoJBNNwEItF8u076SpPANuyyBxYL1OwYxHWn+O8mOpgnG1Lp2/erXt/ ibRcXVj+LSTOP6bQr4k1Nev58QyX4H5WQ5r85xxoOEm+V0Misy1uSB6DUYr0b0EXAh4c 8mb0zwdIfuZ6h9oRhkxtYg6O7CWENHWLsXKcvQJDGqZei0vsKE+7kerJFMm1cSTz+TUD +VRpvnNDwNoYNP9YzssLqYEIuh7dEgidZMQKrDpPBdP4OSRQQ00vV7ZiDckquspD+nEY qFWw==
X-Gm-Message-State: ALoCoQlh+RLoUuZscHxoNhA89XH7G+uAWpYg/2jdihRotXh1BbgusVUKOGTihwv6dCUNq5uo/pT0
MIME-Version: 1.0
X-Received: by 10.50.117.40 with SMTP id kb8mr15223919igb.60.1381800750133; Mon, 14 Oct 2013 18:32:30 -0700 (PDT)
Received: by 10.64.226.131 with HTTP; Mon, 14 Oct 2013 18:32:29 -0700 (PDT)
X-Originating-IP: [108.45.69.60]
Date: Mon, 14 Oct 2013 21:32:29 -0400
Message-ID: <CACd9m-FTTiscTF9HTyVvTDAwTkL3yW=5v-iLbt=0PU05YHrEPw@mail.gmail.com>
From: Dan Blum <dan@respectnetwork.net>
To: oauth list <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="089e0115f49adcc80604e8bd8e60"
Subject: [OAUTH-WG] Proposed OAuth 2.0 Assurance Panel at IIW next week
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Oct 2013 01:32:38 -0000
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