[Security] client-to-client security :: Summary and todo's

Pavel Simerda pavlix at pavlix.net
Sun Aug 24 03:46:49 CDT 2008


On Sun, 24 Aug 2008 10:58:25 +1000
David Banes <david at banes.org> 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:  david at banes.org
> xmpp: dbanes at cleartextsystems.com
> skype: dmbanes
> iChat: dbanes at mac.com
> 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


More information about the Security mailing list