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

Johansson Olle E oej at edvina.net
Sat Aug 23 04:21:55 CDT 2008

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  
   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  
   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  
   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  
thist month, there's plenty of them in the forests of Sweden.


More information about the Security mailing list