Re: [OAUTH-WG] MAC Tokens body hash
In thinking about this I'm coming around to the viewpoint that a single additional predefined spot is sufficient. If the app developer wants to include addtional data there (iun the specified format) that's fine. If what they want to do is include a signature of other payload that's fine too. I'm not in love with the name app though, ext is better. From: Phillip Hunt phil.h...@oracle.com To: Eran Hammer-Lahav e...@hueniverse.com Cc: Ben Adida b...@adida.net; OAuth WG oauth@ietf.org; Adam Barth(a...@adambarth.com) a...@adambarth.com Sent: Tuesday, August 2, 2011 7:14 PM Subject: Re: [OAUTH-WG] MAC Tokens body hash Phil On 2011-08-02, at 18:02, Eran Hammer-Lahav e...@hueniverse.com wrote: The idea is to drop 'ext' and 'bodyhash' due to being underspecified and therefore causing more harm than good. I added 'ext' to allow for application specific data to be included in the signed content. However, the name suggests this is an extension point for future specifications. I believe authentication schemes should not be extensible in ways that affect their security or interop properties and without additional text (registry, process, etc) for the 'ext' parameter, it will cause more issues than help. Instead of the 'ext' parameter I am suggesting the 'app' parameter which will do the same, but will be better positioned as an application-specific data. The prose will go a step further and recommend that the parameter value include a hash of the data, not the data itself. This is to ensure the parameter does not become part of the payload which is inappropriate for HTTP requests. -1 what you describe appears to be a separate feature from ext As for the 'bodyhash' parameter, I would like to remove it because it is underspecified (we had an actual deployment experience showing that it doesn't produce interoperable implementations due to the many HTTP body transformation applied in most frameworks). Solving this issue is not possible due to the many different types of bodies and frameworks (and clearly operating on the raw body doesn't work). Instead, developers can use the new 'app' parameter to accomplish that. +1 As for the normalized string, it will be adjusted to reflect these changes when they are made, so no placeholders which will require code change. Considering this is -00, it is clearly not a stable document. Will these changes work with your use cases? EHL -Original Message- From: Skylar Woodward [mailto:sky...@kiva.org] Sent: Tuesday, August 02, 2011 4:02 PM To: Eran Hammer-Lahav Cc: OAuth WG; Ben Adida; 'Adam Barth (a...@adambarth.com)' Subject: Re: [OAUTH-WG] MAC Tokens body hash hurrah! (not necessarily for losing a way to sign the body, but for simplicity and avoiding some of the potential inconsistencies w/ bodyhash). Is your plan to reserve an empty line 6 for the Normalized Request String (which was used for bodyhash) or eliminate it, brining the total to six elements? skylar On Jul 30, 2011, at 3:43 AM, Eran Hammer-Lahav wrote: I plan to drop support for the bodyhash parameter in the next draft based on bad implementation experience. Even with simple text body, UTF encoding has introduced significant issues for us. The current draft does not work using simple JS code between a browser and node.js even when both use the same v8 engine due to differences in the body encoding. Basically, the JS string used to send a request from the browser is not the actual string sent on the wire. To fix that, we need to force UTF-8 encoding on both sides. However, that is very much application specific. This will not work for non-text bodies. Instead, the specification should offer a simple way to use the ext parameter for such needs, including singing headers. And by offer I mean give examples, but leave it application specific for now. I am open to suggestions but so far all the solutions I came up with will introduce unacceptable complexity that will basically make this work useless. 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___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] MAC Tokens body hash
Only allowing (implied or not) app data is needlessly narrow in scope. Extending MAC to include claims or session information is a perfectly valid thing to do. It improves scalability and reduces the need to look up artifact data. Note: I'd like to share more on this, but I'm prioritizing the Threat Model document. Never-the-less, the above should be a sufficient example about why extensibility is useful. Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-08-03, at 11:03 AM, Eran Hammer-Lahav wrote: My proposal is to change ‘ext’ to ‘app’, keep the same prose as ‘ext’, and add the use case of ‘bodyhash’ as an example. I’m not too stuck on the name, but my thinking is that ‘app’ relays the right message that this is a place where developers can stick any application data they want included. ‘ext’ conveys the idea of extensions which I’m not so thrilled about. In other words, I’d like a developer reading this to feel comfortable using it right away for securing addition bits such as a JSON payload, but I don’t like the idea of someone publishing an I-D with a full syntax and canonicalization requirements for say, singing an entire request, headers and all. I feel that would be much better accomplished by defining a new HTTP authentication scheme. Philosophically, I think extensible authentication schemes are a bad idea. EHL From: William J. Mills [mailto:wmi...@yahoo-inc.com] Sent: Wednesday, August 03, 2011 10:28 AM To: Phillip Hunt; Eran Hammer-Lahav Cc: Ben Adida; OAuth WG; Adam Barth(a...@adambarth.com) Subject: Re: [OAUTH-WG] MAC Tokens body hash In thinking about this I'm coming around to the viewpoint that a single additional predefined spot is sufficient. If the app developer wants to include addtional data there (iun the specified format) that's fine. If what they want to do is include a signature of other payload that's fine too. I'm not in love with the name app though, ext is better. From: Phillip Hunt phil.h...@oracle.com To: Eran Hammer-Lahav e...@hueniverse.com Cc: Ben Adida b...@adida.net; OAuth WG oauth@ietf.org; Adam Barth(a...@adambarth.com) a...@adambarth.com Sent: Tuesday, August 2, 2011 7:14 PM Subject: Re: [OAUTH-WG] MAC Tokens body hash Phil On 2011-08-02, at 18:02, Eran Hammer-Lahav e...@hueniverse.com wrote: The idea is to drop 'ext' and 'bodyhash' due to being underspecified and therefore causing more harm than good. I added 'ext' to allow for application specific data to be included in the signed content. However, the name suggests this is an extension point for future specifications. I believe authentication schemes should not be extensible in ways that affect their security or interop properties and without additional text (registry, process, etc) for the 'ext' parameter, it will cause more issues than help. Instead of the 'ext' parameter I am suggesting the 'app' parameter which will do the same, but will be better positioned as an application-specific data. The prose will go a step further and recommend that the parameter value include a hash of the data, not the data itself. This is to ensure the parameter does not become part of the payload which is inappropriate for HTTP requests. -1 what you describe appears to be a separate feature from ext As for the 'bodyhash' parameter, I would like to remove it because it is underspecified (we had an actual deployment experience showing that it doesn't produce interoperable implementations due to the many HTTP body transformation applied in most frameworks). Solving this issue is not possible due to the many different types of bodies and frameworks (and clearly operating on the raw body doesn't work). Instead, developers can use the new 'app' parameter to accomplish that. +1 As for the normalized string, it will be adjusted to reflect these changes when they are made, so no placeholders which will require code change. Considering this is -00, it is clearly not a stable document. Will these changes work with your use cases? EHL -Original Message- From: Skylar Woodward [mailto:sky...@kiva.org] Sent: Tuesday, August 02, 2011 4:02 PM To: Eran Hammer-Lahav Cc: OAuth WG; Ben Adida; 'Adam Barth (a...@adambarth.com)' Subject: Re: [OAUTH-WG] MAC Tokens body hash hurrah! (not necessarily for losing a way to sign the body, but for simplicity and avoiding some of the potential inconsistencies w/ bodyhash). Is your plan to reserve an empty line 6 for the Normalized Request String (which was used for bodyhash) or eliminate it, brining the total to six elements? skylar On Jul 30, 2011, at 3:43 AM, Eran Hammer-Lahav wrote: I plan to drop support for the bodyhash parameter in the next draft based on bad implementation experience. Even with simple text body, UTF encoding has introduced significant issues for us. The current draft
[OAUTH-WG] I-D Action: draft-ietf-oauth-saml2-bearer-05.txt
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 : SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 Author(s) : Chuck Mortimore Filename: draft-ietf-oauth-saml2-bearer-05.txt Pages : 15 Date: 2011-08-03 This specification defines the use of a SAML 2.0 Bearer Assertion as means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-05.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-saml2-bearer-05.txt ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-saml2-bearer-05.txt
This 'nice' version of this is at http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-05 The draft has been reworked significantly to become a profile of http://tools.ietf.org/html/draft-ietf-oauth-assertions-00 and cover both assertions as access grants as well as assertions as client authentication. The grant_type URI value no longer uses oauth.net and is urn:ietf:params:oauth:grant-type:saml2-bearer which is registered/requested per http://tools.ietf.org/html/draft-campbell-oauth-urn-sub-ns and a new URI of urn:ietf:params:oauth:client-assertion-type:saml2-bearer is introduced for client_assertion_type. Lastly the processing rules on the assertion have been relaxed somewhat to allow for SubjectConfirmationData element(s) to be optional when the Conditions element has a NotOnOrAfter attribute. Thanks, Brian On Wed, Aug 3, 2011 at 3:16 PM, internet-dra...@ietf.org wrote: 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 : SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 Author(s) : Chuck Mortimore Filename : draft-ietf-oauth-saml2-bearer-05.txt Pages : 15 Date : 2011-08-03 This specification defines the use of a SAML 2.0 Bearer Assertion as means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-05.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-saml2-bearer-05.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
[OAUTH-WG] Parameter Registration Requests in draft-ietf-oauth-assertions
One of the changes I made in http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-05 was to drop the parameter registration request for the assertion parameter because the parameter is now defined in http://tools.ietf.org/html/draft-ietf-oauth-assertions however that document doesn't currently have the registration request in its IANA Considerations section. It probably needs to have that as well as requests for client_assertion and client_assertion_type. To bootstrap that bit of work, I've included the XML source for the assertion parameter request from a previous version of the SAML document: section title='IANA Considerations' section title='Parameter Registration Request' t The following is the parameter registration request, as defined in The OAuth Parameters Registry of xref target=I-D.ietf.oauth-v2The OAuth 2.0 Authorization Protocol/xref, for the spanx style='verb'assertion/spanx parameter: list style='symbols' tParameter name: assertion/t tParameter usage location: token request /t tChange controller: IETF/t tSpecification document(s): [[this document]]/t /list /t /section /section ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
