[Security] client-to-client security :: Summary and todo's

Pedro Melo melo at simplicidade.org
Sat Aug 23 09:06:40 CDT 2008


On Aug 23, 2008, at 2:12 PM, Dirk Meyer wrote:
> Pedro Melo wrote:
>>>> - We need a delegation system, that separates "user identity" from
>>>> "resource" or "client" identity, so that a user can delegate the
>>>> right to connect to an account to devices, like set-top-boxes or
>>>> cell phones.  For this a server-based management of this delegation
>>>> and revocation is needed
>>> If you mean the "Hosted solutions" thread than I agree. If not,  
>>> please
>>> explain.
>> I also don't understand this. Are you talking OAuth-style stuff,
>> where I can give some third party a token that its valid for him to
>> connect as me?
> IMHO OAuth is kind of stupid. I have to trust a server I do not
> know. No, the point is that I can upload a certificate to my XMPP
> server and the owner of that certificate (a bot, a client I do not
> trust) can log in using SASL-EXTERNAL as me without having the
> password.

OAuth is not stupid. The server you do not trust is your own XMPP  
server. If you don't trust that, well, what are you doing connected  
to him?

I can ask my XMPP server for a opaque token that I provide to my bot  
and he can use that to authenticate.

Having said that, I also like your "upload-certificate" idea.

>> Yes, what do we need from the server? In a perfect world I would hope
>> not to have to go through the server apart from the Jingle
>> negotiation? Ok, and IBB-Jingle fallback.
> In that case we need a SOCKS5 proxy or a TURN server. I prefer the
> TURN server but we lack ice-tcp support to use it.

If you can negotiate a direct TCP (or TCP-like with order guarantees)  
via ICE, much better.

> I also need the server to help me find a TURN server I can use if I
> need one.

Isn't this a problem to be solved by the Jingle specs?

Best regards,
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo at simplicidade.org

More information about the Security mailing list