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

[[e-mail]]

Hi, Hannes,

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

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


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



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