On Sat, 23 Aug 2008 11:21:55 +0200 Johansson Olle E <[EMAIL PROTECTED]> 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 > systems, > 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 solutions. > - 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. Sounds good. > - 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 > rain > thist month, there's plenty of them in the forests of Sweden. > > /O -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
