Re: [OAUTH-WG] Fwd: OAuth Security Consideration Text
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 Authorizati
Re: [OAUTH-WG] Fwd: OAuth Security Consideration Text
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-trans
[OAUTH-WG] Fwd: OAuth Security Consideration Text
Breno did a review of the security draft. Thanks a lot! Begin forwarded message: > From: Breno de Medeiros > Date: May 7, 2011 4:25:53 AM GMT+03:00 > To: Hannes Tschofenig > 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 des
