I wanted to reply separately to Ralph's concerns about describing how to do the "OAuth dance" over XMPP --- I don't think it's necessary, since HTTP works well and is almost certainly the only / best way that people will do this for some time. At some point in the future, if it becomes prudent to describe how to obtain OAuth tokens via HTTP, we can do that. For now, it just complicates the picture and as such should be removed. b.
On Thu, Jul 31, 2008 at 6:50 AM, Ralph Meijer <[EMAIL PROTECTED]>wrote: > Peter Saint-Andre wrote: > >> I'm making progress on updating XEP-0235 to be OAuth-specific. I'll try to >> finish the edits tomorrow. Here's a sneak peek (thanks to Fritzy for the >> chat earlier today): >> >> http://www.xmpp.org/extensions/tmp/xep-0235-0.4.html >> >> I have my doubts about the invitation use case, so I may remove those >> provisionally until we figure out whether it's reasonable to use OAuth in >> that context. >> >> Peter >> > > Hi, > > I have read this draft in detail and have some doubts about its scope and > use cases. I also discussed this with my colleague, Marc Worrell, who has > written a full PHP implementation of OAuth (service and consumer. > > First off, the use case we discussed at the XMPP Summit was a Consumer > using an OAuth access token to do a particular request over XMPP on behalf > of a User. The assumption being that the access token would be acquired > out-of-band (using regular, over-HTTP OAuth exchanges). > > I don't see any particular use base beyond that one. OAuth was designed for > a state-less protocol with no authentication and identity built-in. In my > opinion, for all the XMPP-only use cases that would be solved with OAuth in > HTTP, we don't need any tokens and/or signatures. > > I first want to tackle the invitation use case in this draft. This example > does not speak of a request token being acquired, although it is included in > the access token request. Also I don't understand the mechanics of the > consumer key here. If it belongs to the invitee, how does the inviter know > it? Why exchange it between User and Consumer? I don't think this exchange > actually works in practice. > > Taking a step back to look at the invite use-case, I notice that what is > desired, is a way to let the muc service know that a particular entity is > invited by an occupant of a room, to that room. Whether that entity is > allowed into the room is a matter of room policy. So I see two possible > exchanges: > > 1) * Inviter sends invitation to invitee. > * Invitee attempts to join room, mentioning inviter's invitation. > * Room asks confirmation with inviter that invitee was indeed invited. > * Room decides on allowing invitee in. > > 2) * Inviter sends notice to room about imminent joining of invitee > * Inviter sends invite to invitee > * Invitee attempts to join room > * Room decided on allowing invitee in > > Exchange 1) can easily be adapted to follow the full token exchange dance > described by OAuth. The room needs to remember the token that shows proof of > the invite. But wait, we have built-in authentication. Leaving optional MITM > and replay attacks out of the picture*, we can just have the invitee mention > the JID of the inviter, and store that instead of a token. No OAuth needed. > > * MITM and replay attacks in XMPP can happen in several places: c2s > traffic, s2s traffic and the servers themselves. If you can assume that all > traffic is TLS based, that severely limits the possibility of those attacks, > leaving you to trust the two servers. In the discussions at the Summit, this > assumption was made. Remind this for later. > > > The node subscription use case shows a full exchange of tokens, whereas I > was under the impression that we got an access token out of band. Why do > this over XMPP? If you really want to define this, and for now I don't see > why, then make it a full implementation of the exchange, with the regular > signature methods. > > Currently the signature method in all the examples is PLAINTEXT+HMAC-SHA1, > a new signature method invented solely for the out-of-band-token use case we > discussed at the Summit. While the short summary [1] on Peter's blog > mentions the way to sign, this draft does not explain it at all. > > Basically, it says to only make a signature (using HMAC-SHA1) over the > consumer key, consumer secret, the access token and the access token secret. > No nonce or timestamp or additional attributes are used here (hence probably > the mention of PLAINTEXT). I had a lengthy discussion about this with Marc > and we are not even sure if we need this special method. > > The assumption of MITM and replay attacks being addressed by XMPP itself > [2] IMO only applies to direct server-to-server traffic only. In that case, > why make a signature at all? Couldn't we just use the PLAINTEXT method, or > even just directly send over the consumer secret and token secret (they are > only obfuscated in PLAINTEXT). Is there any reason to hash them? I can only > think of one reason: one service not being sure if the recipient can be > trusted, which seems odd, because we assumed that to boot. > > A client (like a third-party application that wants to subscribe to a > pubsub node) cannot know if the full path to the pubsub service has TLS in > place, and thus cannot guess if a MITM or replay attack is possible. In this > case, you would need a signature, with nonce and timestamp. Signing without > them gives a false sense of security, if my recollection of security classes > serves me well. So the regular HMAC-SHA1 method should be used here? Maybe > you actually need to sign attributes of the request it self, too? > > I do notice that in Example 18 (Consumer presents an Access Token for > permanent authorization), nonce and timestamp (and version) /are/ used. > Maybe this will be explained by the promised edits by Peter. > > It would be nice if somebody could explain again, why we did the new > signature method, as I am not sure about it anymore. > > Summarizing, I think that we use two things from the OAuth movement in > XMPP: > > a) Presenting an access token that was acquired out-of-band to show > authorization for a particular request. > b) The dialogs that are shown to a User (through the web) to authorize a > Consumer for a particular action. You can reuse them to work for > authorization on a Consumer's JID, only, too. > > Leaves me with pointing out that the actual access token in the reply from > the Service Provider and the one used in the subsequent request is different > in several examples. > > ralphm >
