On Sun, 24 Aug 2008 09:37:46 +0200 Johansson Olle E <[EMAIL PROTECTED]> wrote:
> > 24 aug 2008 kl. 02.58 skrev David Banes: > > > 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. > > > Well, some times I believe you're right. However, I didn't write it > that way, tried to turn it around by suggesting > that we need good guidelines for implementors and a common > terminology. I am still naive enough to believe that > we can educate and encourage users to do things right with proper > software implementations. You actually can. > The effort to make it right is huge, so by sharing the cost by > developing guidelines together > in the community, I still think it can be done. +1 > > > > 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 > That is a policy issue. Servers will have to implement a way to > avoid c2c connections. This policy doesn't need our attention as I tried to explain in my previous post. > > > > 3) If this is to be added to 'core' XMPP it needs to be REALLY > > simple otherwise it won't get implemented. > Well, good security isn't always easy to implement. But by working > together implementing guidelines > for implementors, a common terminology and maybe even open source > libraries, I believe it will be > implemented. Ah good, not that different from what I answered ;). > > Thanks for the feedback! > > /Olle > > > > > > 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 > > ------------------------------------------------------------------------------------------------ > > --- > * Olle E Johansson - [EMAIL PROTECTED] > * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden > > > -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
