[Security] client-to-client security :: Summary and todo's
pavlix at pavlix.net
Sat Aug 23 09:50:30 CDT 2008
On Sat, 23 Aug 2008 11:21:55 +0200
Johansson Olle E <oej at edvina.net> 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
> - 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.
Btw, is it really necessary to set up secure connections through
servers? If it is a session, why not IP to IP (peer-too-peer)?
Or does is the centralization plague of the internet around servers so
severe that nobody considers direct connections?
> - 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.
> - At this point, we place requirements for non-repudation and
> integrity outside
> of the scope of this work
> - The level of security needed depends on the nature of the
> conversation. The standard
> should be flexible and open for several kinds of authentication
> from OpenGPG systems to X.509 certificates, from self-signed
> certificates to
> PKI-managed certificates.
I agree we should allow various systems suitable for both individuals
and companies. This would be a great advantage over custom-protocol
> - 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.
> - 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.
> - 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
> - 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.
> - Any solution does have to work over NAT sessions, possibly with
> NAT relays, where NAT traversal support systems like STUN and
> ICE fails.
If I missed something in my first question, forgive me ;).
> Not in any special order...
> Have a nice weekend! I'm going out to pick mushrooms. After a lot of
> thist month, there's plenty of them in the forests of Sweden.
Jabber & Mail: pavlix(at)pavlix.net
More information about the Security