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
