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

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

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

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


Dirk

-- 
How can something be 'new and improved'? If it's new what was it improving on?


More information about the Security mailing list