Re: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2
I would like to add my support to the comments below on section 2.3, specifically 2.3.1. It is clear to me from reading section 2.3 that clients MAY use HTTP basic, or they MAY include client_id and client_secret in the request body -- however, the latter is not recommended. It is not clear what the authorization server MUST support. IMHO, that leads us to a situation in which there is no universally-agreed set of authentication technology that all programmers can assume is going to work, which means that interoperability will be difficult as some authorization servers will support Basic, others will support the request body, and others will do neither in favor of something else. I would prefer that we make both HTTP basic AND the request body mechanisms in this section both required on the server side, thus giving the client the option of choosing one or the other. That would mean re-writing the beginning of section 2.3.1 as shown below. If I have missed other discussion on this topic I apologize. If there is already consensus to make the message body authentication optional rather than required for the authorization SERVER then I would still recommend that we make HTTP Basic a MUST in order to allow easier interop. Proposed change to 2.3.1: The authorization server MUST support the HTTP Basic authentication scheme as defined in [RFC2617] as a way to identify clients. The client identifier is used as the username, and the client password is used as the password. For example (extra line breaks are for display purposes only): Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Alternatively, the authorization server MUST also allow the client to include the client credentials in the request body using the following parameters: client_id REQUIRED. The client identifier issued to the client during the registration process described by Section 2.2. client_secret REQUIRED. The client secret. The client MAY omit the parameter if the client secret is an empty string. Clients in possession of a client password MAY use either mechanism in order to authenticate with the authorization server. However, including the client credentials in the request body using the two parameters is NOT RECOMMENDED, and should be limited to clients unable to directly utilize the HTTP Basic authentication scheme (or other password-based HTTP authentication schemes). (Rest of section remains as-is with the paragraph beginning For example...) Gregory Brail | Technology | Apigee | +1-650-937-9302 On Mon, Sep 12, 2011 at 2:02 PM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: FYI, probably best for the WG to see/process these secdir comments as appropriate. I've not read 'em in detail myself yet, so as Leif says, feel free to react as appropriate. S. PS: Thanks Leif for reviewing this. Original Message Subject: secdir review of draft-ietf-oauth-v2 Date: Mon, 12 Sep 2011 20:31:06 +0200 From: Leif Johansson le...@sunet.se To: draft-ietf-oauth...@tools.ietf.org, sec...@ietf.org, i...@ietf.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Security review of OAUTH 2.0 core: draft-ietf-oauth-v2-21 Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This review is rather lengthy. This should not be interpreted as anything beyond a desire to do a thorough review. It may well be that I have stumbled on things already covered on the list. If so I apologize and ask that you silently ignore such bits. Also I have included things that are not directly security related but that I found problematic for other reasons. The notes are presented in the order I wrote them down. ** General observations: POST and/or GET Examples are sometimes POST and sometimes GET. In many cases it is not clear to me from the surrounding text if both POST and GET are allowed or if only one is mandated. Illustrating with both a GET _and_ POST example in the cases where both are supported would help or make the method explicit in the text before the example. The P-word The term 'password' is sprinkled throughout the document, sometimes as in client password or resource owner password credentials and I suspect that sometimes it is password as in 'an example of a credential type' and in other cases it is password as in 'plain old password'. This needs to be cleared up throughout (I've included some examples below). Normative Language I've often found myself wanting more normative language often to replace existing but less precise text. I've called out some important cases below. Unknown parameters The sentence The client SHOULD ignore
[OAUTH-WG] Nit: Language in section 1.1
This part of section 1.1 is confusing to me and I stumble whenever I read it – I see that Brian Eaton suggested looking at it a while back but I don’t think it got changed: “OAuth includes four roles working together to grant and provide access to protected resources - access restricted resources requiring authentication:” I would suggest something simpler, such as: “OAuth includes four roles that work together to grant and provide access to protected resources that require authentication.” Gregory Brail | Technology | Apigee | +1-650-937-9302 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Nit: Language in section 1.1
+1, this wording is much clearer to me, too -- justin On Tue, 2011-09-13 at 19:25 -0400, Greg Brail wrote: This part of section 1.1 is confusing to me and I stumble whenever I read it – I see that Brian Eaton suggested looking at it a while back but I don’t think it got changed: “OAuth includes four roles working together to grant and provide access to protected resources - access restricted resources requiring authentication:” I would suggest something simpler, such as: “OAuth includes four roles that work together to grant and provide access to protected resources that require authentication.” Gregory Brail | Technology | Apigee | +1-650-937-9302 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
Is this malicious piece of software external a native application either past of a native client or external to the browser? EHL -Original Message- From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Wednesday, September 14, 2011 6:51 AM To: Eran Hammer-Lahav Cc: Niv Steingarten; oauth@ietf.org Subject: RE: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Hi Eran, As far as I understood, in a textbook CSRF attack the attacker would create his own requests in order to abuse a user's session. This can be prevented by utilizing standard CSRF coutermeasures (page token, nounce, signature as parameter on every request URL), which bind URLs to a certain session. A textbook CSRF attack is when an attacker constructs a URI and then manipulate a user-agent with an active session to call that. In the simplest example, an attacker constructs a URI that transfers a million dollars from the current account to its, then tricks the user to click on that link or automatically redirects the user to that URI. Because the user is already signed in and has an active session token, the request goes through. To prevent it, the request URI must include an artifact that binds the request to the active session. Since the attacker has no way of accessing the session information, it cannot construct as a URI. In practice, this means adding a hidden form parameter to the button with some hash of the session information that the server can verify. So I would conclude we have the same understanding of what CSRF means. But why should the attacker create requests et all? All he needs is already provided by the authorization server themselves. The malicious client can download the HTML pages comprising the authorization flow from the authz server and use the embedded URLs to issue the requests which normaly would have been issued by the resource owner herself (using the use agent indeed). It's more or less the push on a I agree button we are talking about. The authorization server may add a page token to the respective form URL. But it does not matter since the client just uses the authz server manufactured URL to post the form. Of course it matters. The only way the attacker can get access is by calling the 'I agree' button action via an active user session. The attacker cannot access the hidden form value with the session hash (or whatever the server is using for CSRF protection). So whatever URI it constructs will not work when called with the active user session. My point is: the attacker in the threat I'm trying to describe does not need to create any URL since it just remote controls the user-agent. The malicous code runs outside of the browser and just uses the URLs provided by the authz server. Yes, there need to be a session. No, the attacker does not need to inject any URL he made up. So let's assume the attacker has to programmatically handle HTML forms the authorization server delivers to the user agent. As you correctly pointed out, the pre-requisite for such an attack to succeed is that the resource owner must be authenticated somehow, e.g. based on a session cookie. Which also means, we are talking about clients running on the victim's device, within the user agent or as native app. I see the following possible scenarios: 1) external system browser - The app could utilize an existing session within the system browser on the victim's device. It could then remote control a browser window, e.g. using low-level operating system messages (send mouse click) or component techniques such as ActiveX. There are tools available to create macros which automatically control and obtain data from such applications. So this should be feasible. 2) internal browser (cross-browser cookies) - If the authorization server uses cross-browser cookie techniques, such as flash cookies, the attacker could instantiate an internal (invisible) browser and try to utilize a session associated with such a cookie. I assume controlling such a browser instance will be even simpler then in (1). 3) internal browser (silent authz flow) - This is a scenario where the attacker is unable to abuse an existing session on the device. It could instead create an internal browser and perform an authorization flow with the resource owner for one particular scope. Using the same browser instance and based on the cookies obtained in the first run, it could silently perform additional authorization flows for other scopes. 4) internal browser (non-interactive authentication methods) - There are authentication methods available w/o the need for user-interaction, for examples SIM card authentication or certificate-based authentication. The attacker could utilize an internal, invisible browser instance in combination with such an authentication method in order to perform
Re: [OAUTH-WG] Nit: Language in section 1.1
I have no objection, but much clearer? :-) EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer Sent: Wednesday, September 14, 2011 6:04 AM To: Greg Brail Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Nit: Language in section 1.1 +1, this wording is much clearer to me, too -- justin On Tue, 2011-09-13 at 19:25 -0400, Greg Brail wrote: This part of section 1.1 is confusing to me and I stumble whenever I read it – I see that Brian Eaton suggested looking at it a while back but I don’t think it got changed: “OAuth includes four roles working together to grant and provide access to protected resources - access restricted resources requiring authentication:” I would suggest something simpler, such as: “OAuth includes four roles that work together to grant and provide access to protected resources that require authentication.” Gregory Brail | Technology | Apigee | +1-650-937-9302 ___ 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
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
Hi Eran, As far as I understood, in a textbook CSRF attack the attacker would create his own requests in order to abuse a user's session. This can be prevented by utilizing standard CSRF coutermeasures (page token, nounce, signature as parameter on every request URL), which bind URLs to a certain session. A textbook CSRF attack is when an attacker constructs a URI and then manipulate a user-agent with an active session to call that. In the simplest example, an attacker constructs a URI that transfers a million dollars from the current account to its, then tricks the user to click on that link or automatically redirects the user to that URI. Because the user is already signed in and has an active session token, the request goes through. To prevent it, the request URI must include an artifact that binds the request to the active session. Since the attacker has no way of accessing the session information, it cannot construct as a URI. In practice, this means adding a hidden form parameter to the button with some hash of the session information that the server can verify. So I would conclude we have the same understanding of what CSRF means. But why should the attacker create requests et all? All he needs is already provided by the authorization server themselves. The malicious client can download the HTML pages comprising the authorization flow from the authz server and use the embedded URLs to issue the requests which normaly would have been issued by the resource owner herself (using the use agent indeed). It's more or less the push on a I agree button we are talking about. The authorization server may add a page token to the respective form URL. But it does not matter since the client just uses the authz server manufactured URL to post the form. Of course it matters. The only way the attacker can get access is by calling the 'I agree' button action via an active user session. The attacker cannot access the hidden form value with the session hash (or whatever the server is using for CSRF protection). So whatever URI it constructs will not work when called with the active user session. My point is: the attacker in the threat I'm trying to describe does not need to create any URL since it just remote controls the user-agent. The malicous code runs outside of the browser and just uses the URLs provided by the authz server. Yes, there need to be a session. No, the attacker does not need to inject any URL he made up. So let's assume the attacker has to programmatically handle HTML forms the authorization server delivers to the user agent. As you correctly pointed out, the pre-requisite for such an attack to succeed is that the resource owner must be authenticated somehow, e.g. based on a session cookie. Which also means, we are talking about clients running on the victim's device, within the user agent or as native app. I see the following possible scenarios: 1) external system browser - The app could utilize an existing session within the system browser on the victim's device. It could then remote control a browser window, e.g. using low-level operating system messages (send mouse click) or component techniques such as ActiveX. There are tools available to create macros which automatically control and obtain data from such applications. So this should be feasible. 2) internal browser (cross-browser cookies) - If the authorization server uses cross-browser cookie techniques, such as flash cookies, the attacker could instantiate an internal (invisible) browser and try to utilize a session associated with such a cookie. I assume controlling such a browser instance will be even simpler then in (1). 3) internal browser (silent authz flow) - This is a scenario where the attacker is unable to abuse an existing session on the device. It could instead create an internal browser and perform an authorization flow with the resource owner for one particular scope. Using the same browser instance and based on the cookies obtained in the first run, it could silently perform additional authorization flows for other scopes. 4) internal browser (non-interactive authentication methods) - There are authentication methods available w/o the need for user-interaction, for examples SIM card authentication or certificate-based authentication. The attacker could utilize an internal, invisible browser instance in combination with such an authentication method in order to perform the authorization process. I'm not sure whether the scenarios described above can be classified as CSRF. I'm having a hard time following all these scenarios. But the important part is that OAuth assumes the 'user-agent' is a compliant and secure web browser. If the user-agent does not enforce cookie boundaries, XSS, CORS policy, etc. there isn't much we can do. In other words, if the user installs a poorly design native application which has its own user-agent
Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens)
Hi Dave, On Wed, 7 Sep 2011 17:22:14 -0700, Dave Rochwerger wrote: 1. The user does not have to be present. Maybe I should be more clear. What benefit does that have over just a long-lived (forever) access token? The cost is the extra complication for 3rd party developers to have to worry about refresh tokens. I can not see a benefit in our model (everything over SSL, etc) to use refresh tokens. I want to use refresh tokens - but only if there is a reason for them, which I can not see at the moment. The benefit of refresh tokens significantly depends on your access token design. If your access tokens are just a pointer to a database you lookup on any API call, the only benefit if token rotation (coming back to this topic below). But your access tokens could also directly contain all user data you need to actually authorize API access. That way you could save DB lookups, which scales much better. In this model, revocation is much can be easier implement using refresh tokens. I think this is what Eran refered to. 2. As Eran points out, you'd have to have do a DB lookup to have true revocation. The act of revoking tokens is not a common occurrence, DB lookups to revoke tokens is not a concern as there is more time spent by the user navigating the UI (or network latency, etc) than the cost of the DB call. 3. In this sense you get the best of a long-lived credential, combined with good key rotation and authorization re-verification without having to re-involve the end-user. That all sounds good, but in our situation (all SSL, etc) - what do we want key rotation and re-verification for? I fail to see a reasonable vector for access token leakage to warrant any of this in our case. rotation is a mean to detect tokem theft from the device (see also http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01#section-4.1.2). regards, Torsten. On Wed, Sep 7, 2011 at 5:08 PM, Phil Hunt wrote: See below... Phil @independentid www.independentid.com [11] phil.h...@oracle.com [12] On 2011-09-07, at 4:57 PM, Dave Rochwerger wrote: Hi Phil, The client is then forced to periodically reauthenticate (without the user) before getting a new access token. What benefit does that have? The user does not have to be present. Refresh also gives the authzn server a chance to revoke access. Hence it is better to use shorter lived access tokens with long lived refresh tokens. That doesn't follow - we can just as easily revoke the single long-lived access token. As Eran points out, you'd have to have do a DB lookup to have true revocation. But, by having a short expiration time on the access token (say 1 hour or less), you get quasi-revocation which has to be re-validated after the access token expires and the client has to re-authenticate and provide a valid refresh token. In this sense you get the best of a long-lived credential, combined with good key rotation and authorization re-verification without having to re-involve the end-user. Dave. On Wed, Sep 7, 2011 at 4:24 PM, Phillip Hunt wrote: You can also use a long lived refresh token in combination with a short access token. The client is then forced to periodically reauthenticate (without the user) before getting a new access token. Refresh also gives the authzn server a chance to revoke access. Hence it is better to use shorter lived access tokens with long lived refresh tokens. Phil On 2011-09-07, at 15:27, William Mills wrote: I'll talk to the refresh token question: they give you a hook for extensibility and key rotation. If you want to rotate your encryption keys or extend the data carried in the token in any way then you want to be able to cleanly refresh your tokens. Note that the refresh flow allows you to issue a new refresh token at the same time. It also allows a clean path to convert tokens in a new client if you decide you want SAML tokens instead of MAC for example. If you want those things you want to use refresh tokens. You can have long lived access tokens too, and just use the refresh tokens when you want to do something new with the access tokens. -bill - FROM: Dave Rochwerger TO: oauth@ietf.org [2] CC: Quizlet Dev Team SENT: Wednesday, September 7, 2011 2:15 PM SUBJECT: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens) Hi all, I have been implementing OAuth2 based on the various drafts for our new API. Initially, I implemented everything as per the spec, but due to our particular scenario and restrictions we have in place, there are some fundamental questions that I am unable to defend. I am hoping this group could help answer them for me. Our scenario: == * We are implementing an API to allow 3rd party developers to access users' protected resources via their applications. The applications will mostly be native phone apps, but some will have web server backends (javascript-only applications are not a concern at the moment). * We want
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
It is a native app and it is external wrt the browser. regards, Torsten. On Wed, 14 Sep 2011 06:59:47 -0700, Eran Hammer-Lahav wrote: Is this malicious piece of software external a native application either past of a native client or external to the browser? EHL -Original Message- From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Wednesday, September 14, 2011 6:51 AM To: Eran Hammer-Lahav Cc: Niv Steingarten; oauth@ietf.org Subject: RE: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Hi Eran, As far as I understood, in a textbook CSRF attack the attacker would create his own requests in order to abuse a user's session. This can be prevented by utilizing standard CSRF coutermeasures (page token, nounce, signature as parameter on every request URL), which bind URLs to a certain session. A textbook CSRF attack is when an attacker constructs a URI and then manipulate a user-agent with an active session to call that. In the simplest example, an attacker constructs a URI that transfers a million dollars from the current account to its, then tricks the user to click on that link or automatically redirects the user to that URI. Because the user is already signed in and has an active session token, the request goes through. To prevent it, the request URI must include an artifact that binds the request to the active session. Since the attacker has no way of accessing the session information, it cannot construct as a URI. In practice, this means adding a hidden form parameter to the button with some hash of the session information that the server can verify. So I would conclude we have the same understanding of what CSRF means. But why should the attacker create requests et all? All he needs is already provided by the authorization server themselves. The malicious client can download the HTML pages comprising the authorization flow from the authz server and use the embedded URLs to issue the requests which normaly would have been issued by the resource owner herself (using the use agent indeed). It's more or less the push on a I agree button we are talking about. The authorization server may add a page token to the respective form URL. But it does not matter since the client just uses the authz server manufactured URL to post the form. Of course it matters. The only way the attacker can get access is by calling the 'I agree' button action via an active user session. The attacker cannot access the hidden form value with the session hash (or whatever the server is using for CSRF protection). So whatever URI it constructs will not work when called with the active user session. My point is: the attacker in the threat I'm trying to describe does not need to create any URL since it just remote controls the user-agent. The malicous code runs outside of the browser and just uses the URLs provided by the authz server. Yes, there need to be a session. No, the attacker does not need to inject any URL he made up. So let's assume the attacker has to programmatically handle HTML forms the authorization server delivers to the user agent. As you correctly pointed out, the pre-requisite for such an attack to succeed is that the resource owner must be authenticated somehow, e.g. based on a session cookie. Which also means, we are talking about clients running on the victim's device, within the user agent or as native app. I see the following possible scenarios: 1) external system browser - The app could utilize an existing session within the system browser on the victim's device. It could then remote control a browser window, e.g. using low-level operating system messages (send mouse click) or component techniques such as ActiveX. There are tools available to create macros which automatically control and obtain data from such applications. So this should be feasible. 2) internal browser (cross-browser cookies) - If the authorization server uses cross-browser cookie techniques, such as flash cookies, the attacker could instantiate an internal (invisible) browser and try to utilize a session associated with such a cookie. I assume controlling such a browser instance will be even simpler then in (1). 3) internal browser (silent authz flow) - This is a scenario where the attacker is unable to abuse an existing session on the device. It could instead create an internal browser and perform an authorization flow with the resource owner for one particular scope. Using the same browser instance and based on the cookies obtained in the first run, it could silently perform additional authorization flows for other scopes. 4) internal browser (non-interactive authentication methods) - There are authentication methods available w/o the need for user-interaction, for examples SIM card authentication or certificate-based authentication. The attacker could utilize an internal,
Re: [OAUTH-WG] redirect uri validation
ok with me. On Sun, 4 Sep 2011 15:13:01 -0700, Eran Hammer-Lahav wrote: That's not complete. A valid redirection URI is not enough to verify client identity at the time it is presented, but it is enough in many cases to prevent leaking credentials later on. How about a slight change: A valid redirection URI is not sufficient to verify the client's identity when asking for end-user authorization, but can be used to prevent delivering credentials to a counterfeit client after obtaining end-user authorization. EHL -Original Message- From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Monday, August 15, 2011 1:36 PM To: Eran Hammer-Lahav Cc: e...@sled.com; oauth@ietf.org Subject: Re: [OAUTH-WG] redirect uri validation Hi Eran, Am 15.08.2011 08:57, schrieb Eran Hammer-Lahav: Added to 1.4.2: When issuing an implicit grant, the authorization server does not authenticate the client and [[in some cases]], the client identity [[can]] be verified via the redirection URI used to deliver the access token to the client. The access token may be exposed to the resource owner or other applications with access to the resource owner's user-agent. Hope this is sufficient. What do you want to express? Clients can sometimes be verified via redirection URI? My intention was to point out that an invalid redirect URI is a counter- evidence for a client's identity but a valid redirect URI is _not_ an evidence for its identity. I would suggest to add the text below to section 10.1., last paragraph after the sentence For example, by requiring the registration of the client redirection URI or enlisting the resource owner to confirm identity. proposed text: Please note: while an invalid redirection URI indicates a counterfeit client, a valid redirection URI is not sufficient to confirm a client's identity. regards, Torsten. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Sunday, August 14, 2011 11:09 PM To: Torsten Lodderstedt Cc: tors...@lodderstedt-online.de; oauth@ietf.org Subject: Re: [OAUTH-WG] redirect uri validation Where would you suggest I add this? EHL -Original Message- From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Monday, July 25, 2011 10:42 AM To: Eran Hammer-Lahav Cc: tors...@lodderstedt-online.de; oauth@ietf.org Subject: Re: [OAUTH-WG] redirect uri validation Hi Eran, OAuth 1.0 was highly criticized for failing to address client identity in public clients. I believe OAuth 2.0 offers a much better story, within the boundariesof what’s possible today. Agreed. I think we must honestly discuss the value of client authentication/identification itself. I personally think it is over-emphazised right now. The strength of OAuth 2.0 is that it allows solutions where neither client nor resource server have access or do store end-user credentials. Client authentication is nice but not the main feature. Do you have any specific suggestions not already mentioned on the list? I would suggest to mention that while an invalid redirect_uri indicates a counterfeit clients a valid redirect does not prove the calling client's identity. regards, Torsten. EHL ___ 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation)
I suggest we address this particular scenario in the thread model document. EHL -Original Message- From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Wednesday, September 14, 2011 7:26 AM To: Eran Hammer-Lahav Cc: Niv Steingarten; oauth@ietf.org Subject: RE: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) It is a native app and it is external wrt the browser. regards, Torsten. On Wed, 14 Sep 2011 06:59:47 -0700, Eran Hammer-Lahav wrote: Is this malicious piece of software external a native application either past of a native client or external to the browser? EHL -Original Message- From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Wednesday, September 14, 2011 6:51 AM To: Eran Hammer-Lahav Cc: Niv Steingarten; oauth@ietf.org Subject: RE: [OAUTH-WG] Draft 20 last call comment (Resource Owner Impersonation) Hi Eran, As far as I understood, in a textbook CSRF attack the attacker would create his own requests in order to abuse a user's session. This can be prevented by utilizing standard CSRF coutermeasures (page token, nounce, signature as parameter on every request URL), which bind URLs to a certain session. A textbook CSRF attack is when an attacker constructs a URI and then manipulate a user-agent with an active session to call that. In the simplest example, an attacker constructs a URI that transfers a million dollars from the current account to its, then tricks the user to click on that link or automatically redirects the user to that URI. Because the user is already signed in and has an active session token, the request goes through. To prevent it, the request URI must include an artifact that binds the request to the active session. Since the attacker has no way of accessing the session information, it cannot construct as a URI. In practice, this means adding a hidden form parameter to the button with some hash of the session information that the server can verify. So I would conclude we have the same understanding of what CSRF means. But why should the attacker create requests et all? All he needs is already provided by the authorization server themselves. The malicious client can download the HTML pages comprising the authorization flow from the authz server and use the embedded URLs to issue the requests which normaly would have been issued by the resource owner herself (using the use agent indeed). It's more or less the push on a I agree button we are talking about. The authorization server may add a page token to the respective form URL. But it does not matter since the client just uses the authz server manufactured URL to post the form. Of course it matters. The only way the attacker can get access is by calling the 'I agree' button action via an active user session. The attacker cannot access the hidden form value with the session hash (or whatever the server is using for CSRF protection). So whatever URI it constructs will not work when called with the active user session. My point is: the attacker in the threat I'm trying to describe does not need to create any URL since it just remote controls the user-agent. The malicous code runs outside of the browser and just uses the URLs provided by the authz server. Yes, there need to be a session. No, the attacker does not need to inject any URL he made up. So let's assume the attacker has to programmatically handle HTML forms the authorization server delivers to the user agent. As you correctly pointed out, the pre-requisite for such an attack to succeed is that the resource owner must be authenticated somehow, e.g. based on a session cookie. Which also means, we are talking about clients running on the victim's device, within the user agent or as native app. I see the following possible scenarios: 1) external system browser - The app could utilize an existing session within the system browser on the victim's device. It could then remote control a browser window, e.g. using low-level operating system messages (send mouse click) or component techniques such as ActiveX. There are tools available to create macros which automatically control and obtain data from such applications. So this should be feasible. 2) internal browser (cross-browser cookies) - If the authorization server uses cross-browser cookie techniques, such as flash cookies, the attacker could instantiate an internal (invisible) browser and try to utilize a session associated with such a cookie. I assume controlling such a browser instance will be even simpler then in (1). 3) internal browser (silent authz flow) - This is a scenario where the attacker is unable to abuse an existing session on the device. It could instead
Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens)
Thanks for the follow up, Torsten. Whilst I have your attention - any thoughts on my second question, about the use of a client secret? If for all clients we mandated registered URIs and verified them (whether they are private and public), what additional security does the client secret actually provide for private clients in the authorization code flow? Thanks, Dave On Wed, Sep 14, 2011 at 7:20 AM, Torsten Lodderstedt tors...@lodderstedt.net wrote: Hi Dave, On Wed, 7 Sep 2011 17:22:14 -0700, Dave Rochwerger wrote: 1. The user does not have to be present. Maybe I should be more clear. What benefit does that have over just a long-lived (forever) access token? The cost is the extra complication for 3rd party developers to have to worry about refresh tokens. I can not see a benefit in our model (everything over SSL, etc) to use refresh tokens. I want to use refresh tokens - but only if there is a reason for them, which I can not see at the moment. The benefit of refresh tokens significantly depends on your access token design. If your access tokens are just a pointer to a database you lookup on any API call, the only benefit if token rotation (coming back to this topic below). But your access tokens could also directly contain all user data you need to actually authorize API access. That way you could save DB lookups, which scales much better. In this model, revocation is much can be easier implement using refresh tokens. I think this is what Eran refered to. 2. As Eran points out, you'd have to have do a DB lookup to have true revocation. The act of revoking tokens is not a common occurrence, DB lookups to revoke tokens is not a concern as there is more time spent by the user navigating the UI (or network latency, etc) than the cost of the DB call. 3. In this sense you get the best of a long-lived credential, combined with good key rotation and authorization re-verification without having to re-involve the end-user. That all sounds good, but in our situation (all SSL, etc) - what do we want key rotation and re-verification for? I fail to see a reasonable vector for access token leakage to warrant any of this in our case. rotation is a mean to detect tokem theft from the device (see also http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01#section-4.1.2). regards, Torsten. On Wed, Sep 7, 2011 at 5:08 PM, Phil Hunt wrote: See below... Phil @independentid www.independentid.com [11] phil.h...@oracle.com [12] On 2011-09-07, at 4:57 PM, Dave Rochwerger wrote: Hi Phil, The client is then forced to periodically reauthenticate (without the user) before getting a new access token. What benefit does that have? The user does not have to be present. Refresh also gives the authzn server a chance to revoke access. Hence it is better to use shorter lived access tokens with long lived refresh tokens. That doesn't follow - we can just as easily revoke the single long-lived access token. As Eran points out, you'd have to have do a DB lookup to have true revocation. But, by having a short expiration time on the access token (say 1 hour or less), you get quasi-revocation which has to be re-validated after the access token expires and the client has to re-authenticate and provide a valid refresh token. In this sense you get the best of a long-lived credential, combined with good key rotation and authorization re-verification without having to re-involve the end-user. Dave. On Wed, Sep 7, 2011 at 4:24 PM, Phillip Hunt wrote: You can also use a long lived refresh token in combination with a short access token. The client is then forced to periodically reauthenticate (without the user) before getting a new access token. Refresh also gives the authzn server a chance to revoke access. Hence it is better to use shorter lived access tokens with long lived refresh tokens. Phil On 2011-09-07, at 15:27, William Mills wrote: I'll talk to the refresh token question: they give you a hook for extensibility and key rotation. If you want to rotate your encryption keys or extend the data carried in the token in any way then you want to be able to cleanly refresh your tokens. Note that the refresh flow allows you to issue a new refresh token at the same time. It also allows a clean path to convert tokens in a new client if you decide you want SAML tokens instead of MAC for example. If you want those things you want to use refresh tokens. You can have long lived access tokens too, and just use the refresh tokens when you want to do something new with the access tokens. -bill - FROM: Dave Rochwerger TO: oauth@ietf.org [2] CC: Quizlet Dev Team SENT: Wednesday, September 7, 2011 2:15 PM SUBJECT: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens) Hi all, I have been implementing OAuth2 based on the various drafts for our new API. Initially, I implemented
Re: [OAUTH-WG] OAuth2 Implementation questions (client secret and refresh tokens)
Is this a security issue in the OAuth2 process then (for mobile apps using the authorization code flow)? 1. The draft says that mobile apps should be considered public clients because mobile apps can be decompiled and can not keep their credentials private. 2. In this case then, the draft says for these mobile apps to not authenticate with the secret and instead for the server to verify the redirect URI (and make it mandatory). 3. You said that verifying the redirect URI is not good enough to verify the client's identity. What am I missing? Thanks, Dave On Wed, Sep 14, 2011 at 12:51 PM, Torsten Lodderstedt tors...@lodderstedt.net wrote: Hi Dave, redirect URI validation does not authenticate a client. For example, a URI registered for a private web client could be used by a (malicious) native app to assume the web app's identity. The client secret, in contrast, can be used to authenticate it. regards, Torsten. Am 14.09.2011 19:12, schrieb Dave Rochwerger: Thanks for the follow up, Torsten. Whilst I have your attention - any thoughts on my second question, about the use of a client secret? If for all clients we mandated registered URIs and verified them (whether they are private and public), what additional security does the client secret actually provide for private clients in the authorization code flow? Thanks, Dave On Wed, Sep 14, 2011 at 7:20 AM, Torsten Lodderstedt tors...@lodderstedt.net wrote: Hi Dave, On Wed, 7 Sep 2011 17:22:14 -0700, Dave Rochwerger wrote: 1. The user does not have to be present. Maybe I should be more clear. What benefit does that have over just a long-lived (forever) access token? The cost is the extra complication for 3rd party developers to have to worry about refresh tokens. I can not see a benefit in our model (everything over SSL, etc) to use refresh tokens. I want to use refresh tokens - but only if there is a reason for them, which I can not see at the moment. The benefit of refresh tokens significantly depends on your access token design. If your access tokens are just a pointer to a database you lookup on any API call, the only benefit if token rotation (coming back to this topic below). But your access tokens could also directly contain all user data you need to actually authorize API access. That way you could save DB lookups, which scales much better. In this model, revocation is much can be easier implement using refresh tokens. I think this is what Eran refered to. 2. As Eran points out, you'd have to have do a DB lookup to have true revocation. The act of revoking tokens is not a common occurrence, DB lookups to revoke tokens is not a concern as there is more time spent by the user navigating the UI (or network latency, etc) than the cost of the DB call. 3. In this sense you get the best of a long-lived credential, combined with good key rotation and authorization re-verification without having to re-involve the end-user. That all sounds good, but in our situation (all SSL, etc) - what do we want key rotation and re-verification for? I fail to see a reasonable vector for access token leakage to warrant any of this in our case. rotation is a mean to detect tokem theft from the device (see also http://tools.ietf.org/html/**draft-lodderstedt-oauth-** security-01#section-4.1.2http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01#section-4.1.2 ). regards, Torsten. On Wed, Sep 7, 2011 at 5:08 PM, Phil Hunt wrote: See below... Phil @independentid www.independentid.com [11] phil.h...@oracle.com [12] On 2011-09-07, at 4:57 PM, Dave Rochwerger wrote: Hi Phil, The client is then forced to periodically reauthenticate (without the user) before getting a new access token. What benefit does that have? The user does not have to be present. Refresh also gives the authzn server a chance to revoke access. Hence it is better to use shorter lived access tokens with long lived refresh tokens. That doesn't follow - we can just as easily revoke the single long-lived access token. As Eran points out, you'd have to have do a DB lookup to have true revocation. But, by having a short expiration time on the access token (say 1 hour or less), you get quasi-revocation which has to be re-validated after the access token expires and the client has to re-authenticate and provide a valid refresh token. In this sense you get the best of a long-lived credential, combined with good key rotation and authorization re-verification without having to re-involve the end-user. Dave. On Wed, Sep 7, 2011 at 4:24 PM, Phillip Hunt wrote: You can also use a long lived refresh token in combination with a short access token. The client is then forced to periodically reauthenticate (without the user) before getting a new access token. Refresh also gives the authzn server a chance to revoke access. Hence it is better to use shorter lived access tokens with long lived
Re: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2
I agree that stating Clients in possession of a client password MAY use the HTTP Basic authentication scheme [Section 2.3.1 paragraph 1] implies that authorization servers MUST support HTTP basic authentication, but such is never asserted. Instead, it says The authorization server MAY accept any form of client authentication meeting its security requirements. [Section 2.3 paragraph 1] This is somewhat contradictory. I can understand that requiring a specific method of client authentication is desirable for maximum interoperability, but this would be problematic for authorization server implementations that wish to enforce stronger security than HTTP Basic. Such implementations would be forced to deviate from the specification. In particular, implementations which choose MAC access tokens instead of Bearer tokens may wish to add a layer of security to defend against improperly configured TLS connections, or to protect clients who connect to the wrong server. [http://hueniverse.com/2010/09/oauth-bearer-tokens-are-a-terrible-idea/] Such implementations will also find HTTP Basic undesirable for client authentication. To require a form of client authentication that isn't universally sufficient could become a source of criticism and deter adoption of OAuth 2.0. I think the best solution is to clarify section 2.3.1 as follows: --- Clients in possession of client credentials MAY use any form of authentication scheme supported by the authorization server. --- And then follow with the existing example that demonstrates HTTP Basic. Regards, Andre DeMarre On Tue, Sep 13, 2011 at 4:52 PM, Greg Brail g...@apigee.com wrote: I would like to add my support to the comments below on section 2.3, specifically 2.3.1. It is clear to me from reading section 2.3 that clients MAY use HTTP basic, or they MAY include client_id and client_secret in the request body -- however, the latter is not recommended. It is not clear what the authorization server MUST support. IMHO, that leads us to a situation in which there is no universally-agreed set of authentication technology that all programmers can assume is going to work, which means that interoperability will be difficult as some authorization servers will support Basic, others will support the request body, and others will do neither in favor of something else. I would prefer that we make both HTTP basic AND the request body mechanisms in this section both required on the server side, thus giving the client the option of choosing one or the other. That would mean re-writing the beginning of section 2.3.1 as shown below. If I have missed other discussion on this topic I apologize. If there is already consensus to make the message body authentication optional rather than required for the authorization SERVER then I would still recommend that we make HTTP Basic a MUST in order to allow easier interop. Proposed change to 2.3.1: The authorization server MUST support the HTTP Basic authentication scheme as defined in [RFC2617] as a way to identify clients. The client identifier is used as the username, and the client password is used as the password. For example (extra line breaks are for display purposes only): Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Alternatively, the authorization server MUST also allow the client to include the client credentials in the request body using the following parameters: client_id REQUIRED. The client identifier issued to the client during the registration process described by Section 2.2. client_secret REQUIRED. The client secret. The client MAY omit the parameter if the client secret is an empty string. Clients in possession of a client password MAY use either mechanism in order to authenticate with the authorization server. However, including the client credentials in the request body using the two parameters is NOT RECOMMENDED, and should be limited to clients unable to directly utilize the HTTP Basic authentication scheme (or other password-based HTTP authentication schemes). (Rest of section remains as-is with the paragraph beginning For example...) Gregory Brail | Technology | Apigee | +1-650-937-9302 On Mon, Sep 12, 2011 at 2:02 PM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: FYI, probably best for the WG to see/process these secdir comments as appropriate. I've not read 'em in detail myself yet, so as Leif says, feel free to react as appropriate. S. PS: Thanks Leif for reviewing this. Original Message Subject: secdir review of draft-ietf-oauth-v2 Date: Mon, 12 Sep 2011 20:31:06 +0200 From: Leif Johansson le...@sunet.se To: draft-ietf-oauth...@tools.ietf.org, sec...@ietf.org, i...@ietf.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Security review of OAUTH 2.0 core: draft-ietf-oauth-v2-21 Do not be alarmed. I have reviewed this document as part of the security
