[oauth] Re: Request for new Security Considerations text
If I remember correctly, we also talked of recommending or mandating one-time request tokens. Hubert On Wed, May 6, 2009 at 10:43 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: We have identified a few new attack vectors since the spec was originally written and would like to address them in the Security Consideration section. Please reply with proposals for such texts. Ideally we can reach some consensus on these by Fri, but if not, we can add it a bit later since it doesn't affect the protocol directly. EHL --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] IPR contribution policy
What's the IPR policy for contributing to OAuth? I've seen an old thread about an IPR contribution license (http://groups.google.com/group/oauth/browse_thread/thread/c42aefc5abd9b059?pli=1) but it seems it has not yielded a final document. At least I can't see it anywhere on the site - or maybe I missed it. Hubert --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: IPR contribution policy
Are we discussing someone's code or the spec? If the spec is what's meant, then the OWF draft may well collide in some (usally arcance) respect with the IETF's processes (which like everything in this realm are a PITA). I would think that changing the IPR status of the spec at this point could muck up formation of an IETF WG and would be undesirable but maybe someone's already checked all that out? S. Chris Messina wrote: We're wanting to adopt the Open Web Foundation contribution license: http://groups.google.com/group/open-web-legal/web/owf-final-specification-agreement---proposed-draft Chris On Tue, May 12, 2009 at 2:50 PM, Hubert Le Van Gong hubert...@gmail.com mailto:hubert...@gmail.com wrote: What's the IPR policy for contributing to OAuth? I've seen an old thread about an IPR contribution license (http://groups.google.com/group/oauth/browse_thread/thread/c42aefc5abd9b059?pli=1) but it seems it has not yielded a final document. At least I can't see it anywhere on the site - or maybe I missed it. Hubert -- Chris Messina Open Web Advocate factoryjoe.com http://factoryjoe.com // diso-project.org http://diso-project.org // openid.net http://openid.net // vidoop.com http://vidoop.com This email is: [ ] bloggable[X] ask first [ ] private --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Request for new Security Considerations text
That is an implementation detail. I am not sure how helpful it would be to have a security consideration section about limiting the number of allowed token exchange requests for a single request token. EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Hubert Le Van Gong Sent: Tuesday, May 12, 2009 3:26 AM To: oauth@googlegroups.com Subject: [oauth] Re: Request for new Security Considerations text If I remember correctly, we also talked of recommending or mandating one-time request tokens. Hubert On Wed, May 6, 2009 at 10:43 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: We have identified a few new attack vectors since the spec was originally written and would like to address them in the Security Consideration section. Please reply with proposals for such texts. Ideally we can reach some consensus on these by Fri, but if not, we can add it a bit later since it doesn't affect the protocol directly. EHL --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Request for new Security Considerations text
One nit: I think the terminology 'mixed binding' conveys the opposite of what is intended. Mixed or mis-binding is an accurate description of possible errors with an early binding strategy. I suggest 'full binding' instead. On May 12, 2009 7:27 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: That is an implementation detail. I am not sure how helpful it would be to have a security consideration section about limiting the number of allowed token exchange requests for a single request token. EHL -Original Message- From: oauth@googlegroups.com [mailto: oa...@googlegroups.com] On... Of Hubert Le Van Gong Sent: Tuesday, May 12, 2009 3:26 AM To: oauth@googlegroups.com Subject... If I remember correctly, we also talked of recommending or mandating one-time request tokens. ... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] SignatureBaseString in the 3 requests
Hi to everybody. I would like to know if I have well understood what the specifications says. I have understood that the SignatureBaseString must be inserted in each request that the Consumer make to the Service Provider. These requests are 3: 1) for a Request Token 2) for an Access Token 3) to access at the protected resources In the specifications there is only an example of the calculation of the SignatureBaseString, related to the third request, in order to access at the protected resources (Appendix A.5.1. Generating Signature Base String). Now I write the SignatureBaseString for each request, where I ignore the encoding for greater clarity. I ask you a feedback if I am being wrong. 1) Request for a Request Token SignatureBaseString = GEThttp://photos.example.net/ request_tokenoauth_consumer_keyoauth_tokenoauth_nonceoauth_timestampoauth_signature_methodoauth_version 2) Request for an Access Token SignatureBaseString = GEThttp://photos.example.net/ access_tokenoauth_consumer_keyoauth_tokenoauth_nonceoauth_timestampoauth_signature_methodoauth_version 3) Request for access to the protected resources SignatureBaseString = GEThttp://photos.example.net/ photosfileoauth_consumer_keyoauth_tokenoauth_nonceoauth_timestampoauth_signature_methodoauth_versionsize is it correct? The differences are in the URL of the Service Provider and in the last request there are also the file and the size parameters. Obviosly the values of the parameters oauth_token, oauth_nonce, oauth_timestamp are different in the various requests. After that the consumer compute the SignatureBaseString: - in the case of RSA-SHA1: the consumer signs the SignatureBaseString with his private key and assigns this value at the oauth_signature parameter. - in the case of HMAC-SHA1: the consumer computes HMAC-SHA1 (SignatureBaseString), using the key K=ConsumerSecretTokenSecret, and assigns this value at the oauth_signature parameter. is it correct? Thanks --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: IPR contribution policy
OAuth Core 1.0 has its own IPR agreement. For 1.0a we will simply ask all the companies to sign the same agreement again (plus anyone new). This list has *no* IPR policy. The IETF has its own useless IPR policy which will be the baseline for the OAuth WG. Anything else will be handled by the App area directors. And none of this has anything to do with the IETF. EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Stephen Farrell Sent: Tuesday, May 12, 2009 7:23 AM To: oauth@googlegroups.com Subject: [oauth] Re: IPR contribution policy Are we discussing someone's code or the spec? If the spec is what's meant, then the OWF draft may well collide in some (usally arcance) respect with the IETF's processes (which like everything in this realm are a PITA). I would think that changing the IPR status of the spec at this point could muck up formation of an IETF WG and would be undesirable but maybe someone's already checked all that out? S. Chris Messina wrote: We're wanting to adopt the Open Web Foundation contribution license: http://groups.google.com/group/open-web-legal/web/owf-final- specification-agreement---proposed-draft Chris On Tue, May 12, 2009 at 2:50 PM, Hubert Le Van Gong hubert...@gmail.com mailto:hubert...@gmail.com wrote: What's the IPR policy for contributing to OAuth? I've seen an old thread about an IPR contribution license (http://groups.google.com/group/oauth/browse_thread/thread/c42aefc5abd9 b059?pli=1) but it seems it has not yielded a final document. At least I can't see it anywhere on the site - or maybe I missed it. Hubert -- Chris Messina Open Web Advocate factoryjoe.com http://factoryjoe.com // diso-project.org http://diso-project.org // openid.net http://openid.net // vidoop.com http://vidoop.com This email is: [ ] bloggable[X] ask first [ ] private --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Request for new Security Considerations text
Some people agreed. It is very much an implementation detail, and either way, it is outside the scope of this specific security exploit (as is, we knew about it when we wrote the original spec). The spec includes the following language: The Request Token has never been exchanged for an Access Token. I believe it is enough. It is common sense to expect servers to take security measures when requests fail. EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Hubert Le Van Gong Sent: Tuesday, May 12, 2009 8:02 AM To: oauth@googlegroups.com Subject: [oauth] Re: Request for new Security Considerations text If it has a clear security impact then I don't think it should be discarded as implementation detail. People on the list seemed to agree this was a must have so, if not in security consideration, it's probably important enough to make it to a Security Best Practices section or something akin to that. Hubert On Tue, May 12, 2009 at 4:26 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: That is an implementation detail. I am not sure how helpful it would be to have a security consideration section about limiting the number of allowed token exchange requests for a single request token. EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Hubert Le Van Gong Sent: Tuesday, May 12, 2009 3:26 AM To: oauth@googlegroups.com Subject: [oauth] Re: Request for new Security Considerations text If I remember correctly, we also talked of recommending or mandating one-time request tokens. Hubert On Wed, May 6, 2009 at 10:43 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: We have identified a few new attack vectors since the spec was originally written and would like to address them in the Security Consideration section. Please reply with proposals for such texts. Ideally we can reach some consensus on these by Fri, but if not, we can add it a bit later since it doesn't affect the protocol directly. EHL --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: SignatureBaseString in the 3 requests
Just go to: http://www.hueniverse.com/hueniverse/2008/10/beginners-gui-1.html and try it out. The example in the spec shows both HMAC-SHA1 and PLAINTEXT (over HTTPS). PLAINTEXT does not use the signature base string, but if you use HMAC-SHA1 there instead, you will need it. EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Simone Sent: Tuesday, May 12, 2009 9:40 AM To: OAuth Subject: [oauth] SignatureBaseString in the 3 requests Hi to everybody. I would like to know if I have well understood what the specifications says. I have understood that the SignatureBaseString must be inserted in each request that the Consumer make to the Service Provider. These requests are 3: 1) for a Request Token 2) for an Access Token 3) to access at the protected resources In the specifications there is only an example of the calculation of the SignatureBaseString, related to the third request, in order to access at the protected resources (Appendix A.5.1. Generating Signature Base String). Now I write the SignatureBaseString for each request, where I ignore the encoding for greater clarity. I ask you a feedback if I am being wrong. 1) Request for a Request Token SignatureBaseString = GEThttp://photos.example.net/ request_tokenoauth_consumer_keyoauth_tokenoauth_nonceoauth_timestam poauth_signature_methodoauth_version 2) Request for an Access Token SignatureBaseString = GEThttp://photos.example.net/ access_tokenoauth_consumer_keyoauth_tokenoauth_nonceoauth_timestamp oauth_signature_methodoauth_version 3) Request for access to the protected resources SignatureBaseString = GEThttp://photos.example.net/ photosfileoauth_consumer_keyoauth_tokenoauth_nonceoauth_timestamp oauth_signature_methodoauth_versionsize is it correct? The differences are in the URL of the Service Provider and in the last request there are also the file and the size parameters. Obviosly the values of the parameters oauth_token, oauth_nonce, oauth_timestamp are different in the various requests. After that the consumer compute the SignatureBaseString: - in the case of RSA-SHA1: the consumer signs the SignatureBaseString with his private key and assigns this value at the oauth_signature parameter. - in the case of HMAC-SHA1: the consumer computes HMAC-SHA1 (SignatureBaseString), using the key K=ConsumerSecretTokenSecret, and assigns this value at the oauth_signature parameter. is it correct? Thanks --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Request for new Security Considerations text
I am not sure this is in any document. I have seen it being discussed as part of the security considerations. On Tue, May 12, 2009 at 11:48 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: Can you point to the specific text you are talking about? EHL From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Breno Sent: Tuesday, May 12, 2009 8:21 AM To: oauth@googlegroups.com Subject: [oauth] Re: Request for new Security Considerations text One nit: I think the terminology 'mixed binding' conveys the opposite of what is intended. Mixed or mis-binding is an accurate description of possible errors with an early binding strategy. I suggest 'full binding' instead. On May 12, 2009 7:27 AM, Eran Hammer-Lahav e...@hueniverse.com wrote: That is an implementation detail. I am not sure how helpful it would be to have a security consideration section about limiting the number of allowed token exchange requests for a single request token. EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On... Of Hubert Le Van Gong Sent: Tuesday, May 12, 2009 3:26 AM To: oauth@googlegroups.com Subject... If I remember correctly, we also talked of recommending or mandating one-time request tokens. ... -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: SignatureBaseString in the 3 requests
Hi Eran. Yes I have already read that page. But also here there's the example of Signature Base String related to the final request for access to the protected resource at the end of OAuth flow, where compare the identity of the resource. My doubt is: in the OAuth flow the consumer have to compute 3 different Signature Base String like I have previous write, or there is only a unique Signature Base String that is create by the consumer only in the final request? I think that the consumer have to compute 3 differente SBS, one for each different type of request that it do, right? And in particular the identity of the resource (for example the name of a jpeg image) compare only in the last request? On 12 Mag, 20:55, Eran Hammer-Lahav e...@hueniverse.com wrote: Just go to: http://www.hueniverse.com/hueniverse/2008/10/beginners-gui-1.html and try it out. The example in the spec shows both HMAC-SHA1 and PLAINTEXT (over HTTPS). PLAINTEXT does not use the signature base string, but if you use HMAC-SHA1 there instead, you will need it. EHL --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: SignatureBaseString in the 3 requests
Every authenticated OAuth request using HMAC or RSA must be signed and has its own signature base string. EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Simone Sent: Tuesday, May 12, 2009 12:22 PM To: OAuth Subject: [oauth] Re: SignatureBaseString in the 3 requests Hi Eran. Yes I have already read that page. But also here there's the example of Signature Base String related to the final request for access to the protected resource at the end of OAuth flow, where compare the identity of the resource. My doubt is: in the OAuth flow the consumer have to compute 3 different Signature Base String like I have previous write, or there is only a unique Signature Base String that is create by the consumer only in the final request? I think that the consumer have to compute 3 differente SBS, one for each different type of request that it do, right? And in particular the identity of the resource (for example the name of a jpeg image) compare only in the last request? On 12 Mag, 20:55, Eran Hammer-Lahav e...@hueniverse.com wrote: Just go to: http://www.hueniverse.com/hueniverse/2008/10/beginners-gui-1.html and try it out. The example in the spec shows both HMAC-SHA1 and PLAINTEXT (over HTTPS). PLAINTEXT does not use the signature base string, but if you use HMAC-SHA1 there instead, you will need it. EHL --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Core 1.0 Rev A, Draft 2
This is the only open issue left before we can make the draft final: -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Brian Eaton Sent: Tuesday, May 05, 2009 4:20 PM Section 6.2: Consumers that need to maintain compatibility with both 1.0 and 1.0a service providers are going to send oauth_callback on this step. We should be explicit about how to handle backwards compatibility here or we are going to end up with incompatible implementations. Specifically: - if the consumer sent the oauth_callback on the RT step, the oauth_callback on the authorization URL should be ignored. - if the consumer did not send the oauth_callback on the RT step, the oauth_callback may be accepted if the SP wants to be compatible with OAuth 1.0 Alternatively, we should give consumers a way to detect SP version, by having the SP return oauth_callback_accepted=1 in the request token response. I think this might be a better answer. We need to reach quick consensus on this proposal! This will only provide value if we make it required in the reply. EHL --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Core 1.0 Rev A, Draft 2
I am not *objecting*. Just find it visually offensive. I would like to see more than a handful of people express support for it... and make sure it gets the right visibility so people can object if they have an issue. EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Brian Eaton Sent: Tuesday, May 12, 2009 2:27 PM To: oauth@googlegroups.com Subject: [oauth] Re: OAuth Core 1.0 Rev A, Draft 2 On Tue, May 12, 2009 at 2:17 PM, Eran Hammer-Lahav e...@hueniverse.com wrote: Alternatively, we should give consumers a way to detect SP version, by having the SP return oauth_callback_accepted=1 in the request token response. I think this might be a better answer. We need to reach quick consensus on this proposal! This will only provide value if we make it required in the reply. So far I haven't heard anybody object to the proposal except you, and several people have spoken in favor of it. That doesn't mean we're right, but it's possible the measurement is statistically significant. =) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] OAuth Core 1.0 Rev A, Draft 3
Please review: http://oauth.googlecode.com/svn/spec/core/1.0a/drafts/3/oauth-core-1_0a.html Change log: http://code.google.com/p/oauth/source/diff?spec=svn997old=994r=997format=unidiffpath=%2Fspec%2Fcore%2F1.0a%2Foauth-core-1_0a.xml The changes are: 1. Changed draft designation from discussion to implementer. 2. Added author, added 'Editor' designation. 3. IMPACT: Added required response parameter 'oauth_callback_confirmed=true' in 6.1.2. 4. Language changes in 6.2.3 (no impact). 5. Moved Security Considerations appendix to new section 11. 6. Added three new security considerations: 11.14-16. * Deadline for feedback is May 25th. * This is expected to be the last draft. EHL --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
