[Standards-JIG] Internet-scale subscription protocols

Jochen Topf jochen at remote.org
Thu Nov 9 09:14:23 UTC 2006

On Tue, Nov 07, 2006 at 05:15:02PM -0800, Robert B Quattlebaum, Jr. wrote:
> 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  
> certificates.

Just to make one thing more clear: You still have to trust your own
server absolutely. It sees and routes all the messages, so it can send
you fake messages from any address it wants to and it can send your
message to anybody it wants to, not only the intended recipients. This
follows from XMPP's hop-to-hop security model. If you need more than
this, i.e. if you don't trust your server, you at least have to do
end-to-end encryption and/or signing.

Jochen Topf  jochen at remote.org  http://www.remote.org/jochen/  +49-721-388298

More information about the Standards mailing list