Hi Breno, thanks for the feedback. Please find my comments inline.
> > > > 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" the original text says: "on the same device" > > > > 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. This section shall document all assumptions determining the differences between those categories, which are relevant for the security sections. Thus I would like to keep it and probably improve it. > > > > 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. A couple of comments on this: 1) This statement is intended to prohibit secrets for software packages and not software instances. Thus the text also says "An authorization server MAY issue a client secret for an installation of a native application on a specific device.". We just want to get rid of the bad practice of using secrets for authenticating software packages. This practice creates a false feeling of security and people tend to rely on this kind of client authentication too much. They shall be adviced to utilize other means than client secrets. 2) The intention of the text is to give simple and clear rules instead of discussing "if", "then" and "why". This discussion is subject of the security threats and considerations I-D referenced by the introduction of the text. 3) DRM modules give you a device specific authentication, they do not authenticate a certain software package or instance. >>> 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'. The description of how to implement native apps is badly missing right now and has been requested during IETF-80. It will be re-included soon. > > > > 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." As discussed in the other thread. I do not consider the redirect_uri enforcement to be a reliable way to prevent abuse of existing authorizations. > > > > 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. Good point, I agree. > > > > 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. > > In my opinion, the mean you describe is complementary to the redirect_uri-based approach described in the text. Both can be used to detect session fixation attempts. The difference is that the redirect_uri-based appraoch relies on the authz server to detect the attack whereas the redirect_uri-based approach leaves the detection to the client. Would you please elaborate on how the state parameter prevents XSRF? regards, Torsten. > > > > > > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
