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

[Hannes Tschofenig <[e-mail]>]

Hi Zhou, 

sorry I missed your mail because of the subject header. 

On Jan 18, 2013, at 11:22 AM, [e-mail] 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
      security?]


> 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.

Ciao
Hannes

> 
>     
> 
> 
> 
> [e-mail] 写于 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth