Re: [OAUTH-WG] Dynamic Client Registration
Hi Eran, why do you see a relationship between dynamic client registration and discovery? Basically, we don't care so far how a client finds tokens and end-user authorization point. Why is this any different for the client registration endpoint (or the revocation endpoint)? Or do you have a bigger picture in mind? regards, Torsten. Am 15.04.2012 22:36, schrieb Eran Hammer: Where did I say I'm not interested in this work?! All I was saying is that it would be better to postpone it until the discovery layer, which this draft clearly relies upon, is a bit clearer. I would be satisfied with a simple note stating that if the discovery work at the APP area isn't complete, the WG may choose to delay work on this document until ready. EH -Original Message- From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] Sent: Sunday, April 15, 2012 9:01 AM To: Eran Hammer Cc: Hannes Tschofenig; oauth@ietf.org WG Subject: Re: [OAUTH-WG] Dynamic Client Registration Hi Eran, you are saying that you are not interested in the dynamic client registration work and that's OK. There are, however, a couple of other folks in the group who had expressed interest to work on it, to review and to implement it. Note also that the discovery and the dynamic client registration is different from each other; there is a relationship but they are nevertheless different. Ciao Hannes PS: Moving the Simple Web Discovery to the Apps area working group does not mean that it will not be done. On the contrary there will be work happing and we are just trying to figure out what the difference between SWD and WebFinger is. On Apr 15, 2012, at 9:14 AM, Eran Hammer wrote: I'd like to see 'Dynamic Client Registration' removed from the charter along with SWD for the sole reason that figuring out a generic discovery mechanism is going to take some time and this WG has enough other work to focus on while that happens elsewhere. I expect this to come back in the next round with much more deployment experience and discovery clarity. EH -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Friday, April 13, 2012 7:36 AM To: oauth@ietf.org WG Subject: [OAUTH-WG] Dynamic Client Registration Hi all, at the IETF#83 OAuth working group meeting we had some confusion about the Dynamic Client Registration and the Simple Web Discovery item. I just listened to the audio recording again. With the ongoing mailing list discussion regarding WebFinger vs. Simple Web Discovery I hope that folks had a chance to look at the documents again and so the confusion of some got resolved. I believe the proposed new charter item is sufficiently clear with regard to the scope of the work. Right? Here is the item again: Jul. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard [Starting point for the work will be http://tools.ietf.org/html/draft-hardjono-oauth-dynreg ] Of course there there is a relationship between Simple Web Discovery (or WebFinger) and the dynamic client registration since the client first needs to discover the client registration endpoint at the authorization server before interacting with it. Now, one thing that just came to my mind when looking again at draft- hardjono-oauth-dynreq was the following: Could the Client Registration Request and Response protocol exchange could become a profile of the SCIM protocol? In some sense this exchange is nothing else than provisioning an account at the Authorization Server (along with some meta-data). Is this too far fetched? Ciao Hannes ___ 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] Updated Charter to the IESG (this weekend)
Hi all, is there enough experience in the field with such an interface to standardize it? I would expect such an endpoint to return the same payload, which is carried in a JSON Web Token. So once we designed the JSON Web Tokens content, designing the AS-PR interface could be the next logical step (after the next re-charting). regards, Torsten. Am 16.04.2012 21:04, schrieb Justin Richer: OK, but with SWD and discovery off the table, can this now be considered to be within that manageable number instead? We wanted to keep the # of WG items to approximately 5. Once we finish some of these items and get them off our plate we could roll new items onto the plate, theoretically. That's definitely true going forward, but what I was saying is that the number of items under consideration is now down to 4, with SWD moving to the Apps group. I was proposing that the whole introspection endpoint and general AS-PR connection could be this group's fifth starting document. -- Justin ___ 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] Dynamic Client Registration
Hi Eran, thanks for pointing this out. I took a quick look on the document. Seems the I-D combines registration and discovery. I think both should be kept separat. So I would suggest to remove section 5 and the dependency is gone. regards, Torsten. Am 18.04.2012 21:51, schrieb Eran Hammer: Because it is in the draft the WG is suppose to consider. It's a stated dependency. EH -Original Message- From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Wednesday, April 18, 2012 12:50 PM To: Eran Hammer Cc: Hannes Tschofenig; oauth@ietf.org WG Subject: Re: [OAUTH-WG] Dynamic Client Registration Hi Eran, why do you see a relationship between dynamic client registration and discovery? Basically, we don't care so far how a client finds tokens and end- user authorization point. Why is this any different for the client registration endpoint (or the revocation endpoint)? Or do you have a bigger picture in mind? regards, Torsten. Am 15.04.2012 22:36, schrieb Eran Hammer: Where did I say I'm not interested in this work?! All I was saying is that it would be better to postpone it until the discovery layer, which this draft clearly relies upon, is a bit clearer. I would be satisfied with a simple note stating that if the discovery work at the APP area isn't complete, the WG may choose to delay work on this document until ready. EH -Original Message- From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] Sent: Sunday, April 15, 2012 9:01 AM To: Eran Hammer Cc: Hannes Tschofenig; oauth@ietf.org WG Subject: Re: [OAUTH-WG] Dynamic Client Registration Hi Eran, you are saying that you are not interested in the dynamic client registration work and that's OK. There are, however, a couple of other folks in the group who had expressed interest to work on it, to review and to implement it. Note also that the discovery and the dynamic client registration is different from each other; there is a relationship but they are nevertheless different. Ciao Hannes PS: Moving the Simple Web Discovery to the Apps area working group does not mean that it will not be done. On the contrary there will be work happing and we are just trying to figure out what the difference between SWD and WebFinger is. On Apr 15, 2012, at 9:14 AM, Eran Hammer wrote: I'd like to see 'Dynamic Client Registration' removed from the charter along with SWD for the sole reason that figuring out a generic discovery mechanism is going to take some time and this WG has enough other work to focus on while that happens elsewhere. I expect this to come back in the next round with much more deployment experience and discovery clarity. EH -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: Friday, April 13, 2012 7:36 AM To: oauth@ietf.org WG Subject: [OAUTH-WG] Dynamic Client Registration Hi all, at the IETF#83 OAuth working group meeting we had some confusion about the Dynamic Client Registration and the Simple Web Discovery item. I just listened to the audio recording again. With the ongoing mailing list discussion regarding WebFinger vs. Simple Web Discovery I hope that folks had a chance to look at the documents again and so the confusion of some got resolved. I believe the proposed new charter item is sufficiently clear with regard to the scope of the work. Right? Here is the item again: Jul. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard [Starting point for the work will be http://tools.ietf.org/html/draft-hardjono-oauth-dynreg ] Of course there there is a relationship between Simple Web Discovery (or WebFinger) and the dynamic client registration since the client first needs to discover the client registration endpoint at the authorization server before interacting with it. Now, one thing that just came to my mind when looking again at draft- hardjono-oauth-dynreq was the following: Could the Client Registration Request and Response protocol exchange could become a profile of the SCIM protocol? In some sense this exchange is nothing else than provisioning an account at the Authorization Server (along with some meta-data). Is this too far fetched? Ciao Hannes ___ 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] Updated Charter to the IESG (this weekend)
Hi Justin, I refered to the data format used at the AS-PR interface. According to your description, you use JSON objects there. What data does such an object contain? Is this any different from a JSON Web Token (leaving aside digital signatures and encryption)? regards, Torsten. Am 18.04.2012 22:01, schrieb Justin Richer: Not all implementations in the field that do this are using JWTs as the tokens. Ours in particular used a random blob with no structured information in it. The endpoint returned a JSON object. -- Justin On 04/18/2012 03:53 PM, Torsten Lodderstedt wrote: Hi all, is there enough experience in the field with such an interface to standardize it? I would expect such an endpoint to return the same payload, which is carried in a JSON Web Token. So once we designed the JSON Web Tokens content, designing the AS-PR interface could be the next logical step (after the next re-charting). regards, Torsten. Am 16.04.2012 21:04, schrieb Justin Richer: OK, but with SWD and discovery off the table, can this now be considered to be within that manageable number instead? We wanted to keep the # of WG items to approximately 5. Once we finish some of these items and get them off our plate we could roll new items onto the plate, theoretically. That's definitely true going forward, but what I was saying is that the number of items under consideration is now down to 4, with SWD moving to the Apps group. I was proposing that the whole introspection endpoint and general AS-PR connection could be this group's fifth starting document. -- Justin ___ 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] Using Oauth2 token to SOAP web services
Hi Grant, did you consider to use the binary security token feature of WS-Security? http://schemas.xmlsoap.org/specs/ws-security/ws-security.htm#ws-security__toc6201554 We use it for some services. regards, Torsten. Guang Yang guang.g.y...@oracle.com schrieb: Thank you. Actually I am looking for a standard spec defines how to put the access token in soap request. I know several vendors in the industry have their solution of it but none of them is following a public standardization. So could you please do me a favor on letting me know how your product does for soap? Appreciate for your help. To the community, according recent emails back and force looks like we agree that it makes sense to have oauth enabled for soap, but nobody is giving a suggestion how to do it except using saml. I will appreciate to hear more suggestions before choosing a private way of my organization. Thanks a lot, Grant. Oracle Communications, SDP On Mar 28, 2012, at 4:38 AM, Jay Thorne jtho...@layer7tech.com wrote: http://www.layer7tech.com/ http://www.layer7tech.com/products/oauth-toolkit Yes, we can work with OAuth2 in SOAP context. Let me know if you want to hear more about it. -- Jay Thorne, Director of Development, Tactical Group Layer 7 Technologies t: 778 329 9974 c:604 836 7257 From: Chris Dryden Sent: Tuesday, March 27, 2012 1:04 PM To: Jay Thorne Subject: FW: [OAUTH-WG] Using Oauth2 token to SOAP web services Jay, this message was posted to the OAuth working group today. I have seen someone else asking for the same thing -- OAuth tokens in a SOAP context. This seems like our area of expertise, doesn't it? From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Grant Yang Sent: Wednesday, March 14, 2012 10:41 PM To: oauth@ietf.org Subject: [OAUTH-WG] Using Oauth2 token to SOAP web services Hi all, We were discussing the possibility to use Oauth2 token on SOAP in our product. The preferred way in mentioned in RFC is of course to put it to HTTP Authorization header, but in this case it will beyond the scope of SOAP stack and I am not sure it shall be the correct way to go. It is also recognized that there is some implementation (such as salesforce) is using some SOAP header (“sessionId”) to put this token, but it looks like a private implementation and I did not find any specification supporting it. Could any experts here illustrate any organization or forum is working on using Oauth2 token for SOAP request? As there are quite some legacy SOAP based web services, hopefully it is a question makes sense for you as well. Thoughts? Grant Yang Architect, SDP of ORACLE Communications ___ 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] Agenda Proposal
Hi Barry, we incorporated all issues we were aware of in the last revision (esp. Tim Bray's review comments). regards, Torsten. Am 14.03.2012 22:23, schrieb Barry Leiba: Looks good to me. One note: 2. OAuth Threats Document (Torsten) https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel/ I have been terribly remiss on this, so here's the thing: - We have completed WGLC on this, and are awaiting my shepherd review (which will include a recommendation for the remaining unresolved issue). - I will do this before I leave chairdom and head into the abyss that is the IESG. - Torsten, please let me know if there's anything outstanding that you have to do; else it's all waiting for my action. Unless I've missed something, this agenda item should be brief indeed. Barry, two more weeks ___ 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] OAuth WG Re-Chartering
Hi John, I don't think dynamic registration completely removes the need for a public client, that can't keep secrets. I don't get this argument. In my opinion, there are two use cases, which currently motivate usage of public clients and none of them is about keeping secrets. 1) native apps - There is no mechanism for securely _provisioning_ those clients with client secrets. So it does not make sense to use secrets for authenticating them. Dynamic client registration would allow them to obtain client id and secret on activation/installation. The security of the respective secret is the same as for refresh tokens. So either both can be protected appropriately or none of them. Please note: I'm not talking about trust in the identity/authenticity of the particular app installation. I'm just talking about simplifying the OAuth flows and description. Today an AS needs to support the refresh tokens or resource owner grant type for both confidential and public clients in order to also support native apps. 2) implicit grant - here, public clients are used because the protocol design itself does not allows for validating client secrets. Obviously, digital signature would help but make the protocol more difficult to use. Basically, dynamic client registration allows a client to bind to an AS at runtime. That's what it makes so valuable with respect to interoperatibility. Whether the client just registers meta data or also obtains a secret is another aspect but not the only one. regards, Torsten. While we did do dynamic client registration for Connect that is a more constrained use case. I would put JWT and AS-RS communication as higher priorities than dynamic registration. Partially because they are more self contained issues. John B. On 2012-03-21, at 4:35 PM, Torsten Lodderstedt wrote: In my opinion, dynamic client registration would allow us to drop public client thus simplifying the core spec. regards, Torsten. Am 15.03.2012 16:00, schrieb Eran Hammer: I believe most do, except for the dynamic client registration. I don't have strong objections to it, but it is the least important and least defined / deployed proposal on the list. The AS-RS work is probably simpler and more useful at this point. EH -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Thursday, March 15, 2012 4:47 AM To: ext Blaine Cook; Hannes Tschofenig Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering Hi Blaine, These are indeed good requirements you stated below. When you look at the list of topics do you think that the proposed items indeed fulfill them? Ciao Hannes -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of ext Blaine Cook Sent: Thursday, March 15, 2012 1:31 PM To: Hannes Tschofenig Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering On 14 March 2012 20:21, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: So, here is a proposal: [Editor's Note: New work for the group. 5 items maximum! ] Aug. 2012Submit 'Token Revocation' to the IESG for consideration as a Proposed Standard Nov. 2012Submit 'JSON Web Token (JWT)' to the IESG for consideration as a Proposed Standard Nov. 2012Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for consideration Jan. 2013Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard Sep. 2012Submit 'OAuth Use Cases' to the IESG for consideration as an Informational RFC This looks great to me. I have serious concerns about feature-creep, and think that the OAuth WG should strongly limit its purview to these issues. In general, I think it prudent for this working group in particular to consider standardisation of work only under the following criteria: 1. Proposals must have a direct relationship to the mechanism of OAuth (and not, specifically, bound to an application-level protocol). 2. Proposals must have significant adoption in both enterprise and startup environments. 3. Any proposal must be driven based on a consideration of the different approaches, as adopted in the wild, and strive to be a better synthesis of those approaches, not a means to an end. These are the constraints with which I started the OAuth project, and they're more relevant than ever. I'd hate to see OAuth fail in the end because of a WS-*-like death by standards-pile-on. b. ___ 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] OAuth WG Re-Chartering
Hi George, I see two distinct areas of interoperability, which are Client-AS and AS-RS. Dynamic client registration belongs to Client-AS whereas JWT AS-RS communication belong to the later area. OAuth 2.0 currently (not fully) covers Client-AS and does not address AS-RS. In my opinion, the WG should decide whether we first complete Client-AS and address AS-RS later on or vice versa. I'm in favour of completing Client-AS first and consider client registration a major missing piece. Why? Because otherwise clients cannot dynamically bind to any OAuth-AS at runtime but have to pre-register (with any?) :-(. regards, Torsten. Am 21.03.2012 21:50, schrieb George Fletcher: +1 to JWT and AS-RS communication over dynamic registration On 3/21/12 3:52 PM, John Bradley wrote: I don't think dynamic registration completely removes the need for a public client, that can't keep secrets. While we did do dynamic client registration for Connect that is a more constrained use case. I would put JWT and AS-RS communication as higher priorities than dynamic registration. Partially because they are more self contained issues. John B. On 2012-03-21, at 4:35 PM, Torsten Lodderstedt wrote: In my opinion, dynamic client registration would allow us to drop public client thus simplifying the core spec. regards, Torsten. Am 15.03.2012 16:00, schrieb Eran Hammer: I believe most do, except for the dynamic client registration. I don't have strong objections to it, but it is the least important and least defined / deployed proposal on the list. The AS-RS work is probably simpler and more useful at this point. EH -Original Message- From: oauth-boun...@ietf.org [6] [mailto:oauth-boun...@ietf.org [7]] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Thursday, March 15, 2012 4:47 AM To: ext Blaine Cook; Hannes Tschofenig Cc: oauth@ietf.org [8] Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering Hi Blaine, These are indeed good requirements you stated below. When you look at the list of topics do you think that the proposed items indeed fulfill them? Ciao Hannes -Original Message- From: oauth-boun...@ietf.org [1] [mailto:oauth-boun...@ietf.org [2]] On Behalf Of ext Blaine Cook Sent: Thursday, March 15, 2012 1:31 PM To: Hannes Tschofenig Cc: oauth@ietf.org [3] WG Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering On 14 March 2012 20:21, Hannes Tschofenig wrote: So, here is a proposal: [Editor's Note: New work for the group. 5 items maximum! ] Aug. 2012 Submit 'Token Revocation' to the IESG for consideration as a Proposed Standard Nov. 2012 Submit 'JSON Web Token (JWT)' to the IESG for consideration as a Proposed Standard 2.0' to the IESG for consideration er-left:#1010ff 2px solid; margin-left:5px; width:100% Jan. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for considerat solid; margin-left:5px; width:100% Sep. 2012 Submit 'OAuth Use Cases' to consideration as an Informational RFC This looks great to me. I have serious concerns about feature-creep, and think that the OAuth WG should strongly limit its purview to these issues. y under the following criteria: 1. Proposals must have a direct relationship to t of OAuth (and not, specifically, bound to an application-level protocol). 2. Proposals must have significant adoption in both enterprise and startup environments. 3. Any proposal must be driven based on a consideration of the different approaches, as adopted in the wild, and strive to be a better synthesis of those approaches, not a means to an end. These are the constraints with which I started the OAuth project, and they're more relevant than ever. I'd hate to see OAuth fail in the end because of a WS-*-like death by standards-pile-on. b. ___ OAuth mailing list OAuth@ietf.org [4] https://www.ietf.org/mailman/listinfo/oauth [5] ___ OAuth mailing list OAuth@ietf.org [9] https://www.ietf.org/mailman/listinfo/oauth [10] ___ OAuth mailing list OAuth@ietf.org [11] https://www.ietf.org/mailman/listinfo/oauth [12] ___ OAuth mailing list OAuth@ietf.org [13] https://www.ietf.org/mailman/listinfo/oauth [14] ___ OAuth mailing list OAuth@ietf.org [15] https://www.ietf.org/mailman/listinfo/oauth [16] Links: -- [1] mailto:oauth-boun...@ietf.org [2] mailto:oauth-boun...@ietf.org [3] mailto:oauth@ietf.org [4] mailto:OAuth@ietf.org [5] https://www.ietf.org/mailman/listinfo/oauth [6] mailto:oauth-boun...@ietf.org [7] mailto:oauth-boun...@ietf.org [8] mailto:oauth@ietf.org [9] mailto:OAuth@ietf.org [10] https://www.ietf.org/mailman/listinfo/oauth [11] mailto:OAuth@ietf.org [12] https://www.ietf.org/mailman/listinfo/oauth [13] mailto:OAuth
Re: [OAUTH-WG] OAuth WG Re-Chartering
Hi Paul, for me, your proposal looks like the natural counterpart of JWT, as it standardizes the way to implement handle-based token designs (in contrast to self-contained tokens). therefore +1 from my side. regards, Torsten. Am 15.03.2012 11:35, schrieb Paul Madsen: +1 to defining RS-AS interactions. We've implemented such a 'token introspection' endpoint in our AS and I'm be happy to no longer need to explain to customers/partners why it's not part of the standard. As input, an (incomplete) spec for our endpoint enclosed. (we modeled the verification as a new grant type, leveraging as much as possible the existing token endpoint API) Wrt the 5 item limit 1) is this an arbitrary #? if people sign up to work on more items, could it be extended? 2) the use cases document seems already well progressed (and informational). Need it count against the 5? paul On 3/14/12 5:53 PM, Richer, Justin P. wrote: Methods of connecting the PR to the AS are something that several groups have invented outside of the OAuth WG, and I think we should try to pull some of this work together. OAuth2 gives us a logical separation of the concerns but not a way to knit them back together. Proposals for inclusion in the discussion include UMA's Step 3, OpenID Connect's CheckID, and several token introspection endpoints in various implementations. -- Justin On Mar 14, 2012, at 4:21 PM, Hannes Tschofenig wrote: So, here is a proposal: --- Web Authorization Protocol (oauth) Description of Working Group The Web Authorization (OAuth) protocol allows a user to grant a third-party Web site or application access to the user's protected resources, without necessarily revealing their long-term credentials, or even their identity. For example, a photo-sharing site that supports OAuth could allow its users to use a third-party printing Web site to print their private pictures, without allowing the printing site to gain full control of the user's account and without having the user sharing his or her photo-sharing sites' long-term credential with the printing site. The OAuth protocol suite encompasses * a procedure for allowing a client to discover a resource server, * a protocol for obtaining authorization tokens from an authorization server with the resource owner's consent, * protocols for presenting these authorization tokens to protected resources for access to a resource, and * consequently for sharing data in a security and privacy respective way. In April 2010 the OAuth 1.0 specification, documenting pre-IETF work, was published as an informational document (RFC 5849). With the completion of OAuth 1.0 the working group started their work on OAuth 2.0 to incorporate implementation experience with version 1.0, additional use cases, and various other security, readability, and interoperability improvements. An extensive security analysis was conducted and the result is available as a stand-alone document offering guidance for audiences beyond the community of protocol implementers. The working group also developed security schemes for presenting authorization tokens to access a protected resource. This led to the publication of the bearer token as well as the message authentication code (MAC) access authentication specification. OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token with the SAML 2.0 bearer assertion profile. This offers interworking with existing identity management solutions, in particular SAML based deployments. OAuth has enjoyed widespread adoption by the Internet application service provider community. To build on this success we aim for nothing more than to make OAuth the authorization framework of choice for any Internet protocol. Consequently, the ongoing standardization effort within the OAuth working group is focused on enhancing interoperability of OAuth deployments. While the core OAuth specification truly is an important building block it relies on other specifications in order to claim completeness. Luckily, these components already exist and have been deployed on the Internet. Through the IETF standards process they will be improved in quality and will undergo a rigorous review process. Goals and Milestones [Editor's Note: Here are the completed items.] DoneSubmit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item DoneSubmit 'HTTP Authentication: MAC Authentication' as a working group item DoneSubmit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard DoneSubmit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard [Editor's Note: Finishing existing work. Double-check the proposed dates - are they realistic?] Jun. 2012 Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard Apr. 2012 Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the
Re: [OAUTH-WG] OAuth WG Re-Chartering
In my opinion, dynamic client registration would allow us to drop public client thus simplifying the core spec. regards, Torsten. Am 15.03.2012 16:00, schrieb Eran Hammer: I believe most do, except for the dynamic client registration. I don't have strong objections to it, but it is the least important and least defined / deployed proposal on the list. The AS-RS work is probably simpler and more useful at this point. EH -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Thursday, March 15, 2012 4:47 AM To: ext Blaine Cook; Hannes Tschofenig Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering Hi Blaine, These are indeed good requirements you stated below. When you look at the list of topics do you think that the proposed items indeed fulfill them? Ciao Hannes -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of ext Blaine Cook Sent: Thursday, March 15, 2012 1:31 PM To: Hannes Tschofenig Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering On 14 March 2012 20:21, Hannes Tschofenig hannes.tschofe...@gmx.net wrote: So, here is a proposal: [Editor's Note: New work for the group. 5 items maximum! ] Aug. 2012Submit 'Token Revocation' to the IESG for consideration as a Proposed Standard Nov. 2012Submit 'JSON Web Token (JWT)' to the IESG for consideration as a Proposed Standard Nov. 2012Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for consideration Jan. 2013Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard Sep. 2012Submit 'OAuth Use Cases' to the IESG for consideration as an Informational RFC This looks great to me. I have serious concerns about feature-creep, and think that the OAuth WG should strongly limit its purview to these issues. In general, I think it prudent for this working group in particular to consider standardisation of work only under the following criteria: 1. Proposals must have a direct relationship to the mechanism of OAuth (and not, specifically, bound to an application-level protocol). 2. Proposals must have significant adoption in both enterprise and startup environments. 3. Any proposal must be driven based on a consideration of the different approaches, as adopted in the wild, and strive to be a better synthesis of those approaches, not a means to an end. These are the constraints with which I started the OAuth project, and they're more relevant than ever. I'd hate to see OAuth fail in the end because of a WS-*-like death by standards-pile-on. b. ___ 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth WG Re-Chartering
Hi Hannes, +1 You have compiled a list of meaningful and feasible objectives. regards, Torsten. Am 14.03.2012 21:21, schrieb Hannes Tschofenig: So, here is a proposal: --- Web Authorization Protocol (oauth) Description of Working Group The Web Authorization (OAuth) protocol allows a user to grant a third-party Web site or application access to the user's protected resources, without necessarily revealing their long-term credentials, or even their identity. For example, a photo-sharing site that supports OAuth could allow its users to use a third-party printing Web site to print their private pictures, without allowing the printing site to gain full control of the user's account and without having the user sharing his or her photo-sharing sites' long-term credential with the printing site. The OAuth protocol suite encompasses * a procedure for allowing a client to discover a resource server, * a protocol for obtaining authorization tokens from an authorization server with the resource owner's consent, * protocols for presenting these authorization tokens to protected resources for access to a resource, and * consequently for sharing data in a security and privacy respective way. In April 2010 the OAuth 1.0 specification, documenting pre-IETF work, was published as an informational document (RFC 5849). With the completion of OAuth 1.0 the working group started their work on OAuth 2.0 to incorporate implementation experience with version 1.0, additional use cases, and various other security, readability, and interoperability improvements. An extensive security analysis was conducted and the result is available as a stand-alone document offering guidance for audiences beyond the community of protocol implementers. The working group also developed security schemes for presenting authorization tokens to access a protected resource. This led to the publication of the bearer token as well as the message authentication code (MAC) access authentication specification. OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token with the SAML 2.0 bearer assertion profile. This offers interworking with existing identity management solutions, in particular SAML based deployments. OAuth has enjoyed widespread adoption by the Internet application service provider community. To build on this success we aim for nothing more than to make OAuth the authorization framework of choice for any Internet protocol. Consequently, the ongoing standardization effort within the OAuth working group is focused on enhancing interoperability of OAuth deployments. While the core OAuth specification truly is an important building block it relies on other specifications in order to claim completeness. Luckily, these components already exist and have been deployed on the Internet. Through the IETF standards process they will be improved in quality and will undergo a rigorous review process. Goals and Milestones [Editor's Note: Here are the completed items.] DoneSubmit 'OAuth 2.0 Threat Model and Security Considerations' as a working group item DoneSubmit 'HTTP Authentication: MAC Authentication' as a working group item DoneSubmit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for consideration as a Proposed Standard DoneSubmit 'The OAuth 2.0 Authorization Protocol' to the IESG for consideration as a Proposed Standard [Editor's Note: Finishing existing work. Double-check the proposed dates - are they realistic?] Jun. 2012 Submit 'HTTP Authentication: MAC Authentication' to the IESG for consideration as a Proposed Standard Apr. 2012 Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard Apr. 2012 Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a Proposed Standard Apr. 2012 Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for consideration as a Proposed Standard May 2012Submit 'OAuth 2.0 Threat Model and Security Considerations' to the IESG for consideration as an Informational RFC [Editor's Note: New work for the group. 5 items maximum! ] Aug. 2012Submit 'Token Revocation' to the IESG for consideration as a Proposed Standard [Starting point for the work will be http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/] Nov. 2012Submit 'JSON Web Token (JWT)' to the IESG for consideration as a Proposed Standard [Starting point for the work will be http://tools.ietf.org/html/draft-jones-json-web-token] Nov. 2012Submit 'JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0' to the IESG for consideration as a Proposed Standard [Starting point for the work will be http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer] Jan. 2013Submit 'OAuth Dynamic Client Registration Protocol' to the IESG for consideration as a Proposed Standard [Starting point for the work will be http://tools.ietf.org/html/draft-hardjono-oauth-dynreg] Sep.
Re: [OAUTH-WG] Multiple access tokens
Hi, Ross Boucher rbouc...@gmail.com schrieb: The spec doesn't seem to have any recommendations on this point, but should an OAuth v2 API always return the same access token if the same client makes multiple requests? Is there any benefit to not generating a new access token for each request? I don't see any. Similarly, if you do generate new access tokens (as I am doing now), should you also generate new refresh tokens? Depends on the grant type. I would expect an authz server to generate new refresh tokens for code, whether the authz server creates a new one for grant type refresh_token might depend on server impl. and client-specific policy (refresh token rotation). An unrelated question about revoking access tokens when the same authorization code is used more than once: should refresh tokens also be revoked? Does it make sense to not revoke refresh token? Otherwise, it could be used to obtain fresh access tokens. And, if so, should any tokens issued with that refresh token then also be revoked? It seems :-) sounds reasonable but not nessessarily feasable simpler (if slightly less correct) to just revoke all access tokens for that specific client/resource pair in that case, rather than tracking the ancestry of all tokens. Generally, I would consider revoking access tokens more difficult then revoking refresh tokens. It depends on your token design. One can use handles for refresh tokens and self-contained access tokens and revoke refresh tokens only. In that case, I would limit the access token lifetime in order to force a periodic refresh. Regarding client/resource: Depends on whether you are able to really identify a particular client instance. Otherwise, you would revoke tokens for different (potentially a lot of) client installations using the same client_id. regards, Torsten. Thanks, Ross___ 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] [apps-discuss] Apps Area review of draft-ietf-oauth-v2-threatmodel-01
Hi Tim, I just submitted the revised version of the OAuth 2.0 security document (http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-02). This revision should address the issues you raised in your AppsDir review. We especially removed all normative language from the document. We took the liberty to leave the back references in Section 5. We consider this back references to section 4 a valuable information for implementors since they justify the particular countermeasure. All to often security considerations are given without the corresponding rationales. And without a justification, the unconvinced implementor may tend to ignore or underestimate the respective controls. regards, Torsten. Am 23.01.2012 22:47, schrieb S Moonesamy: The following is the AppsDir review performed by Tim Bray. It would be appreciated if a reply is sent to Tim Bray with a copy to the apps-discuss mailing list. I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-oauth-v2-threatmodel-01 Title: OAuth 2.0 Threat Model and Security Considerations Reviewer: Tim Bray Review Date: Jan 23, 2012 Summary: This needs some more editorial work, but is basically sound. It's not clear, though, whether it wants to be an Informational RFC or not; the use of RFC2119 language needs special attention. I think a few of the minor issues are worthy of a little bit more work in another draft. Major Issues: The use of 2119 MUST/SHOULD/etc doesn't seem fully thought through. I normally wouldn't expect a threat model to include normative text. The basic idea would be to say Here is an enumeration of the threats, and here are the tools available to OAUTH2 implementors to meet them. I was impressed by the enumeration, which seemed very complete and well thought through. But the usage of 2119, which makes statements normative, seems inconsistent. I can think of 2 ways to address this: 1. Remove all the 2119 words, so this document isn't normative, and publish it as an Informational RFC 2. Go through and clean up the 2119 language so it's used consistently; then this becomes a normative document. This is going to affect the references to this document from other I-Ds in the OAuth suite, which are currently in last call. Here are all the section-numbered notes enumerating my issues around 2119, as I encountered them: Section 2.3, I'm a little confused about the use of RFC2119 MAY in a threat analysis. When you say The following data elements MAY be stored or accessible..., Is this saying that The OAuth2 RFC says that the following data elements MAY be... or is it saying something else. I don't think there's anything seriously wrong here, but a bit more explanation might be in order. I note a comparative absence of 2119-ese in section 5 describing countermeasures, where one would expect to find it. Also in 4.3.1, first bullet point, there's Authorization servers MUST... Also in: 4.4.1.1, 4.4.1.6, 4.4.1.12, 4.6.*, 5.1.4.1.5, 5.1.5.11 Related: SHALL?! in 4.6.3 Adding to the concern, there is use of lower-case must; note 2nd 3rd bullet points in 4.4.3, which use MUST and must respectively. Minor Issues: 4.1.2 first attack: It says An attack may obtain the refresh tokens issued to a web server client. This needs to be clearer... a Web server client can be a browser or a native app. Do you mean, the refresh tokens issued by the web server to multiple clients? 4.1.2 last attack. In the case where a device is cloned, wouldn't Utilize device lock to prevent unauthorized device access still be a countermeasure? In many devices, such cloning would carry along the user's device-lock settings. 4.4.1.4 2nd bullet. The explanation of why this wouldn't work for native clients wasn't comprehensible to me. I'm suspicious of any such claims because I can emulate most things a browser can do in a mobile client. Perhaps this would be obvious to someone who is an OAuth2 implementor. 4.4.1.9 I think where it says iFrame it might mean WebView, i.e. a Web Browser control embedded in the native app. If that's not what it means, I don't understand what it's saying. If this is true, then the second bullet point is probably wrong. 4.6.6 1st bullet. I'm not convinced that the Cache-Control header will *ensure* that a client protects information properly. Should say something like minimize the risk that authenticated content is not protected 5.* The enumeration, for some but not all of the countermeasures in this section, of the threats against which this is a countermeasure, reduces readability and, unless it's generated automatically from the underlying source, is redundant
Re: [OAUTH-WG] Clarification request on draft-ietf-oauth-v2-23#section-10.10
Hi Nat, ... We probably should put some text that gives flexibility in that respect, such as or put in place the controls that achieves equivalent risk mitigation. etc. One could add this text to nearly any of the guidelines given in Section 10. But how do you assess the equivalence of the respective control? The intention of the security considerations section was to give clear guidance even for implementors unfamiliar with security and threat analysis. We therefore gave simple guidelines without much explanation of the rationale. I think this will work for most implementations. Implementors confronted with circumstances which do not allow them to adhere to the security considerations should create an appropriate security design based on the threat model and security considerations document. regards, Torsten. =nat On Fri, Feb 3, 2012 at 9:37 AM, Igor Faynberg igor.faynb...@alcatel-lucent.com wrote: Nat, Your note made me think (as always), so maybe some text clarification is indeed in order. I have a slightly different understanding of the items you brought up. RFC 1750 is Informational, and I thought (maybe mistakenly?) that it cannot be used as a norm in a MUST clause. Therefore, I assumed that the clause prescribes the use of cryptographically-strong pseudo-random generators but stopped short of listing them. The second item, I read as defining the strength, giving the necessary and desired bounds for a collision probability of two generated values. Igor On 2/2/2012 4:25 AM, Nat Sakimura wrote: hi. The rev. 23 has a normative change in section 10.10 as: 10.10. Credentials Guessing Attacks [...] Generated tokens and other credentials not intended for handling by end-users MUST be constructed from a cryptographically strong random or pseudo-random number sequence ([RFC1750]) generated by the authorization server. Does this normative requirement only allows pseudo-random number sequence described as in Section 6.3 of RFC1750? Or does it allow something that includes it? I gather that it is the later, but the wording constructed from sounds a little vague. It also states: The probability of any two values being identical MUST be less than or equal to 2^(-128) and SHOULD be less than or equal to 2^(-160). It is the probability that a randomly generated guessed value being identical to the authoritatively generated token or credential value, I suppose. -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en ___ 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] [apps-discuss] Apps Area review of draft-ietf-oauth-v2-threatmodel-01
Hi, thanks for the thoroughly review. The threat document is intended to become an Informational RFC. So we will follow your advice and remove all normative language. regards, Torsten. Am 23.01.2012 22:47, schrieb S Moonesamy: The following is the AppsDir review performed by Tim Bray. It would be appreciated if a reply is sent to Tim Bray with a copy to the apps-discuss mailing list. I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-oauth-v2-threatmodel-01 Title: OAuth 2.0 Threat Model and Security Considerations Reviewer: Tim Bray Review Date: Jan 23, 2012 Summary: This needs some more editorial work, but is basically sound. It's not clear, though, whether it wants to be an Informational RFC or not; the use of RFC2119 language needs special attention. I think a few of the minor issues are worthy of a little bit more work in another draft. Major Issues: The use of 2119 MUST/SHOULD/etc doesn't seem fully thought through. I normally wouldn't expect a threat model to include normative text. The basic idea would be to say Here is an enumeration of the threats, and here are the tools available to OAUTH2 implementors to meet them. I was impressed by the enumeration, which seemed very complete and well thought through. But the usage of 2119, which makes statements normative, seems inconsistent. I can think of 2 ways to address this: 1. Remove all the 2119 words, so this document isn't normative, and publish it as an Informational RFC 2. Go through and clean up the 2119 language so it's used consistently; then this becomes a normative document. This is going to affect the references to this document from other I-Ds in the OAuth suite, which are currently in last call. Here are all the section-numbered notes enumerating my issues around 2119, as I encountered them: Section 2.3, I'm a little confused about the use of RFC2119 MAY in a threat analysis. When you say The following data elements MAY be stored or accessible..., Is this saying that The OAuth2 RFC says that the following data elements MAY be... or is it saying something else. I don't think there's anything seriously wrong here, but a bit more explanation might be in order. I note a comparative absence of 2119-ese in section 5 describing countermeasures, where one would expect to find it. Also in 4.3.1, first bullet point, there's Authorization servers MUST... Also in: 4.4.1.1, 4.4.1.6, 4.4.1.12, 4.6.*, 5.1.4.1.5, 5.1.5.11 Related: SHALL?! in 4.6.3 Adding to the concern, there is use of lower-case must; note 2nd 3rd bullet points in 4.4.3, which use MUST and must respectively. Minor Issues: 4.1.2 first attack: It says An attack may obtain the refresh tokens issued to a web server client. This needs to be clearer... a Web server client can be a browser or a native app. Do you mean, the refresh tokens issued by the web server to multiple clients? 4.1.2 last attack. In the case where a device is cloned, wouldn't Utilize device lock to prevent unauthorized device access still be a countermeasure? In many devices, such cloning would carry along the user's device-lock settings. 4.4.1.4 2nd bullet. The explanation of why this wouldn't work for native clients wasn't comprehensible to me. I'm suspicious of any such claims because I can emulate most things a browser can do in a mobile client. Perhaps this would be obvious to someone who is an OAuth2 implementor. 4.4.1.9 I think where it says iFrame it might mean WebView, i.e. a Web Browser control embedded in the native app. If that's not what it means, I don't understand what it's saying. If this is true, then the second bullet point is probably wrong. 4.6.6 1st bullet. I'm not convinced that the Cache-Control header will *ensure* that a client protects information properly. Should say something like minimize the risk that authenticated content is not protected 5.* The enumeration, for some but not all of the countermeasures in this section, of the threats against which this is a countermeasure, reduces readability and, unless it's generated automatically from the underlying source, is redundant information, which is unlikely to be consistent between sections 4 and 5, and adds difficulty to maintenance of this document without adding much value. I'd just wipe all these bullet lists out. If it's generated automatically it's less damaging, but still reduces readability. In the current draft, this is there for some countermeasures but absent for others. Another good reason to just take it out. 5.2.2.5 Device identifiers are very tricky. It's correct that IMEI is not adequate, but there are ways to do it without
Re: [OAUTH-WG] SHOULD vs MUST for indicating scope on response when different from client request
MUST sounds reasonable Eran Hammer e...@hueniverse.com schrieb: The current text: If the issued access token scope is different from the one requested by the client, the authorization server SHOULD include the scope response parameter to inform the client of the actual scope granted. Stephen asked why not a MUST. I think it should be MUST. Any disagreement? EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Access Token Response without expires_in
Hi Paul, that's not what I meant. The Client should know which tokens should be one time usage based on the API description. The authz server must not return expires_in because this would not make any sense in this case. regards, Torsten Paul Madsen paul.mad...@gmail.com schrieb: Hi Torsten, yes the use case in question is payment-based as well. Your suggestion for the client to infer one-time usage from a missing expires_in contradicts the general consensus of this thread does it not? paul On 1/17/12 11:38 AM, tors...@lodderstedt.net wrote: Hi, isn't one-time semantics typically associated with certain requests on certain resources/resource types. I therefore would assume the client to know which tokens to use one-time only. The authz server should not return an expires_in paramter. We for example use one time access tokens for payment transactions. What would such an extension specify? regards, Torsten. Gesendet mit BlackBerry® Webmail von Telekom Deutschland -Original Message- From: Paul Madsen paul.mad...@gmail.com Sender: oauth-boun...@ietf.org Date: Tue, 17 Jan 2012 08:23:37 To: Richer, Justin P.jric...@mitre.org Cc: OAuth WGoauth@ietf.org Subject: Re: [OAUTH-WG] Access Token Response without expires_in ___ 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] Access Token Response without expires_in
good point William Mills wmi...@yahoo-inc.com schrieb: One use tokens can also expire before they are used. You have 5 minutes to do this once. _ From: Torsten Lodderstedt [tors...@lodderstedt.net] Sent: Tuesday, January 17, 2012 12:26 PM To: Paul Madsen Cc: oauth-boun...@ietf.org; Richer, Justin P.; OAuth WG Subject: Re: AW: Re: [OAUTH-WG] Access Token Response without expires_in Hi Paul, that's not what I meant. The Client should know which tokens should be one time usage based on the API description. The authz server must not return expires_in because this would not make any sense in this case. regards, Torsten Paul Madsen paul.mad...@gmail.com schrieb: Hi Torsten, yes the use case in question is payment-based as well. Your suggestion for the client to infer one-time usage from a missing expires_in contradicts the general consensus of this thread does it not? paul On 1/17/12 11:38 AM, tors...@lodderstedt.net wrote: Hi, isn't one-time semantics typically associated with certain requests on certain resources/resource types. I therefore would assume the client to know which tokens to use one-time only. The authz server should not return an expires_in paramter. We for example use one time access tokens for payment transactions. What would such an extension specify? regards, Torsten. Gesendet mit BlackBerry® Webmail von Telekom Deutschland -Original Message- From: Paul Madsen paul.mad...@gmail.com Sender: oauth-boun...@ietf.org Date: Tue, 17 Jan 2012 08:23:37 To: Richer, Justin P.jric...@mitre.org Cc: OAuth WGoauth@ietf.org Subject: Re: [OAUTH-WG] Access Token Response without expires_in ___ 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] Security Considerations - Access Tokens
makes sense. regards, Torsten. Am 16.01.2012 20:00, schrieb Eran Hammer: Added the word 'credentials' (e.g. Access token credentials (as well as...) to make this clearer. IOW, when using MAC tokens, the token secret is the part that must be protected, not the token id. EHL *From:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of *Marco De Nadai *Sent:* Sunday, October 30, 2011 9:44 AM *To:* oauth@ietf.org *Subject:* [OAUTH-WG] Security Considerations - Access Tokens Hi all, i've recently noticed that in OAuth 2.0 draft 22, in the section 10.3 there is this statment: Access token (as well as any access token type-specific attributes) MUST be kept confidential in transit and storage, and only shared among the authorization server, the resource servers the access token is valid for, and the client to whom the access token is issued. BUT in OAuth 2.0 draft 22 with Authorization Code and MAC Access Authentication, I can request a resource with Access Token sent in clear. This invalidates the Access token (as well as any access token type-specific attributes) MUST be kept confidential in transit and storage. Is it my error? -- *Marco De Nadai* http://www.marcodena.it/ http://www.marcodena.it/?utm_source=emailutm_medium=emailutm_campaign=Email%2Bpersonali ___ 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] Detecting revoked token in OAuth 2.0 client libraries
Hi, an invalid token should cause the server to reply with status code 401. regards, Torsten. Bart Wiegmans b...@all4students.nl schrieb: Hi, As far as I know, the implementation of API endpoints is outside of the specification of OAuth. But the specification of Bearer Tokens state that the endpoint must return the HTTP 403 (Access Denied) status code, along with a WWW-Authenticate: Bearer response header. That should be enough to determine token invalidity. With kind regards, Bart Wiegmans -Oorspronkelijk bericht- Van: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] Namens Andreas Åkre Solberg Verzonden: maandag 9 januari 2012 9:41 Aan: oauth@ietf.org Onderwerp: [OAUTH-WG] Detecting revoked token in OAuth 2.0 client libraries Hi, I'm trying to do an OAuth 2.0 library, and got a question: I cannot find a standardized way for an OAuth protected endpoint to report to the client that the Token is not valid (expired or revoked). As a library developer, I'd like to take away as much of possible of the OAuth logic from the application. I need a way to distinguish applicaiton specific protocol errors, from OAuth related errors on protected endpoints. If the library could detect this, it could also in example do refresh the token automatically, and even start a new flow if neccessary. I'm sorry if the answer is obvious. Another question on token validity; the optional expires_in parameter. If I would like to indicate permanent validity, how can I express that? I assume that if I leave the parameter out it is not possible to distinguish between 'undefined / not specified' and 'infitite'. Putting the semanthics into a specific scope could off course work, but lack the feature of beeing standardized between providers. Andreas _ 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] OAuth2 security considerations for client_id
Hi, your observation is correct. OAuth security considerations recommend not to rely on secrets for authenticating mobile apps (aka native apps) but to manage them as so-called public clients. Please take a look onto section 10 of the core spec for further details. regards, Torsten. Karim medkarim.esska...@gmail.com schrieb: Hello, When using User-agent flow with OAuth2 for mobile platform, there is no way for Authorization server to authenticate the client_id of the application. So, anyone can impersonate my app by copying the client_id (and so get all access tokens on my behalf), and this is applicable to Facebook, Foursquare,... This is not managed by OAuth2 ? Or I missed something ? For Web applications (Web server flow), access token is stored on the server side, and the client is authenticated using secret key. -- Karim ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
Hi Michael, Am 04.01.2012 22:06, schrieb Michael Thomas: I think the perhaps unwisely goes to the heart of my objection. You might as well be talking about perhaps unwisely driving a car, or perhaps unwisely eating food: the reality is that people download apps by the *billions*. When I was initially blown off, many of the participants including document editors implied that only idiots get apps for their phones. That is *completely* unhelpful as the reality is that OAUTH's use is hugely if not primarily deployed in that sort of environment. I fully agree with you. That's why the core spec and the threat document both consider native apps. This is a threat that cuts to the very heart of what OAUTH is, and purports to defend against: keeping user credentials out of the hands of an untrusted third party. If there really aren't any good ways to mitigate this in an app environment, why is OAUTH being deployed so aggressively there? Shouldn't the threat draft say in blinking bold: DEPLOYING OAUTH IN NATIVE APPS CONSIDERED HARMFUL? You lost me. Is the situation getting any worse with OAuth? I don't think so. I think the situation is getting better, probably not as you might expect. The key question is: Why do we aim on keeping user credentials out of the hands of an untrusted third party? 1) To prevent phishing or 2) to prevent leakage of end-user credentials due to inappropriate handling or weak defence on the 3rd party? wrt 1) I don't think so. I don't see how an authorization server shall validate the authenticity and trustworthiness of a client-side application. We already state this in section 4.4.1.4. of the threat document. --- It is not the task of the authorization server to protect the end-user's device from malicious software. This is the responsibility of the platform running on the particular device probably in cooperation with other components of the respective ecosystem (e.g. an application management infrastructure). The sole responsibility of the authorization server is to control access to the end-user's resources living in resource servers and to prevent unauthorized access to them. --- wrt 2) Yes, I think that's the reason. And OAuth is a appropriate protocol to achieve this goal, even for mobile apps. Why? A typical mobile application consists of the app itself on the device and a corresponding backend service storing user data and implementing business and integration logic. Let's assume this application features address book import from other service providers. W/o OAuth, the app would gather the end-user's credential for a certain address book service and pass it to its backend service. This service in turn uses this credentials to access the service provider's API. So in such a scenario the following parties get in touch with the user credentials: - the app - the app's backend service - the address book resource server What threats do you see here? And which is most likely to occur? My favorite is an attack against the log files or the database of the backend service in order to obtain the end-users passwords for the resource server. Why? Because the cost/benefit ratio for an attacker is much better then attacking any app installation on a device and the protective measure on the resource server might be more appropriate then on the client side (backend service). OAuth mitigates this kind of attack by reducing the number of parties handling user credentials to the authorization server and the user agent. So even if the app itself would be the user agent (which is not recommended), it would directly interact with the authorization server and the app's backend service would use tokens instead of end-user credentials. Moreover, the recommended way is to let the app delegate the flow to a trusted system component on the user's device, such as the system browser or an account manager. In that case, the 3rd party is not getting in touch with the user credentials at all. I think the key question is whether anyone expects OAuth to solve the phishing problem. I don't think this is its main purpose, but it could facilitate to overcome the habit to enter user credentials everywhere. And this in turn may contribute to the fight against phishing. regards, Torsten. Mike ___ 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] OAuth Bearer authentication - for proxies?
Hi, Amos, I believe that the draft addresses the replay matters by specifying the validity time field. Do you see a problem with that? I did not see any such validity time field in the HTTP mechanisms. You mean the validity period of the token itself? that would be irrelevant as the case I am raising is for software which does not support Bearer specs. Even if the software is not aware of the bearer spec, a token that becomes invalid after a certain time span cannot sucessfully be replayed any longer. general note: I do not understand why caching proxies should impose a problem in case TLS is used (end2end). Could you please explain? regards, Torsten. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Question on section 10.3 in Core spec.
Hi, you are right, iframe is not the correct techniquehere. Browsers are embedded into a native UI using browser widget or something similar. I think ... embedding a browser into the application's user interface when requesting end-user authorization ... would fit better. regards, Torsten. Am 11.11.2011 09:23, schrieb matake@gmail: Hi all, I'm now translating OAuth 2.0 Core Bearer specs into Japanese with my friends. I have one question on section 10.3 in Core spec. To prevent this form of attack, native applications SHOULD use external browsers instead of embedding browsers in an iframe when requesting end-user authorization. Here, what do you mean for in an iframe? I thought it means embedded browser is in an iframe, but I can't imagine it can be.. Thanks in advance -- nov matake ___ 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] Rechartering JSON based request.
Hi, standard OAuth does not sign request parameters. Does this mean OAuth itself is not secure enough? Or is there a new threat angle against those parameters in the contect of Connect? regards, Torsten. Am 27.10.2011 22:24, schrieb George Fletcher: The main reason to include the OAuth parameters in the request is to ensure that the request object was not modified in transit since the JSON request object can be signed. Agreed that it would be simpler if OAuth adopted the JSON request style. Thanks, George On 10/27/11 1:33 PM, tors...@lodderstedt.net wrote: Hi John, why do you need to include the OAuth request parameters into the JSON document? I would expect OpenId Connect to extend OAuth none-intrusively. This would mean to use the JSON document for OpenId connect specific parameters only. Alternatively, the JSON request style could be adopted as part of OAuth. Then, the URI request parameters could be omitted. regards, Torsten. Gesendet mit BlackBerry® Webmail von Telekom Deutschland *From: * John Bradley ve7...@ve7jtb.com *Date: *Thu, 27 Oct 2011 13:52:31 -0300 *To: *Torsten Lodderstedttors...@lodderstedt.net *Cc: *Nat Sakimurasakim...@gmail.com; OAuth WGoauth@ietf.org *Subject: *Re: [OAUTH-WG] Rechartering JSON based request. Hopefully to make it more compatible with existing OAuth 2 libraries. At least leave open the possibility of dealing with it at a higher level. The argument has been made that you probably need to modify the library anyway to check that the duplicate parameters are a match. If there is consensus that the parameters should only be in the JSON then we would happily not duplicate them. It is mostly a case of trying to fit in to the existing OAuth work and libraries. John B. On 2011-10-27, at 2:22 AM, Torsten Lodderstedt wrote: why is it neccessary to duplicate the OAuth request parameters? Am 27.10.2011 00:31, schrieb John Bradley: Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl. It is essentially a standardization of the method we are using in openID Connect to make signed requests to the Authorization server. We do have the issue that parameters in the signed/encrypted request necessarily duplicate the query parameters to keep it a valid OAuth request plus an extension. Even if it doesn't wind up as a OAuth WG item it is probably worth people looking at it before the final openID spec is voted on. Regards John B. On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote: Hi Nat, I think your proposal would be a useful OAuth enhancement. A JSON-based request format would allow for more complex requests (e.g. carrying resource server URLs and corresponding scope values ;-)). Please note: I also think the way this mechanism is introduced and used in the current OpenID connect spec requires OpenID connect clients and servers to handle OAuth request parameters differently than for standard OAuth requests. Introducing the JSON based claim request capability to OAuth would be a way to cope with this. regards, Torsten. Am 22.10.2011 16:00, schrieb Nat Sakimura: Hi. Just a clarification: Although my expired draft is 'request by reference', what was proposed through it at the iiw really is a generalized JSON based claim request capability. It could be passed by value as JSON or could be passed by reference. The later is an optimization for bandwidth constrained network as well as strengthening security in some ways. This capability already exists in OpenID Connect but it is actually an underpinning transport, so it probably should belong to OAuth instead. This was the primary reason for the proposal. Nat On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt tors...@lodderstedt.net mailto:tors...@lodderstedt.net wrote: Hi all, my prioritization is driven by the goal to make OAuth the authorization framework of choice for any internet standard protocol, such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is missing from my point of view and explain some thoughts how to fill the gaps. A standard protocol is defined in terms of resource types and messages by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and used by different but deployment-independent clients. OAuth-based protocol specifications must also define scope values (e.g. read, write, send) and their relation to the resource types and messages. The different deployments expose the standard protocol on different resource server endpoints. In my opinion, it is fundamental to clearly distinguish scope values (standardized, static) and resource server addresses (deployment specific) and to manage their relationships. The current scope definition is much to weak and insufficient. Probably, the UMA concepts of hosts, resources sets, and corresponding
Re: [OAUTH-WG] AD review of -22
Hi Stephen, I'm concerned about your proposal (7) to make support for MAC a MUST for clients and BEARER a MAY only. In my opinion, this does not reflect the group's consensus. Beside this, the security threat analysis justifies usage of BEARER for nearly all use cases as long as HTTPS (incl. server authentication) can be utilized. regards, Torsten. Am 13.10.2011 19:13, schrieb Stephen Farrell: Hi all, Sorry for having been quite slow with this, but I had a bunch of travel recently. Anyway, my AD comments on -22 are attached. I think that the first list has the ones that need some change before we push this out for IETF LC, there might or might not be something to change as a result of the 2nd list of questions and the rest are really nits can be handled either now or later. Thanks for all your work on this so far - its nearly there IMO and we should be able to get the IETF LC started once these few things are dealt with. Cheers, S. ___ 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] AD review of -22
If we must define a mandatory token type then bearer + TLS would be my suggestion. regards, Torsten. Am 02.11.2011 21:28, schrieb Stephen Farrell: Hi Torsten, On 11/02/2011 07:45 PM, Torsten Lodderstedt wrote: Hi Stephen, I'm concerned about your proposal (7) to make support for MAC a MUST for clients and BEARER a MAY only. In my opinion, this does not reflect the group's consensus. That wasn't quite my comment, which is below: (7) Doesn't 7.1 need to say which token types are MTI so that we get interop? I think I'd like to see mac being a MUST and bearer being a MAY but regardless of my preference, I don't think you can be silent on this. And as a consequence one or both of the mac/bearer drafts need to end up as normative. Beside this, the security threat analysis justifies usage of BEARER for nearly all use cases as long as HTTPS (incl. server authentication) can be utilized. As I said, I personally prefer the mac scheme since it demonstrates use of a key. However, as I also said, the main concern with this point is interop. (I do note though that bearer has server-auth TLS as a MUST USE, so the implication of making bearer a MUST is that TLS is MTI for the base spec too and a MUST USE for anything involving the MTI token type.) In any case I can live with it so long as the set of things that are MTI is clear. Incidentally, I don't believe any amount of +1 messages to your mail answer my point above. As Eran's mail asks: what is it that you're suggesting be MTI for whom? S. regards, Torsten. Am 13.10.2011 19:13, schrieb Stephen Farrell: Hi all, Sorry for having been quite slow with this, but I had a bunch of travel recently. Anyway, my AD comments on -22 are attached. I think that the first list has the ones that need some change before we push this out for IETF LC, there might or might not be something to change as a result of the 2nd list of questions and the rest are really nits can be handled either now or later. Thanks for all your work on this so far - its nearly there IMO and we should be able to get the IETF LC started once these few things are dealt with. Cheers, S. ___ 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] Phishing with Client Application Name Spoofing
Hi Andre, how do you think differs the threat you descibed from http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01#section-4.4.1.4? regards, Torsten. Am 26.10.2011 22:44, schrieb André DeMarre: Should a brief explanation of this be added to the Threat Model and Security Considerations document? Or does anyone even agree that this can be a problem? Regards, Andre DeMarre On Tue, Oct 4, 2011 at 11:32 AM, André DeMarreandredema...@gmail.com wrote: I've not seen this particular variant of phishing and client impersonation discussed. A cursory search revealed that most of the related discussion centers around either (a) client impersonation with stolen client credentials or (b) phishing by malicious clients directing resource owners to spoofed authorization servers. This is different. This attack exploits the trust a resource owner has for an OAuth authorization server so as to lend repute to a malicious client pretending to be from a trustworthy source. This is not necessarily a direct vulnerability of OAuth; rather, it shows that authorization servers have a responsibility regarding client application names and how they present resource owners with the option to allow or deny authorization. A key to this exploit is the process of client registration with the authorization server. A malicious client developer registers his client application with a name that appears to represent a legitimate organization which resource owners are likely to trust. Resource owners at the authorization endpoint may be misled into granting authorization when they see the authorization server asserting some trustworthy name is requesting permission to... Imagine someone registers a client application with an OAuth service, let's call it Foobar, and he names his client app Google, Inc.. The Foobar authorization server will engage the user with Google, Inc. is requesting permission to do the following. The resource owner might reason, I see that I'm legitimately on the https://www.foobar.com site, and Foobar is telling me that Google wants permission. I trust Foobar and Google, so I'll click Allow. To make the masquerade act even more convincing, many of the most popular OAuth services allow app developers to upload images which could be official logos of the organizations they are posing as. Often app developers can supply arbitrary, unconfirmed URIs which are shown to the resource owner as the app's website, even if the domain does not match the redirect URI. Some OAuth services blindly entrust client apps to customize the authorization page in other ways. This is hard to defend against. Authorization server administrators could police client names, but that approach gives them a burden similar to certificate authorities to verify organizations before issuing certificates. Very expensive. A much simpler solution is for authorization servers to be careful with their wording and educate resource owners about the need for discretion when granting authority. Foobar's message above could be changed: An application calling itself Google, Inc. is requesting permission to do the following later adding, Only allow this request if you are sure of the application's source. Such wording is less likely to give the impression that the resource server is vouching for the application's identity. Authorization servers would also do well to show the resource owner additional information about the client application to help them make informed decisions. For example, it could display all or part of the app's redirect URI, saying, The application is operating on example.com or If you decide to allow this application, your browser will be directed to http://www.example.com/.; Further, if the client app's redirect URI uses TLS (something authorization servers might choose to mandate), then auth servers can verify the certificate and show the certified organization name to resource owners. This attack is possible with OAuth 1, but OAuth 2 makes successful exploitation easier. OAuth 1 required the client to obtain temporary credentials (aka access tokens) before sending resource owners to the authorization endpoint. Now with OAuth 2, this attack does not require resource owners to interact with the client application before visiting the authorization server. The malicious client developer only needs to distribute links around the web to the authorization server's authorization endpoint. If the HTTP service is a social platform, the client app might distribute links using resource owners' accounts with the access tokens it has acquired, becoming a sort of worm. Continuing the Google/Foobar example above, it might use anchor text such as I used Google Plus to synchronize with my Foobar account. Moreover, if the app's redirect URI bounces the resource owner back to the HTTP service after acquiring an authorization code, the victim will never see a page rendered at the insidious app's domain. This is especially dangerous because
Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-revocation-03.txt
Hi Craig, thanks for your comment. The revocation endpoint uses the same authentication policy as the core spec. Confidential client must authenticate using their client secret (or any other credential). The end-user's credentials are not involved at all. regards, Torsten. Am 27.10.2011 08:10, schrieb Craig McClanahan: As a substantive comment on the draft (I'm in favor of it being a working group item), it is not clear whether Basic is a required value on the Authorization header included in a revocation request. In some scenarios (particularly three legged), the client app will not possess the username and password of they end user -- it might only possess a currently valid access token. It would seem that including such a token should be a viable authentication mechanism. Craig McClanahan On Fri, Sep 16, 2011 at 12:32 PM, Torsten Lodderstedt wrote: Hi all, I just published a new revision of the token revocation draft. We added JSONP support (thanks to Marius) and aligned the text with draft 21 of the core spec. We would like to bring this draft forward as working group item (once the WG is ready). We think its relevance is illustrated by the fact that this draft (or its predecessor) has already been implemented by Google, Salesforce, and Deutsche Telekom. regards, Torsten. Original-Nachricht BETREFF: New Version Notification for draft-lodderstedt-oauth-revocation-03.txt DATUM: Fri, 16 Sep 2011 12:20:14 -0700 VON: internet-dra...@ietf.org [1] AN: tors...@lodderstedt.net [2] CC: sdro...@gmx.de [3], tors...@lodderstedt.net [4], mscurte...@google.com [5] A new version of I-D, draft-lodderstedt-oauth-revocation-03.txt has been successfully submitted by Torsten Lodderstedt and posted to the IETF repository. Filename: draft-lodderstedt-oauth-revocation Revision: 03 Title: Token Revocation Creation date: 2011-09-16 WG ID: Individual Submission Number of pages: 6 Abstract: This draft proposes an additional endpoint for OAuth authorization servers for revoking tokens. The IETF Secretariat ___ OAuth mailing list OAuth@ietf.org [6] https://www.ietf.org/mailman/listinfo/oauth [7] Links: -- [1] mailto:internet-dra...@ietf.org [2] mailto:tors...@lodderstedt.net [3] mailto:sdro...@gmx.de [4] mailto:tors...@lodderstedt.net [5] mailto:mscurte...@google.com [6] mailto:OAuth@ietf.org [7] https://www.ietf.org/mailman/listinfo/oauth [8] mailto:tors...@lodderstedt.net ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Rechartering
Hi Nat, I think your proposal would be a useful OAuth enhancement. A JSON-based request format would allow for more complex requests (e.g. carrying resource server URLs and corresponding scope values ;-)). Please note: I also think the way this mechanism is introduced and used in the current OpenID connect spec requires OpenID connect clients and servers to handle OAuth request parameters differently than for standard OAuth requests. Introducing the JSON based claim request capability to OAuth would be a way to cope with this. regards, Torsten. Am 22.10.2011 16:00, schrieb Nat Sakimura: Hi. Just a clarification: Although my expired draft is 'request by reference', what was proposed through it at the iiw really is a generalized JSON based claim request capability. It could be passed by value as JSON or could be passed by reference. The later is an optimization for bandwidth constrained network as well as strengthening security in some ways. This capability already exists in OpenID Connect but it is actually an underpinning transport, so it probably should belong to OAuth instead. This was the primary reason for the proposal. Nat On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt tors...@lodderstedt.net mailto:tors...@lodderstedt.net wrote: Hi all, my prioritization is driven by the goal to make OAuth the authorization framework of choice for any internet standard protocol, such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is missing from my point of view and explain some thoughts how to fill the gaps. A standard protocol is defined in terms of resource types and messages by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and used by different but deployment-independent clients. OAuth-based protocol specifications must also define scope values (e.g. read, write, send) and their relation to the resource types and messages. The different deployments expose the standard protocol on different resource server endpoints. In my opinion, it is fundamental to clearly distinguish scope values (standardized, static) and resource server addresses (deployment specific) and to manage their relationships. The current scope definition is much to weak and insufficient. Probably, the UMA concepts of hosts, resources sets, and corresponding scopes could be adopted for that purpose. OAuth today requires clients to register with the service provider before they are deployed. Would you really expect IMAP clients, e.g. Thunderbird, to register with any a-Mail services upfront? So clients should be given a way to register dynamically to the authorization servers. This should also allow us to cover client instance aspects. It is interesting to note, that such a mechanism would allow us to get rid of secret-less clients and the one-time usage requirement for authorization codes. We also assume the client to know the URLs of the resource server and the corresponding authorization server and to use HTTPS server authentication to verify the resource server's authenticity. This is impossible in the standard scenario. Clients must be able to discover the authorization server a particular resource server relies on at runtime. The discovery mechanism could be specified by the OAuth WG, but could also be part of an application protocols specification. But we MUST find another way to prevent token phishing by counterfeit resource servers. As one approach, the client could pass the (previously HTTPS validated) resource server's URL with the authorization request. The authorization server should then refuse such requests for any unknown (counterfeit) resource servers. Such an additional parameter could also serve as namespace for scope values and enable service providers to run multiple instances of the same service within a single deployment. If the additional data enlarges the request payload to much, we could consider to adopt the request by reference proposal. Let's now assume, OAuth is successful in the world of standard protocols and we will see plenty of deployments with a bunch of different OAuth protected resource servers. Shall this servers all be accessible with a single token? In my opinion, this would cause security, privacy and/or scalability/performance problems. To give just the most obvious example, the target audience of such a token cannot be restricted enough, which may allow a resource server (or an attacker in control of it) to abuse the token on other servers. But the current design of the code grant type forces deployments to use the same token for all services. What is needed from my point of view is a way to request and issue multiple server-specific access tokens with a single authorization process. I've been
Re: [OAUTH-WG] Returning two tokens. Was: Re: Rechartering
Hi, Am 26.10.2011 05:41, schrieb Bob Van Zant: I'm going to reiterate what has already been said. OAuth already supports what you're trying to do. Just request a token twice, the first time request it with a scope or scopes that allows these special operations. The second time request it with a scope or scopes that do not. In general I really like how simple OAuth 2 is. By working within the constraints of this simplicity we can keep the protocol simple and easy to use. I also very much like the simplicity of the protocol but is this an end in itself? There are use cases not supported by the protocol at present. I intended to point this out and raise a discussion. We did not discuss a solution so far, so we also don't know the impact this may cause to the protocol. Justin made a proposal some month ago, which seems reasonable to me: http://www.ietf.org/mail-archive/web/oauth/current/msg06771.html I think the multiple tokens use case is relevant for every multi-service provider. If a client uses different services of such a provider (e.g. mail, web storage, telephony, and payment), there are good reasons to use different tokens for the respective resource servers, e.g. abuse prevention, service seggragation, privacy protection. This holds especially true if the services are operated by different business partners in an ASP model. The problem becomes even more obvious in cloud scenarios. With the current capabilities of the authorization code, such a client must send the user through the OAuth dance twice or more often. Alternatively, a single token is good to access all service. This means to trade user experience for security or vice versa. I don't like this. regards, Torsten. -Bob On Tuesday, October 25, 2011, Dave Rochwerger da...@quizlet.com mailto:da...@quizlet.com wrote: Hi Dan, I think we are going down the wrong path here. Basically, you've started with the premise of wanting plain HTTP scheme (in some circumstances), which has caused you to suggest both of, firstly, relaxing the only method of encryption in oauth2 and secondly, to further complicate the protocol by allowing multiple tokens to be returned. OAuth2 (unlike version 1) has no signatures or other encryption - it relies solely on SSL. Therefore any relaxation of this requirement breaks security wide open (even in your specific short-term token case). I think you're asking the wrong question. We should not ask to relax the SSL requirement, but rather - Why do you not want to use SSL? With today's computer speeds, there is no reason not to use SSL. The plain HTTP scheme does not really provide a noticeable enough performance boost. On a side note, if the likes of Google's SPDY is anything to go by, the future might always be SSL only anyway. Cheers, Dave On Tue, Oct 25, 2011 at 4:21 PM, Dan Taflin dan.taf...@gettyimages.com mailto:dan.taf...@gettyimages.com wrote: You're right, if tracking was all we needed then a single token would suffice. The reason for two tokens has more to do with the fact that we'd like to allow protected operations to be called over plain http. This opens up the possibility of an attacker intercepting the token for his own nefarious use. If the only thing that token gave him access to was relatively benign operations like image search, it would be an acceptable risk (especially if we have a relatively short lifespan for the token). In contrast, confidential operations would only be callable over https. By requiring a different token for them (and not allowing that token to be used for unprotected operations) we prevent it from being intercepted. This design intentionally mimics the way secure and non-secure http cookies work. Oauth today basically requires https for all bearer token implementations. I would like to see this relaxed somewhat. Dan From: Dave Rochwerger [mailto:da...@quizlet.com mailto:da...@quizlet.com] Sent: Tuesday, October 25, 2011 4:08 PM To: Dan Taflin Cc: OAuth WG Subject: Re: [OAUTH-WG] Rechartering Is separating this out into 2 different tokens, really the best way to solve your use case? It sounds to me that you simply want to track/log the two types of accesses differently, which can be done entirely outside of the oauth2 process. Just bucket your operations into two piles internally and track appropriately (which you would have to do anyway with scopes). Scopes are the specific access that the end user grants to a 3rd party to access their protected resources. When an application, to use your example, asks for the scope protected confidential, they are providing those two levels of access to the 3rd party application. If the user says allow, then that application has all the access that those two scopes provides. Rather than getting applications to then further choose between two tokens to simply delineate two sets of operations seems like the
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-threatmodel-01.txt
Hi all, the new version of the security document is mostly dedicated to the alignment with the core draft -22. * Alignment of terminology with core draft 22 (private/public client, redirect URI validation policy, replaced definition of the client categories by reference to respective core section) * Synchronisation with the core's security consideration section (UPDATE 10.12 CSRF, NEW 10.14/15) * Added Resource Owner Impersonation * Improved section 5 * Renamed Refresh Token Replacement to Refresh Token Rotation Thanks to all people involved! regards, Torsten. Am 26.10.2011 21:11, schrieb internet-dra...@ietf.org: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth 2.0 Threat Model and Security Considerations Author(s) : Torsten Lodderstedt Mark McGloin Phil Hunt Filename: draft-ietf-oauth-v2-threatmodel-01.txt Pages : 64 Date: 2011-10-26 This document gives security considerations based on a comprehensive threat model for the OAuth 2.0 Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-threatmodel-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-threatmodel-01.txt ___ 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] Rechartering JSON based request.
why is it neccessary to duplicate the OAuth request parameters? Am 27.10.2011 00:31, schrieb John Bradley: Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl. It is essentially a standardization of the method we are using in openID Connect to make signed requests to the Authorization server. We do have the issue that parameters in the signed/encrypted request necessarily duplicate the query parameters to keep it a valid OAuth request plus an extension. Even if it doesn't wind up as a OAuth WG item it is probably worth people looking at it before the final openID spec is voted on. Regards John B. On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote: Hi Nat, I think your proposal would be a useful OAuth enhancement. A JSON-based request format would allow for more complex requests (e.g. carrying resource server URLs and corresponding scope values ;-)). Please note: I also think the way this mechanism is introduced and used in the current OpenID connect spec requires OpenID connect clients and servers to handle OAuth request parameters differently than for standard OAuth requests. Introducing the JSON based claim request capability to OAuth would be a way to cope with this. regards, Torsten. Am 22.10.2011 16:00, schrieb Nat Sakimura: Hi. Just a clarification: Although my expired draft is 'request by reference', what was proposed through it at the iiw really is a generalized JSON based claim request capability. It could be passed by value as JSON or could be passed by reference. The later is an optimization for bandwidth constrained network as well as strengthening security in some ways. This capability already exists in OpenID Connect but it is actually an underpinning transport, so it probably should belong to OAuth instead. This was the primary reason for the proposal. Nat On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt tors...@lodderstedt.net mailto:tors...@lodderstedt.net wrote: Hi all, my prioritization is driven by the goal to make OAuth the authorization framework of choice for any internet standard protocol, such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is missing from my point of view and explain some thoughts how to fill the gaps. A standard protocol is defined in terms of resource types and messages by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and used by different but deployment-independent clients. OAuth-based protocol specifications must also define scope values (e.g. read, write, send) and their relation to the resource types and messages. The different deployments expose the standard protocol on different resource server endpoints. In my opinion, it is fundamental to clearly distinguish scope values (standardized, static) and resource server addresses (deployment specific) and to manage their relationships. The current scope definition is much to weak and insufficient. Probably, the UMA concepts of hosts, resources sets, and corresponding scopes could be adopted for that purpose. OAuth today requires clients to register with the service provider before they are deployed. Would you really expect IMAP clients, e.g. Thunderbird, to register with any a-Mail services upfront? So clients should be given a way to register dynamically to the authorization servers. This should also allow us to cover client instance aspects. It is interesting to note, that such a mechanism would allow us to get rid of secret-less clients and the one-time usage requirement for authorization codes. We also assume the client to know the URLs of the resource server and the corresponding authorization server and to use HTTPS server authentication to verify the resource server's authenticity. This is impossible in the standard scenario. Clients must be able to discover the authorization server a particular resource server relies on at runtime. The discovery mechanism could be specified by the OAuth WG, but could also be part of an application protocols specification. But we MUST find another way to prevent token phishing by counterfeit resource servers. As one approach, the client could pass the (previously HTTPS validated) resource server's URL with the authorization request. The authorization server should then refuse such requests for any unknown (counterfeit) resource servers. Such an additional parameter could also serve as namespace for scope values and enable service providers to run multiple instances of the same service within a single deployment. If the additional data enlarges the request payload to much, we could consider to adopt the request by reference proposal. Let's now assume, OAuth is successful in the world of standard protocols and we will see plenty of deployments with a bunch
Re: [OAUTH-WG] Client credentials for native applications: seeking clarification
http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00 Forest tadafor...@gmail.com schrieb: Thanks for the clarification. The subtle difference makes sense to me, and indeed was what prompted me to address this list in the first place. It *is* subtle, though, and the oauth-v2-22 draft doesn't even hint at it until six sections after a very clear MUST statement apparently forbidding this use of client credentials. I nearly walked away from OAuth 2 as soon as I read that bit in Section 4.4, and I suspect others would do exactly that. I only discovered the distinction because I happened to read an additional twelve discouraging pages past the apparent roadblock. So, for the sake of clarity in the working draft and in the hope of widespread adoption, I suggest that this subtle difference be stated alongside aforementioned MUST statement. I'll read the oauth-security rationale. Thanks for the link. I'm having trouble finding the current device flow proposal. The last mention of it I remember was an earlier oauth-v2 draft. Can you send me a current link? Cheers, Forest On Fri, Oct 21, 2011 at 01:38, Torsten Lodderstedt tors...@lodderstedt.net wrote: Hi, there is no contradiction. The subtle difference lays in the word instance. Using secrets for a software package (and all of its installations) is useless and therefore not allowed. If you are able to issue a distinct id/secret pair to every installation of your app, this is fine. For a the complete rationale pls. take a look into http://tools.ietf.org/html/draft-lodderstedt-oauth-security/. The question is whether you really want to authenticate the client or the user. For users, resource owner password is an option. I agree with you that the user experience is bad. You may consider to use another device (pc, smartphone) to perform the authorization flow. You may take a look onto the device flow proposal. Alternatively, you could utilize the code flow on the secondary device and ask the user to enter the code on the TV Set. regards, Torsten. Forest tadafor...@gmail.com schrieb: Hi there. I've been considering OAuth 2 and its client credentials grant type for use with applications that run on televisions and other consumer devices. It is appealing mainly because it requires no built-in web browser and no cumbersome data entry for the user. (Similar to the Netflix device registration procedure.) However, I think I've run into a snag. Section 4.4 of draft-ietf-oauth-v2-22 says: The client credentials grant type MUST only be used by confidential clients. Since Section 2.1 defines confidential clients as distinct from clients executing on the resource owner's device, I have the impression that this forbids pretty much any device in the user's possession from using client credentials. (Except perhaps the rare gadget that embeds encrypted storage and physical safeguards against key discovery.) I suppose this would mean OAuth 2 is unsuitable for the task at hand. However, Section 10.1 says: The authorization server MAY issue a client password or other credentials for a specific installation of a native application client on a specific device. This seems to contradict Section 4.4, although if I understand it correctly, it would allow me to use client credentials as I had hoped without violating the spec. That's encouraging. Maybe I can use OAuth 2 after all, so long as each installed instance of my application gets its own credentials. So, I could use some clarification on a few points: 1. Is that quote in Section 10.1 meant to be an exception to the one in Section 4.4? If so, I would suggest rephrasing 4.4 to allow for the exception and to make it easier for OAuth 2 implementors to discover. 2. If it is not intended as an exception, meaning that apps running on consumer devices are not to be issued client credentials, what is the recommended alternative? Section 1.3.3 suggests resource owner password credentials when other authorization grant types are not available, and using a long-lived access token or refresh token. I suppose this approach would enable OAuth on devices that have no web browser, though it would create a usability problem by requiring users to enter their credentials using awkward, frustrating input devices (like 5-button remote controls). Perhaps more importantly, it begs the question of how storing a long-lived token is any more secure than storing client credentials. After all, both could grant access, both could be revoked, and both could be exposed just as easily. Which brings me to my third question: 3. From whom is a confidential client expected to keep its credentials secret? From the resource owner? (I suppose this would make sense for a server-side application trusted by many users, but it makes little sense for a consumer device, since a user is unlikely to give out his own device's credentials and could more easily give out his own
Re: [OAUTH-WG] Client credentials for native applications: seeking clarification
Hi, there is no contradiction. The subtle difference lays in the word instance. Using secrets for a software package (and all of its installations) is useless and therefore not allowed. If you are able to issue a distinct id/secret pair to every installation of your app, this is fine. For a the complete rationale pls. take a look into http://tools.ietf.org/html/draft-lodderstedt-oauth-security/. The question is whether you really want to authenticate the client or the user. For users, resource owner password is an option. I agree with you that the user experience is bad. You may consider to use another device (pc, smartphone) to perform the authorization flow. You may take a look onto the device flow proposal. Alternatively, you could utilize the code flow on the secondary device and ask the user to enter the code on the TV Set. regards, Torsten. Forest tadafor...@gmail.com schrieb: Hi there. I've been considering OAuth 2 and its client credentials grant type for use with applications that run on televisions and other consumer devices. It is appealing mainly because it requires no built-in web browser and no cumbersome data entry for the user. (Similar to the Netflix device registration procedure.) However, I think I've run into a snag. Section 4.4 of draft-ietf-oauth-v2-22 says: The client credentials grant type MUST only be used by confidential clients. Since Section 2.1 defines confidential clients as distinct from clients executing on the resource owner's device, I have the impression that this forbids pretty much any device in the user's possession from using client credentials. (Except perhaps the rare gadget that embeds encrypted storage and physical safeguards against key discovery.) I suppose this would mean OAuth 2 is unsuitable for the task at hand. However, Section 10.1 says: The authorization server MAY issue a client password or other credentials for a specific installation of a native application client on a specific device. This seems to contradict Section 4.4, although if I understand it correctly, it would allow me to use client credentials as I had hoped without violating the spec. That's encouraging. Maybe I can use OAuth 2 after all, so long as each installed instance of my application gets its own credentials. So, I could use some clarification on a few points: 1. Is that quote in Section 10.1 meant to be an exception to the one in Section 4.4? If so, I would suggest rephrasing 4.4 to allow for the exception and to make it easier for OAuth 2 implementors to discover. 2. If it is not intended as an exception, meaning that apps running on consumer devices are not to be issued client credentials, what is the recommended alternative? Section 1.3.3 suggests resource owner password credentials when other authorization grant types are not available, and using a long-lived access token or refresh token. I suppose this approach would enable OAuth on devices that have no web browser, though it would create a usability problem by requiring users to enter their credentials using awkward, frustrating input devices (like 5-button remote controls). Perhaps more importantly, it begs the question of how storing a long-lived token is any more secure than storing client credentials. After all, both could grant access, both could be revoked, and both could be exposed just as easily. Which brings me to my third question: 3. From whom is a confidential client expected to keep its credentials secret? From the resource owner? (I suppose this would make sense for a server-side application trusted by many users, but it makes little sense for a consumer device, since a user is unlikely to give out his own device's credentials and could more easily give out his own password.) From other applications running on the same device? (This makes sense, but devices with sandboxed per-application storage would seem to warrant an exception from the clients executing on the resource owner's device generalization in Section 2.1.) From the world at large? (If this is the only level of confidentiality then I would think clients executing on the resource owner's device would easily qualify as confidential.) Thanks, all. I look forward to a better understanding of what is intended here. _ 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] Rechartering
Hi all, my prioritization is driven by the goal to make OAuth the authorization framework of choice for any internet standard protocol, such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is missing from my point of view and explain some thoughts how to fill the gaps. A standard protocol is defined in terms of resource types and messages by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and used by different but deployment-independent clients. OAuth-based protocol specifications must also define scope values (e.g. read, write, send) and their relation to the resource types and messages. The different deployments expose the standard protocol on different resource server endpoints. In my opinion, it is fundamental to clearly distinguish scope values (standardized, static) and resource server addresses (deployment specific) and to manage their relationships. The current scope definition is much to weak and insufficient. Probably, the UMA concepts of hosts, resources sets, and corresponding scopes could be adopted for that purpose. OAuth today requires clients to register with the service provider before they are deployed. Would you really expect IMAP clients, e.g. Thunderbird, to register with any a-Mail services upfront? So clients should be given a way to register dynamically to the authorization servers. This should also allow us to cover client instance aspects. It is interesting to note, that such a mechanism would allow us to get rid of secret-less clients and the one-time usage requirement for authorization codes. We also assume the client to know the URLs of the resource server and the corresponding authorization server and to use HTTPS server authentication to verify the resource server's authenticity. This is impossible in the standard scenario. Clients must be able to discover the authorization server a particular resource server relies on at runtime. The discovery mechanism could be specified by the OAuth WG, but could also be part of an application protocols specification. But we MUST find another way to prevent token phishing by counterfeit resource servers. As one approach, the client could pass the (previously HTTPS validated) resource server's URL with the authorization request. The authorization server should then refuse such requests for any unknown (counterfeit) resource servers. Such an additional parameter could also serve as namespace for scope values and enable service providers to run multiple instances of the same service within a single deployment. If the additional data enlarges the request payload to much, we could consider to adopt the request by reference proposal. Let's now assume, OAuth is successful in the world of standard protocols and we will see plenty of deployments with a bunch of different OAuth protected resource servers. Shall this servers all be accessible with a single token? In my opinion, this would cause security, privacy and/or scalability/performance problems. To give just the most obvious example, the target audience of such a token cannot be restricted enough, which may allow a resource server (or an attacker in control of it) to abuse the token on other servers. But the current design of the code grant type forces deployments to use the same token for all services. What is needed from my point of view is a way to request and issue multiple server-specific access tokens with a single authorization process. I've been advocating this topic for a long time now and I'm still convinced this is required to really complete the core design. We at Deutsche Telekom needed and implemented this function on top of the existing core. In my opinion, a core enhancement would be easier to handle and more powerful. If others support this topic, I would be willed to submit an I-D describing a possible solution. If we take standards really seriously, then service providers should be given the opportunity to implement their service by utilizing standard server implementations. This creates the challenge to find a standardized protocol between authorization server and resource server to exchange authorization data. Depending on the token design (self-contained vs. handle) this could be solved by either standardizing a token format (JWT) or an authorization API. Based on the rationale given above, my list is as follows (topics w/o I-D are marked with *): - Revocation (low hanging fruit since I-D is ready and implemented in some places) - Resource server notion* - Multiple access tokens* - Dynamic client registration 1) Dynamic Client Registration Protocol 4) Client Instance Extension - Discovery (10) Simple Web Discovery, probably other specs as well - (6) JSON Web Token - (7) JSON Web Token (JWT) Bearer Profile - 8) User Experience Extension - Device flow - 9) Request by Reference (depending
Re: [OAUTH-WG] OAuth2 Implementation questions (client secret andrefresh tokens)
Hi Dave, there has been a long debate about native client security and you can also find a comprehensive analysis in the security document. It's just a fact that such clients cannot reliably be authenticated in a public environment (even if malicious clients can be detected in some cases). So it is the responsibility of the resource owner to validate the authenticity/trustworthiness of an app before using it. The authz server's task is to authz access to cloud resources, so it asks the resource owner for consent. Once the consent is given, the refresh token itself represents the fact that the holder should be a legitimate client. regards, Torsten. *From: * Dave Rochwerger da...@quizlet.com *Date: *Wed, 14 Sep 2011 13:45:42 -0700 *To: *Torsten Lodderstedttors...@lodderstedt.net *Cc: *oauth@ietf.org *Subject: *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 mailto: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 mailto: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
Re: [OAUTH-WG] Reviewing draft-ietf-oauth-v2-21
I reviewed the diffs and it looks ok. regards, Torsten. Am 07.09.2011 17:59, schrieb Barry Leiba: As you've all probably seen, Eran has posted version 21 of the OAuth base spec, in which he believes he's addressed all comments and issues that came up in the review of version 20. We should be ready to send this to the IESG. Everyone who had comments or issues, please review -21 and make sure that your concerns have been handled to your satisfaction (or that there was no consensus to make a change). And we encourage everyone to review the changes from -20 to -21, to make sure Eran didn't inadvertently break anything along the way. The -21 is here: http://tools.ietf.org/html/draft-ietf-oauth-v2-21 And diffs from -20 can be found here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-21.txt We'll give it until the end of next week, while I work on the shepherd writeup. Comments, please, by 16 September. A few affirmative notes saying, Yes, I reviewed it and it looks good, will also be helpful. Keep in mind, as you review, that pet changes are out of scope at this point. We're just reviewing -21 to make sure (1) it doesn't break anything from -20, and (2) it isn't missing anything that was brought up in WGLC. New issues will have to be very serious, indeed, in order to be considered now. Also, a note on the thread that Mike Thomas started about the OAuth problem statement and threats: I did encourage him to start the discussion, and I think it can be a useful conversation. I do NOT think it will or should result in a change to the base spec, but it might feed into the threat model document (draft-ietf-oauth-v2-threatmodel), as Torsten, et al, move that toward completion. Remember that the base spec encourages readers to refer to the threat model document for more detailed descriptions of threats and attacks. Barry, as chair ___ 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-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-revocation-03.txt
Hi all, I just published a new revision of the token revocation draft. We added JSONP support (thanks to Marius) and aligned the text with draft 21 of the core spec. We would like to bring this draft forward as working group item (once the WG is ready). We think its relevance is illustrated by the fact that this draft (or its predecessor) has already been implemented by Google, Salesforce, and Deutsche Telekom. regards, Torsten. Original-Nachricht Betreff: New Version Notification for draft-lodderstedt-oauth-revocation-03.txt Datum: Fri, 16 Sep 2011 12:20:14 -0700 Von:internet-dra...@ietf.org An: tors...@lodderstedt.net CC: sdro...@gmx.de, tors...@lodderstedt.net, mscurte...@google.com A new version of I-D, draft-lodderstedt-oauth-revocation-03.txt has been successfully submitted by Torsten Lodderstedt and posted to the IETF repository. Filename:draft-lodderstedt-oauth-revocation Revision:03 Title: Token Revocation Creation date: 2011-09-16 WG ID: Individual Submission Number of pages: 6 Abstract: This draft proposes an additional endpoint for OAuth authorization servers for revoking tokens. The IETF Secretariat ___ 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)
Hi Eran, This is still just a CSRF attack. I think you may be right. I still believe this particular style of attack on the authorization server is worth mentioning, be it in its own separate section or under the existing CSRF section (as you suggested). This is not a style of attack but techniques to enhance other exploits, in this case, CSRF. If you lack CSRF protection, then yes, lack of resource owner forced interaction will make it easier to execute. But that's just a tiny speed bump considering the actual exploit. I don't see any reason to include this new text based on this threat analysis. However, this doesn't mean this discussion wasn't useful. We did identify the need to explicitly discuss CSRF attacks on the authorization endpoint. We need to explicitly separate the two target of CSRF attacks (client, server) because while the solution is the same, the implementation is very different (due to the use of redirections in one). I agree, we should explicitely document these two variants of CSRF (client, authz server). But I suspect it's not only CSRF we are talking about in this thread - at least not textbook CSRF. Let me explain my thoughts: 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. 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. 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. regards, Torsten. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Auth Code Swap Attack
My intention is to require clients to implement CSRF prevention. I thought making the state parameter mandatory would be the straightforward way. regards, Torsten. Am 18.08.2011 08:04, schrieb Eran Hammer-Lahav: I would like to hear from the other 3 authors of the proposed change about their reasons for changing the use of 'state' from recommended to required for CSRF prevention. It would also help moving this issue forward if the 4 authors can provide answers or clarifications on the issues raised below. Assuming we can count all 4 authors are in favor of making the change, I believe we have a tie (4:4) and therefore no consensus for making it (as of this point). However, we did identify issues with the section's language and clarity which we should address either way. To clarify -- I am not proposing we close this issue just yet. EHL *From:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of *Eran Hammer-Lahav *Sent:* Monday, August 15, 2011 9:35 AM *To:* OAuth WG (oauth@ietf.org) *Subject:* Re: [OAUTH-WG] Auth Code Swap Attack To demonstrate why making state required as proposed isn't very helpful, here is an incomplete list of other requirements needed to make an effective CSRF: * State value must not be empty (a common bug in many implementations using simple value comparison). * 'Non-guessable' isn't sufficient as most developers will simply use a hash of the session cookie, with or without salt which isn't sufficient. We use cannot be generated, modified, or guessed to produce valid values elsewhere in the document, but this is much easier to get right for access tokens and refresh tokens than CSRF tokens which are often just some algorithm on top of the session cookie. * State CSRF value should be short-lived or based on a short-lived session cookie to prevent the use of a leaked state value in multiple attacks on the same user session once the leak is no longer viable. In addition, this is not what state was originally intended for. If the working group decides to mandate a CSRF parameter, it should probably be a new parameter with a more appropriate name (e.g. 'csrf'). By forcing clients to use state for this purpose, developers will need to use dynamic queries for other state information which further reduces the security of the protocol (as the draft recommends not using dynamic callback query components). Encoding both CSRF tokens and other state information can be non-intuitive or complicated for some developers/platforms. EHL *From:*Eran Hammer-Lahav *Sent:* Friday, August 12, 2011 2:53 PM *To:* Anthony Nadalin; OAuth WG (oauth@ietf.org mailto:oauth@ietf.org) *Subject:* Re: [OAUTH-WG] Auth Code Swap Attack This is really just a flavor of CSRF attacks. I have no objections to better documenting it (though I feel the current text is already sufficient), but we can't realistically expect to identify and close every possible browser-based attack. A new one is invented every other week. The problem with this text is that developers who do no understand CSRF attacks are not likely to implement it correctly with this information. Those who understand it do not need the extra verbiage which is more confusing than helpful. As for the new requirements, they are insufficient to actually accomplish what the authors propose without additional requirements on state local storage and verification to complete the flow. Also, the proposed text needs clarifications as noted below. *From: *Anthony Nadalin tony...@microsoft.com mailto:tony...@microsoft.com *Date: *Fri, 12 Aug 2011 12:06:36 -0700 *To: *OAuth WG (oauth@ietf.org mailto:oauth@ietf.org) oauth@ietf.org mailto:oauth@ietf.org *Subject: *[OAUTH-WG] Auth Code Swap Attack *Recommended Changes to draft-ietf-oauth-v2* In section 4, request options (e.g. 4.1.1) featuring state should change from: state OPTIONAL. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. to: state REQUIRED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The encoded value SHOULD enable the client application to determine the user-context that was active at the time of the request (see section 10.12). The value MUST NOT be guessable or predictable, and MUST be kept confidential. Making the parameter required without making its usage required (I.e. value SHOULD enable) accomplishes nothing. Also, what does MUST be kept confidential mean? Confidential from what? Why specify an encoded value? Section 10.12 Cross-Site Request Forgery Change to: Cross-site request forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted
Re: [OAUTH-WG] Draft 20 last call comments
I can see the logic of putting both token types first (though I still prefer the auth grant first), but having the auth grant in between the two token types is definitely a bad idea. +1 -- Justin ___ 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] Auth Code Swap Attack
Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav: This is really just a flavor of CSRF attacks. I have no objections to better documenting it (though I feel the current text is already sufficient), but we can't realistically expect to identify and close every possible browser-based attack. A new one is invented every other week. The problem with this text is that developers who do no understand CSRF attacks are not likely to implement it correctly with this information. Those who understand it do not need the extra verbiage which is more confusing than helpful. We are constantly facing the fact that a comprehensive description of security threats needs more space than we have in the core draft. That's the reason why the security document has 63 pages and that's also the reason why we decided to let the core spec refer to this document for in-depth explanations. This holds true for this threat as well. regards, Torsten. As for the new requirements, they are insufficient to actually accomplish what the authors propose without additional requirements on state local storage and verification to complete the flow. Also, the proposed text needs clarifications as noted below. From: Anthony Nadalin tony...@microsoft.com mailto:tony...@microsoft.com Date: Fri, 12 Aug 2011 12:06:36 -0700 To: OAuth WG (oauth@ietf.org mailto:oauth@ietf.org) oauth@ietf.org mailto:oauth@ietf.org Subject: [OAUTH-WG] Auth Code Swap Attack *Recommended Changes to draft-ietf-oauth-v2* In section 4, request options (e.g. 4.1.1) featuring state should change from: state OPTIONAL. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. to: state REQUIRED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The encoded value SHOULD enable the client application to determine the user-context that was active at the time of the request (see section 10.12). The value MUST NOT be guessable or predictable, and MUST be kept confidential. Making the parameter required without making its usage required (I.e. value SHOULD enable) accomplishes nothing. Also, what does MUST be kept confidential mean? Confidential from what? Why specify an encoded value? Section 10.12 Cross-Site Request Forgery Change to: Cross-site request forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from the user-agent of an end-user the server trusts or has authenticated. CSRF attacks enable the attacker to intermix the attacker's security context with that of the resource owner resulting in a compromise of either the resource server or of the client application itself. In the OAuth context, such attacks allow an attacker to inject their own authorization code or access token into a client, which can result in the client using an access token associated with the attacker's account rather than the victim's. Depending on the nature of the client and the protected resources, this can have undesirable and damaging effects. In order to prevent such attacks, the client application MUST encode a non-guessable, confidential end-user artifact and submit as the state parameter to authorization and access token requests to the authorization server. The client MUST keep the state value in a location accessible only by the client or the user-agent (i.e., protected by same-origin policy), for example, using a DOM variable, HTTP cookie, or HTML5 client-side storage. The authorization server includes the value of the state parameter when redirecting the user-agent back to the client. Upon receiving a redirect, the client application MUST confirm that returned value of state corresponds to the state value of the user-agent's user session. If the end-user session represents an authenticated user-identity, the client MUST ensure that the user-identity has NOT changed. The above text uses 'user-context' and this 'user-identity'. Neither term is defined. 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-WG] Draft 20 last call comment (Resource Owner Impersonation)
Hi all, I think the impersonation issue as raised by Niv on the list should be covered by the core spec. It directly aims at the trustworthiness of the user consent, which in my opinion is one of the core principles of OAuth. I therefore suggest to add a description to section 10. Please find below the text Niv and I prepared. In comparison to Niv's original proposal, it covers resource owner impersonation for all client categories. regards, Torsten. proposed text: 10.to be determined Resource Owner Impersonation When a client requests access to protected resources, the authorization flow normally involves the resource owner's explicit response to the access request, either granting or denying access to the protected resources. A malicious client can exploit knowledge of the structure of this flow in order to gain authorization without the resource owner's consent, by transmitting the necessary requests programmatically, and simulating the flow against the authorization server. An suthorization server will be vulnerable to this threat, if it uses non-interactive authentication mechanisms or split the authorization flow across multiple pages. It is RECOMMENDED that the authorization server takes measures to ensure that the authorization flow cannot be simulated. Attacks performed by scripts running within a trusted user-agent can be detected by verifying the source of the request using HTTP referrer headers. In order to prevent such an attack, the authorization server may force a user interaction based on non-predictable input values as part of the user consent approval. The authorization server could combine password authentication and user consent in a single form, make use of CAPTCHAs or one-time secrets. Alternatively, the authorization server could notify the resource owner of any approval by appropriate means, e.g. text message or e-Mail. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Refresh Tokens
OAuth allows a client to access user resources without revealing the resource owner's identity to the client. Isn't this anonymity? I consider this an important property of the protocol. regards, Torsten. On Thu, 11 Aug 2011 21:00:54 -0400, Barry Leiba wrote: This seems to need a chair to step in. Tony is taking a strong stand and maintaining it: On Thu, Aug 11, 2011 at 1:40 PM, Anthony Nadalin tony...@microsoft.com wrote: Nowhere in the specification is there explanation for refresh tokens, The reason that the Refresh token was introduced was for anonymity. The scenario is that a client asks the user for access. The user wants to grant the access but not tell the client the user's identity. By issuing the refresh token as an 'identifier' for the user (as well as other context data like the resource) it's possible now to let the client get access without revealing anything about the user. Recommend that the above explanation be included so developers understand why the refresh tokens are there. So far, though it's been only half a day, I've seen several posts disagreeing with Tony, and none supporting any change to the text for this. We're close to ending WGLC, so please post here if you agree with Tony's suggested change. Otherwise, it looks like consensus is against. Barry, as chair ___ 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: Several typos in -20 and a possible security consideration
I think this threat is similar to clickjacking (http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-10.13). Could we incorporate it into this section (w/o delaying the spec's release process)? regards, Torsten. Am 26.07.2011 19:29, schrieb Niv Steingarten: Would it be possible to consider adding this to the list of security considerations? Of course, the spec cannot cover all possible security threats, but this appears to be a realistic one which could easily be exploited if overlooked by developers (evident in the lack of scraping defense mechanisms in many applications). Is it too late to make such an amendment to the draft? Thank you, Niv On Tue, Jul 26, 2011 at 02:40, Niv Steingartennivst...@gmail.com wrote: Yes, I believe the vast majority of user-agents would block this kind of request if it originated from a JavaScript XMLHttpRequest or such. However, there are still scenarios in which a user-agent based client could manipulate this vulnerability. For example, the client could launch the GET request to the authorization server via animg HTML tag, taking the form of a CSRF. Since it's a blind attack, the client would likely not receive the contents of the web-page. However, this request is still necessary from the client since it has the side-effect of creating an access token (or other temporary token) on the authorization server. Since it is highly likely that a malicious client has a priori knowledge of the structure of the authorization page and form, it does not need the response in order to advance to the next step, and can simply send the fake request to 'Allow' itself to access the resource owner's resources. I believe this attack could be made very hard by either including a CAPTCHA, as you suggested, or including some kind of token or nonce in the submission of the form (which would still not prevent the attack if the authorization server doesn't enforce same origin policy). Niv On Tue, Jul 26, 2011 at 02:10, Torsten Lodderstedt tors...@lodderstedt.net wrote: Hi Niv, thank you for posting this to the list. I think you are right with your threat description. One question: shouldn't the browser already prevent the request to the authorization endpoint because of the same origin policy (or CORS restrictions)? Apart from that, a similar attack can be performed by a native applicication (using an embedded browser). This kind of attack could not be prevented using HTTP features but by enforcing a real user interaction (password input, CAPTCHA). regards, Torsten. Am 25.07.2011 18:27, schrieb Niv Steingarten: Forwarded as per Eran's request. A couple of corrections to my original email: 1. By AJAX, I mean, AJAX like techniques (if the user agent does not enforce same origin policy). 2. When saying POST to '/authorize_callback' -- it may well be GET, if the authorization server mishandles the request. Thank you, Niv -- Forwarded message -- From: Eran Hammer-Lahave...@hueniverse.com Date: Tue, Jul 26, 2011 at 01:21 Subject: RE: Several typos in -20 and a possible security consideration To: Niv Steingartennivst...@gmail.com Please forward this message to the oauth list at oa...@ieft.org. Thanks, EHL From: Niv Steingarten [mailto:nivst...@gmail.com] Sent: Monday, July 25, 2011 2:52 PM To: draft-ietf-oauth...@tools.ietf.org Subject: Several typos in -20 and a possible security consideration Hello, I've noticed a couple of typos in -20: Section 6 (page 41): Under 'The authorization server MUST', the second bullet should end with the word and, and the third bullet should end with a full-stop. Section 10.2 (first paragraph): ...keep is client credentials confidential should be ...keep *its* client credentials confidential. Regarding the security consideration -- I might be missing something, but I saw there are references to clickjacking and to client impersonation, but I haven't seen any reference to possible resource owner impersonation. For example, in the implicit grant flow, a malicious client could send a request to the authorization endpoint via, say, AJAX, and receive the markup of the page asking the resource owner to authorize the client (assuming the resource owner is signed in and no resource owner authentication is required). Then, in a poorly designed authorization endpoint, the 'Allow' button might be the submission button of a form whose target is '/authorize_callback' on the authz server. Then, it may possible for the malicious client to simply POST to '/authorize_callback' and authorize itself without any resource owner intervention or knowledge that the process has even taken place. This, of course, can be mitigated in most modern browsers if the authorization server verifies the source of the request using the HTTP referrer header. Thanks for your time and for the fantastic work on OAuth, -- Niv Steingarten T: +972-54-5828088 E: nivst...@gmail.com W: http://nivstein.com
Re: [OAUTH-WG] treatment of client_id for authentication and identification
the client_id parameter had been added to the token endpoint in -16. As far as I remember, the reason was to properly separate client identification and authentication in order to support further client authentication methods. quote from http://www.ietf.org/mail-archive/web/oauth/current/msg06346.html: The goal is a cleaner protocol design. The protocol design separates client identification as part of the flow (URI parameter) and originator authentication. While the client_id parameter is required, the authentication can be omitted (unauthenticated access) or performed using other authentication mechanisms. And such mechanisms not neccessarily use client_id's. Moreover, the spec just says, The authorization server MUST ensure the two identifiers belong to the same client. So the client_id's (request parameter and header) may differ. You removed the parameter in -17, can you please explain why? regards, Torsten. Am 27.07.2011 18:45, schrieb Eran Hammer-Lahav: There is not clean way of adding it. First where? In each flow of the token endpoint or just in 3.2? Then how is it defined? Optional? Required for public clients? How does it work alongside authentication? If you use client_password or Basic then it becomes authentication but otherwise identification? What about duplication between Basic and the parameter? It also means adding a new section discussing client authentication vs identification which is currently implicit. I strongly believe that it is better to have a simple model as the one already defined in –20 and let other use case find their way around it instead of producing a confusing document that is trying to hard to solve every possible combination. As I said before, we can tweak the definition of client_secret to make it more esthetically pleasing (the server doesn't mind having an empty parameter included, just people), but that's as far am I'm (as wg member) willing to support, especially at this point. EHL From: Torsten Lodderstedt tors...@lodderstedt.net mailto:tors...@lodderstedt.net Date: Wed, 27 Jul 2011 15:21:16 -0700 To: Brian Campbell bcampb...@pingidentity.com mailto:bcampb...@pingidentity.com Cc: Eran Hammer-lahav e...@hueniverse.com mailto:e...@hueniverse.com, oauth oauth@ietf.org mailto:oauth@ietf.org Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification I personally think that would be more confusing than just adding the client_id parameter to the token endpoint request (independent of client authentication credentials). Am 27.07.2011 18:17, schrieb Brian Campbell: I think that would be helpful, thanks. On Wed, Jul 27, 2011 at 12:43 PM, Eran Hammer-Lahave...@hueniverse.com mailto:e...@hueniverse.com wrote: If you want, we can tweak section 2.4.1 to make client_secret optional if the secret is the empty string. That will give you exactly what you want without making the document any more confusing. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] treatment of client_id for authentication and identification
+1 Am 28.07.2011 15:10, schrieb Brian Campbell: I would be very much in favor of that addition/clarification. On Thu, Jul 28, 2011 at 9:20 AM, Eran Hammer-Lahave...@hueniverse.com wrote: [...] and I can also add a short note that public clients may use the client_id for the purpose of identification with the token endpoint. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] treatment of client_id for authentication and identification
Am 27.07.2011 12:08, schrieb Eran Hammer-Lahav: The way I've set it up in --18 is that the client_id parameter in the authorization endpoint is used to identify the client registration record. The identifier is described in section 2.3. Then in section 2.4.1 the parameter is extended for use with the token endpoint for client authentication when Basic is not available. So the idea is that the only place you should be using client_id is with the authorization endpoint to reference the client registration information (needed to lookup the redirection URI). I have argued in the past that a future extension to remove the need to register clients should make this parameter optional but that's outside our current scope. The token endpoint performs client authentication instead of client identification using the client identifier as username. It can do so for confidential clients only. What about public clients using e.g. the Resource Owners Password flow? I see the need to identify them as well. For example, if the authz server issues a refresh token to such a client there must be a way to relate this token to a certain client in order to give the user a chance to revoke this specific token. regards, Torsten. Hope this helps. EHL From: Brian Campbell bcampb...@pingidentity.com mailto:bcampb...@pingidentity.com Date: Wed, 27 Jul 2011 04:32:42 -0700 To: Eran Hammer-lahav e...@hueniverse.com mailto:e...@hueniverse.com Cc: oauth oauth@ietf.org mailto:oauth@ietf.org Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification Okay, looking at some of those drafts again, I see that now. Except for -16 they are all pretty similar on client_id back to -10. Apparently it was my misunderstanding. Maybe I'm the only one who doesn't get it but I do think it could be clearer. I'd propose some text but I'm still not fully sure I understand what is intended. If a client doesn't have a secret, is client_id a SHOULD NOT, a MUST NOT or OPTIONAL to be included on token endpoint requests? Here's a specific question/example to illustrate my continued confusion - it would seem like the majority of clients that would use the Resource Owner Password Credentials grant (although 4.3.2 shows the use of HTTP Basic) would be public clients. How is it expected that such clients Identify themselves to the AS? The client identity, even if not something that can be strongly relied on, is useful for things like presenting a list of access grants to the user for revocation. http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-4.3.2 On Tue, Jul 26, 2011 at 12:17 PM, Eran Hammer-Lahav e...@hueniverse.com mailto:e...@hueniverse.com wrote: Not exactly. The current setup was pretty stable up to --15. In --16 I tried to clean it up by moving the parameter into each token endpoint type definition. That didn't work and was more confusing so in --17 I reverted back to the --15 approach. What makes this stand out in --20 is that all the examples now use HTTP Basic instead of the parameters (since we decided to make them NOT RECOMMENDED). So it feels sudden that client_id is gone, but none of this is actually much different from --15 on. Client authentication is still performed the same way, and the role of client_id is just as an alternative to using HTTP Basic on the token endpoint. I think the current text is sufficient, but if you want to provide specific additions I'm open to it. EHL From: Brian Campbell bcampb...@pingidentity.com mailto:bcampb...@pingidentity.com Date: Tue, 26 Jul 2011 10:16:21 -0700 To: Eran Hammer-lahav e...@hueniverse.com mailto:e...@hueniverse.com Cc: oauth oauth@ietf.org mailto:oauth@ietf.org Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification I'm probably somewhat biased by having read previous version of the spec, previous WG list discussions, and my current AS implementation (which expects client_id) but this seems like a fairly big departure from what was in -16. I'm okay with the change but feel it's wroth mentioning that it's likely an incompatible one. That aside, I feel like it could use some more explanation in draft-ietf-oauth-v2 because, at least to me and hence my question, it wasn't entirely clear how client_id should be used for those cases. On Mon, Jul 25, 2011 at 4:18 PM, Eran Hammer-Lahav e...@hueniverse.com mailto:e...@hueniverse.com wrote: The client_id is currently only defined for password authentication on the token
Re: [OAUTH-WG] treatment of client_id for authentication and identification
There is no need and I don't intend to pro-forma issue client secrets just to conform to some text of the spec. I thought we are beyond that point. The obvious approach would be to use the client_id the same way as it is used on the authz endpoint. regards, Torsten. Am 27.07.2011 13:45, schrieb Eran Hammer-Lahav: You just issue them a set of password credentials (which can include an empty or fixed password). There is nothing preventing you from doing that and once you do, the spec requires them to use those credentials. EHL From: Torsten Lodderstedt tors...@lodderstedt.net mailto:tors...@lodderstedt.net Date: Wed, 27 Jul 2011 10:38:36 -0700 To: Eran Hammer-lahav e...@hueniverse.com mailto:e...@hueniverse.com Cc: Brian Campbell bcampb...@pingidentity.com mailto:bcampb...@pingidentity.com, oauth oauth@ietf.org mailto:oauth@ietf.org Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification Am 27.07.2011 12:08, schrieb Eran Hammer-Lahav: The way I've set it up in –18 is that the client_id parameter in the authorization endpoint is used to identify the client registration record. The identifier is described in section 2.3. Then in section 2.4.1 the parameter is extended for use with the token endpoint for client authentication when Basic is not available. So the idea is that the only place you should be using client_id is with the authorization endpoint to reference the client registration information (needed to lookup the redirection URI). I have argued in the past that a future extension to remove the need to register clients should make this parameter optional but that's outside our current scope. The token endpoint performs client authentication instead of client identification using the client identifier as username. It can do so for confidential clients only. What about public clients using e.g. the Resource Owners Password flow? I see the need to identify them as well. For example, if the authz server issues a refresh token to such a client there must be a way to relate this token to a certain client in order to give the user a chance to revoke this specific token. regards, Torsten. Hope this helps. EHL From: Brian Campbell bcampb...@pingidentity.com mailto:bcampb...@pingidentity.com Date: Wed, 27 Jul 2011 04:32:42 -0700 To: Eran Hammer-lahav e...@hueniverse.com mailto:e...@hueniverse.com Cc: oauth oauth@ietf.org mailto:oauth@ietf.org Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification Okay, looking at some of those drafts again, I see that now. Except for -16 they are all pretty similar on client_id back to -10. Apparently it was my misunderstanding. Maybe I'm the only one who doesn't get it but I do think it could be clearer. I'd propose some text but I'm still not fully sure I understand what is intended. If a client doesn't have a secret, is client_id a SHOULD NOT, a MUST NOT or OPTIONAL to be included on token endpoint requests? Here's a specific question/example to illustrate my continued confusion - it would seem like the majority of clients that would use the Resource Owner Password Credentials grant (although 4.3.2 shows the use of HTTP Basic) would be public clients. How is it expected that such clients Identify themselves to the AS? The client identity, even if not something that can be strongly relied on, is useful for things like presenting a list of access grants to the user for revocation. http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-4.3.2 On Tue, Jul 26, 2011 at 12:17 PM, Eran Hammer-Lahav e...@hueniverse.com mailto:e...@hueniverse.com wrote: Not exactly. The current setup was pretty stable up to –15. In –16 I tried to clean it up by moving the parameter into each token endpoint type definition. That didn't work and was more confusing so in –17 I reverted back to the –15 approach. What makes this stand out in –20 is that all the examples now use HTTP Basic instead of the parameters (since we decided to make them NOT RECOMMENDED). So it feels sudden that client_id is gone, but none of this is actually much different from –15 on. Client authentication is still performed the same way, and the role of client_id is just as an alternative to using HTTP Basic on the token endpoint. I think the current text is sufficient, but if you want to provide specific additions I'm open
Re: [OAUTH-WG] treatment of client_id for authentication and identification
I personally think that would be more confusing than just adding the client_id parameter to the token endpoint request (independent of client authentication credentials). Am 27.07.2011 18:17, schrieb Brian Campbell: I think that would be helpful, thanks. On Wed, Jul 27, 2011 at 12:43 PM, Eran Hammer-Lahave...@hueniverse.com wrote: If you want, we can tweak section 2.4.1 to make client_secret optional if the secret is the empty string. That will give you exactly what you want without making the document any more confusing. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Comments on -18
Hi Eran, section 5.2 The authorization server MAY return an HTTP 401 (Unauthorized) status code to indicate which HTTP authentication schemes are supported. Given the usage of HTTP authentication schemes is the way to authenticated client recommended by the spec, status code 401 should be the default status code for this kind of error. Usage of status code 400 should be the exception. unauthorized_client So above - status code 403 seems to be a more appropriate default. I think this is fine unchanged. Can you please give a rationale? ... section 10.6 Please replace the first sentence with the following text: Such an attack leverages the authorization code ... That reads funny. How about 'An attacker can leverage...' No one said we have to write boring text :-) Your proposal is fine. regards, Torsten. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Issue 16, revised Redirection URI section (3.1.2)
Hi Eran, Am 25.07.2011 03:28, schrieb Eran Hammer-Lahav: -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Wednesday, July 20, 2011 2:15 PM The authorization server redirects the user-agent to the client's redirection URI previously established with the authorization server during the client registration process. Conflicts with section 3.1.2.3, which allows to pass a redirect_uri via URI query parameter. Added 'or when initiating the authorization request' 3.1.2.1 Endpoint Confidentiality What does endpoint confidentiality mean? Which endpoint does this text refer to? The client's redirect_uri endpoint? This is a sub-section of the Redirection URI endpoint. ok, but how can an endpoint be confidential? 3.1.2.5. Endpoint Content As this section discusses security aspects of the client's implementation of the redirect_uri page, shouldn't this go to the security considerations section? I think it is important enough to appear earlier. It is part of my effort to integrate concrete normative language from the security sections up to the protocol sections. Understood and in support for this approach. Wouldn't this mean to remove some text from section 10 in order to prevent redundancies? Regarding this particular section: I think the two different issues (transport security and endpoint authenticity) should be presented separately. regards, Torsten. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Section 10.1 (Client authentication)
+1 Am 25.07.2011 02:16, schrieb Eran Hammer-Lahav: How about, add this to 10.1: When client authentication is not possible, the authorization server SHOULD employ other means to validate the client's identity. For example, by requiring the registration of the client redirection URI or enlisting the resource owner to confirm identity. The authorization server must consider the security implications of interacting with unauthenticated clients and take measures to limit the potential exposure of other credentials (e.g. refresh tokens) issued to such clients. EHL *From:*Torsten Lodderstedt [mailto:tors...@lodderstedt.net] *Sent:* Sunday, July 10, 2011 1:59 AM *To:* Eran Hammer-Lahav; OAuth WG *Subject:* RE: Section 10.1 (Client authentication) Hi, I just remembered the original aim of the text. We not just intended to list alternative means but to get a general message across: If you cannot authenticate a client considers this in your security design! Either (1) you accept the fact the respective identities can be forged and handle them as untrusted entities through your logic (as far as I remember Skylar suggested the term forgeable clients) or (2) you find other ways to establish trust in the client's identity. The effect of (1) depends on the security policy of the certain deployment and the risk associated with certain functions. It could e.g. mean to rely on the id to aggregate log entries (not critical) but never to automatically process authz processes or settle payment transaction. Examples for (2) are: redirect uri validation, relying on the user to identify the client, and (subsequently) use refresh tokens as mean for client authentication. I don't think we can give a complete list of means here since I assume some deployments will have their own capabilities. Please also note: redirect uri validation is not an adequate replacement for client authentication. It's not effective for native apps and useless if the attacker uses a native app (no matter whether the legitimate client is a web, user agent based or native app). regards, Torsten. Eran Hammer-Lahav e...@hueniverse.com mailto:e...@hueniverse.com schrieb: Hey Torsten, The provided text and alternative text are just not helpful. If I am unable to understand it, I have doubt other readers will be able to. I don't know what you mean by 'other means' which are not already described in the document (based on -17). Referencing the security thread model document in a normative reference requires making it a normative reference which I am opposed to doing - the v2 document should include everything needed to implement the protocol without any additional specifications (for the core functionality). When I was asking for examples, I was hoping for something like 'for example, use x, y, or z', not a reference to about 10 pages of text (which by itself is pretty confusing, but that's a different issue - I hope to find the time to provide detailed feedback for that document). I think the current document makes a pretty good case for using the redirection URI as a form of client validation, and clearly lays out the differences between a public and private client. It has new requirements for the registration of redirection URIs when client authentication is not possible. If there are specific things the authorization server can do to improve security beyond client authentication, we should list them explicitly in the document. Can you list exactly what you have in mind by 'other means'? Just the bullet points will be enough. EHL -Original Message- From: Torsten Lodderstedt[mailto:tors...@lodderstedt.net] mailto:[mailto:tors...@lodderstedt.net] Sent: Friday, July 08, 2011 12:59 AM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Section 10.1 (Client authentication) seems you are contradicting yourself. You criticised the MUST and suggested to include some examples. I bought into your argument and suggested to refer to the security doc for examples and additional explanations. That's what this document is intended for, to provide background beyond what we can cover in the core spec. And I don't think the spec already makes that point. But you are free to refer me to the respective text. regards, Torsten. Eran Hammer-Lahave...@hueniverse.com mailto:e...@hueniverse.com schrieb: I still don’t find it useful. I think the existing text overall makes this point already. EHL From: Torsten Lodderstedt[mailto:tors...@lodderstedt.net] mailto:[mailto:tors...@lodderstedt.net] Sent: Wednesday, July 06, 2011 12:48 AM To: Eran Hammer-Lahav; OAuth WG Subject: Re: Section 10.1 (Client authentication) Hi Eran, I would suggest to change it to SHOULD and add a reference to https://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00 sections 3.7 and 5.2.3
Re: [OAUTH-WG] Issue 16, revised Redirection URI section (3.1.2)
Hi Eran, Regarding this particular section: I think the two different issues (transport security and endpoint authenticity) should be presented separately. Which section? 3.1.2.1. regards, Torsten. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
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
Re: [OAUTH-WG] Fwd: Several typos in -20 and a possible security consideration
Hi Niv, thank you for posting this to the list. I think you are right with your threat description. One question: shouldn't the browser already prevent the request to the authorization endpoint because of the same origin policy (or CORS restrictions)? Apart from that, a similar attack can be performed by a native applicication (using an embedded browser). This kind of attack could not be prevented using HTTP features but by enforcing a real user interaction (password input, CAPTCHA). regards, Torsten. Am 25.07.2011 18:27, schrieb Niv Steingarten: Forwarded as per Eran's request. A couple of corrections to my original email: 1. By AJAX, I mean, AJAX like techniques (if the user agent does not enforce same origin policy). 2. When saying POST to '/authorize_callback' -- it may well be GET, if the authorization server mishandles the request. Thank you, Niv -- Forwarded message -- From: *Eran Hammer-Lahav* e...@hueniverse.com mailto:e...@hueniverse.com Date: Tue, Jul 26, 2011 at 01:21 Subject: RE: Several typos in -20 and a possible security consideration To: Niv Steingarten nivst...@gmail.com mailto:nivst...@gmail.com Please forward this message to the oauth list at oa...@ieft.org mailto:oa...@ieft.org. Thanks, EHL *From:*Niv Steingarten [mailto:nivst...@gmail.com mailto:nivst...@gmail.com] *Sent:* Monday, July 25, 2011 2:52 PM *To:* draft-ietf-oauth...@tools.ietf.org mailto:draft-ietf-oauth...@tools.ietf.org *Subject:* Several typos in -20 and a possible security consideration Hello, I've noticed a couple of typos in -20: Section 6 (page 41): Under 'The authorization server MUST', the second bullet should end with the word and, and the third bullet should end with a full-stop. Section 10.2 (first paragraph): ...keep is client credentials confidential should be ...keep *its* client credentials confidential. Regarding the security consideration -- I might be missing something, but I saw there are references to clickjacking and to client impersonation, but I haven't seen any reference to possible resource owner impersonation. For example, in the implicit grant flow, a malicious client could send a request to the authorization endpoint via, say, AJAX, and receive the markup of the page asking the resource owner to authorize the client (assuming the resource owner is signed in and no resource owner authentication is required). Then, in a poorly designed authorization endpoint, the 'Allow' button might be the submission button of a form whose target is '/authorize_callback' on the authz server. Then, it may possible for the malicious client to simply POST to '/authorize_callback' and authorize itself without any resource owner intervention or knowledge that the process has even taken place. This, of course, can be mitigated in most modern browsers if the authorization server verifies the source of the request using the HTTP referrer header. Thanks for your time and for the fantastic work on OAuth, -- *Niv Steingarten* T:+972-54-5828088 E: nivst...@gmail.com mailto:nivst...@gmail.com W:http://nivstein.com -- *Niv Steingarten* * * T:+972-54-5828088 E: nivst...@gmail.com mailto:nivst...@gmail.com W:http://nivstein.com ___ 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] Issue 18: defining new response types
So far response type values are just strings one need to compare literally. What use case justifies the more complex proposal? regards, Torsten. Am 15.07.2011 19:44, schrieb Eran Hammer-Lahav: I was only arguing against the proposed text which doesn't accomplish what you want from a normative perspective. I can easily address the use case with very short prose but I would like to see more working group discussion about it first. Seems like WG members representing three large OAuth implementations (Facebook, Google, Microsoft) are very supportive. Does anyone objects to making the change to allow space-delimited values in the response_type parameter? Once we get consensus on that, I can proceed to offer a proposal. The main difficulty is how to deal with errors. EHL *From:*Mike Jones [mailto:michael.jo...@microsoft.com] *Sent:* Friday, July 15, 2011 10:16 AM *To:* Eran Hammer-Lahav; oauth@ietf.org *Subject:* RE: Issue 18: defining new response types Yes, that's the intent of the change *From:*Eran Hammer-Lahav [mailto:e...@hueniverse.com] mailto:[mailto:e...@hueniverse.com] *Sent:* Friday, July 15, 2011 10:14 AM *To:* Mike Jones; oauth@ietf.org mailto:oauth@ietf.org *Subject:* RE: Issue 18: defining new response types You can't have it both way. Either it is a simple string comparison or it requires parsing of the string. The current prose is designed to offer a visual cue without making any code changes to how response types are compared. To allow different orders, we have to turn the value to a parsed list. EHL *From:*oauth-boun...@ietf.org mailto:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] mailto:[mailto:oauth-boun...@ietf.org] *On Behalf Of *Mike Jones *Sent:* Friday, July 15, 2011 10:02 AM *To:* oauth@ietf.org mailto:oauth@ietf.org *Subject:* [OAUTH-WG] Issue 18: defining new response types I agree that this functionality is needed. However, I believe its current embodiment is overly restrictive. I would suggest changing this text: Only one response type of each combination may be registered and used for making requests. Composite response types are treated and compared in the same as manner as non-composite response types. The + notation is meant only to improve human readability and is not used for machine parsing. For example, an extension can define and register the token+coderesponse type. However, once registered, the same combination cannot be registered as code+token, or used to make an authorization request. to this: The order of the composite response type values is not significant. For instance, the composite response types token+codeand code+tokenare equivalent. Each composite response type value MUST occur only once. Thanks, -- Mike ___ 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-WG] Issue 15, new client registration
2.1 Client types I'm struggeling with the new terminology of private and public clients. In my perception, the text just distinguishes clients which can be authenticated and such which cannot. This is fine but I consider the wording misleading. I would suggest to change it to something like trusted/untrusted or authenticated/unauthenticated or Verifiable/Forgeable. Moreover, I think merging section 2.1 with the text on client types in section 10 would make sense for the following reasons: - there is large overlap between them - It would introduce the term native application before it is used for the first time in Section 9 2.2. Registration Requirements Why is the redirect URI a MUST? It should be a MUST for clients using the implicit grant and probably for private clients but why generally? I would suggest to change this to RECOMMENDED. 2.4 Client Authentication In addition, the client and authorization server establish a client authentication method suitable for the client type and security requirements of the authorization server. Does this hold true for public clients? 2.4.1 Client Password ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Issue 15, new client registration
2.1 Client types I'm struggeling with the new terminology of private and public clients. In my perception, the text just distinguishes clients which can be authenticated and such which cannot. This is fine but I consider the wording misleading. I would suggest to change it to something like trusted/untrusted or authenticated/unauthenticated or Verifiable/Forgeable. Moreover, I think merging the text on client types in section 10 into section 2.1 would make sense for the following reasons: - there is large overlap between them - It would introduce the term native application before it is used for the first time in Section 9 2.2. Registration Requirements Why is the redirect URI a MUST? It should be a MUST for clients using the implicit grant and probably for private clients but why generally? I would suggest to change this to RECOMMENDED. 2.4 Client Authentication In addition, the client and authorization server establish a client authentication method suitable for the client type and security requirements of the authorization server. Does this hold true for public clients? 2.4.1 Client Password Clients in possession of a client password MAY Why not SHOULD? regards, Torsten. Am 20.07.2011 22:56, schrieb Torsten Lodderstedt: 2.1 Client types I'm struggeling with the new terminology of private and public clients. In my perception, the text just distinguishes clients which can be authenticated and such which cannot. This is fine but I consider the wording misleading. I would suggest to change it to something like trusted/untrusted or authenticated/unauthenticated or Verifiable/Forgeable. Moreover, I think merging section 2.1 with the text on client types in section 10 would make sense for the following reasons: - there is large overlap between them - It would introduce the term native application before it is used for the first time in Section 9 2.2. Registration Requirements Why is the redirect URI a MUST? It should be a MUST for clients using the implicit grant and probably for private clients but why generally? I would suggest to change this to RECOMMENDED. 2.4 Client Authentication In addition, the client and authorization server establish a client authentication method suitable for the client type and security requirements of the authorization server. Does this hold true for public clients? 2.4.1 Client Password ___ 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-WG] Issue 16, revised Redirection URI section (3.1.2)
The authorization server redirects the user-agent to the client's redirection URI previously established with the authorization server during the client registration process. Conflicts with section 3.1.2.3, which allows to pass a redirect_uri via URI query parameter. 3.1.2.1 Endpoint Confidentiality What does endpoint confidentiality mean? Which endpoint does this text refer to? The client's redirect_uri endpoint? The text, in my opinion, covers two different scenarios: first paragraph: confidentiality of access tokens and authz codes in transit. second paragraph/last sentence: men-in-the-middle attacks Those attacks are also covered in sections 10.5 and 10.8. 3.1.2.5. Endpoint Content As this section discusses security aspects of the client's implementation of the redirect_uri page, shouldn't this go to the security considerations section? regards, Torsten. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Issue 17, new token endpoint Client Authentication section (3.2.1)
just a minor issue In addition, this specification does not provide a mechanism for refresh token rotation. The spec provides a mechanisms. It allows for the issuance of a new refresh token with every request to referesh an access token. regards, Torsten. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Comments on -18
section 1.5 (A) The client requests an access token by authenticating with the authorization server, and presenting an authorization grant. This statement does not reflect that client authentication is not always required. Proposal: The client requests an access token by presenting an authorization grant. The authorization server may require the client to authenticate as a pre-requisite. section 4.1 (D) The client requests an access token from the authorization server's token endpoint by including the authorization code received in the previous step. When making the request, the client authenticates with the authorization server. Same as above. Proposal: When making the request, the client may be required to authenticate with the authorization server (E) The authorization server authenticates the client, validates the authorization code, and ensures the redirection URI received matches the URI used to redirect the client in step (C). Same as above. Additionally, is the URI check also required if the client did not passed a redirect uri but relied on its pre-registered redirect_uri? section 4.1.1 state parameter: Would it make sense to elaborate on the usage of this parameter and its importance for preventing CSRF attacks (incl. the nessessary entropy)? Alternatively, a reference to the security consideration section could be added. section 4.1.3 If the client type is private or was issued client credentials ... Isn't the later the most important property of a private client? If so, or was issued client credentials is redundant. section 4.4.3 A refresh token SHOULD NOT be included. Why not MUST NOT? section 5.2 The authorization server MAY return an HTTP 401 (Unauthorized) status code to indicate which HTTP authentication schemes are supported. Given the usage of HTTP authentication schemes is the way to authenticated client recommended by the spec, status code 401 should be the default status code for this kind of error. Usage of status code 400 should be the exception. unauthorized_client So above - status code 403 seems to be a more appropriate default. section 10 and furthermore that rotation of the client authentication credentials is impractical. What does this mean? Please update reference [I-D.lodderstedt-oauth-security] to [I-D.ietf-oauth-v2-threatmodel]. section 10.2 last sentence: ... ensure the repeated request comes from an authentic client and not an impersonator. The authorization server must ensure that the request comes from the same client not just any authentic client. So I would propose to adjust the text as follows: ... ensure the repeated request comes from the original client and not an impersonator. section 10.3 Access token (as well as any type-specific attributes) MUST ... does type-specific refer to access token type specific? If so, please add this information. section 10.6 Please replace the first sentence with the following text: Such an attack leverages the authorization code ... ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Refresh token security considerations
Why? William J. Mills wmi...@yahoo-inc.com schrieb: I agree that this is something you could do, but it doesn't seem like a good design pattern. _ From: Torsten Lodderstedt tors...@lodderstedt.net To: Eran Hammer-Lahav e...@hueniverse.com; OAuth WG oauth@ietf.org Sent: Sunday, July 10, 2011 1:21 AM Subject: Re: [OAUTH-WG] Refresh token security considerations replacement of the refresh token with every access token refresh is an example. The authz server creates and returns a new refresh token value with every access token refreshment. The old value is invalidated and must not be used any further. Note: The authz server keeps track of all old (invalidated) refresh tokens. If a client presents one of those old refresh tokens, the legitimate client has been compromised most likely. The authz then revokes the refresh token and the associated access authorization. regards, Torsten. Eran Hammer-Lahav e...@hueniverse.com schrieb: “the authorization server SHOULD deploy other means to detect refresh token abuse” This requires an example. 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
Re: [OAUTH-WG] Refresh token security considerations
replacement of the refresh token with every access token refresh is an example. The authz server creates and returns a new refresh token value with every access token refreshment. The old value is invalidated and must not be used any further. Note: The authz server keeps track of all old (invalidated) refresh tokens. If a client presents one of those old refresh tokens, the legitimate client has been compromised most likely. The authz then revokes the refresh token and the associated access authorization. regards, Torsten. Eran Hammer-Lahav e...@hueniverse.com schrieb: “the authorization server SHOULD deploy other means to detect refresh token abuse” This requires an example. EHL ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Section 10.1 (Client authentication)
Hi, I just remembered the original aim of the text. We not just intended to list alternative means but to get a general message across: If you cannot authenticate a client considers this in your security design! Either (1) you accept the fact the respective identities can be forged and handle them as untrusted entities through your logic (as far as I remember Skylar suggested the term forgeable clients) or (2) you find other ways to establish trust in the client's identity. The effect of (1) depends on the security policy of the certain deployment and the risk associated with certain functions. It could e.g. mean to rely on the id to aggregate log entries (not critical) but never to automatically process authz processes or settle payment transaction. Examples for (2) are: redirect uri validation, relying on the user to identify the client, and (subsequently) use refresh tokens as mean for client authentication. I don't think we can give a complete list of means here since I assume some deployments will have their own capabilities. Please also note: redirect uri validation is not an adequate replacement for client authentication. It's not effective for native apps and useless if the attacker uses a native app (no matter whether the legitimate client is a web, user agent based or native app). regards, Torsten. Eran Hammer-Lahav e...@hueniverse.com schrieb: Hey Torsten, The provided text and alternative text are just not helpful. If I am unable to understand it, I have doubt other readers will be able to. I don't know what you mean by 'other means' which are not already described in the document (based on -17). Referencing the security thread model document in a normative reference requires making it a normative reference which I am opposed to doing - the v2 document should include everything needed to implement the protocol without any additional specifications (for the core functionality). When I was asking for examples, I was hoping for something like 'for example, use x, y, or z', not a reference to about 10 pages of text (which by itself is pretty confusing, but that's a different issue - I hope to find the time to provide detailed feedback for that document). I think the current document makes a pretty good case for using the redirection URI as a form of client validation, and clearly lays out the differences between a public and private client. It has new requirements for the registration of redirection URIs when client authentication is not possible. If there are specific things the authorization server can do to improve security beyond client authentication, we should list them explicitly in the document. Can you list exactly what you have in mind by 'other means'? Just the bullet points will be enough. EHL -Original Message- From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Friday, July 08, 2011 12:59 AM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Section 10.1 (Client authentication) seems you are contradicting yourself. You criticised the MUST and suggested to include some examples. I bought into your argument and suggested to refer to the security doc for examples and additional explanations. That's what this document is intended for, to provide background beyond what we can cover in the core spec. And I don't think the spec already makes that point. But you are free to refer me to the respective text. regards, Torsten. Eran Hammer-Lahav e...@hueniverse.com schrieb: I still don’t find it useful. I think the existing text overall makes this point already. EHL From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Wednesday, July 06, 2011 12:48 AM To: Eran Hammer-Lahav; OAuth WG Subject: Re: Section 10.1 (Client authentication) Hi Eran, I would suggest to change it to SHOULD and add a reference to https://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00 sections 3.7 and 5.2.3. regards, Torsten. Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com schrieb: It's a pointless MUST given how undefined the requirements are. It will only be understood by security experts and they don't really need it. At a minimum, it needs some examples. EHL From: Torsten Lodderstedt tors...@lodderstedt.netmailto:tors...@lodderstedt.net Date: Wed, 1 Jun 2011 00:53:37 -0700 To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com, OAuth WG oauth@ietf.orgmailto:oauth@ietf.org Subject: 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
Re: [OAUTH-WG] state parameter and XSRF detection
. Understood and afterwards agreed. I would be happy to add this to the security document. regards, Torsten. If I had it my way, the specification would ban any type of dynamic redirection URI (other than selecting one out of multiple fully specified options). But this proposal was rejected (for no good reasons, just people stuck to their broken old ways), so the new text is the best I can do without making breaking changes. EHL From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Friday, July 08, 2011 1:23 AM To: Eran Hammer-Lahav; OAuth WG Subject: RE: [OAUTH-WG] state parameter and XSRF detection Hi Eran, including dynamic values within redirect uris is standard practice today and is allowed by the spec's text so far. I don't mind to change it but the restricted behavior you prefer is a significant protocol change. Moreover, I would like to understand the threat you have in mind and include it into our threat model. So would you please provide a more detailed description? regards, Torsten. Eran Hammer-Lahav e...@hueniverse.com schrieb: Allowing any flexibly in the redirection URI is a bad thing and the latest draft (pre -17) clearly states that. The main fear is that by allowing the query to be changed dynamically, attackers can find open redirector loopholes to abuse. I really wanted to make registration of the absolute URI a MUST, but didn't go that far. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Monday, June 27, 2011 2:22 PM To: OAuth WG Subject: [OAUTH-WG] state parameter and XSRF detection Hi all, while working on a new revision of the OAuth security document, a question arose I would like to clarify on the list. The state parameter is supposed to be used to link a certain authorization request and response. Therefore, the client stores a value in this parameter that is somehow bound to a value retained on the device (the user agent) originating the authorization request. The question now is: Would it be compliant with the core spec to use any other URI query parameter encoded in the redirect_uri, instead of the state parameter, to achieve the same goal? Probably the client already has a working legacy implementation it does not want to change just for OAuth2 compliance. According to section 2.2.1, the redirection uri could contain a dynamic portion: The authorization server SHOULD require the client to pre-register their redirection URI or at least certain components such as the scheme, host, port and path So this should be fine. Any comments? regards, Torsten. 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] Section 10.1 (Client authentication)
seems you are contradicting yourself. You criticised the MUST and suggested to include some examples. I bought into your argument and suggested to refer to the security doc for examples and additional explanations. That's what this document is intended for, to provide background beyond what we can cover in the core spec. And I don't think the spec already makes that point. But you are free to refer me to the respective text. regards, Torsten. Eran Hammer-Lahav e...@hueniverse.com schrieb: I still don’t find it useful. I think the existing text overall makes this point already. EHL From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Wednesday, July 06, 2011 12:48 AM To: Eran Hammer-Lahav; OAuth WG Subject: Re: Section 10.1 (Client authentication) Hi Eran, I would suggest to change it to SHOULD and add a reference to https://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00 sections 3.7 and 5.2.3. regards, Torsten. Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com schrieb: It's a pointless MUST given how undefined the requirements are. It will only be understood by security experts and they don't really need it. At a minimum, it needs some examples. EHL From: Torsten Lodderstedt tors...@lodderstedt.netmailto:tors...@lodderstedt.net Date: Wed, 1 Jun 2011 00:53:37 -0700 To: Eran Hammer-lahav e...@hueniverse.commailto:e...@hueniverse.com, OAuth WG oauth@ietf.orgmailto:oauth@ietf.org Subject: 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] state parameter and XSRF detection
Hi Eran, including dynamic values within redirect uris is standard practice today and is allowed by the spec's text so far. I don't mind to change it but the restricted behavior you prefer is a significant protocol change. Moreover, I would like to understand the threat you have in mind and include it into our threat model. So would you please provide a more detailed description? regards, Torsten. Eran Hammer-Lahav e...@hueniverse.com schrieb: Allowing any flexibly in the redirection URI is a bad thing and the latest draft (pre -17) clearly states that. The main fear is that by allowing the query to be changed dynamically, attackers can find open redirector loopholes to abuse. I really wanted to make registration of the absolute URI a MUST, but didn't go that far. EHL -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Monday, June 27, 2011 2:22 PM To: OAuth WG Subject: [OAUTH-WG] state parameter and XSRF detection Hi all, while working on a new revision of the OAuth security document, a question arose I would like to clarify on the list. The state parameter is supposed to be used to link a certain authorization request and response. Therefore, the client stores a value in this parameter that is somehow bound to a value retained on the device (the user agent) originating the authorization request. The question now is: Would it be compliant with the core spec to use any other URI query parameter encoded in the redirect_uri, instead of the state parameter, to achieve the same goal? Probably the client already has a working legacy implementation it does not want to change just for OAuth2 compliance. According to section 2.2.1, the redirection uri could contain a dynamic portion: The authorization server SHOULD require the client to pre-register their redirection URI or at least certain components such as the scheme, host, port and path So this should be fine. Any comments? regards, Torsten. _ 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] security considerations - authorization tokens
Hi Brian, your text is definitely a valuable contribution. Please note: your earlier text on OAuth security considerations has already been incorporated into the security document. I would suggest to first incorporate your new text there (probably together with your proposal regarding redirect uri validation). Afterwards we can decide what we really need in the core spec's sec considerations section. When we wrote the first draft of this section, we intended to keep it focused on the essential MUSTs to be considered by implementors (client, as, rs). Otherwise we will blow up this section to much and none will read it. I would prefer to keep it that way. Does this sound reasonable for you? regards, Torsten. Brian Eaton bea...@google.com schrieb: On Thu, Jul 7, 2011 at 11:08 AM, Anthony Nadalin tony...@microsoft.comwrote: I was responding to the structure question only. The token text is questionable sine the tokens are opaque to the core, seems like the token write-up better belongs in the threat model document. Developers of the various token specs and use this as guidance and reference it. OK, leaving aside the question of where the token text should end up, is the text I sent technically correct and useful? The proposed text is here: http://www.ietf.org/mail-archive/web/oauth/current/msg06362.html. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Section 10.1 (Client authentication)
Hi Eran, I would suggest to change it to SHOULD and add a reference to https://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00 sections 3.7 and 5.2.3. regards, Torsten. Eran Hammer-Lahav e...@hueniverse.com schrieb: It's a pointless MUST given how undefined the requirements are. It will only be understood by security experts and they don't really need it. At a minimum, it needs some examples. EHL From: Torsten Lodderstedt tors...@lodderstedt.net Date: Wed, 1 Jun 2011 00:53:37 -0700 To: Eran Hammer-lahav e...@hueniverse.com, OAuth WG oauth@ietf.org Subject: 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] Resource Owner Password Credentials question/feedback
Am 30.06.2011 18:39, schrieb Eran Hammer-Lahav: This debate has been going on for 3 years. In OAuth 1.0 it was called token attributes. Someone just need to write a proposal. Last time I tried, no one wanted to implement any such mechanism. we already did regards, Torsten. EHL *From:*Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de] *Sent:* Thursday, June 30, 2011 6:38 AM *To:* Eran Hammer-Lahav; George Fletcher; oauth@ietf.org *Subject:* AW: [OAUTH-WG] Resource Owner Password Credentials question/feedback Issuing a refresh token is more a function of the access grant duration than anything else. Agreed. How shall the user influence this duration? There is no direct interaction between authz server and end-user. The client can always throw away tokens when it is done of if the user doesn't want to stay connected, but issuing long term credentials is not really something the client asks but the server decides (based on user approval and policy). This is a waste of resources. Moreover, how do you explain the end-user if a long-term authorization shows up in his service providers account management screen for a certain client he never explicitly authorized for long-term access? regards, Torsten. *Von:*Eran Hammer-Lahav [mailto:e...@hueniverse.com] mailto:[mailto:e...@hueniverse.com] *Gesendet:* Donnerstag, 30. Juni 2011 10:48 *An:* Lodderstedt, Torsten; George Fletcher; oauth@ietf.org mailto:oauth@ietf.org *Betreff:* RE: [OAUTH-WG] Resource Owner Password Credentials question/feedback Issuing a refresh token is more a function of the access grant duration than anything else. The client can always throw away tokens when it is done of if the user doesn't want to stay connected, but issuing long term credentials is not really something the client asks but the server decides (based on user approval and policy). EHL *From:*oauth-boun...@ietf.org mailto:oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] mailto:[mailto:oauth-boun...@ietf.org] *On Behalf Of *Lodderstedt, Torsten *Sent:* Thursday, June 30, 2011 1:10 AM *To:* George Fletcher; oauth@ietf.org mailto:oauth@ietf.org *Subject:* Re: [OAUTH-WG] Resource Owner Password Credentials question/feedback No exactly the topic but also related to this grant type There is currently no parameter the client could use to explicitly request a refresh token. So server-policies based on user, client and scope are the only mean to decide whether a refresh token is issued or not. I consider this to limited as there might be the desire this control this per authorization process, i.e. I client could ask the user whether he/she wants to stay connected or stay logged in. A parameter to pass this information to the authz server would be useful. regards, Torsten. *Von:*George Fletcher [mailto:gffle...@aol.com] mailto:[mailto:gffle...@aol.com] *Gesendet:* Dienstag, 28. Juni 2011 17:47 *An:* oauth@ietf.org mailto:oauth@ietf.org *Betreff:* [OAUTH-WG] Resource Owner Password Credentials question/feedback I'm working on spec'ing out a use of the Resource Owner Password Credentials flow and in trying to map out possible error cases, realized that there is no good error for the case that the resource owner's password credentials are invalid. Section 4.3 of draft 16 references section 5.2 for errors. The list of available errors in section 5.2 are... error REQUIRED. A single error code from the following: invalid_request The request is missing a required parameter, includes an unsupported parameter or parameter value, repeats a parameter, includes multiple credentials, utilizes more than one mechanism for authenticating the client, or is otherwise malformed. invalid_client Client authentication failed (e.g. unknown client, no client credentials included, multiple client credentials included, or unsupported credentials type). The authorization server MAY return an HTTP 401 (Unauthorized) status code to indicate which HTTP authentication schemes are supported. If the client attempted to authenticate via the Authorization request header field, the authorization server MUST respond with an HTTP 401 (Unauthorized) status code, and include the WWW-Authenticate response header field matching the authentication scheme used by the client. invalid_grant The provided authorization grant is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client. unauthorized_client The authenticated client is not authorized to use this authorization grant type.
[OAUTH-WG] draft-ietf-oauth-v2-threatmodel-00 posted
Hi all, I just posted the new revision of the OAuth 2.0 security threat model and considerations document as WG item (http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00). We incoporated all feedback we got on the list and at IETF-80. Many thanks to all people who have given us feedback. Special thanks to Hui-Lan Lu, Francisco Corella, Eric Pflam, Shane B Weeden, Skylar Woodward, and James H. Manger for their comments and suggestions. New threats descriptions: - User session impersonation - XSRF - Clickjacking - DoS using manufactured authorization codes Modification: - renamed session fixation to authorization code disclosure through counterfeit client regards, Torsten. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Deutsche Telekom launched OAuth 2.0 support
Hi all, I would like to announce that we recently launched OAuth 2.0 support in our Security Token Service. It will be used in upcoming consumer products (e.g. Smartphone apps). The current implementation supports draft 10 (but is also inline with the latest text on native apps). It has the following additional features: - Issuance of multiple tokens for different services in single authorization process (Bulk User Authorization) - Token revocation (http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/) - custom grant types for token exchange and SIM card authentication - Token replacement - Parameter to explicitely request refresh token for Resource Owner Password Credentials grant type regards, Torsten. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] state parameter and XSRF detection
Hi all, while working on a new revision of the OAuth security document, a question arose I would like to clarify on the list. The state parameter is supposed to be used to link a certain authorization request and response. Therefore, the client stores a value in this parameter that is somehow bound to a value retained on the device (the user agent) originating the authorization request. The question now is: Would it be compliant with the core spec to use any other URI query parameter encoded in the redirect_uri, instead of the state parameter, to achieve the same goal? Probably the client already has a working legacy implementation it does not want to change just for OAuth2 compliance. According to section 2.2.1, the redirection uri could contain a dynamic portion: The authorization server SHOULD require the client to pre-register their redirection URI or at least certain components such as the scheme, host, port and path So this should be fine. Any comments? regards, Torsten. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Client authentication requirement
What seems to be missing in the discussion and the security considerations of the spec is a decent list of general and grant-type-specific security implications/pros/cons for the system if meaningful client authentication at the token endpoint is available or not available. What about this? http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01 regards, Torsten. ___ 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] Client authentication requirement
-1 making client authentication required at the access token endpoint Client authentication is useful in some situations to raise the security level. But requiring it will either keep out native apps or force there developers to use useless/insecure secrets (I would call this pseudo security). +1 making the client authentication required for certain client types. for a definition of client types and there respective security properties see http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-10 In my opinion, the security considerations section already gives a clear guideline when client authentication should be used and when the authz server should rely on other mechanims. regards, Torsten. Am 16.06.2011 17:08, schrieb Thomas Hardjono: Apologies for the late response. From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Wednesday, June 15, 2011 1:27 PM To: OAuth WG Subject: [OAUTH-WG] Client authentication requirement Client authentication has been one of the main problem areas in OAuth 1.0 and 2.0 does nothing to resolve it (arguably, it makes it more confusing). Because of the desire to allow any client type in any deployment environment, we ended up with a barely defined client authentication model. We offer password-based client authentication using HTTP Basic (and an alternative parameter), but leave it optional. I would to suggest that perhaps we need a better definition of the client by way of identifying one or two (or three) types of clients and listing their respective security properties/capabilities. For example, if a client can/cannot keep cryptographic keys (secrets), then say so. Similarly, if a client can do TLS but cannot do proper X509 processing, then list this, etc. etc. In this way developers can at least map (in the minds) which client type matches their deployment scenario, based on the best-match capabilities list. I would like to go back to requiring client authentication for the access token endpoint, using HTTP Basic or other schemes. To leave the door open for clients incapable of authenticating to use the endpoint, we will add a security consideration section discussing the ramifications of using the access token endpoint without client authentication. This suggestions is linked to the topic of refresh tokens which I'll post separately. EHL +1 agree that client authentication (to access token endpoint) should be made a requirement. /thomas/ ___ 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] consistency of token param name in bearer token type
token_type is defined in the core spec only and indicates the token type to the client and not the resource server. So either the core spec defines a way to distinguish token types towards resource servers (probably by utilizing the token_type parameter) or the respective schemes (BEARER, MAC) define ways to recognize the differences. regards, Torsten. Am 16.06.2011 15:38, schrieb Doug Tangren: -Doug Tangren http://lessis.mehe Just one question: Is the assumption of the group that bearer tokens are the only type of tokens to be used in conjunction with URI query parameters? Otherwise, a mechanism is needed to distinguish bearer and other tokens, e.g. another parameter (token_type?). I thought the idea was that token_type was a way to define general extensions which define protocols to provide access_tokens to resources servicers. I think its up to the provider of access_tokens to document which of these token_types they support and how to distinguish them if there are multiple token_types what use access_tokens in query parameters. I think its up to the extension authors to provide a consistent naming scheme with the base oauth2's defined vocabulary. Where it gets confusing, is when multiple token_type extensions all use different vocabulary for roughly the same thing. I say that in regards to the naming of query parameters. ___ 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] Client authentication requirement
Certainly not. Are we discussing to make client authentication required just for syntactical purposes? To me, notasecret logically means to abandon on client authentication. regards, Torsten. Am 16.06.2011 21:46, schrieb Brian Eaton: On Thu, Jun 16, 2011 at 12:42 PM, Torsten Lodderstedt tors...@lodderstedt.net mailto:tors...@lodderstedt.net wrote: -1 making client authentication required at the access token endpoint Client authentication is useful in some situations to raise the security level. But requiring it will either keep out native apps or force there developers to use useless/insecure secrets (I would call this pseudo security). Are you seriously arguing that including the phrase notasecret in the request would make native applications less secure? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Client authentication requirement
Am 16.06.2011 22:02, schrieb Brian Eaton: On Thu, Jun 16, 2011 at 12:56 PM, Torsten Lodderstedt tors...@lodderstedt.net mailto:tors...@lodderstedt.net wrote: Certainly not. Are we discussing to make client authentication required just for syntactical purposes? That is what I'd like to see. From my perspective, no harm is done by making client authentication a syntactical requirement of the protocol. - clients that can't keep secrets aren't harmed; they have the exact same security they do today. - everyone else benefits because the spec becomes simpler and more consistent. No, it's not simpler nor clearer. Such a client secret is useless, so the security implications have to be explained anyway. Moreover, whatever the spec will state people would start to _rely_ on client secrets even for native apps, which is a really bad idea. regards, Torsten. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Client authentication requirement
no I'm saying people will use real secrets and rely on them - just as with OAuth 1.0 Am 16.06.2011 22:20, schrieb Brian Eaton: On Thu, Jun 16, 2011 at 1:05 PM, Torsten Lodderstedt tors...@lodderstedt.net mailto:tors...@lodderstedt.net wrote: No, it's not simpler nor clearer. Such a client secret is useless, so the security implications have to be explained anyway. The issue really isn't the security implications being unclear; the issue is that the normative language that describes the protocol flows is ambiguous. Moreover, whatever the spec will state people would start to _rely_ on client secrets even for native apps, which is a really bad idea. OK, so you are arguing that baking the string notasecret into a client application makes that client application less secure. That's not really plausible. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Client authentication requirement
Am 16.06.2011 22:30, schrieb Brian Eaton: On Thu, Jun 16, 2011 at 1:25 PM, Torsten Lodderstedt tors...@lodderstedt.net mailto:tors...@lodderstedt.net wrote: no I'm saying people will use real secrets and rely on them - just as with OAuth 1.0 =) People are going to ignore what the spec says on this. If you read through the mailing list threads on this topic, you'll notice several people have stated quite clearly that they are going to be baking secrets into installed applications, and that they think they have reasonable mitigations in place for the security risk. It's not that those people are dumb, either. They understand exactly what they are doing. And their native applications are not going to be any less secure because of the choices they are making. If those people have reasonable means in place to protect secrets on deployment channels and in the local installation - fine. I would be eager to learn more about those means because I would be willed to utilize them as well. My current assumption is that in a open market scenario secrets can be reverse engineered from binary or source code. Since the same secret is used for all installations of the same software, an attacker can utilize it to built a counterfeit app. Because of this risk, I would not recommend to rely on the secret for authenticating such an app. The situation may vary for corporate/enterprise scenarios, where an application can be installed by an administrator and equiped with an installation specific id/secret during this process. In that case, the authz server can rely on the secret for authenticating and authorizing the client. That's why the security considerations section states: ... The authorization server MAY issue a client password or other credentials for a specific installation of a native application on a specific device. regards, Torsten. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Text for Native Applications
Hi Thomas, Am 02.06.2011 21:17, schrieb Thomas Hardjono: Hi Torsten, folks, I reviewed the text of Section 4.1 of draft-lodderstedt-oauth-security, and also the text of Section 9 of oath-draft16. I think there seems to be a disconnect (may be its just me). (a) Oauth2.0 today is designed for low-assurance environments. So I think the WG is wasting a lot of time in trying to address whether the Client can keep secrets. The WG should just assume that the problem of keeping secrets is out of scope for Oauth. Unless we are trying to address high-assurance environments (and start talking about smartcards, HSMs, TPMs, trusted execution, trusted boot, etc), I think the WG should just move on. ps. Section 4.1 is OK, but this WG will not be able to solve many of the problems listed in Section 4.1 (b) The current text of Section 9 says: Native applications SHOULD use the authorization code grant type flow without client password credentials (due to their inability to keep the credentials confidential) to obtain short-lived access tokens, and use refresh tokens to maintain access. When it comes to keeping secrets I don't know why we are assuming that a native application (software running in user-space managed by an OS) is any worse than a browser (user-agent). Did I misunderstood the definition of a native application? I would assume a browser refers to apps running within the browser. http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-10 calls them user-agent-based apps. For both user-agent-based and native apps, the text states the assumption that The OAuth protocol data and credentials are accessible to the end-user.. So both are equivalent with respect to the topic discused in this thread. For native apps, another important issue is the way their client secret (today) is typically assigned and distributed (backed into the binary). So the same secret is accessible in all installations. This is considered bad practice by many people. Web applications are quite different since the OAuth credentials are kept in a server under control of the service provider and not accessible to the end-user. regards, Torsten. Thanks. /thomas/ _ -Original Message- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt Sent: Thursday, June 02, 2011 5:00 AM To: Skylar Woodward Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Text for Native Applications Dave, Skylar, the assumption of the OAuth 2.0 security threat model (http://tools.ietf.org/html/draft-lodderstedt-oauth-security- 01#section-4.1) is that client secrets, which are distributed with applications, cannot reliably kept confidential. Therefore the advice is given to use other means to validate the client identity (e.g. user consent, platform security measures). I would highly appreciate if you would review this document and give us feedback. thanks in advance, Torsten. Am 01.06.2011 22:07, schrieb Skylar Woodward: 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 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] Proposed OAuth Extensions
Hi, I also see the need to request and issue multiple tokens in a single authorization process. There has already been some discussion about this topic roughly a year ago: - http://www.ietf.org/mail-archive/web/oauth/current/msg02688.html. - http://www.ietf.org/mail-archive/web/oauth/current/msg03639.html We at Deutsche Telekom have implemented an OAuth 2.0 extension supporting that use case. It's called bulk authorization. Would that be an interessting topic we could discuss at IETF-81 for the re-chartering? I could present our approach there. regards, Torsten. Am 10.06.2011 21:08, schrieb John Bradley: We have identified the need to request multiple tokens as one issue that we would have to extend. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Text for Native Applications
+1 Skylar Woodward sky...@kiva.org schrieb: This may be true for a secret of sorts in some applications, but not for the client_credential in OAuth. The client secret is the only element that can secure the identity of the app and if it is compromised then so is the ability of the app to assert its identity. There's no way a software program on a open mass-market runtime can secure the secret as a part of its own software distribution (and likely true for any mass-distirbuted system) . So we should stick with the advisement that apps that can't keep secrets not be issued them - its a big win for setting the correct expectations to developers and users over 1.0. If the client_secret were merely one element in protecting access maybe this your suggestion would be true. However, given the difficulty of embedding and obfuscating a secret in a hard-to-find way, and the requirement that every developer would have to do this in his own proprietary and secret way, it seems not a scalable solution for the multitudes of apps that will be OAuth clients. It's better for developers to consider other mechanisms - starting with secure distribution of the software. skylar On Jun 2, 2011, at 11:54 PM, Dave Nelson wrote: On Thu, Jun 2, 2011 at 5:40 PM, Brian Eaton bea...@google.com wrote: Well, rely is a strong-term. I know of various teams who do this. I don't know of any teams that put a heavy reliance on it. It might validly be just one element of a defense-in-depth strategy. 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] review of draft-ietf-oauth-v2-16
I fully agree with Brian and would like to add some thoughts: Not authenticating the client does not directly create a security problem at all. If we would follow this line, every e-Mail client out there would be considered insecure because the client itself is never authenticated. Not even Kerbereos has a concept of client authentication. In my opinion, OAuth client authentication (in delegated authorization scenarios) is an improvement over classical approaches. But I do not see a degration in security if it is not applicable. As long as the _user_ authorizes the client's access (and the duration of the token) and is able to revoke the tokens at any time, the situation is much better than with classical approaches. regards, Torsten. Am 01.06.2011 21:06, schrieb Brian Eaton: 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] review of draft-ietf-oauth-v2-16
in my opinion, the problem with client authentication is more the secure distribution of the secret than the storage. How should a USIM help here? regards, Torsten. Thomas Hardjono hardj...@mit.edu schrieb: Thanks Igor, If you bring smartcards into the picture, then it's a different ballgame :) If mobile phones are assumed to have smartcards (which is increasingly true today via USIMs), then OAUTH can assume that native apps (running on the phones) may have access to crypto-store. In this case the text in Section 9 of draft-16 would needs changes/clarifications. /thomas/ __ -Original Message- From: Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.com] Sent: Thursday, June 02, 2011 3:31 PM To: Thomas Hardjono Cc: Torsten Lodderstedt; OAuth WG Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16 Actually, for the devices that use smart cards (mobile devices, in particular), this assumption is quite appropriate. Igor Thomas Hardjono wrote: ... However, there is indeed the assumption in Kerberos/RFC4120 (and in the original Needham-Schroeder protocol) that the client can keep secrets. /thomas/ _ ___ 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] 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
[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] 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
I think refresh token support in implicit grant is worth a discussion. The main difference to authz code from a security perspective is that the refresh token as long term credential could be disclosed via the user agent's URL history. In my perception, this fact and the assumption that user agent clients (the primary audience of this grant type) are not able to securely store referesh tokens are the reasons why the spec currently does not support it. wrt Facebook's implementation: is this really inline with the spec's idea of access token duration? regards, Torsten. Am 31.05.2011 19:41, schrieb Chuck Mortimore: 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? -cmort On 5/24/11 10:30 PM, tors...@lodderstedt.net tors...@lodderstedt.net wrote: Hi Chuck, one of the advantages of the authz code grant type is refresh token support. I would suggest to mention this in the comparision with the implicit grant type. regards, Torsten. Gesendet mit BlackBerry® Webmail von Telekom Deutschland -Original Message- From: Chuck Mortimore cmortim...@salesforce.com Sender: oauth-boun...@ietf.org Date: Tue, 24 May 2011 17:30:05 To: oauth@ietf.orgoauth oauth@ietf.org%3Coauth@ietf.org Subject: [OAUTH-WG] Text for Native Applications ___ 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 security considerations section does recommend to not automatically process repeated authorizations without validating the client's identity The authorization server SHOULD NOT automatically, without active end-user interaction, process repeated authorization requests without authenticating the client or relying on other measures to ensure the repeated request comes from a valid client and not an impersonator. BTW: I would suggest to rephrase the last part to ... comes from the same client as authorized by the original authorization request regards, Torsten. Am 31.05.2011 21:06, schrieb Brian Campbell: On Tue, May 31, 2011 at 12:00 PM, Doug Tangren d.tang...@gmail.com mailto:d.tang...@gmail.com wrote: I think there is still a usability issue with the implicit flow in general where there is no way in the spec to obtain an access token without re-asking the user for authorization a second time even if the user has already authorized your client. I don't think there is anything in the spec (correct me if I'm wrong) saying that an AS couldn't remember a user's authorization for a given client using implicit so as to avoid subsequent prompts for authorization? ___ 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 16 notes on security considerations
Am 28.05.2011 20:25, schrieb Doug Tangren: I just re-read draft 16 on this memorial day weekend :) 1. I had a comment on the suggested use of the authorization code flow for native clients [1]. Section 10.9 on auth code transmission [2] suggests users of the auth code flow should implement tls on it's redirect uri. This makes sense for web servers which may register something like https://foo.com/i/got/authed; but may not be possible on native clients. It makes sense for all flows where the redirect_uri referes to a server resource. This holds true for web servers acting as OAuth client as well as any server-based resource used by other clients to obtain the authorization code. This should be clarified. It's a common practice for android clients, for instance, to open a browser window to authorize a user via `Intent` and then register their redirect_uri to be a custom scheme registered with their android `activity`, something like myapp://i/got/authed. As pointed out by e.g. Marius in some postings, there are other techniques as well. Some of them are based on server resources the native app relies on. 2. With regards to resource owner creds flow security consideration mentioned [3], it really feels like this is dodging the whole idea of oauth asking for authorization on the site owning the resources. The section clearly states our preference to use other grant types. The authorization server and client SHOULD minimize use of this grant type and utilize other grant types whenever possible. Apart from that, I would not limit OAuth 2.0 to just delegated authorization via end-user authorization. In my opinion, OAuth 2.0 is a generic token issuance framework. Such tokens can be issued based on delegation flows but also based on direct authentication on the tokens endpoint. Other examples of reasonable credentials are assertions of all kind. We at Deutsche Telekom also added a custom grant type to directly authenticate users based on their SIM card. What I like the most, OAuth 2.0 combines the user involvement of OAuth 1.0 with architectural properties of Kerberos (trusted third-party authentication, scalability). Moreover, it is based on and integrated with HTTP(S) and allows to use different token formats (and even designs). Is this mainly meant for `official` apps developed by the site owning the resource? We use it for our own apps. Here, the decision to use web-based flows or username/password is typically met by product managers. Otherwise, it feels like its no different than ye old basic http auth and gimme your login and password and trust me not to store them. It clearly has the security advantages that refresh tokens instead of passwords are stored in order to provide a convenient login experience. The scope of such a token can (and must) be much less powerful than a password. regards, Torsten. [1]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-9 [2]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-10.9 [3]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-10.12 -Doug Tangren http://lessis.me ___ 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] Question on action item to make RedirectURI optional
why must the redirect_uri be validated if it is pre-registered and not included in the authorization request? regards, Torsten. Am 29.05.2011 18:20, schrieb Eran Hammer-Lahav: This applies to 4.1.1 and 4.2.1 only. It must be required in 4.1.3 is must match the location actually used by the server to deliver the code to (regardless of whether the redirection uri was registered or included explicitly with the request). EHL *From:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of *Mike Jones *Sent:* Friday, May 27, 2011 2:08 PM *To:* oauth@ietf.org *Subject:* [OAUTH-WG] Question on action item to make RedirectURI optional The minutes from the special meeting included: TODO: Eran to add extensibility language for this based on requirements. -RedirectURI should be optional TODO: Eran to send mail to the list proposing language changes to either change this from REQUIRED to OPTIONAL and add clarifying language, or leave as required and add a pre-defined value for we're not actually using this. Is this proposed change just limited to section 4.5? It seems to make sense to have redirect_uri be optional in section 4.1.3 as well (access token request using grant_type authorization code). Since this request is made directly from the client to the authorization server, I don't see why this would be required. For at least some implementations of the 3-legged flow, it would make sense to not have this be a requirement. Comments? Thanks, -- Mike ___ 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] Question on action item to make RedirectURI optional
we need to distinguish (1) the registration of a redirect uri template for the purpose of validating the actual redirect uri of an authorization transaction and the (2) registration of the redirect uri to be used in all authorization requests of a client. In the later case, there is no need for the pass a redirect uri with every authz request. Is OAuth supposed to support (2)? regards, Torsten. Doug Tangren d.tang...@gmail.com schrieb: -Doug Tangren http://lessis.me On Sun, May 29, 2011 at 12:41 PM, Torsten Lodderstedt tors...@lodderstedt.net wrote: why must the redirect_uri be validated if it is pre-registered and not included in the authorization request? I think the preregistered redirect_uri may only require the core components of where the user will be redirected to after authorization The authorization server SHOULD require the client to pre-register their redirection URI or at least certain components such as the scheme, host, port and path. If a redirection URI was registered, the authorization server MUST compare any redirection URI received at the authorization endpoint with the registered URI. - http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-2.1.1 What you pre-register determines how you would match the provided requests' redirect_uris. It's explicitly required for an explicit location to redirect to on a request by request basis. The exact match in 4.1.3 is required to have a binding between the first and second request in the auth code flow. I think the idea behind a pre-registered redirect_uri was to limit where credentials will be sent to after authorization. In oauth1 someone could supply a redirection callback to a completely different for every request. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
