[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  
> ensure
> 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  
> message's
> 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.

Quick summary:

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  

Robert Quattlebaum
Jabber: darco at deepdarc.com
eMail:  darco at deepdarc.com
www:    http://www.deepdarc.com/

More information about the Standards mailing list