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. Yes > - clients can be both humans and applications (bots/devices) Yes > - "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. Yes > - 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 http://www.tzi.de/~dmeyer/tlsauth.html 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 explain. > - 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 Dirk -- panic("Aarggh: attempting to free lock with active wait queue - shoot Andy"); 2.0.38 /usr/src/linux/fs/locks.c
