[Security] client-to-client security :: Summary and todo's
dmeyer at tzi.de
Sat Aug 23 06:54:05 CDT 2008
Johansson Olle E wrote:
> Ok, I'll try to summarize a bit. With all these very technichal mails
> flowing around,
> I might have missed something, so please add/correct/flame as needed
Will do :)
> - The issue at hand is "how to set up a secure connection between
> two XMPP clients". Assume that we do have the ability to set up
> sessions through a network of XMPP servers or by using the same
> server and need to move from that channel to a secure channel - end
> to end.
Or use serverless messaging
> - The XMPP community wants to encourage use of secure connections
> and create a recommended solution that is so simple so it is
> actually becomes used, and so well documented and standardized, so
> it becomes implemented quickly in clients.
> - clients can be both humans and applications (bots/devices)
> - "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.
> - The level of security needed depends on the nature of the
> conversation. The standard should be flexible and open for several
> kinds of authentication systems, from OpenGPG systems to X.509
> certificates, from self-signed certificates to PKI-managed
> - In the documents needed, there is a need to separate the
> technology used for setting up secure connections from the trust
> systems involved.
> - The confidentiality solution is based on the well-known TLS
> standard, as specified by the IETF. Any authentication systems has
> to work in conjunction with TLS.
Yes. I wrote a proposal nobody answered to but it covers exactly that
It misses the Mnemonic stuff discussed here. There should be an
option that a client will accept unknwon certificates with a later
verification using Mnemonic or other tricks to hide the complexity of
> - A set of guidelines for GUI interfaces are needed, so that the
> XMPP implementations use the same terminology and concepts, thus
> making it easier for users to set up a secure connection.
Yes, maybe a different "Best Practice" XEP or in my XEP proposal in
> - 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
> - 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
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.
> - Any solution does have to work over NAT sessions, possibly with
> NAT relays, where NAT traversal support systems like STUN and ICE
Yes, jingle should take care of that. We need jingle-ice-tcp. :)
> Have a nice weekend! I'm going out to pick mushrooms. After a lot of
> rain thist month, there's plenty of them in the forests of Sweden.
Lucky you, we have rain without mushrooms in Bremen
panic("Aarggh: attempting to free lock with active wait queue - shoot
More information about the Security