[Security] client-to-client security :: Summary and todo's
dmeyer at tzi.de
Sat Aug 23 08:12:26 CDT 2008
Pedro Melo wrote:
> Why not say:
> * "encrypted" channel: a casual sniffer will not be able to see the
> the messages, but it is susceptible to MITM attacks;
> * "trusted" channel: a encrypted channel in which the certificates
> presented where verified by some method (SRP, SAS, CA signature, GPG
> Web-of-trust, other).
Sounds ok to me
>>> - 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
> 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
> 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.
I also need the server to help me find a TURN server I can use if I
So after setup you do not need the XMPP server anymore if you have a
direct connection and you only need a TURN server if not. If you have
some firewall problems or no TURN server you need the XMPP server for
How can something be 'new and improved'? If it's new what was it improving on?
More information about the Security