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

Johansson Olle E oej at edvina.net
Sun Aug 24 02:37:46 CDT 2008


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.
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.

>
> 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.

>
> 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.

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





More information about the Security mailing list