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.
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
3) If this is to be added to 'core' XMPP it needs to be REALLY simple
otherwise it won't get implemented.
Maybe these are all obvious. :)
David.
David Banes
web: http://davidbanes.com/
pics: http://web.mac.com/dbanes/
email: [EMAIL PROTECTED]
xmpp: [EMAIL PROTECTED]
skype: dmbanes
iChat: [EMAIL PROTECTED]
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
------------------------------------------------------------------------------------------------
