Subject: [xmpp] #8: stream directionality is poorly defined

From: "xmpp issue tracker" <[email-masked]>
Date: Mon, 14 Jun 2010 16:20:49 -0000

#8: stream directionality is poorly defined
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |       Owner:  stpeter@…         
     Type:  defect              |      Status:  new               
 Priority:  minor               |   Milestone:                    
Component:  3920bis             |     Version:                    
 Severity:  In WG Last Call     |    Keywords:                    
--------------------------------+-------------------------------------------
 Reported by Dave Cridland:

 The concept of stream directionality in Section 3.3 (Directionality) is
 weak.

 "I sincerely hope that a client ensures that the identity of the server is
 correct. This has nothing whatsoever to do with bidirectionality. I think
 much of this section needs replacing with a nice, handwavey 'For
 historical reasons' bit."

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/xmpp/trac/ticket/8>
xmpp <http://tools.ietf.org/xmpp/>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 Jun 2010 19:11:20 -0600

On 6/14/10 10:20 AM, xmpp issue tracker wrote:
>  correct. 

In the absence of TLS, how exactly does the server authenticate to the
client (and what does it mean for the client to ensure that the identity
of the server is correct)?

> This has nothing whatsoever to do with bidirectionality. 

I respectfully disagree.

> I think

Suggested text is always appreciated so that we can discuss the matter
in a more thorough manner.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "xmpp issue tracker" <[email-masked]>
Date: Fri, 25 Jun 2010 04:04:03 -0000

#8: stream directionality is poorly defined
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |        Owner:  stpeter@…         
     Type:  defect              |       Status:  closed            
 Priority:  minor               |    Milestone:                    
Component:  3920bis             |      Version:                    
 Severity:  In WG Last Call     |   Resolution:  wontfix           
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by stpeter@…):

  * status:  new => closed
  * resolution:  => wontfix

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/xmpp/trac/ticket/8#comment:1>
xmpp <http://tools.ietf.org/xmpp/>

---

From: Dave Cridland <[email-masked]>
Date: Fri, 25 Jun 2010 10:48:29 +0100

> of the server is correct)?
The client has to, always, authenticate the server.

If it does not do so and continues to send stanzas, it is potentially  
transmitting data to a spoofed server.

Now, it may be that a client considers DNS to be sufficient in terms  
of credentials - despite the fact this DNS spoofing is possible - and  
this is what's actually happening in the wild, at least for the most  
part.

> > This has nothing whatsoever to do with bidirectionality.
So you think that when one server connects to another, then either  
the initiating entity or the receiving entity is unauthenticated by  
the other? You think that at some level, the initiator is thinking  
"Gosh, I don't know who you are, but have some stanzas anyway!"  
Thankfully, this does not occur - albeit mostly due to the fact we  
consider the DNS to be adequate for authenication in most  
circumstances.

On the contrary, the receiver typically authenticates the initiator  
at least via dialback, yet we consider this inappropriate for  
actually sending stanzas to it.

I understand the reasons for this unidirectional S2S thing - it's  
simply because in the original jabber protocol, there was no  
authentication of the initiator, and the model has never been changed  
since.

So I'd simply replace all but the final paragraph of §3.3 with:

<t>An XML Stream is either bidirectional, allowing stanzas to be sent  
in either direction at any time, or unidirectional, allowing stanzas  
to be send only in one, fixed, direction.</t>

<t>Clients establish a single, bidirectional link to a server for a  
session, allowing XML stanzas to be sent from client to server and  
server to client. Servers, for historical reasons, establish two  
unidirectional connections between each other, one in each direction.  
A future extension might allow servers to establish bidirectional  
links given suitable mutual authentication, however this is out of  
scope for this document.</t>

Dave.

---

From: Justin Karneges <[email-masked]>
Date: Fri, 25 Jun 2010 09:32:54 -0700

> scope for this document.</t>

I still think we need to get the words "mutual authentication" out of here, 
because it makes directionality seem like a security issue when it isn't.  
Maybe replace with "feature negotiation".

-Justin

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 27 Jun 2010 20:55:16 -0600

> On Fri Jun 25 02:11:20 2010, Peter Saint-Andre wrote:

<tangent>

> The client has to, always, authenticate the server.

If, absent DNSSEC and TLS, the client resolves the hostname of the
server to an IP address and connects to that IP address, does that count
as authentication? I don't think so, but such a scenario is quite common
in XMPP, just as it is in HTTP and IMAP and many other application
protocols. In this case as in so many others, the client considers
itself as subordinate to the server and trusts in the Domain Name System
and other parts of the Internet infrastructure to return the right
answers and do the right thing. Foolish, but common.

> transmitting data to a spoofed server.

You betcha. I didn't say it was a smart idea for a client to connect
without authenticating the server.

> Now, it may be that a client considers DNS to be sufficient in terms of
> credentials - despite the fact this DNS spoofing is possible - and this
> is what's actually happening in the wild, at least for the most part.

Right. But let's not pretend that such behavior counts as authentication.

> So you think that when one server connects to another, then either the
> initiating entity or the receiving entity is unauthenticated by the
> other? You think that at some level, the initiator is thinking "Gosh, I
> don't know who you are, but have some stanzas anyway!" Thankfully, this
> does not occur - albeit mostly due to the fact we consider the DNS to be
> adequate for authenication in most circumstances.

No, that is not authentication.

> On the contrary, the receiver typically authenticates the initiator at
> least via dialback, yet we consider this inappropriate for actually
> sending stanzas to it.

Dialback does not result in authentication. Section 14.4 of RFC 3920
states in part:

   Server dialback helps protect against domain spoofing, thus making it
   more difficult to spoof XML stanzas.  It is not a mechanism for
   authenticating, securing, or encrypting streams between servers as is
   done via SASL and TLS, and results in weak verification of server
   identities only.  Furthermore, it is susceptible to DNS poisoning
   attacks unless DNSSec [DNSSEC] is used, and even if the DNS
   information is accurate, dialback cannot protect from attacks where
   the attacker is capable of hijacking the IP address of the remote
   domain.  Domains requiring robust security SHOULD use TLS and SASL.
   If SASL is used for server-to-server authentication, dialback SHOULD
   NOT be used since it is unnecessary.

> I understand the reasons for this unidirectional S2S thing - it's simply
> because in the original jabber protocol, there was no authentication of
> the initiator, and the model has never been changed since.

By "original jabber protocol" I take it you mean everything before the
introduction of server dialback in October 2000. But server dialback
does not provide authentication, either.

</tangent>

<substance>

> <t>An XML Stream is either bidirectional, allowing stanzas to be sent in
> either direction at any time, or unidirectional, allowing stanzas to be
> send only in one, fixed, direction.</t>
> 
> unidirectional connections between each other, one in each direction. A
> future extension might allow servers to establish bidirectional links
> given suitable mutual authentication, however this is out of scope for
> this document.</t>

Despite my disagreements with you over the definition of authentication,
I think that text is fine, and indeed less confusing than what's in
3920bis now (with the suggestion from Justin Karneges to replace "mutual
authentication" with "feature negotiation").

</substance>