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

[Pavel Simerda]

On Sat, 23 Aug 2008 11:21:55 +0200
Johansson Olle E <oej at edvina.net> 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.

Btw, is it really necessary to set up secure connections through
servers? If it is a session, why not IP to IP (peer-too-peer)?

Or does is the centralization plague of the internet around servers so
severe that nobody considers direct connections?

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

I agree we should allow various systems suitable for both individuals
and companies. This would be a great advantage over custom-protocol
solutions.

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

Sounds good.

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

If I missed something in my first question, forgive me ;).

> 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


-- 

Web: http://www.pavlix.net/
Jabber & Mail: pavlix(at)pavlix.net
OpenID: pavlix.net