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

[Pavel Simerda]

On Sun, 24 Aug 2008 09:37:46 +0200
Johansson Olle E <oej at edvina.net> 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:  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
> > ------------------------------------------------------------------------------------------------
> 
> ---
> * Olle E Johansson - oej at edvina.net
> * 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