[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 []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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 []) 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 with SMTP id kb8mr15223919igb.60.1381800750133; Mon, 14 Oct 2013 18:32:30 -0700 (PDT)
Received: by with HTTP; Mon, 14 Oct 2013 18:32:29 -0700 (PDT)
X-Originating-IP: []
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>
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
*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
   - OAuth 2.0 Assurance

   - Mitigating OAuth Security Issues with Good

   - OAuth 2.0 and RESTful Protocol Security Testing
   - 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