[Social] OAuth update

[Peter Saint-Andre]

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

[Ralph Meijer]

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

[Blaine Cook]

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="x (AT) example (DOT) com" from="y (AT) example (DOT) org" 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%26y%40example.org
&oauth_consumer_key%3Dfoo%40oauth_signature_method% 3DHMAC-SHA1%40oauth_token%3Dbar

So 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.

On Thu, Jul 31, 2008 at 6:50 AM, Ralph Meijer <jabber.org (AT) ralphm (DOT) ik.nu>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
>

[Blaine Cook]

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 <jabber.org (AT) ralphm (DOT) ik.nu>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
>

[Ralph Meijer]

Blaine Cook wrote:
> [..] At some point in the future, if it becomes prudent to describe how to
> obtain OAuth tokens via HTTP, we can do that. [..]

XMPP, that is.

[Blaine Cook]

Right, thanks ;-)

On Thu, Jul 31, 2008 at 11:44 AM, Ralph Meijer <jabber.org (AT) ralphm (DOT) ik.nu>wrote:

> Blaine Cook wrote:
>
>> [..] At some point in the future, if it becomes prudent to describe how to
>>
> > obtain OAuth tokens via HTTP, we can do that. [..]
>
> XMPP, that is.
>
>
>

[Nathan Fritz]

I'm going to disagree. We can treat the XMPP client/transport as the
consumer, and a pubsub service as the service. We can use it to prove that
this XMPP JID is approved by an HTTP based user to have certain access over
HTTP. We can use a specialized XMPP client (like Twhirl) as the consumer as
well as the authorizer over the two transports. Take this example:



1. Say you want LinkedIn to be informed LIVE whenever your Gmail contact
list changes (additions, edits, and deletes).
2. Gmail and LinkedIn have agreed upon a certificate and secret for
LinkedIn.
3. Gmail stores your contact list in an XMPP PubSub Node.
4. You go to LinkedIn.com and inform it that you want [your-user-here]@
gmail.com's contacts to update your LinkedIn contacts live.
5. LinkedIn, over XMPP, requests a "request token" from Gmail's pubsub
service, signing it with the agreed upon certificate and secret.
6. Gmail, if the signature was valid, sends LinkedIn a "request token."
7. LinkedIn then redirects the user to a Gmail webpage.
8. On the Gmail Webpage, you have to log in or already be logged in. You
are asked whether you approve of LinkedIn having read-only access to your
contact list with live updates. You could optionally set a timeframe (6
months to expire).
9. You approve the request and Gmail redirects you back to LinkedIn.
10. LinkedIn, over XMPP, requests an "access token," again, signing it,
and now using the "request token" that you approved.
11. Gmail, if the signature is correct, and the request token was
approved, replies with an access token.
12. LinkedIn, over XMPP, subscribes to your Publish-Subscribe Contact
List node using the access token.
13. From there on out (until the token expires if you set an expiration)
gets updated every time you add/edit/delete items from your contact list in
Gmail as they happen!

Sure, maybe there are other ways of accomplishing this, but then take the
Twhirl example:


1. Twhirl logs into twhirl.org via XMPP SASL-Anonymous and is assigned a
random JID.
2. Twhirl, over XMPP, requests a request token from the identi.ca bot.
3. Twhirl, over the identi.ca HTTP API, with the user's account, approves
the token. Now we have proof that this random JID is approved by the user
to get updates.
4. Twhirl, over XMPP, requests the access token.
5. Twhirl sends presence to the bot with the OAuth access token via XMPP.
6. Twhirl gets updates from the bot via XMPP until presence is
unavailable.

This is a bit of an edge case, but in it, we use OAuth to prove that the
XMPP JID is approved by the HTTP user. I'm perfectly willing to listen to
other STANDARDS BASED ways of solving this.

In short, the HTTP OAuth dance still has it's place in XMPP.

Thanks,
Nathan Fritz

[Ralph Meijer]

On Thu, Jul 31, 2008 at 12:02:00PM -0700, Nathan Fritz wrote:
> I'm going to disagree. We can treat the XMPP client/transport as the consumer,
> and a pubsub service as the service. We can use it to prove that this XMPP JID
> is approved by an HTTP based user to have certain access over HTTP.

That we can doesn't mean we should. Both your examples can easily be
implemented by doing the requests for the request token and subsequent
exhange for an access token over HTTP as the OAuth spec specifies. How
access is granted, by the way, is unspecified. The only thing we would
need to spec is how to pass the access token over XMPP, to prove that
the sending party is indeed authorized to perform the associated action.

I haven't heard of a compelling reason to do the bit up to the consumer
getting the access token over XMPP rather than HTTP. It is likely that
all of your use cases require the HTPP OAuth exhange implemented anyway,
allowing you to use existing libraries. By providing a way to present
the access token over XMPP we have enabled the use of OAuth in XMPP with
minimal effort.

If you still want that, I can transform your examples to match my
hypotheses above. But I first need some sleep.

--
Groetjes,

ralphm

[Blaine Cook]

I really strongly agree with Ralph here --- in all cases, the use needs to
go to the Service Provider's website in order to grant permission to the
Consumer (verify the token). Since HTTP is part of the flow, why not just
use HTTP? It's well understood, libraries exist that support it, and it's
easier to guarantee security (which is really important when you're talking
about the exchange of secrets).

b.

On Thu, Jul 31, 2008 at 2:18 PM, Ralph Meijer <jabber.org (AT) ralphm (DOT) ik.nu>wrote:

> On Thu, Jul 31, 2008 at 12:02:00PM -0700, Nathan Fritz wrote:
> > I'm going to disagree. We can treat the XMPP client/transport as the
> consumer,
> > and a pubsub service as the service. We can use it to prove that this
> XMPP JID
> > is approved by an HTTP based user to have certain access over HTTP.
>
> That we can doesn't mean we should. Both your examples can easily be
> implemented by doing the requests for the request token and subsequent
> exhange for an access token over HTTP as the OAuth spec specifies. How
> access is granted, by the way, is unspecified. The only thing we would
> need to spec is how to pass the access token over XMPP, to prove that
> the sending party is indeed authorized to perform the associated action.
>
> I haven't heard of a compelling reason to do the bit up to the consumer
> getting the access token over XMPP rather than HTTP. It is likely that
> all of your use cases require the HTPP OAuth exhange implemented anyway,
> allowing you to use existing libraries. By providing a way to present
> the access token over XMPP we have enabled the use of OAuth in XMPP with
> minimal effort.
>
> If you still want that, I can transform your examples to match my
> hypotheses above. But I first need some sleep.
>
> --
> Groetjes,
>
> ralphm
>
>

[Nathan Fritz]

On Thu, Jul 31, 2008 at 3:07 PM, Blaine Cook <romeda (AT) gmail (DOT) com> wrote:

> I really strongly agree with Ralph here --- in all cases, the use needs to
> go to the Service Provider's website in order to grant permission to the
> Consumer (verify the token). Since HTTP is part of the flow, why not just
> use HTTP? It's well understood, libraries exist that support it, and it's
> easier to guarantee security (which is really important when you're talking
> about the exchange of secrets).
>
> b.
>
>
>> I haven't heard of a compelling reason to do the bit up to the consumer
>> getting the access token over XMPP rather than HTTP. It is likely that
>> all of your use cases require the HTPP OAuth exhange implemented anyway,
>> allowing you to use existing libraries. By providing a way to present
>> the access token over XMPP we have enabled the use of OAuth in XMPP with
>> minimal effort.
>>
>
But the proof that a given XMPP account is approved is less direct. Yes,
you use the access key over XMPP, but it breaks the consumer-service
paradigm. Perhaps my argument is weak, but shouldn't the consumer request
the keys through the protocol it is consuming on? I am, however,
reasonable. If there is no advantage for the requests to be made from the
same protocol as the access token is used in, then I bow out of this debate.

[Nathan Fritz]

On Thu, Jul 31, 2008 at 3:33 PM, Nathan Fritz <nathanfritz (AT) gmail (DOT) com> wrote:

>
>
> On Thu, Jul 31, 2008 at 3:07 PM, Blaine Cook <romeda (AT) gmail (DOT) com> wrote:
>
>> I really strongly agree with Ralph here --- in all cases, the use needs to
>> go to the Service Provider's website in order to grant permission to the
>> Consumer (verify the token). Since HTTP is part of the flow, why not just
>> use HTTP? It's well understood, libraries exist that support it, and it's
>> easier to guarantee security (which is really important when you're talking
>> about the exchange of secrets).
>>
>> b.
>>
>>
>>> I haven't heard of a compelling reason to do the bit up to the consumer
>>> getting the access token over XMPP rather than HTTP. It is likely that
>>> all of your use cases require the HTPP OAuth exhange implemented anyway,
>>> allowing you to use existing libraries. By providing a way to present
>>> the access token over XMPP we have enabled the use of OAuth in XMPP with
>>> minimal effort.
>>>
>>
> But the proof that a given XMPP account is approved is less direct. Yes,
> you use the access key over XMPP, but it breaks the consumer-service
> paradigm. Perhaps my argument is weak, but shouldn't the consumer request
> the keys through the protocol it is consuming on? I am, however,
> reasonable. If there is no advantage for the requests to be made from the
> same protocol as the access token is used in, then I bow out of this debate.
>

To be a bit more clear, if the token is used on a different transport than
it was requested on, this brings us one step closer to a man in the middle
attack. I think the service should expect the access token to be used on
the same transport that requested it. What if the Authorization process is
over XMPP as well via x-data-forms? What if there isn't any HTTP service?
I think that omitting a method for doing this is short sighted, and the
argument of "you could do this over HTTP" does not equate to "you should do
this over HTTP." Also, by dropping XMPP as negotiating the tokens, you lose
the inherit benefit of XMPP being natively resistant to replay-attacks.
Just because we *can* use HTTP in a non-browser based app, why would we?

XMPP is not tied to HTTP, and we shouldn't force it in an extension unless
it's an extension for HTTP like BOSH.

[Ralph Meijer]

Nathan Fritz wrote:
> [..]
>
> To be a bit more clear, if the token is used on a different transport
> than it was requested on, this brings us one step closer to a man in the
> middle attack.

I don't believe this is true, from a security standpoint. Do you have
anything to back this up?

> I think the service should expect the access token to be
> used on the same transport that requested it.

Given the above, I don't see why.

> What if the Authorization process is over XMPP as well via x-data-forms?

I don't see why this would be useful. I see two possibilities: the User
and Consumer use the same JID, or not.

If you assume that User and Consumer are in fact the same entity, maybe
from different Jabber resources, but the same account, then why do you
need the whole OAuth dance at all? You would get these steps:

* The client sends a request to get a request token.
* The client needs to somehow point itself to get an authorization
form. Unlike the HTTP flow, I suppose you would ask for the
authorization form?
* You approve, by submitting the form.
* The client requests the exchange the request token for an access
token.
* You perform the intended request, presenting the access token.

I'm sorry, but if you trust a particular JID to approve authorization to
itself, why not just do the request right away?

If the User and Consumer don't use the same JID, then the flow becomes:

* The Consumer sends a request to get a request token.
* The Consumer then needs to either:

1) Ask the Service provider to send an authorization form to the User
2) Send the request token to the User

* The User approves
* The Consumer learns of the approval
* The Consumer requests the exchange of the request token for an
access token.
* The Consumer performs the intended request, presenting the access
token.

In case 1) you apparently don't trust the authenticity of Consumer while
it is connected, otherwise you wouldn't need OAuth. If that is not true,
you could just ask the service provider to authorize this (temporary?)
JID and do perform your request. The publish-subscribe spec does this a
bit in reverse, but is more or less the same.

We have traditionally said that address spoofing in Jabber is quite
difficult, and if this succeeds while using TLS (possibly with client
certificates, too), you probably have other problems.

In case 2) you do apparently trust the JID, so you could ask the User to
let the Service Provider know you are allowed to do something and then
do it. No signing or tokens required.

> What if there isn't any HTTP service?

Then IMO, you don't need OAuth at all.

> I think that omitting a method for doing this is short sighted ..

Why?

> ... and the argument of "you could do this over HTTP" does not
> equate to "you should do this over HTTP."

Agreed.

> Also, by dropping XMPP as negotiating the tokens, you lose the
> inherit benefit of XMPP being natively resistant to replay-attacks.

Well, OAuth only marginally provides resistance for replay attacks in
how we currently suggested it should work. We don't do any signing of
requests themselves, for example. Injection has not been considered to
be a major thread in Jabber (up till now?), and if you are worried about
that, I suggest we focus on finishing end-to-end encryption first.

If you don't agree on this, I would like you to provide the threat model
you envision in your scenarios. Please use relevant information security
terminology. On a side node, we need to do the same for the limited
use-case of only presenting an access token, too.

> Just because we *can* use HTTP in a non-browser based app, why would
> we?

I agree that this should not be needed.

> XMPP is not tied to HTTP, and we shouldn't force it in an extension
> unless it's an extension for HTTP like BOSH.

Agreed.

In closing, I want to mention that most of the people I have spoken to
at the summit, but also all the time from the inception of OAuth up to
the Summit, have come with the limited use-case of wanting to reuse an
access token to prove authorization for hybrid HTTP/XMPP (client)
applications. This is why we discussed it in that manner at the Summit.

ralphm

[Pedro Melo]

On Jul 31, 2008, at 11:33 PM, Nathan Fritz wrote:
> But the proof that a given XMPP account is approved is less
> direct. Yes, you use the access key over XMPP, but it breaks the
> consumer-service paradigm. Perhaps my argument is weak, but
> shouldn't the consumer request the keys through the protocol it is
> consuming on?

Really, no.

It's normal behaviour to negotiate over protocol A and then connect
over protocol B.

Think SIP, SDP, and the RTP stream for audio.

Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo (AT) simplicidade (DOT) org
Use XMPP!

[Blaine Cook]

On Thu, Jul 31, 2008 at 11:44 PM, Nathan Fritz <nathanfritz (AT) gmail (DOT) com>wrote:
>
>
> What if there isn't any HTTP service? I think that omitting a method for
> doing this is short sighted, and the argument of "you could do this over
> HTTP" does not equate to "you should do this over HTTP."
>

Can you present a scenario that you actually have to implement for in the
next, say, 3 months where you can't use HTTP, but can use XMPP?


> Also, by dropping XMPP as negotiating the tokens, you lose the inherit
> benefit of XMPP being natively resistant to replay-attacks.
>

XMPP is not resistant to replay attacks, and shouldn't be presented as such.


> Just because we *can* use HTTP in a non-browser based app, why would we?
>
XMPP is not tied to HTTP, and we shouldn't force it in an extension unless
> it's an extension for HTTP like BOSH.
>

We should use HTTP here for three reasons:

1. XMPP is new to people. Implementing simple applications is difficult
enough already, and requiring that they implement token exchange mechanisms
to get started unreasonably raises the bar.

2. OAuth is tied to HTTP. There are existing implementations of the token
exchange over HTTP, in production.

3. OAuth is tied to HTTP. Whether you use HTTP or XMPP to do the token
exchange bits, you need to send the user to a web page to approve the OAuth
request.

In practice, no-one will use the XMPP-based token exchange mechanism
(FireEagle won't, Ralph's work won't, any existing site with HTTP OAuth
endpoints won't), so (1) it shouldn't be in the spec and (2) you'll have to
implement the HTTP OAuth mechanism anyhow. If it turns out that there's a
compelling reason to have the XMPP-based token exchange documented, then it
can be added back in (without breaking the signing mechanism) or added as a
separate spec. In the meantime, it just confuses the matter.

b.

[Peter Saint-Andre]

Sorry for the delayed reply, I got behind on email.

Short answer: I think Ralph and Blaine are right.

Long answer follows.

Ralph Meijer 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).

Yes, I misunderstood that.

> 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.

Right -- for MUC invitations we can just send the invitation directly to
the invitee. If the room really needs to know you're inviting the person
(e.g., because the room is invite-only) then you'll need to tell the
room you're inviting the person as well. The hacky way to do that is to
the send the invite both directly and to the room.

> 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.

Agreed.

> 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.

Right. We don't have the protocol flow in XEP-0045 right now for the
room to poke the inviter for confirmation, but that's easy enough to
build in.

> * 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.

Yes, Isaac and Justin might cause trouble even in a full-TLS deployment.
But that's a discussion for the security (AT) xmpp (DOT) org list. :)

> 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.

Correct.

> 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.

I was sleepy at the time, sorry. :)

> 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.

Not really. It was probably a copy-and-paste assumption/error.

> It would be nice if somebody could explain again, why we did the new
> signature method, as I am not sure about it anymore.

I leave that to our OAuth experts. I'm just the documentation guy here.

> 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.

Yes.

> 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.

What exactly do you mean by "the dialogs"? The content of the web pages?

> 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.

OK, will fix that.

/psa

[Peter Saint-Andre]

Blaine Cook wrote:
> 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.

Agreed.

/psa

[Peter Saint-Andre]

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="x (AT) example (DOT) com <mailto:x (AT) example (DOT) com>" from="y (AT) example (DOT) org
> <mailto:y (AT) example (DOT) org>" 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%3Dbar
>
> So 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.

[Ralph Meijer]

Peter Saint-Andre wrote:
> Sorry for the delayed reply, I got behind on email.
>
> Short answer: I think Ralph and Blaine are right.

Yay :-P

> Long answer follows.
>
> [..]
>
>> 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.
>
> What exactly do you mean by "the dialogs"? The content of the web pages?

Yeah, the interaction design, layout and some of the text of the web
pages. Maybe that's not much ;-)

>> 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.
>
> OK, will fix that.

Well, if you strip out the whole dance, this point is really moot.

ralphm