Breno did a review of the security draft. Thanks a lot! Begin forwarded message:
> From: Breno de Medeiros <br...@google.com> > Date: May 7, 2011 4:25:53 AM GMT+03:00 > To: Hannes Tschofenig <hannes.tschofe...@gmx.net> > Subject: Re: OAuth Security Consideration Text > > Hi Hannes, > > I have gone through the test and I have a few edits and questions. > > In the edits below, text between -- -- are supposed the be stricken > out. Example if the original is: > > They quick brown fox ... > > and my suggested edit is: > > --They--The quick brown fox ... > > it means that I am suggesting that you replace the original with > > The quick brown fox ... > > Now edits by section: ------------------------------------- > > IN: Section 1. Definitions > > Web Application .... to the OAuth protocol is--are-- stored on the > server and --is-- not accessible ... > > User Agent-based Application ... they can seamlessly make use of > --it--its capabilities ... > > IN: Section 2.2 Malicious Client Obtains Authorization > > ... > > Where the client can be --authenticate--authenticated ... > > ... > > It is --higly--highly RECOMMENDED that ... > > IN: Section 2.9 Phishing Attacks > > in which users can confirm the --authentictity--authenticity of the site. > > -----------------/edits > > Now higher level comments: > > On Native Apps protection of refresh token: > > On section Definitions, there is a sentence in the Native Apps "It is > assumed that such applications can protect dynamically issued secrets, > such as refresh tokens, from eavesdropping by other applications > residing in the same service" > > I suggest that you strike out this sentence from definitions since it > is confusing. This should be moved to section 2.4, with a specific > headed paragraph about management of refresh tokens for native > applications including specific recommendation. > > E.g. of substitution paragraph: > > Native Applications MUST use operating system mediated protections to > ensure that the refresh tokens are safe from unauthorized access by > other users and applications. It is highly RECOMMENDED that such > applications use OS-provided APIs to manage secrets. The applications > MUST apply appropriately restrictive access controls to any file > system or persistent memory objects where the refresh token is stored. > > On Client Authentication: > > "Authorization servers are encouraged to consider stronger client > authentication means" --> This is too vague to be actionable. There is > a great tradition of 'innovation' in client security that promotes no > security and hinders interoperability. I tend to believe that it is > better for servers to be conscious of the limitations of client > authentication and implement mitigation measures than to create ad-hoc > authentication mechanisms. Suggest to strike out this sentence. > > "Authorization server MUST NOT issue client secrets to native or user > agent-based applications in general." -> Agreed on user-agent, however > at least in principle it is possible to issue secrets to native > applications that use hardware-based DRM modules and can hold on to > secrets. More importantly, since the OAuth2 spec no longer actually > specifies how to implement a Native App Flow end-to-end, I am not sure > how to even reason about Native App issues. Propose simply strike out > 'native or'. > > On Malicious Client Obtains Authorization: > > "Authorization servers MUST NOT automatically process (without user > interaction) repeated authorizations without authenticating the > client." -> Not sure what to make of this sentence. If this implies > User-Agent should not support automatic renewal of access tokens > (since user-agent apps cannot be 'authenticated'), then it is a > harmful recommendation because it ignores practical requirements. The > bad word here is 'authenticating', since what is really intended is > some assurance that it is the same client, e.g., the redirect URI > matches a registered value in the User-Agent case. Please strike out > this sentence or substitute it with one like: > > "Authorization servers MUST implement measures to ensure that > automatically issued tokens (without user interaction, based on > previously recorded grant) are delivered to the same client to whom > original grant was performed. Example of suitable measures are > enforcing client authentication or enforcing that the destination of a > redirect (in case of implicit grant) matches the expected value for > the client." > > On Access Tokens > > "Application developers MUST NOT store access tokens in non-transient > memory." -> This is not realistic -- consider the case of a Web > Application running on distributed servers. It is quite possible that > the only distributed storage mechanism available to the application is > based on persistent storage. I suggest you strike out this sentence, > since the previous one is sufficient. > > On Session Fixation > > This section needs to cover XSRF protection, the measures described > within are insufficient for Web Applications or User-Agent-Based > applications. Also the current mitigation described there is better > described as a mitigation against token/code leakage. > > I suggest that you create a new section: > > == > Token and Code Leakage via Referer Header and/Or Open Redirectors > > Attackers can leverage inclusion of third party content (images, ads) > and/or the presence of redirectors in legitimate Web or > User-Agent-Based Applications to steal codes and/or tokens issued to > such sites. > > "In order to prevent such attack ..." (move here the 2nd paragraph > that currently lives on Session Fixation) > > Now for the Session Fixation section, I would recommend that you > expand it to also include 'token', since the attack is also possible > via token. > > The Session fixation attack involves an attacker that forwards a link > to an unsuspecting victim. The victim clicks on the link and > subsequently approves an expected application but as a result the > attacker obtains access to the victim's data either at application or > at the authorization server. > > In order to prevent such attack, a Web or User-Agent-Based application > MUST bind the state of authorization requests to the user's session > with the application. This requires that the Application generate a > strongly unguessable random number, and both include it in the 'state' > parameter of the authorization request as well as to store it in the > user's session, e.g., as an HTTP cookie, a DOM variable, or in any > other suitable storage in the user's agent. When processing the > response from the authorization server (whether in the form of a code > or token), the Application MUST verify that the returned 'state' > parameter matches the value in the user agent. > > > > On Thu, May 5, 2011 at 14:26, Hannes Tschofenig > <hannes.tschofe...@gmx.net> wrote: >> Hey Breno, >> >> here is the draft I mentioned: >> http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-02 >> >> It would be great to get your review comments in. >> >> Ciao >> Hannes >> >> > > > > -- > --Breno _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
