Subject: [OAUTH-WG] Reminder: OAuth WG Conference Call, 21st January 2013, 1pm EST

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 17 Jan 2013 15:43:26 +0200

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.

---

From: [email-masked]
Date: Fri, 18 Jan 2013 17:22:59 +0800

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

[email-masked] 写于 2013-01-17 21:43:26:

> We will continue where we stopped last time, namely we stopped our 
> discussions at the crypto agility requirement 
> 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:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 28 Jan 2013 14:53:38 +0200

Hi Zhou, 

sorry I missed your mail because of the subject header. 

>  however, collusion between resource server and client could happen. 

Correct. I should add this. 

>    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?]

>    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

---

From: [email-masked]
Date: Tue, 29 Jan 2013 20:09:44 +0800

Hi, Hannes,

Hannes Tschofenig <[email-masked]> 写于 2013-01-28 20:53:38:

> >   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?
Privacy is always welcome.
The question is what will be the OAuth solution under this privacy 
condition? 
Or is it possible to obtain an OAuth method with both security and 
anonymity?

> phishing RO's credential, for example. 
In the current text, it is pointed out the compromise of a single Client ( 
RS) should not  result 
in compromise of other clients (RS).
The thing is compromise of a client could result in disclosure of keying 
material held by RS, or vice verse.
it should also be considered IMO.
Further, even if compromise of client (RS) does not leak keys held by 
other clients (RS), 
the incident may have other consequence that will do harm to the system, 
for example, 
a compromised RS might redirect the Client and Resource Owner to a forged 
AS, which phishing Resource owner's password.
I am saying compromise of a client or RS or AS may lead to more threat 
than Domino effect.
I wonder if they have been well considered in the current document.