Hi all, I am very happy that you got a proposal put together to quickly. Thanks for the good writeup!
A few comments below. --------------- 2. Security Considerations Note: This section focuses on the security principles implementors of the protocol MUST consider. These principles have been derived based on the comprehensive security analysis of the OAuth 2.0 protocol given in [ I-D.lodderstedt-oauth-security ]. I would write: This section focuses on the security principles implementors of the protocol must consider. We encourage readers to consult the more detailed analysis with additional background information can be found in [I-D.lodderstedt-oauth-security]. 2.1. Client Secrets Authorization servers can issue client secrets to web applications. Application developers MUST ensure confidentiality of client secrets. Authorization server MUST NOT issue client secrets to native or JavaScript applications. [hannes] "... since these client secrets cannot be protected easily in these environments." Instead authorization servers MUST utilize [hannes] I added the MUST here. other means than client authentication to achieve their security objectives. Authorization servers can issue client secrets to native applications on a per installation base. [hannes] I am not sure what you want to say with the last sentence given what you said in the earlier sentence. Authorization servers MUST NOT automatic repeat approvals for clients without secrets. [hannes] Could you say why? 2.2. Refresh Tokens Authorization servers may issue refresh tokens to web and native applications. [hannes] I would say: "The OAuth protocol allows authorization servers may issue refresh tokens to web and native applications." Refresh tokens should only be accessible to the authorization server and the client the token has been issued to. [hannes] why do you say "should"? Couldn't we say "MUST"? The authorization server MUST maintain the link between a refresh token and the client it has been issued to. This relation MUST be validated on every token refreshment request. Authorization server as well as application developers MUST ensure [hannes] write: "Authorization server operators as well as application developers MUST ensure" confidentiality of refresh tokens, on transit and storage. Authorization servers should implement means to detect abuse of refresh tokens. [hannes] write : "It is RECOMMENDED for authorization server operators to enable means to detect abuse of refresh tokens." On the other hand we could argue that authorization server operators are encouraged to monitor abuse in general; not only for refresh tokens. (what about revocation?) [hannes] Ignore revocation because OAuth core does not consider revocation. 2.3. Access Tokens Access tokens should only be accessible to the authorization server, the target resource servers and the client the token has been issued to. [hannes] why should and not must? (with the exception listed below) The only exception is the implicit grant where the user agent gets access to the access token that is transmitted in the URI fragment. Application developers MUST NOT store access tokens in non-transient memory. 2.4. Token Scope Application developers should only acquire access tokens with the minimal scope they need in order to implement the respective application function. [hannes] I would say that it is useful to talk about "It is strongly RECOMMENDED ....". 2.5. Phishing attacks on redirect-based flows Application developers should, when possible, use external browsers instead of browsers embedded in the application for performing the end-user authorization process. [hannes] again, recommended is more appropriate. I would also extend the sentence to say a few words about the why. Authorization servers MUST ensure authenticity of the endpoint in order to prevent phishing attacks. [hannes] I wonder whether this is the right way of phrasing it: What about "To reduce the risk of phishing attacks authorization servers MUST provide their identity to other entities." For example, they can utilize HTTPS server authentication for that purpose. Moreover, service Providers should attempt to educate users about the risks phishing attacks pose, and should provide mechanisms that make it easy for Users to confirm the authenticity of their sites. e.g. extended validation certificates. [hannes] s/Providers/providers s/Users/users. 2.6. Request confidentiality The following data MUST be transmitted over secure transport (such as TLS) only: [hannes] What about The following security sensitive data elements MUST NOT transmitted in clear: access tokens, refresh tokens, resource owner passwords, authorization codes, and client secrets. 2.7. Online Guessing Attacks Authorization servers MUST prevent guessing attacks on the following credentials: authorization codes, refresh tokens, resource owner passwords, and client secrets. When creating token handles or other secrets not intended for usage by human users, the authorization server MUST include a reasonable level of entropy in order to mitigate the risk of guessing attacks. 2.8. Authorization code disclosure Confidentiality of authorization codes MUST be ensured on transport, even considering browser histories and HTTP referer headers. Authorization server as well as the client MUST ensure that authorization code transmission is protected by using transport-layer mechanisms such as TLS and that the duration of an authorization code is limited. [hannes] Minor change: " The authorization server and the client MUST ensure that the authorization code transmission is protected by using channel security, such as TLS, and that the lifetime of the authorization code is limited. " For web applications, authorization servers MUST authenticate the client and validate that the authorization code had been issued to the same client. For native applications, authorization servers MUST enforce one time usage of the authorization code. Moreover, if an Authorization Server observes multiple attempts to redeem an authorization code, the Authorization Server MAY want to revoke all tokens granted based on the authorization code. 2.9. Session Fixation The session fixation attack leverages the authorization code flow in an attempt to get another user to log-in and authorize access on behalf of the attacker. The victim, seeing only a normal request from an expected application, approves the request. The attacker then uses the victim's authorization to gain access to the information unknowingly authorized by the victim. In order to prevent such an attack, authorization servers MUST ensure that the redirect_uri used in the authorization flow is the same as the redirect_uri used to exchange the respective authorization code into tokens. Authorization servers SHOULD require clients to pre- register their redirect_uri's and validate the actual redirect_uri against the pre-registered value. [hannes] I think that this is what you want to say: " The authorization server operators SHOULD require client application developers to pre-register their redirect_uri's and validate the actual redirect_uri against the pre-registered value. " 2.10. Malicious client obtains authorization A malicious client could impersonate a valid client and obtain an access authorization that way. [hannes] " A malicious client could impersonate as a valid client to obtain access to a protected resource. " Assumption: It is not the task of the authorization server to protect the end-user's device from malicious software. This is the responsibility of the platform running on the particular device probably in cooperation with other components of the respective ecosystem (e.g. an application management infrastructure). The sole responsibility of the authorization server is to control access to the end-user's resources living in resource servers and to prevent unauthorized access to them. Based on this assumption, the following countermeasures are recommended. If the impersonated client is a web application, the authorization server MUST authentication the client. [hannes] Write: " In case of a client running as web application, the authorization server MUST authentication the client. " The authorization server SHOULD require clients to pre-register their redirect_uri's and validate the actual redirect_uri against the pre-registered value. If the impersonated client is an native or JavaScript application, [hannes] write: "In case of a client running as a native or JavaScript application," the authorization server MUST utilize other means to achieve its security objectives. The authorization server may enforce explicit user authentication or ask the end-user for consent. In this context, the user shall be explained the purpose, scope, and duration of the authorization. The authorization server must make the metat- data available to the end-user it associates with the particular client. It is up to the user to validate the binding of this data to the particular application (e.g. Name) and to approve the authorization request. [hannes] Do you want to use RFC 2119 language in the above paragraph? What meta-data are you talking about? The authorization server MAY also limit the scope of tokens. [hannes] Is MAY a bit weak here? In what cases would you say it is highly recommended to limit the scope. Would't you always want to do that? 2.11. Resource Owner Password Credentials The "Resource Owner Password Credentials" grant type is often used for legacy/migration reasons. It has higher risk because it maintains the uid/password anti-pattern and the client could abuse the user id and password. Additionally, because the user does not have control over the authorization process, clients using this grant type are not limited by scope, but instead have potentially the same capabilities as the user themselves. The client could also acquire long-living tokens and pass them up to a attacker web service for further abuse. Authorization servers and application developers SHOULD minimize use of this grant types. Other flows which facilitate user control and transparency should be used instead. [hannes] This writeup essentially says "Please don't use it; it is completely insecure". The authorization server SHOULD generally restrict the scope of access tokens issued by this flow. The authorization server MUST ensure the resource owners control and transparency with respect to all authorizations issued to clients. 2.12. Authenticity of endpoints Authorization servers MUST support validation of endpoint authenticity using HTTPS server authentication. [hannes] write: " HTTPS with server-side authentication MUST be implemented and used by authorization servers in all exchanges. " Application developers MUST validate the authorization server endpoint's authenticity and ensure proper handling of CA certificates as well as certificate chain validation. [hannes] I am not sure what you want. Do you want the human (as the application developer to verify something) or do you want the application developer to write code that does certificate checking. Then, you may also want to perform authorization. --------------- Ciao Hannes On Mar 31, 2011, at 12:08 PM, Torsten Lodderstedt wrote: > Hi all, > > I just uploaded a proposal for the security section of the core spec to the > IETF site > (http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-securityconsiderations/). > > > As posted on the list previously, our idea was first to derive a security > consideration section for the core spec by cutting down > http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-security/ to a > reasonable size. We tried to go through the document and identify the pieces > that should go into the spec in the informal OAuth security session here at > IETF-80. Although we did not make it further than 4.1.3, the meeting turned > out to be valuable since we agreed on certain principles we are expected to > apply when producing the section: > - focus on service provider and application developers perspective (and the > protocol implementation) > - document the "what" and not the "why" - for "why" include informative > reference to security document > - explicitely state don'ts and explicitely define and distinguish three > client categories (web, native, JavaScript) > For example we had a really lengthy discussion about native apps, client > secrets and client authentication - bottom line: we just state "Authorization > server MUST NOT issue client secrets to installed or JavaScript applications." > > Moreover, we agreed to produce a security considerations section as concise > as possible and as quickly as possible. There were objections in the room to > "just" cut down our document. Instead the proposal was to start something new. > > So the proposed text focus on the "WHAT" and references > http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-security/ for a > discussion of the "WHY". > > Your feedback is appreciated. > > regards, > Torsten. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
