On Wed Aug 20 07:37:32 2008, Johansson Olle E wrote:
1) XMPP often uses (and the XMPP foundation strongly recommends)
TLS between client and server. Within server, the messages are in
the clear. Thus, it gives no secure channel between two end
points. Also, between two endpoints connecting to servers with
TLS, there could be a non-TLS connection server-to-server (S2S).
So even with a TLS connection between a client and a server, we
can't assume that we have security end-to-end. We need to set that
up. This discussion is about how to set up confidential and
authenticated client-to-client sessions, based on the this
scenario.
Right, good summary.
3) Clients may be behind NAT, so even a client-to-client direct
session may need help from a server (proxy). This will have to be
considered.
This is a non-issue - we have Jingle, so we have the ability to
negotiate various channels, at least one of which (IBB) will work
through any amount of NATs and firewalling, albeit at a cost of
efficiency and ugliness. Really, this whole debate about IBB vs NATs
vs whatever is immaterial; we have Jingle specifically to solve all
these problems, and it passes the buck to ICE-TCP et al to solve the
tricky cases.
5) Not all clients are human. We need solutions, but maybe not one
solution, for
- human clients on some sort of computer
- bots with a delegation from a human (set-top-boxes)
- applications (XMPP is used as middleware)
For reasons concerning the retention of my santity, at least, I'd
prefer these to be as common as possible.
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
