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

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


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

> - 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
section 5.

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

> - Any solution does have to work over NAT sessions, possibly with
> NAT relays, where NAT traversal support systems like STUN and ICE
> fails.

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
	2.0.38 /usr/src/linux/fs/locks.c

More information about the Security mailing list