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

Pedro Melo melo at simplicidade.org
Sat Aug 23 07:38:25 CDT 2008


On Aug 23, 2008, at 12:54 PM, Dirk Meyer wrote:

> Johansson Olle E wrote:
>> - "secure" can be divided into
>>    * confidential - meaning encrypted in a secure way (secure here
>> depends on the nature of the conversation)
>>    *authenticated - all involved parties have assured the identity of
>> the other parties.
>
> Yes and no. You can not have a secure channel without
> authentication. If you do not know who the peer is you do not know if
> there is a man-in-the-middle.

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


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


>>  - To bootstrap the usage of this, we need a set of solutions that
>> MUST be implemented in clients and servers. This should also be
>> included in the XEPs for base profile of clients/servers. The
>> standards should define optional solutions that can be used in
>> various environments, like enterprise PKI controlled IM and
>> middle-ware-messaging XMPP systems or solutions that emphasize
>> strong authentication but doesn't necessarily have a need of
>> confidentiality.
>
> My XEP proposal from above does not require anything from a server,
> but XEP-0189 using PubSub would be required. For the hosted solutions
> we need server support.

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.

I use Jingle to setup a end-to-end channel, encrypted with TLS, and  
trusted with verification of certificates. That's it.

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




More information about the Security mailing list