On Sun, 24 Aug 2008 10:58:25 +1000 David Banes <[EMAIL PROTECTED]> wrote:
> After scanning this thread I have just two observations... > > 1) A solution needs to assume users are hopeless, that is they can't > setup home routers, crypto etc. No. A solution needs to assume most users are hopeless. Not all. XMPP has been mostly used by geeks. I believe we want to keep them and add common users to the userbase. And geeks are the ones that do care about encryption. > 2) Most companies will want a c2s solution as they will need to > scan, archive and audit content in the same way they for email now This is offtopic. If you want to scan, archive and audit, you don't want end-to-end security. If you want a secure e2e channel, you don't anyone to scan/archive/audit. This is mutually exclusive. If a local policy is to scan/archive/audit everything, they should just block any direct IP communication and for XMPP, block any e2e extensions. They don't need our help (and standards) to achieve this. > 3) If this is to be added to 'core' XMPP it needs to be REALLY > simple otherwise it won't get implemented. I don't think e2e encryption will ever get to any of the *basic* profiles anyway. Security is not an easy problem, it can't be easily solved. Though I believe it should be as easy as possible for the users and it should work well with other XMPP extensions. > Maybe these are all obvious. :) > > David. > > David Banes > web: http://davidbanes.com/ > pics: http://web.mac.com/dbanes/ > email: [EMAIL PROTECTED] > xmpp: [EMAIL PROTECTED] > skype: dmbanes > iChat: [EMAIL PROTECTED] > Director & Secretary, Internet Industry Association > > > > On 23/08/2008, at 7:21 PM, 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 > > > > > > - 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. > > > > - 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. > > > > - 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. > > > > 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 > > > ------------------------------------------------------------------------------------------------ > Email Security by Cleartext a CO2 Free company - www.cleartext.net > ------------------------------------------------------------------------------------------------ -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
