On Wed, May 11, 2011 at 7:23 PM, Lodderstedt, Torsten < t.lodderst...@telekom.de> wrote:
> 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. > This may be a difference of opinion rather than substance, but I find that assumptions stated too far ahead of their use suffer from lack of connection. I would suggest again that the definition remain purely semantic, and the security assumptions be discussed more closely to the attending threats and mitigations. > > > > > > > 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. > When the spec did define a Native App flow it mandated the opposite (the secret was required not optional), which led Google, for instance, to launch the OAuth2 registration for clients to include secret issuance for native apps---against the recommendation of our internal security team---for pure compliance reasons (not that we are relying on its remaining a secret, our security model does not rely on this). I welcome the change of language (even if we may take some time for Google to catch up with it), but find it a bit too strong. Possibly "It is NOT RECOMMENDED ..." followed by some description of why this is ineffective as a security measure? > 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. > Yes, and I am not suggesting it should -- my recommendation was to strike it out. However, what about a softened approach as above? > 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. > That's welcome news indeed. > > > > > > > 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. > Google's experience with threat models on this space leads us to believe that it can be effective in practice. Note that expansive variants of this practice are not safe, e.g., domain matching versus full redirect URI matching. Note that: - There is high value from the perspective of deployment flexibility to support auto-approval in flows where the client cannot authenticate (e.g., user-agent); and - There is a class of existence of effective mitigation strategies: one of these that is fully spec-compliant is full URL matching. Another is to use non-HTTP transport such as windows.postMessage() for authenticated cross-domain communication of the response. (You could consider that a case of client authentication where the user-agent is the authority). I believe that is quite important that we address this issue with a bit of finesse. I understand that there is interest in not going into too much detail into a security considerations section for a broadly applicable spec. However this is a point where abstraction can easily change the threat model/risk profile to the point where a security practitioner would reverse their recommendation on usage. Taking the easy option here to use categorical language may be counterproductive. It is perfectly appropriate to issue guidance that one expects to be widely disregarded provided that one is convinced that those ignoring the guidance will inevitably be putting their services and/or their users at risk. However, I do not think this is the case here. It is possible (or so I believe) to violate this guidance as current stated and mitigate the risks appropriately. > > > > > > > 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. > They are complementary but not in an optional way. By that I mean that _both_ types of measures must _always_ be applied. The client cannot help the user agent against exploits where the attacker abuses the inherent authority of the user agent (while acting on behalf of the user), causing it to perform actions against itself in a confused deputy-type scenario. That's the essence of an XSRF. The client is impotent to help the user agent protect itself without explicit involvement by the user agent. > > Would you please elaborate on how the state parameter prevents XSRF? > The state parameter can provide XSRF (which in turn is essential to prevent session fixation attacks) as follows. - Client or user-agent generates a secret. - The secret is stored in a location accessible only by the client or the user agent (i.e., protected by same-origin policy). E.g.: DOM variable (protected by javascript or other DOM-binding language's enforcement of SOP), HTTP cookie, HTML5 client-side storage, etc. - The secret is attached to the state before a request is issued by the client - When the response is received, before accepting the token or code, the client consults the user agent state and rejects the response altogether if the state does not match the user agent's stored value. Concrete example using HTTP cookies: Client issues a 302 to the user agent with a Set-Cookie header with value "XsrfToken1=$unguessable_random_number" and while simultaneously attaching to the request the state parameter "&state=XsrfToken1%3D$unguessable_random_number" When the client receives the response from the authorization server, it checks that such cookie is also visible. Now, an attacker cannot perform a session fixation attack because it cannot cause the user agent to modify its state in the same-domain-origin scope of the client (if it could it would be game over as it could cause the user agent to supply user credentials in most circumstances). Since it cannot modify the user agent state, it cannot cause the user agent to succeed in completing transactions with the client. In the case of a web server application the client is a web server. In the case of a user agent application the client is logic running within the user agent (so instead of a 302 you would most likely have a window.location reassignment and instead of a Set-Cookie header you would have a reassignment of document.cookie). The principle is the same. > > 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 > -- Breno de Medeiros
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
