Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
Eran, sorry, where should use cases be officially documented? I assume the use cases being more like HTTP Auth are not in reference to the ones I've been describing. For my part, I'm focused on OAuth use cases. Both that of a single token being used on multiple devices (or app instances) and that of tokens being presented for client credentials in the OAuth flow. I thought we had already agreed from a previous thread that the MAC token spec should be extensible beyond just use of access tokens and at least to that of client credentials. skylar On Jun 1, 2011, at 7:54 AM, Eran Hammer-Lahav wrote: They are coming in 2-3 directions, the use case isn't really clear (other than claims of some flavors being harder than others), and overall this is more about general HTTP authentication than OAuth use cases. Don't get me wrong - if you want to put the effort in to capture these, go ahead. I just think this isn't worth the effort in a formal document. EHL -Original Message- From: Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.com] Sent: Tuesday, May 31, 2011 6:15 PM To: Eran Hammer-Lahav Cc: Phil Hunt; OAuth WG Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token Maybe... But this information must be captured somewhere, right? At the moment, there seems to be no record of and consequently no reference point to the use case in question. And this is what has created all this discussion--with messages coming from all directions. Igor Eran Hammer-Lahav wrote: I think the use case document should focus on v2, not on MAC. At some point, it becomes impractical to keep every use case discussed on this list recorded. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Igor Faynberg Sent: Tuesday, May 31, 2011 3:50 PM To: Phil Hunt Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token ...Sorry to turn the question around so as to underline my pet peeve: Have we *documented* all cases? (This is what the Use Cases document is supposed to be all about.) Just to clarify: I am not arguing with Phil's point now. I just stress that as of this moment we don't have anything to check against. Igor Phil Hunt wrote: There seems to be a demonstrated need for both age and timestamp tokens. The list has 2 separate cases with 2 separate proposals that do not solve all cases. Can we at least agree that neither proposal works in all cases? Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-05-31, at 2:41 PM, Adam Barth wrote: You haven't described a problem. On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward sky...@kiva.org wrote: First we should agree on a common understanding of the spec. The reason why age works with unsynchronized clocks is that the client determines issue_date based on the time when it receives the token over the wire. This depends on the server and client both recording time this way and for the transmission of the token to be be not longer than the margin of error for validating age. Are we agreed on this understanding? That's not correct. The age allows the server to protect against replay attacks in bounded memory. With unbounded memory, the server can just remember every nonce it has ever seen associated with a given key and reject replays. With bounded memory, the server eventually needs to evict some of these nonces due to memory pressure. The age value lets the server reject the nonces with the smallest age values first. The server then rejects any messages with age values smaller than (or equal to) the largest age value it has ever evicted for the given key. Notice that neither clock synchronization nor transmission time plays a role in that implementation. The easiest case for me to explain here is client credentials because I have to assume you've built and registered a Twitter app at some point (or similar OAuth 1.0a app). You registered your app on the site and were issued a client_id and client_secret (called consumer_key and consumer_secret in 1.0). You then embedded these values in your client (they were not issued programmatically to your app). Assuming the MAC token algorithm is used then for establishing client identity (originally one of the uses we, the working group, hoped MAC would cover) how then will your client determine issue date? I recommend the date at which the developer obtained the credential from Twitter because that is the date when the credential was issued. After we can establish where you're at on the two above points I'll continue with the explanation. But as a preview, the next points would be: - If issue_date comes form the server, how is it translated to the client? The issue_date does not come from the server. - If you use a server
Re: [OAUTH-WG] Text for Native Applications
On Tue, May 31, 2011 at 10:39 PM, Kris Selden kris.sel...@gmail.com wrote: Why can't you just revoke the refresh token for a client when you change the client secret? Is it not easier to revoke a token than it is to rotate the client secret (which is usually configured or embedded in the client whereas the token is issued)? As I noted in my original e-mail on this thread, I was talking specifically about the web server flow. This is one area where the security considerations for installed applications are different than for web servers. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
On Jun 1, 2011, at 7:58 AM, Eran Hammer-Lahav wrote: I don't think you have made the case why you age is any harder to implement than a timestamp. It is not that your email isn't clear, it's that we're not convinced that timestamp will produce any better result than age in practice. This is purely technical, not political. That's no longer my point. I've now realized it doesn't work for all of my uses for MAC token (assuming we validate age, either by the implementation Adam suggested or by the one I had assumed where age is judged old by comparing to a device system time). Let me know if my latest response to Adam doesn't it make it clear why this does not work for either client credentials or a token issued to multiple instances of a client. If not, I'll continue attempting to explain myself. I also would like to see the specification not to be configurable. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
No, no, my little I told you so aside, I don't insist on putting this in the document, especially that we have already agreed that the use case document is a post-2.0 issue. I think that for the purposes of the discussion on this thread it would help if all the use cases in question were clearly described--if only in an e-mail for now. Then it would be a matter of logic to see if there is a problem, and if there is one, what the solutions to it might be. Igor Eran Hammer-Lahav wrote: They are coming in 2-3 directions, the use case isn't really clear (other than claims of some flavors being harder than others), and overall this is more about general HTTP authentication than OAuth use cases. Don't get me wrong - if you want to put the effort in to capture these, go ahead. I just think this isn't worth the effort in a formal document. EHL -Original Message- From: Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.com] Sent: Tuesday, May 31, 2011 6:15 PM To: Eran Hammer-Lahav Cc: Phil Hunt; OAuth WG Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token Maybe... But this information must be captured somewhere, right? At the moment, there seems to be no record of and consequently no reference point to the use case in question. And this is what has created all this discussion--with messages coming from all directions. Igor Eran Hammer-Lahav wrote: I think the use case document should focus on v2, not on MAC. At some point, it becomes impractical to keep every use case discussed on this list recorded. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Igor Faynberg Sent: Tuesday, May 31, 2011 3:50 PM To: Phil Hunt Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token ...Sorry to turn the question around so as to underline my pet peeve: Have we *documented* all cases? (This is what the Use Cases document is supposed to be all about.) Just to clarify: I am not arguing with Phil's point now. I just stress that as of this moment we don't have anything to check against. Igor Phil Hunt wrote: There seems to be a demonstrated need for both age and timestamp tokens. The list has 2 separate cases with 2 separate proposals that do not solve all cases. Can we at least agree that neither proposal works in all cases? Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-05-31, at 2:41 PM, Adam Barth wrote: You haven't described a problem. On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward sky...@kiva.org wrote: First we should agree on a common understanding of the spec. The reason why age works with unsynchronized clocks is that the client determines issue_date based on the time when it receives the token over the wire. This depends on the server and client both recording time this way and for the transmission of the token to be be not longer than the margin of error for validating age. Are we agreed on this understanding? That's not correct. The age allows the server to protect against replay attacks in bounded memory. With unbounded memory, the server can just remember every nonce it has ever seen associated with a given key and reject replays. With bounded memory, the server eventually needs to evict some of these nonces due to memory pressure. The age value lets the server reject the nonces with the smallest age values first. The server then rejects any messages with age values smaller than (or equal to) the largest age value it has ever evicted for the given key. Notice that neither clock synchronization nor transmission time plays a role in that implementation. The easiest case for me to explain here is client credentials because I have to assume you've built and registered a Twitter app at some point (or similar OAuth 1.0a app). You registered your app on the site and were issued a client_id and client_secret (called consumer_key and consumer_secret in 1.0). You then embedded these values in your client (they were not issued programmatically to your app). Assuming the MAC token algorithm is used then for establishing client identity (originally one of the uses we, the working group, hoped MAC would cover) how then will your client determine issue date? I recommend the date at which the developer obtained the credential from Twitter because that is the date when the credential was issued. After we can establish where you're at on the two above points I'll continue with the explanation. But as a preview, the next points would be: - If issue_date comes form the server, how is it translated to the client? The
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
Yeah, sorry, I didn't mean to offend you Skylar. Your suggested approach is similar to the approach Eran alluded to earlier. Hopefully he'll have some new text that will work for your use case (which I still don't fully understand). Adam On Tue, May 31, 2011 at 10:58 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: No need to get worked up. I'm sure Adam didn't mean to offend - that's just his style (speaking as someone who is considered much less polite by a landslide). I don't think you have made the case why you age is any harder to implement than a timestamp. It is not that your email isn't clear, it's that we're not convinced that timestamp will produce any better result than age in practice. This is purely technical, not political. However, we did come up with a solution that should cover all bases. I do strongly object to making this protocol configurable. Configurable authentication schemes are by definition complex and right now MAC is amazingly simple. EHL -Original Message- From: Skylar Woodward [mailto:sky...@kiva.org] Sent: Tuesday, May 31, 2011 10:14 PM To: Eran Hammer-Lahav Cc: igor.faynb...@alcatel-lucent.com; Phil Hunt; OAuth WG Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token Yes, but I think my case is very important (eg, being able to use a MAC token as a client credential). I don't understand why Adam can't comprehend my explanation. My best guess is this is some kind of political game on his front to protect the age specification yet I don't understand any motivation for being so close-minded. His reply to my last thread was completely disrespectful and ignorant. Unless I've made him mad or offended him in some way I see no excuse for this behavior. I'm going to make one more attempt to try to explain this to him over email. After that I recommend a Skype call (hopefully brief) or I will work offline with Eran to see if we can find some solution. Btw, in addition to the use case of using MAC tokens for client credentials, we also have the use case of re-issuing a valid token multiple times to instances of the same client. (eg, the value of ID and secret are constant across multiple transmissions to client instances). Thanks, skylar On Jun 1, 2011, at 2:00 AM, Eran Hammer-Lahav wrote: I think the use case document should focus on v2, not on MAC. At some point, it becomes impractical to keep every use case discussed on this list recorded. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Igor Faynberg Sent: Tuesday, May 31, 2011 3:50 PM To: Phil Hunt Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token ...Sorry to turn the question around so as to underline my pet peeve: Have we *documented* all cases? (This is what the Use Cases document is supposed to be all about.) Just to clarify: I am not arguing with Phil's point now. I just stress that as of this moment we don't have anything to check against. Igor Phil Hunt wrote: There seems to be a demonstrated need for both age and timestamp tokens. The list has 2 separate cases with 2 separate proposals that do not solve all cases. Can we at least agree that neither proposal works in all cases? Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-05-31, at 2:41 PM, Adam Barth wrote: You haven't described a problem. On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward sky...@kiva.org wrote: First we should agree on a common understanding of the spec. The reason why age works with unsynchronized clocks is that the client determines issue_date based on the time when it receives the token over the wire. This depends on the server and client both recording time this way and for the transmission of the token to be be not longer than the margin of error for validating age. Are we agreed on this understanding? That's not correct. The age allows the server to protect against replay attacks in bounded memory. With unbounded memory, the server can just remember every nonce it has ever seen associated with a given key and reject replays. With bounded memory, the server eventually needs to evict some of these nonces due to memory pressure. The age value lets the server reject the nonces with the smallest age values first. The server then rejects any messages with age values smaller than (or equal to) the largest age value it has ever evicted for the given key. Notice that neither clock synchronization nor transmission time plays a role in that implementation. The easiest case for me to explain here is client credentials because I have to assume you've built and registered a Twitter app at some point (or similar OAuth 1.0a app). You registered your app on the site and were issued a client_id and
Re: [OAUTH-WG] Text for Native Applications
The distinction is that the client_secret tends to be a global secret, and there is little ability to protect this type of secret in many common means of application distribution. For example, a iOS app that is shipped through iTunes certainly has access to reasonably secure storage via KeyChain for secrets issued to the application at runtime, such as the referesh_token, but it can't do a good job of protecting the client_secret, since this must be embeded in the binary that is distributed to everyone. -cmort On 5/31/11 2:17 PM, Dave Nelson dnel...@elbrys.com wrote: This issue has likely been discussed long ago, but I'd like to potentially re-open the discussion. o Native applications that use the authorization code grant type flow SHOULD do so without client password credentials, due to their inability to keep those credentials confidential. I understand that, in a strict sense, a software component running in a non-embedded environment cannot be guaranteed to maintain the confidentiality of credentials entrusted to it. On the other hand, I think this proscription may go too far. All security is a matter of providing sufficient counter-measures to identified attack vectors, and I believe that native applications probably *can* keep secrets well enough to resist the types of attacks they are likely to be subject to in certain specified use cases. Perhaps the SHOULD wording leaves enough room for implementations with credential hiding mechanisms that are deemed appropriate in a given use scenario to include the use of a client password. I think it would be more accurate to say that native applications SHOULD NOT include the client password in the authorization grant type flow, *unless* the design of the application can provide a sufficient level of protection for said password storage to meet the risks identified in association with the deployment scenario. Thoughts? Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 ___ 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] Text for Native Applications
-Doug Tangren http://lessis.me On Wed, Jun 1, 2011 at 1:39 AM, Kris Selden kris.sel...@gmail.com wrote: Why can't you just revoke the refresh token for a client when you change the client secret? This makes sense for a server implementation for added precaution but in practice, most clients dont change client secrets often. Is it not easier to revoke a token than it is to rotate the client secret (which is usually configured or embedded in the client whereas the token is issued)? Yes, providing a user means to revoke a token or to break a connection is a defacto feature of most server implementations. However, most users will accept the authorization for an app and forget about it. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
-Original Message- From: Skylar Woodward [mailto:sky...@kiva.org] Sent: Tuesday, May 31, 2011 10:54 PM Unfortunately though, this implementation doesn't help my use cases because such sequential requirement of a timestamp/age requires all devices with the token to be in sync as to the value of timestamp/age. So let's move on. This is not true. The age value has to be monotonically increasing, but not necessarily unique. Really, any counter will do. The reason why timestamp isn't any better than age or sequence is because ultimately, it is the server's memory restriction which determines the nonces storage size, not anything else (like a time limit). I am going to change the spec to define age as any 'monotonically increasing, but not necessarily unique' positive numerical value, and give timestamp and time-since-received as two examples, along with a counter. It will also specify that if the numerical value is time-based, it MUST use seconds precision. This should provide a practical solution to everyone. When the first request comes in, it goes into storage. When the second one comes, you check if its numerical part is equal or greater than the one you previously received. If the number is smaller, you should allow for some margin in case the client is using time-based value, otherwise you reject the request. Once the storage fills, you evict the nonces with the smallest numerical values as needed. The storage size should match the speed in which clients transmit requests. Unlike timestamps, the margin can be very small, like 60 seconds, because this is time-sync across *client* machines, not the client and server. It is perfectly reasonable to expect a client sharing the same MAC credentials across multiple machines to implement clock sync keeping all machines less than a minute apart. Any kind of storage-limited nonce-checking is going to fail sometimes even for valid requests because of how the numerical part is generated and how much storage the server has (across all clients). I think this is a very reasonable compromise that in practice, will produce good results with little complexity and plenty of flexibility. The alternatives presented so far (using timestamps or offering multiple options) will fail completely for the primary use cases this specification was written for. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
-Original Message- From: Skylar Woodward [mailto:sky...@kiva.org] Sent: Tuesday, May 31, 2011 11:03 PM To: Eran Hammer-Lahav Cc: igor.faynb...@alcatel-lucent.com; OAuth WG Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token Eran, sorry, where should use cases be officially documented? This list seems a fine enough place. I have no problem keeping track. I assume the use cases being more like HTTP Auth are not in reference to the ones I've been describing. For my part, I'm focused on OAuth use cases. Both that of a single token being used on multiple devices (or app instances) and that of tokens being presented for client credentials in the OAuth flow. I thought we had already agreed from a previous thread that the MAC token spec should be extensible beyond just use of access tokens and at least to that of client credentials. Useful for, yes. Extensible, no. The only extensible part if the choice of algorithm. skylar On Jun 1, 2011, at 7:54 AM, Eran Hammer-Lahav wrote: They are coming in 2-3 directions, the use case isn't really clear (other than claims of some flavors being harder than others), and overall this is more about general HTTP authentication than OAuth use cases. Don't get me wrong - if you want to put the effort in to capture these, go ahead. I just think this isn't worth the effort in a formal document. EHL -Original Message- From: Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.com] Sent: Tuesday, May 31, 2011 6:15 PM To: Eran Hammer-Lahav Cc: Phil Hunt; OAuth WG Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token Maybe... But this information must be captured somewhere, right? At the moment, there seems to be no record of and consequently no reference point to the use case in question. And this is what has created all this discussion--with messages coming from all directions. Igor Eran Hammer-Lahav wrote: I think the use case document should focus on v2, not on MAC. At some point, it becomes impractical to keep every use case discussed on this list recorded. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Igor Faynberg Sent: Tuesday, May 31, 2011 3:50 PM To: Phil Hunt Cc: OAuth WG Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token ...Sorry to turn the question around so as to underline my pet peeve: Have we *documented* all cases? (This is what the Use Cases document is supposed to be all about.) Just to clarify: I am not arguing with Phil's point now. I just stress that as of this moment we don't have anything to check against. Igor Phil Hunt wrote: There seems to be a demonstrated need for both age and timestamp tokens. The list has 2 separate cases with 2 separate proposals that do not solve all cases. Can we at least agree that neither proposal works in all cases? Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-05-31, at 2:41 PM, Adam Barth wrote: You haven't described a problem. On Tue, May 31, 2011 at 1:46 AM, Skylar Woodward sky...@kiva.org wrote: First we should agree on a common understanding of the spec. The reason why age works with unsynchronized clocks is that the client determines issue_date based on the time when it receives the token over the wire. This depends on the server and client both recording time this way and for the transmission of the token to be be not longer than the margin of error for validating age. Are we agreed on this understanding? That's not correct. The age allows the server to protect against replay attacks in bounded memory. With unbounded memory, the server can just remember every nonce it has ever seen associated with a given key and reject replays. With bounded memory, the server eventually needs to evict some of these nonces due to memory pressure. The age value lets the server reject the nonces with the smallest age values first. The server then rejects any messages with age values smaller than (or equal to) the largest age value it has ever evicted for the given key. Notice that neither clock synchronization nor transmission time plays a role in that implementation. The easiest case for me to explain here is client credentials because I have to assume you've built and registered a Twitter app at some point (or similar OAuth 1.0a app). You registered your app on the site and were issued a client_id and client_secret (called consumer_key and consumer_secret in 1.0). You then embedded these values in your client (they were not issued programmatically to your app). Assuming the MAC token algorithm is used then for establishing client identity (originally one of the uses we, the working group, hoped MAC would
Re: [OAUTH-WG] Text for Native Applications
It's not entirely necessary; I'm just having a tough time figuring out any practical difference between the implicit grant flow, and the webserver flow with no credentials. In general I agree with your points, but I think we have a similar, perhaps worse, scenario with relaxing the need for credentials on the web server flow. In terms of your example, wouldn't basic XSRF protection in the state param protect? -cmort On 5/31/11 5:37 PM, Brian Eaton bea...@google.com wrote: On Tue, May 31, 2011 at 10:41 AM, Chuck Mortimore cmortim...@salesforce.com wrote: Updated in language I just sent out - thanks. On that note, we currently return refresh_token using the implicit grant type under certain controlled circumstances. Facebook in turn uses the implicit grant type, and simply issues long term access_tokens. Are there any strong objections to adding optional support for referesh_token on the implicit grant along with security considerations? Is that really necessary? Why? The justification of reduced network round trips seems bogus to me. We're talking about clients that just loaded up an entire web page, asked the user to login, picked up a redirect, and are about to make at least one and possibly several other API calls. I'd prefer to keep the spec simple and consistent. We can add all kinds of options and maybes to the language, but long-term it will just hurt interop. I'd rather settle on protocol flows that make sense. One risk that comes up with returning refresh tokens with the implicit grant type involves recovering from compromise of client web servers. That's not strictly relevant to the current distinction (we're talking about installed apps, different threat model), but it might be worth thinking about anyway. Consider what happens when a client web server is compromised and the client secret and refresh tokens are stolen. - the attacker can use the tokens until the compromise is discovered. - the client secret is then changed - the stolen refresh tokens then become useless Now, *if* the implicit grant type returns refresh token, that story changes. Even if the client secret is changed, the attacker can keep using the refresh tokens! They do it by passing them to the victim client again, through the implicit grant flow. The victim client will then link the refresh token to the attacker's account. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Text for Native Applications
-Doug Tangren http://lessis.me For example, a iOS app that is shipped through iTunes certainly has access to reasonably secure storage via KeyChain for secrets issued to the application at runtime, such as the referesh_token, but it can’t do a good job of protecting the client_secret, since this must be embeded in the binary that is distributed to everyone. Neither can anything that runs in you browser [1] [1]: https://github.com/cezarsa/silver_bird/commit/6c0c0b439d49f716ba5ea8ae2e13d15f2096c6fa ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Text for Native Applications
I would suspect that many users are overwhelmed when authorizing many fine grained scopes and don't fully understand the risks. Many popular sites ask for offline access straight away upon connecting to Facebook (Foursquare, Quora, Instagram, etc). This offline access token, has a higher chance of being exposed, like if you use the cookie: true option in the Facebook JS SDK (which Foursquare does), which sets a Javascript accessible non secure cookie on your domain which now means that if Foursquare makes a non secure http request to foursquare.com a non expiring bearer token will go out in plaintext. Foursquare is https only but many sites that use the JS SDK aren't. The biggest difference between a refresh token and a non-expiring access token is that the refresh token needs to be verified by the authorization server only whereas the access token needs to be verified by the resource servers. --- Here is the rationale in Scalable OAuth Extension (http://wiki.oauth.net/w/page/12238549/ScalableOAuth#RationaleforRenewableAccessTokensSessions) which was a predecessor to OAuth WRAP and OAuth 2: Rationale for Renewable Access Tokens (Sessions) Many Service Providers have the concept of a Session credential with a finite lifetime. Consumers authenticate with the Service Provider's Authentication Service to obtain a Session credential to access the Service Provider's protected resources. When the Session credential expires, the consumer is able to obtain a new Session credential by re-authenticating with the Authentication service. The primary benefit to this architecture is that Session credentials do not need to be revocable if they expire quickly, and that protected resources can be returned without a database lookup to verify that the consumer is still authorized. Rationale for Auth Session (aka Refresh Secret) Service Providers often run their Authentication Service separately from other protected resources. The Authentication Service is usually strictly monitored and controlled, while other Protected Resources may be running relatively new and unproven code. In the event that a Protected Resource is compromised (the SP gets hacked), it is desirable to prevent the intruder from being able to continue to compromise the system after the vulnerability has been fixed. Issuing credentials with a finite lifetime limits the duration that the intruder can continue to use compromised credentials. Issuing a credential to a Consumer that is not known by the Protected Resource but is known by the Authentication Service can enable an Service Provider to revoke access to an intruder without requiring consumers to be reauthorized. -- Another related issue with Native Apps like iPhone Apps that can't be shipped with a client secret is the end user's expectation to stay logged in. On May 31, 2011, at 7:12 PM, Doug Tangren wrote: offline_access permission. If I read that right, that says the user has to opt into the access_token not expiring. I believe this may be the smarted solution for now because it uses the scope parameter to gain this additional access which is using the actual protocol parameters as intended instead of hacking around them. ___ 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] Text for Native Applications
On Tue, May 31, 2011 at 11:41 PM, Chuck Mortimore cmortim...@salesforce.com wrote: It’s not entirely necessary; I’m just having a tough time figuring out any practical difference between the implicit grant flow, and the webserver flow with no credentials. In general I agree with your points, but I think we have a similar, perhaps worse, scenario with relaxing the need for credentials on the web server flow. No doubt. =) I think it's unfortunate that the spec was changed to make the client credentials optional for the web server flow. As you say, it's a security problem for web apps. We are treating the client secret as mandatory in our deployments, and basically everyone who deploys the web server flow should do the same. It's a shame the spec is so vague on this point. The root cause of the spec ambiguity was disagreement over how to handle secrets for installed applications. I can think of three paths forward. - split out installed app flow from web server flow. Use a new grant type. (DON'T switch installed apps to use the implicit grant type. That doesn't work either, because it doesn't return a long-lived credential. DON'T have the implicit grant type return a refresh token directly, either, since that causes serious security problems for real web apps that can keep client secrets.) - make the client secret mandatory, but tell people who are offended by client secrets in installed apps to use the string notasecret for all installed apps. - ignore the problem and leave the spec vague and insecure. In terms of your example, wouldn’t basic XSRF protection in the state param protect? Nope. Assume the following scenario: - bad guy has stolen refresh token - client web server has detected attack and changed their client secret - bad guy wants to find a way to keep using the refresh token If refresh tokens are returned without client authentication, the bad guy can do it as follows: - visit client. log in as account badguy1234. - client redirects to authorization server, including state=1234 - bad guy ignores redirect to authorization server, visits client callback server with refresh_token=stolenstate=1234 - client picks up stolen refresh token and associates it with badguy1234. - whenever badguy1234 visits the client web site, he can see data from the stolen refresh token. Cheers, Brian ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Text for Native Applications
I'm getting confused. This thread is about native apps. So why discuss security considerations for web apps here? regards, Torsten. Am 01.06.2011 09:00, schrieb Brian Eaton: On Tue, May 31, 2011 at 11:47 PM, Kris Seldenkris.sel...@gmail.com wrote: If a provider chooses to do that though, in the attack you described, they could still revoke the refresh token to stop the abuse when it is discovered, and that is still easier in my opinion than rotating a client secret but yes, allowing that does make the client secret pointless for refreshing tokens. The attack I am describing is against a web server, so what you are saying is not true. We should talk about installed apps (no real client secret) differently than we talk about web servers. They are different problems. ___ 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] Fwd: issues with token age element - MAC token
Provider: api.megaworld.com Software Program: A universal binary iOS app called MegaWorld for iOS Client ID: mega_app User: Frankie in London Username: frankie_uk Device A: Frankie's iPhone Device B: Frankie's iPad Now imagine MegaWorld for iOS installed on device A B. Client ID is the same across the two devices. - Frankie uses device A to authorize his iPhone to allow MegaWorld for iOS to access his account (frankie_uk) - Device A is issued MAC token with ID: 89ARC at UTC time 1306911549. Time on device A is 1306911444. - Frankie uses device B to authorize his iPhone to allow MegaWorld for iOS to access his account (frankie_uk) - Device B is issued MAC token with ID: 89ARC at UTC time 1306917830. Time on device B is 1275375611. The provider, mega_app, does not issue multiple tokens for the same grant request (scope, client_id). This simplifies provider implementation but also helps enforce the correct user UI with respect to credential control at http://megaworld.com/my/apps - that is, the provider can't accurately know if frankie_uk has authorized one software instance twice on the same device, or multiple software instances once each (across multiple devices). Thus, the my/apps UI shows one authorization for Megaworld for iOS and thus one option to de-authorize this client_id (and thus all installed instances of the single software program with ID mega_app). Regardless if age or timestamp is used, if the implementation for validating the time value is sequential (perhaps with some window of error) then one device will have all its OAuth requests rejected as soon as the other presents a request. If timestamps are used the one with the older clock (device B) is rejected. If age is used, the one with the highest value of time (in this case, the more correct client) will be rejected as age will be calculated to be smaller than device B with an incorrect clock. If you also consider the case where device A and B have the same value for current time (UTC time, let's say) then age fails for device B after device A submits a request since device B thinks the credential is younger than device A. Timestamp does not fail in this case (because clocks are already sync'd). Only when the timestamp is a unified standard like UTC can both device A and B both use token 89ARC. If client B has it's request rejected it can quickly check UTC from any reasonable source (including api.megaworld.com) to correct its clock. Even better, it can politely check the correct system time on a regular basis and cache the offset between UTC and device time. Though experience may show that many software developers don't currently do this clock correction, it is trivial to adopt as a best practice. (Many software developer also don't routinely review their software for security or stability vulnerabilities of any sort.) Certainly is nothing for the small percentage of well-written high-value clients such as Firefox, TweetDeck or any serious effort with even moderate distribution or engineering resources. skylar On Jun 1, 2011, at 8:36 AM, Eran Hammer-Lahav wrote: This is not true. The age value has to be monotonically increasing, but not necessarily unique. Really, any counter will do. The reason why timestamp isn't any better than age or sequence is because ultimately, it is the server's memory restriction which determines the nonces storage size, not anything else (like a time limit). ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Text for Native Applications
On Wed, Jun 1, 2011 at 12:08 AM, Chuck Mortimore cmortim...@salesforce.com wrote: This is one reason we’ve favored implicit for native apps. OK, so are you using the implicit grant for both web apps and native apps...? I'm trying to figure out if you need two flows are three. - web server flow used with real secret client credentials gives out long-lived tokens - native app flow doesn't have real secret client credentials gives out long-lived tokens - implicit flow for javascript apps gives out short-lived tokens based on callback URLs (We need all three of those flows, BTW, plus at some point we'll get around to implementing a javascript flow that returns authorization codes, and a web server flow that provides short-lived credentials... but those are lower priority.) ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Text for Native Applications
On Wed, Jun 1, 2011 at 12:15 AM, Torsten Lodderstedt tors...@lodderstedt.net wrote: I'm getting confused. This thread is about native apps. So why discuss security considerations for web apps here? They overlap because they both use refresh tokens. =/ When people propose changes that impact refresh tokens, it impacts both flows and we need to be careful it doesn't create new problems. For example: Chuck proposed returning a refresh token on the implicit grant type, for use by native apps. That would screw up the security considerations for javascript web apps that rely on the implicit grant type. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
-Original Message- From: Skylar Woodward [mailto:sky...@kiva.org] Sent: Wednesday, June 01, 2011 12:16 AM To: Eran Hammer-Lahav Cc: Adam Barth; OAuth WG Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token Provider: api.megaworld.com Software Program: A universal binary iOS app called MegaWorld for iOS Client ID: mega_app User: Frankie in London Username: frankie_uk Device A: Frankie's iPhone Device B: Frankie's iPad Now imagine MegaWorld for iOS installed on device A B. Client ID is the same across the two devices. This is broken. You are using MAC for client authentication, but your client is a native application which should not have a secret... - Frankie uses device A to authorize his iPhone to allow MegaWorld for iOS to access his account (frankie_uk) - Device A is issued MAC token with ID: 89ARC at UTC time 1306911549. Time on device A is 1306911444. - Frankie uses device B to authorize his iPhone to allow MegaWorld for iOS to access his account (frankie_uk) - Device B is issued MAC token with ID: 89ARC at UTC time 1306917830. Time on device B is 1275375611. When you say issued, you mean MAC credentials (access token) or client credentials? EHL The provider, mega_app, does not issue multiple tokens for the same grant request (scope, client_id). This simplifies provider implementation but also helps enforce the correct user UI with respect to credential control at http://megaworld.com/my/apps - that is, the provider can't accurately know if frankie_uk has authorized one software instance twice on the same device, or multiple software instances once each (across multiple devices). Thus, the my/apps UI shows one authorization for Megaworld for iOS and thus one option to de-authorize this client_id (and thus all installed instances of the single software program with ID mega_app). Regardless if age or timestamp is used, if the implementation for validating the time value is sequential (perhaps with some window of error) then one device will have all its OAuth requests rejected as soon as the other presents a request. If timestamps are used the one with the older clock (device B) is rejected. If age is used, the one with the highest value of time (in this case, the more correct client) will be rejected as age will be calculated to be smaller than device B with an incorrect clock. If you also consider the case where device A and B have the same value for current time (UTC time, let's say) then age fails for device B after device A submits a request since device B thinks the credential is younger than device A. Timestamp does not fail in this case (because clocks are already sync'd). Only when the timestamp is a unified standard like UTC can both device A and B both use token 89ARC. If client B has it's request rejected it can quickly check UTC from any reasonable source (including api.megaworld.com) to correct its clock. Even better, it can politely check the correct system time on a regular basis and cache the offset between UTC and device time. Though experience may show that many software developers don't currently do this clock correction, it is trivial to adopt as a best practice. (Many software developer also don't routinely review their software for security or stability vulnerabilities of any sort.) Certainly is nothing for the small percentage of well-written high-value clients such as Firefox, TweetDeck or any serious effort with even moderate distribution or engineering resources. skylar On Jun 1, 2011, at 8:36 AM, Eran Hammer-Lahav wrote: This is not true. The age value has to be monotonically increasing, but not necessarily unique. Really, any counter will do. The reason why timestamp isn't any better than age or sequence is because ultimately, it is the server's memory restriction which determines the nonces storage size, not anything else (like a time limit). ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Text for Native Applications
On 6/1/11 12:20 AM, Brian Eaton bea...@google.com wrote: On Wed, Jun 1, 2011 at 12:15 AM, Torsten Lodderstedt tors...@lodderstedt.net wrote: I'm getting confused. This thread is about native apps. So why discuss security considerations for web apps here? They overlap because they both use refresh tokens. =/ When people propose changes that impact refresh tokens, it impacts both flows and we need to be careful it doesn't create new problems. For example: Chuck proposed returning a refresh token on the implicit grant type, for use by native apps. That would screw up the security considerations for javascript web apps that rely on the implicit grant type. Not entirely what I'm suggesting, but looking back I wasn't clear. My Bad. See my description of what we currently support that I just sent. -cmort ___ 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] Text for Native Applications
Am 01.06.2011 08:56, schrieb Brian Eaton: On Tue, May 31, 2011 at 11:41 PM, Chuck Mortimore cmortim...@salesforce.com wrote: It’s not entirely necessary; I’m just having a tough time figuring out any practical difference between the implicit grant flow, and the webserver flow with no credentials. In general I agree with your points, but I think we have a similar, perhaps worse, scenario with relaxing the need for credentials on the web server flow. No doubt. =) I think it's unfortunate that the spec was changed to make the client credentials optional for the web server flow. As you say, it's a security problem for web apps. We are treating the client secret as mandatory in our deployments, and basically everyone who deploys the web server flow should do the same. It's a shame the spec is so vague on this point. The root cause of the spec ambiguity was disagreement over how to handle secrets for installed applications. I can think of three paths forward. - split out installed app flow from web server flow. Use a new grant type. (DON'T switch installed apps to use the implicit grant type. That doesn't work either, because it doesn't return a long-lived credential. DON'T have the implicit grant type return a refresh token directly, either, since that causes serious security problems for real web apps that can keep client secrets.) So far every grant type represented a different protocol flow (not client type). Why do you want to define different grant types for basically the same flow but different client identification/authentication policies? What if a service provider is able to securely deploy instance-specific secrets to its native apps (e.g. in intranet scenarios - see Chuck's posting). Shall it use the web server flow then? The current text keeps client authentication and the grant type orthogonal. I would suggest to stick to this approach. - make the client secret mandatory, but tell people who are offended by client secrets in installed apps to use the string notasecret for all installed apps. How is that any different from just not using a secret from a security perspective? - ignore the problem and leave the spec vague and insecure. Could you please describe what you consider insecure? I think we have the challenge to defining a secure protocol while supporting the needs of different client types. Past versions of the spec entirely focused on client secrets as mechanism to validate a client's identity. This created the false impression that native apps either 1) must use the implicit grant type (which does not support refresh tokens), or 2) use the authz code grant type in conjunction with a (weakly/none protected) secret in order to comply with the text of the specification. 3) It is also interesting to note that people have started to think OAuth does not support native apps! (1) results in a sub-optimal user experience since the app has to go through the (interactive) authz cycle with every startup or the authz server issues long-living a access tokens (?) or (even worse) the authz server automatically issue access tokens for sub-sequent requests by the same client (how to determine same?). (2) creates a _false_ impression of security because the authz server authenticated the clients. But the authorization server _must not_ rely on such a secret for validating the client's identity. The security consideration section clearly states this now. regards, Torsten. In terms of your example, wouldn’t basic XSRF protection in the state param protect? Nope. Assume the following scenario: - bad guy has stolen refresh token - client web server has detected attack and changed their client secret - bad guy wants to find a way to keep using the refresh token If refresh tokens are returned without client authentication, the bad guy can do it as follows: - visit client. log in as account badguy1234. - client redirects to authorization server, including state=1234 - bad guy ignores redirect to authorization server, visits client callback server with refresh_token=stolenstate=1234 - client picks up stolen refresh token and associates it with badguy1234. - whenever badguy1234 visits the client web site, he can see data from the stolen refresh token. Cheers, Brian ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Text for Native Applications
OK, so you've got some native apps using the web server flow, and some using a modified version of the implicit grant that includes a refresh token. I hate to say it, but I think this whole thing would be a lot simpler if we had a grant type called native app. Instead everyone is adding unspecified parameters or making parameters optional so that they can support native apps properly. On Wed, Jun 1, 2011 at 12:41 AM, Chuck Mortimore cmortim...@salesforce.com wrote: We have have need for all three types For web apps, we use web server flow with credentials, and can escalate some capabilities for the client since we can be more assured we’re talking to the actual client. For native apps, we support: the implicit grant ( but we wont give out a refresh token to web/js based applications ) the web server flow with a user+client_id specific secret which we can issue through an admin controlled provisioning process. In this case we can also escalate capabilities as we’re reasonably sure we’re talking to an instance of the client. For JS Apps we support the implicit grant with no refresh token -cmort On 6/1/11 12:16 AM, Brian Eaton bea...@google.com wrote: On Wed, Jun 1, 2011 at 12:08 AM, Chuck Mortimore cmortim...@salesforce.com wrote: This is one reason we’ve favored implicit for native apps. OK, so are you using the implicit grant for both web apps and native apps...? I'm trying to figure out if you need two flows are three. - web server flow used with real secret client credentials gives out long-lived tokens - native app flow doesn't have real secret client credentials gives out long-lived tokens - implicit flow for javascript apps gives out short-lived tokens based on callback URLs (We need all three of those flows, BTW, plus at some point we'll get around to implementing a javascript flow that returns authorization codes, and a web server flow that provides short-lived credentials... but those are lower priority.) ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Section 10.1 (Client authentication)
Hi Eran, would you please add the following sentence (which was contained in the original security considerations text) to the second paragraph of section 1.0.1? Alternatively, authorization servers MUST utilize other means than client authentication to achieve their security objectives. I think it's important to state that authorization server should consider alternative way to validate the client identity if secrets cannot be used. The security threat document also suggest some. regards, Torsten. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
-Original Message- From: Skylar Woodward [mailto:sky...@kiva.org] Sent: Wednesday, June 01, 2011 12:16 AM To: Eran Hammer-Lahav Cc: Adam Barth; OAuth WG Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token Provider: api.megaworld.com Software Program: A universal binary iOS app called MegaWorld for iOS Client ID: mega_app User: Frankie in London Username: frankie_uk Device A: Frankie's iPhone Device B: Frankie's iPad Now imagine MegaWorld for iOS installed on device A B. Client ID is the same across the two devices. This is broken. You are using MAC for client authentication, but your client is a native application which should not have a secret... No, I had two use cases to discuss. One of access tokens being re-issued and the other of client credentials. Token re-issue seemed easier to explain because it is the more common case of device conflict. The issues with client credentials are minimized with the algorithm for nonce expiration that Adam suggested (sequential) which was not clear as a suggestion by the spec. I could outline a problem with age for client credentials which use the flagged as old algorithm, but this seems less important now if we assume sequential with a window of tolerance as the algorithm for invalidation. However, there are possible cases where two software instances use the same client credential (and where it's still possible to secure the secret). Most of those cases are ones where the software distribution is protected inside a controlled network. A few examples (not common across OAuth, though some of these will be popular for providers like Kiva where its customers deploy proprietary software inside controlled intranets where secrets can be protected from the public even in native apps): - Great State University makes an app for managing student grading. This app is distributed to all faculty iPhones using the Apple Enterprise Deployment system. GSU expects faculty not to share the installed software with non-faculty or to use jail-broken phones -- doing so is a violation of school code of ethics. GSU makes the case that the client credentials in the grading app are securable with reasonable deployment and legal protections in place. All installs of the app onto faculty iPhones use the same client credential. They use the client credential as an additional hurdle to protect against forged clients trying to authorize. - Green Microlender makes an app for submitting loan data to Kiva that also interfaces with their local MIS system. This is a Visual Basic program installed on Windows PCs throughout field offices in southern Uganda which each on the organization's protected VLAN (or multiple protected LANs). This program is deployed by IT staff only onto these devices. They choose to use client credentials in this program as they feel comfortable in asserting that the client secrets are protected adequately by Green Microlender. - MegaWorld Tracker deploys websites in France and the US. They set up different instances of their website program in servers in France and the US. Each deployment is configured with the same MegaWorld OAuth client ID since it is the same program, but different locale settings to make the software render text in French or English, respectively. Since MegaWorld Tracker isn't a huge corp, they've haven't put in place measures to sync user's access tokens between the French servers and the US servers. This means a user that hits both the FR server and the US server will have to authenticate twice to megaworld.com (and thus access tokens issued to each server install). Since they also didn't bother to register two client IDs (mw_tracker instead of mw_tracker_us and mw_tracker_fr) they essentially have two installs using the same client credentials. It's a reasonable gray area. I do admit these won't be en masse in the grand collective of all deployed OAuth v2 apps, but they are reasonable use cases, and for some organizations, very important use cases. - Frankie uses device A to authorize his iPhone to allow MegaWorld for iOS to access his account (frankie_uk) - Device A is issued MAC token with ID: 89ARC at UTC time 1306911549. Time on device A is 1306911444. - Frankie uses device B to authorize his iPhone to allow MegaWorld for iOS to access his account (frankie_uk) - Device B is issued MAC token with ID: 89ARC at UTC time 1306917830. Time on device B is 1275375611. When you say issued, you mean MAC credentials (access token) or client credentials? these are access tokens EHL The provider, mega_app, does not issue multiple tokens for the same grant request (scope, client_id). This simplifies provider implementation but also helps enforce the correct user UI with respect to credential control at http://megaworld.com/my/apps - that is, the provider can't accurately know if frankie_uk has authorized one software
Re: [OAUTH-WG] Draft 16 Security Considerations additions
Hi Mark, Am 31.05.2011 22:58, schrieb Mark Mcgloin: Eran Here are some additional sections to add to the next draft under security considerations CSRF Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from a user that the website trusts or has authenticated. CSRF attacks on OAuth approvals can allow an attacker to obtain authorization to OAuth Protected Resources without the consent of the User. The state parameter should be used to mitigate against CSRF attacks, particularly for login CSRF attacks. It is strongly RECOMMENDED that the client sends the state parameter with authorization requests to the authorization server. The authorization server will send it in the response when redirecting the user to back to the client which SHOULD then validate the state parameter matches on the response. As far as I understand, the goal of the countermeasure is to bind the authz flow to a certain user agent (instance). So client must verify that the state parameter (or any other URL parameter?) matches some data found in the user agent itself before further processing the authz code. Breno explained it 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. I would suggest to incorporate this into the decription: It is strongly RECOMMENDED that the client sends the state parameter with authorization requests to the authorization server. _The state parameter MUST refer to a secret value retained at the user agent._ The authorization server will send the _state parameter_ in the response when redirecting the user to back to the client which _MUST_ then validate the state parameter_'s value against the secret value in the user agent_. regards, Torsten. Clickjacking Clickjacking is the process of tricking users into revealing confidential information or taking control of their computer while clicking on seemingly innocuous web pages. In more detail, a malicious site loads the target site in a transparent iframe overlaid on top of a set of dummy buttons which are carefully constructed to be placed directly under important buttons on the target site. When a user clicks a visible button, they are actually clicking a button (such as an Authorize button) on the hidden page. To prevent clickjacking (and phishing attacks), native applications SHOULD use external browsers instead of embedding browsers in an iFrame when requesting end-user authorization. For newer browsers, avoidance of iFrames can be enforced server side by using the X-FRAME-OPTION header. This header can have two values, deny and sameorigin, which will block any framing or framing by sites with a different origin, respectively. For older browsers, javascript framebusting techniques can be used but may not be effective in all browsers. Regards Mark ___ 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] Text for Native Applications
On Wed, Jun 1, 2011 at 12:47 AM, Torsten Lodderstedt tors...@lodderstedt.net wrote: - ignore the problem and leave the spec vague and insecure. Could you please describe what you consider insecure? As an example, optional client authentication in the authorization code flow makes the web server flow much less secure. But it's permitted by the spec. The confusion you mention about how to support native apps is also going to create security problems. You mentioned the risks of auto-approving token requests from native apps. I think we have the challenge to defining a secure protocol while supporting the needs of different client types. +1 to that. Past versions of the spec entirely focused on client secrets as mechanism to validate a client's identity. This created the false impression that native apps either... snip analysis of the consequences of the spec language and how the security considerations tries to fix the spec I think your efforts to clear this up in the security considerations are so admirable that they should move into the main body of the spec instead. =) In particular, I think the spec should say that: - native apps always use the authorization code grant - if authorization servers are comfortable issuing client secrets to native apps, they may do so - if authorization servers are not comfortable issuing client secrets to installed apps, they may use a blank or well-known client secret. That would let us simplify the authorization code protocol and the refresh token protocol, since parameters would move from sometimes-they-are-required-sometimes-not to being required. It would also let us have a clear direction to point people who want to support native apps. And it would meet the requirement of having a clear path forward for people who don't want to trust native apps to keep secrets really secret. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Text for Native Applications
On Jun 1, 2011, at 10:18 AM, Brian Eaton wrote: And it would meet the requirement of having a clear path forward for people who don't want to trust native apps to keep secrets really secret. I just want to re-iterate my point from a few months ago that it necessarily helpful to draw the line for secret protection between native and non-native apps. For our users we're going to use the terms VERIFIABLE and FORGEABLE with respect to client identity. We'll help users determine if the can keep secrets or not. Developers who understand they can't keep secrets will understand their app identity to be forgeable (and thus they will not be issued secrets). Most native apps will be forgeable thus we'll point them in this direction, but there will be exceptions (especially with partners with protected app distribution). My point is, we should focus on having developers understand if and why their app can't keep secrets, not merely thinking oh, this is app is native so I have to do it this way. Verifyable and Forgeable were the best terms we've come up with so far in attempt to put a label on apps that can keep secrets and apps that can't keep secrets, respectively. There are some aspects of OAuth flow that are unique to native apps (mostly on account of the app not executing in a user agent), but ability to keep secrets is not a property shared or exclusive to all native apps. (Some web apps might not be able to keep secrets based on open development or deployment model). ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [apps-discuss] HTTP MAC Authentication Scheme
Just on DOSETA - that's not currently got any official home in the IETF so its not something that would be right to reference at this point (unless the oauth WG wanted to adopt DOSETA but I'd be very surprised if that were the case for timing reasons). However I do agree that keeping in mind that folks may move towards something like DOESTA in future is a good plan. To be clear, as an individual, I do think that something like DOSETA is a really good idea and maybe DOSETA will turn out to be that something, I don't know. S. On 01/06/11 00:57, Mark Nottingham wrote: Hi, Reading draft -05. The normalized request string contains the request-URI and values extracted from the Host header. Be aware that intermediaries can and do change these; e.g., they may change an absolute URI to a relative URI in the request-line, without affecting the semantics of the request. See [1] for details (it covers other problematic conditions too). It would be more robust to calculate an effective request URI, as in [2]. Also, if you include a hash of the request body, you really need to include a hash of the body media type. Generally, I think that people can and will want to include other headers; just because *some* developers can't get this right doesn't mean we should preclude *all* developers from doing it. It'd be really nice to see this either leverage DOSETA [3][4], or at least offer a clean transition path to it. Regards, 1. http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-4.1.2 2. http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-4.3 3. http://tools.ietf.org/html/draft-crocker-dkim-doseta-00 4. http://tools.ietf.org/html/draft-crocker-doseta-base-02 On 10/05/2011, at 5:22 AM, Eran Hammer-Lahav wrote: (Please discuss this draft on the Apps-Discuss apps-disc...@ietf.org mailing list) http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token The draft includes: * An HTTP authentication scheme using a MAC algorithm to authenticate requests (via a pre-arranged MAC key). * An extension to the Set-Cookie header, providing a method for associating a MAC key with a session cookie. * An OAuth 2.0 binding, providing a method of returning MAC credentials as an access token. Some background: OAuth 1.0 introduced an HTTP authentication scheme using HMAC for authenticating an HTTP request with partial cryptographic protection of the HTTP request (namely, the request URI, host, and port). The OAuth 1.0 scheme was designed for delegation-based use cases, but is widely “abused” for simple client-server authentication (the poorly named ‘two-legged’ use case). This functionality has been separated from OAuth 2.0 and has been reintroduced as a standalone, generally applicable HTTP authentication scheme called MAC. Comments and feedback is greatly appreciated. EHL ___ apps-discuss mailing list apps-disc...@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ ___ apps-discuss mailing list apps-disc...@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Fwd: issues with token age element - MAC token
Then all these clients sharing the same credentials will require clock sync (not a problem for cell phones usually, but can be for other devices). But if you are implementing OAuth 2.0, the request including client authentication is made over TLS (as required) and so replay isn't much of a concern. If for some reason you are not using TLS alongside client authentication for obtaining an access token, this particular use case becomes out of scope. EHL -Original Message- From: Skylar Woodward [mailto:sky...@kiva.org] Sent: Wednesday, June 01, 2011 1:06 AM To: Eran Hammer-Lahav Cc: Adam Barth; OAuth WG Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token -Original Message- From: Skylar Woodward [mailto:sky...@kiva.org] Sent: Wednesday, June 01, 2011 12:16 AM To: Eran Hammer-Lahav Cc: Adam Barth; OAuth WG Subject: Re: [OAUTH-WG] Fwd: issues with token age element - MAC token Provider: api.megaworld.com Software Program: A universal binary iOS app called MegaWorld for iOS Client ID: mega_app User: Frankie in London Username: frankie_uk Device A: Frankie's iPhone Device B: Frankie's iPad Now imagine MegaWorld for iOS installed on device A B. Client ID is the same across the two devices. This is broken. You are using MAC for client authentication, but your client is a native application which should not have a secret... No, I had two use cases to discuss. One of access tokens being re-issued and the other of client credentials. Token re-issue seemed easier to explain because it is the more common case of device conflict. The issues with client credentials are minimized with the algorithm for nonce expiration that Adam suggested (sequential) which was not clear as a suggestion by the spec. I could outline a problem with age for client credentials which use the flagged as old algorithm, but this seems less important now if we assume sequential with a window of tolerance as the algorithm for invalidation. However, there are possible cases where two software instances use the same client credential (and where it's still possible to secure the secret). Most of those cases are ones where the software distribution is protected inside a controlled network. A few examples (not common across OAuth, though some of these will be popular for providers like Kiva where its customers deploy proprietary software inside controlled intranets where secrets can be protected from the public even in native apps): - Great State University makes an app for managing student grading. This app is distributed to all faculty iPhones using the Apple Enterprise Deployment system. GSU expects faculty not to share the installed software with non- faculty or to use jail-broken phones -- doing so is a violation of school code of ethics. GSU makes the case that the client credentials in the grading app are securable with reasonable deployment and legal protections in place. All installs of the app onto faculty iPhones use the same client credential. They use the client credential as an additional hurdle to protect against forged clients trying to authorize. - Green Microlender makes an app for submitting loan data to Kiva that also interfaces with their local MIS system. This is a Visual Basic program installed on Windows PCs throughout field offices in southern Uganda which each on the organization's protected VLAN (or multiple protected LANs). This program is deployed by IT staff only onto these devices. They choose to use client credentials in this program as they feel comfortable in asserting that the client secrets are protected adequately by Green Microlender. - MegaWorld Tracker deploys websites in France and the US. They set up different instances of their website program in servers in France and the US. Each deployment is configured with the same MegaWorld OAuth client ID since it is the same program, but different locale settings to make the software render text in French or English, respectively. Since MegaWorld Tracker isn't a huge corp, they've haven't put in place measures to sync user's access tokens between the French servers and the US servers. This means a user that hits both the FR server and the US server will have to authenticate twice to megaworld.com (and thus access tokens issued to each server install). Since they also didn't bother to register two client IDs (mw_tracker instead of mw_tracker_us and mw_tracker_fr) they essentially have two installs using the same client credentials. It's a reasonable gray area. I do admit these won't be en masse in the grand collective of all deployed OAuth v2 apps, but they are reasonable use cases, and for some organizations, very important use cases. - Frankie uses device A to authorize his iPhone to allow MegaWorld for iOS to access his account (frankie_uk) - Device A is issued MAC token with ID: 89ARC
Re: [OAUTH-WG] Text for Native Applications
- native apps always use the authorization code grant I don't like this if it means I can't use passwrd grant for stuff like IMAP clients. From: Brian Eaton bea...@google.com To: Torsten Lodderstedt tors...@lodderstedt.net Cc: oauth@ietf.org oauth@ietf.org Sent: Wednesday, June 1, 2011 1:18 AM Subject: Re: [OAUTH-WG] Text for Native Applications On Wed, Jun 1, 2011 at 12:47 AM, Torsten Lodderstedt tors...@lodderstedt.net wrote: - ignore the problem and leave the spec vague and insecure. Could you please describe what you consider insecure? As an example, optional client authentication in the authorization code flow makes the web server flow much less secure. But it's permitted by the spec. The confusion you mention about how to support native apps is also going to create security problems. You mentioned the risks of auto-approving token requests from native apps. I think we have the challenge to defining a secure protocol while supporting the needs of different client types. +1 to that. Past versions of the spec entirely focused on client secrets as mechanism to validate a client's identity. This created the false impression that native apps either... snip analysis of the consequences of the spec language and how the security considerations tries to fix the spec I think your efforts to clear this up in the security considerations are so admirable that they should move into the main body of the spec instead. =) In particular, I think the spec should say that: - native apps always use the authorization code grant - if authorization servers are comfortable issuing client secrets to native apps, they may do so - if authorization servers are not comfortable issuing client secrets to installed apps, they may use a blank or well-known client secret. That would let us simplify the authorization code protocol and the refresh token protocol, since parameters would move from sometimes-they-are-required-sometimes-not to being required. It would also let us have a clear direction to point people who want to support native apps. And it would meet the requirement of having a clear path forward for people who don't want to trust native apps to keep secrets really secret. ___ 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] Text for Native Applications
On Wed, Jun 1, 2011 at 1:41 AM, Skylar Woodward sky...@kiva.org wrote: Verifyable and Forgeable were the best terms we've come up with so far in attempt to put a label on apps that can keep secrets and apps that can't keep secrets, respectively. You might be on to something there. There are two ways clients are authenticated in the spec. - client credentials - registered callback URLs People are combining them in interesting ways. And there is stuff outside the spec, such as the app-to-app authentication built into smart phone platforms. (This is used heavily in the facebook developer platform. We use it on Android, not on iPhone yet.) I haven't tried it yet, but I suspect organizing the security considerations based on how your client authenticates would be constructive. (Some web apps might not be able to keep secrets based on open development or deployment model). Can you clarify what you mean by this? What flows are you using for those apps? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Text for Native Applications
Most native apps will be forgeable ... I don't understand the rationale behind this assertion. Would you please point me to the discussion that elaborates on this point. Thanks! Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
Hey Peter - I haven't read all of your comments yet, but I wanted to clarify one point about client impersonation and installed apps. The cuirrent text is unrealistic, but your request would push it the wrong way. CC'ing Torsten as well. - OLD: The authorization server SHOULD issue access tokens with limited scope and duration to clients incapable of authenticating. NEW: If the authorization server issues access tokens to clients that are incapable of authenticating, the scope and duration of such tokens SHOULD be limited. RATIONALE: We're not actively RECOMMENDING authorization servers are to issue such tokens, are we? - We are most definitely recommending that clients that have no way of authenticating are issued long-lived credentials to access user data. Most installed applications work as follows: - they ask the user for their password - they save the password to disk That's a horrible security problem, because it means you cannot upgrade user authentication to anything stronger than a password. Client certificates, one time passwords, risk based authentication, throw it all out the window. If you're going to let installed apps authenticate with just a password, nothing else you do to improve authentication is going to help. This is a blocking issue for rolling out stronger forms of user authentication, and it's one of the main reasons I care about OAuth2. Think IMAP and XMPP clients running on Windows desktops. They are important, and we need a way to migrate them off of saving passwords. So the current text basically says that you should issue temporary credentials to native apps. That's not practical. Native apps end up needing permanent or near-permanent credentials. Expirations need to be measured in months. And the credentials are going to be issued to stock IMAP and XMPP clients that don't have any way of authenticating themselves. The advantage with OAuth2 over passwords is that a) the refresh tokens are unguessable. b) the refresh tokens aren't sent directly to the IMAP and XMPP servers, they are restricted to authorization servers. c) if you've got a managed machine (think Kerberos logins), you can create flows that bridge from those managed credentials to temporary access credentials. Cheers, Brian ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Text for Native Applications
On Jun 1, 2011, at 6:54 PM, Brian Eaton wrote: (Some web apps might not be able to keep secrets based on open development or deployment model). Can you clarify what you mean by this? Simple really, I just mean for some developers it might be more important to have an open development model (eg, over github) than to secure secrets. Rather than request and manage a secret for their project, they just choose to make the project a forgeable app. Let's say it's a Rails app deployed to Heroku and for convenience the team doesn't want to add a build step where a protected secret is brought down from a private repo. It's not a native app, but because of how the team works they can't (or won't) secure a secret. What's in production is exactly whats in a public github branch. Systems like Heroku are blurring the line between source control and deployment. So you can imagine 3rd party apps, especially voluntary contributions and hack day output being totally transparent from code to server. For some web apps it just won't be a priority to secure a secret. That's all I'm implying. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Draft 16 Security Considerations additions
Hi William Agree it is a good definition but I am not sure we need to spell out more details as we are trying to keep this section tight. Developers can look up CSRF if they are unsure. However, I will add the example of how it can happen Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from a user that the website trusts or has authenticated _(e.g., via HTTP redirects or HTML forms)_. CSRF attacks on OAuth approvals can allow an attacker to obtain authorization to OAuth Protected Resources without the consent of the User. Regards Mark William J. Mills wmi...@yahoo-inc.com wrote on 01/06/2011 00:17:44: From: William J. Mills wmi...@yahoo-inc.com To: Mark Mcgloin/Ireland/IBM@IBMIE, oauth@ietf.org oauth@ietf.org Date: 01/06/2011 00:17 Subject: Re: [OAUTH-WG] Draft 16 Security Considerations additions http://tools.ietf.org/html/rfc6265#section-8.2 has good text on CSRF definition, which I think is clearer. Perhaps that can be used to touch up your first paragraph? From: Mark Mcgloin mark.mcgl...@ie.ibm.com To: oauth@ietf.org Sent: Tuesday, May 31, 2011 1:58 PM Subject: [OAUTH-WG] Draft 16 Security Considerations additions Eran Here are some additional sections to add to the next draft under security considerations CSRF Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from a user that the website trusts or has authenticated. CSRF attacks on OAuth approvals can allow an attacker to obtain authorization to OAuth Protected Resources without the consent of the User. The state parameter should be used to mitigate against CSRF attacks, particularly for login CSRF attacks. It is strongly RECOMMENDED that the client sends the state parameter with authorization requests to the authorization server. The authorization server will send it in the response when redirecting the user to back to the client which SHOULD then validate the state parameter matches on the response. Clickjacking Clickjacking is the process of tricking users into revealing confidential information or taking control of their computer while clicking on seemingly innocuous web pages. In more detail, a malicious site loads the target site in a transparent iframe overlaid on top of a set of dummy buttons which are carefully constructed to be placed directly under important buttons on the target site. When a user clicks a visible button, they are actually clicking a button (such as an Authorize button) on the hidden page. To prevent clickjacking (and phishing attacks), native applications SHOULD use external browsers instead of embedding browsers in an iFrame when requesting end-user authorization. For newer browsers, avoidance of iFrames can be enforced server side by using the X-FRAME-OPTION header. This header can have two values, deny and sameorigin, which will block any framing or framing by sites with a different origin, respectively. For older browsers, javascript framebusting techniques can be used but may not be effective in all browsers. Regards Mark ___ 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] Text for Native Applications
The group is operating under the assumption that most native apps are publicly deployed or that copies of the app bundle/binary can at least be obtained by a malicious party. Whether and open system or a high protected system like Playstation 3 its always possible for the attacker to disassemble the program and obtain the secret. The secret is the key to an app proving its identity, so as soon as an attacker obtains the secret it can forge the identity of an app in so far as the OAuth auth server is concerned. On Jun 1, 2011, at 7:17 PM, Dave Nelson wrote: Most native apps will be forgeable ... I don't understand the rationale behind this assertion. Would you please point me to the discussion that elaborates on this point. Thanks! Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Text for Native Applications
The group is operating under the assumption that most native apps are publicly deployed or that copies of the app bundle/binary can at least be obtained by a malicious party. Agreed. ... its always possible for the attacker to disassemble the program and obtain the secret. Always possible? In theory, perhaps. As with any threat analysis, it depends on the resources available to the attacker and the motivations for mounting the attack. I firmly believe that secrets can be sufficiently obfuscated in code delivered in binary format without the benefit of a symbol table, so as to be sufficiently resistant to discovery via disassembly by attackers you'd expect to encounter in a typical commercial environment. I'm not talking about printable strings stored in contiguous memory. I think it's important, for a number of use cases, some of them of particular interest to me, for an application to be able to use this form of identification, when sufficient care has been taken to mitigate the threat model for the intended use. I'd rather see the risks inherent in providing secure storage of application credentials thoroughly discussed in the Security Considerations section, rather than discouraging it's use altogether in the normative protocol definition sections of the draft. I agree that there are many deployment scenarios in which secrets or passwords would not be an appropriate method of client identification, but I see some in which is clearly would be appropriate. Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Text for Native Applications
On Jun 1, 2011, at 9:43 PM, Dave Nelson wrote: for mounting the attack. I firmly believe that secrets can be sufficiently obfuscated in code delivered in binary format without the benefit of a symbol table, so as to be sufficiently resistant to discovery via disassembly by attackers you'd expect to encounter in a typical commercial environment. I'm not talking about printable I have empirical evidence to support this. At Yahoo! we devised one of the most complex systems I've ever seen in a publicly distributed program (Messenger). It was disassembled in 3 days. Scott Renfro (now over with David at Facebook) and likely Bill Mills can also vouch for the difficulty of this having also studied the case well. Moreover if a hardware-enforced system like that of Playstation 3 can be broken, then so can most systems. The PS3 protection mechanisms are/were very sophisticated. Even if a system is not yet cracked or is very hard, you have to assume it can be cracked. History has shown this to be true nearly without exception - at least to the point it is not worth considering for the OAuth use cases. skylar ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Getting the authorization code - Native Applications
I've read the latest spec and some of the discussions around the user-agent flow and native apps. I've read about the different options to get the authz code (copy-paste, polling the title of the window, custom scheme, etc). I might be missing something but my question is: why can't we send a nonce in the initial request to the authz server and have the client app polling an endpoint until the authz code is generated and associated to that nonce? Why that is not a possible approach to get the authz code in the native client? Is it because the authz server might get several requests during the app polling? Or I am missing some security issue (assuming this all goes through TLS)? Thanks, Matias ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
