[Standards-JIG] Internet-scale subscription protocols
Robert B Quattlebaum, Jr.
darco at deepdarc.com
Wed Nov 8 01:15:02 UTC 2006
On Nov 7, 2006, at 1:31 PM, Benjamin Carlyle wrote:
> The final aspect of XMPP that I don't feel I appreciate well enough to
> understand the protocol as a whole is how authentication and trust
> mechanisms fit into the picture. Previously I would have guessed that
> explicit digital signatures would be required on notifications to
> they came from an appropriate source. However, I'm suspicious that
> is encapsulating a trust mechanism in the network that I haven't
> come to
> terms with yet. I'm suspicious that a subscriber can trust the
> source address is accurate without needing any additional assurances
> that the source is not a man in the middle.
I'll take a stab at explaining this one.
1) Users of a server can only send stanzas from their own JID.
2) Servers can only send stanzas from JID's in that server's domain.
3) Servers will only receive and handle stanzas for JID's in that
server's domain. There is no relaying like what is inherent in SMTP.
Mechanisms are in place (SASL) for both client-to-server and server-
to-server authentication, which makes it very difficult to spoof.
More elaborate description:
When a client (say, jane at jabber.org) connects to it's server
(jabber.org), it must authenticate itself to the server before it
will be routed packets which are destened for jane at jabber.org. That
channel is only authorized for that JID and resource, so if jane
decides to send some stanzas to jabber.org with a from field of
joe at jabber.org, jabber.org will not forward it.
If a user on another server (bob at example.com) wanted to send a
message to jane, they would go through a similar login process on
their server. After they are logged in, they would send a stanza with
a 'to' field of jane at jabber.org to the example.com server. The
example.com server would realize that the user isn't on that server,
and would attempt to contact jabber.org.
The key here is that servers must perform some sort of channel
authentication (similar to what users go thru) before packets will be
routed. Once the channel has been authenticated, it is only valid for
packets with a from JID in the example.com domain. If jabber.org
wants to send packets back to example.com, another separate channel
is negotiated and authenticated.
The two most common methods servers can authenticate themselves to
each other are server dialback (the most common) and signed
Jabber: darco at deepdarc.com
eMail: darco at deepdarc.com
More information about the Standards