Hi Blaine, this looks good to me. Thanks for the text/examples.
Blaine Cook wrote:
I've been thinking about this (did the OAuth-over-XMPP implementation for FireEagle on Tuesday), and there are a few problems with the way we specified the OAuth interactions. Ralph's right, except that we do need OAuth support over XMPP. The use case that I have is when a user has granted permission to an application over OAuth, that application should be able to perform actions over XMPP, without the user knowing which transport is being used.Regarding the signature semantics, the points raised are important. I think the signature should actually be just HMAC-SHA1 as defined in the OAuth specification, with the following modifications:- method should be equal to the type of XMPP stanza (message, presence, or iq) - request url should be the "to" address concatenated (with '&') with the "from" address. - the normalized request parameters should be all oauth_* parameters included in the <oauth> element (note that we are NOT trying to map from HTTP application/x-www-form-urlencoded parameters to XMPP "parameters").Thus, for the following stanza:<iq to="[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>" from="[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>" id="1234"><pubsub xmlns='http://jabber.org/protocol/pubsub'> <subscribe node='mynode'/> <oauth xmlns='urn:xmpp:tmp:oauth'> <oauth_consumer_key>foo</oauth_consumer_key> <oauth_token>bar</oauth_token> <oauth_signature_method>HMAC-SHA1</oauth_signature_method> <oauth_signature>h2vvES3WQpdYmjzUK7Fl2G1Nez8=</oauth_signature> </oauth> </pubsub> </iq> The signature base string would work out to:iq&x%40example.com <http://40example.com>%26y%40example.org <http://40example.org>&oauth_consumer_key%3Dfoo%40oauth_signature_method%3DHMAC-SHA1%40oauth_token%3DbarSo assuming a consumer secret of 'consumersecret' and a token secret of 'tokensecret', the signature is going to be:h2vvES3WQpdYmjzUK7Fl2G1Nez8=Note that this is subject to replay attacks BUT, by including the "to" and "from" addresses, it limits the replayability to compromised servers or c2s connections (in which case, you have larger problems to worry about). Ideally, OAuth subscriptions should only be sent via TLS encrypted c2s connections, and all s2s connections should be TLS-enabled. For security conscious individuals (i.e., the wording in the spec should be this way), all connections MUST be over TLS.Does this satisfy the signature requirements? It's not exactly what I currently have implemented, but only minor changes are necessary, and I think expresses the intent of the PLAINTEXT+HMAC-SHA1 (hiding the secret) while addressing the fact that only encoding the secrets in the signature meant arbitrary replay attacks.
smime.p7s
Description: S/MIME Cryptographic Signature
