20 aug 2008 kl. 12.08 skrev Dave Cridland:
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.
Thanks
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.
After spending many years with SIP and NAT traversal, I know that we
will still need NAT traversal proxys, ICE/STUN is just a discovery
service. And considering a possible future with IPv4 and IPv6, there
will be proxys there too. Any solution has to work with an unknown or
wellidentified point in the middle.
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.
Me too!
I think we have to separate the technichal solution from implementor's
guidelines. The guidelines could talk about using USB sticks, propose
user interaction and other things that help those who write the
interface in the server and the client. We need to make sure that all
clients and servers share the same terminology. For instance -
ejabberd docs talk about a "certificate" when they mean a file
consisting of "private key in PEM encoding and CA certificate in PEM
encoding" - which is confusing. And PSI always complain over my CAcert
certificate, but doesn't propose a solution if I really want to keep
using this certificate, like SSH. All of the little tings need to
improve in order for users and admins to get going in the same
direction - a more secure XMPP network :-)
/O
