[OAUTH-WG] Security Requirement -- was Re: Reminder: OAuth WG Conference Call, 21st January 2013, 1pm EST

Hannes Tschofenig <hannes.tschofenig@gmx.net> Mon, 28 January 2013 12:53 UTC

Return-Path: <hannes.tschofenig@gmx.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 5377921F9224 for <oauth@ietfa.amsl.com>; Mon, 28 Jan 2013 04:53:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.626
X-Spam-Status: No, score=-100.626 tagged_above=-999 required=5 tests=[AWL=-0.477, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id L3glDq3wLjV7 for <oauth@ietfa.amsl.com>; Mon, 28 Jan 2013 04:53:43 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net []) by ietfa.amsl.com (Postfix) with ESMTP id CC22721F9222 for <oauth@ietf.org>; Mon, 28 Jan 2013 04:53:42 -0800 (PST)
Received: from mailout-de.gmx.net ([]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Ljwk3-1Ubd0e3CUj-00bvy1 for <oauth@ietf.org>; Mon, 28 Jan 2013 13:53:41 +0100
Received: (qmail invoked by alias); 28 Jan 2013 12:53:41 -0000
Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO []) [] by mail.gmx.net (mp019) with SMTP; 28 Jan 2013 13:53:41 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19iUmoReC5iOob6NdIT0o4UMHtZVAOoBgIBvY23kJ 5R1LMVNAn3JsHq
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset="GB2312"
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
In-Reply-To: <OF04977A3C.3107D452-ON48257AF7.0032865D-48257AF7.003394FF@zte.com.cn>
Date: Mon, 28 Jan 2013 14:53:38 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2EF51CC5-C203-4B71-A318-E94890021324@gmx.net>
References: <OF04977A3C.3107D452-ON48257AF7.0032865D-48257AF7.003394FF@zte.com.cn>
To: zhou.sujing@zte.com.cn
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Cc: "oauth@ietf.org WG" <oauth@ietf.org>, oauth-bounces@ietf.org
Subject: [OAUTH-WG] Security Requirement -- was Re: Reminder: OAuth WG Conference Call, 21st January 2013, 1pm EST
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: Mon, 28 Jan 2013 12:53:44 -0000

Hi Zhou, 

sorry I missed your mail because of the subject header. 

On Jan 18, 2013, at 11:22 AM, zhou.sujing@zte.com.cn wrote:

> I have some questions concerning the oauth-security document. 
> 1. collusion 
>     Only collusion between resource servers are considered, 
>  however, collusion between resource server and client could happen. 

Correct. I should add this. 

> 2. AS-to-RS relationship anonymity 
>    if "the Client must not provide information about the Resource Server in the access token request."   
>   then how AS can encrypt access token using the key shared between AS and RS? 
>   I feel this requirement is unclear and conflict with some security measures that might be taken in OAuth 2.0. 

It is certainly true that there is a conflict between security and privacy here. For this reason I was hoping for feedback on how important this requirement is.
There is a trade-off decision that has to be made here. From your point of view, how do you see the importance of the added security vs. the improved anonymity?

Here is the current text:

      The Authorization Server can be
      prevented from knowing which Resource Servers a Resource Owner
      interacts with.  This requires avoiding direct communication
      between the Authorization Server and the Resource Server at the
      time when access to a protected resource by the Client is made.
      Additionally, the Client must not provide information about the
      Resource Server in the access token request.  [QUESTION: Is this a
      desirable property given that it has other implications for

> 3. Compromise of client, RS have been considered (separately) 
>    But the result of their compromise may not be limited to "client accessing more resources ", 
> it could be compromised client/RS  redirect RO to a manipulated AS phishing RO's credential, for example. 
Could you expand your thoughts a bit? Here is the current text:

   Prevent the Domino Effect:

      Compromise of a single Client MUST NOT
      compromise keying material held by any other Client within the
      system, including session keys and long-term keys.  Likewise,
      compromise of a single Resource Server MUST NOT compromise keying
      material held by any other Resource Server within the system.  In
      the context of a key hierarchy, this means that the compromise of
      one node in the key hierarchy must not disclose the information
      necessary to compromise other branches in the key hierarchy.
      Obviously, the compromise of the root of the key hierarchy will
      compromise all of the keys; however, a compromise in one branch
      MUST NOT result in the compromise of other branches.  There are
      many implications of this requirement; however, two implications
      deserve highlighting.  First, the scope of the keying material
      must be defined and understood by all parties that communicate
      with a party that holds that keying material.  Second, a party
      that holds keying material in a key hierarchy must not share that
      keying material with parties that are associated with other
      branches in the key hierarchy.


> oauth-bounces@ietf.org 写于 2013-01-17 21:43:26:
> > Hi all, 
> > 
> > We will have our next OAuth conference call on the 21st January 
> > 2013, 1pm EST (for roughly one hour).
> > 
> > John & Nat kindly offered their conference bridge. It is the same 
> > bridge we used before.
> > https://www3.gotomeeting.com/join/695548174
> > 
> > We will continue where we stopped last time, namely we stopped our 
> > discussions at the crypto agility requirement 
> > (first requirement in http://tools.ietf.org/html/draft-tschofenig-
> > oauth-security-01#section-5).  
> > 
> > Here is the slide set I used last time:
> > http://www.tschofenig.priv.at/OAuth2-Security-11Jan2013.ppt
> > (We stopped at slide #2.)
> > 
> > We also did not manage to get to discuss the use case Justin raised 
> > at the first conference call. He distributed a writeup on the list:
> > http://www.ietf.org/mail-archive/web/oauth/current/msg10407.html
> > 
> > Ciao
> > Hannes & Derek
> > 
> > PS: I will try to distribute my meeting minute notes from the 
> > previous call by tomorrow. 
> > 
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth