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
