[asterisk-dev] [Code Review] New application JabberReceive, implement SendText in chan_gtalk and chan_jingle

[John Todd]

On Dec 15, 2008, at 8:46 AM, Tzafrir Cohen wrote:

> On Mon, Dec 15, 2008 at 03:58:09PM +0000, Julian Lyndon-Smith wrote:
>> Tzafrir Cohen wrote:
>>> On Mon, Dec 15, 2008 at 02:00:02PM +0000, Julian Lyndon-Smith wrote:
>>>
>>>> [/me adds to the burden]
>>>>
>>>> Would anyone consider using the jabber receive as a source for AMI
>>>> commands as well ?
>>>
>>> Who actually authenticates the user in this case? How difficult  
>>> would it
>>> be for me to sneak in a message pretending to be from someone  
>>> else? Who
>>> do I trust?
>>
>> I would have thought that (just like the ami manager) you would  
>> have a
>> list of JID's that are allowed to use the appropriate AMI commands.
>
> So regarding my questions:
>
> | Who actually authenticates the user in this case?
>
> Remote XMPP servers authenticating the users (what about those  
> relaying
> the messages?)
>
> | How difficult would it be for me to sneak in a message pretending to
> | be from someone else?
>
> I have no idea. I guess each server basically trusts all of its peers.
> But I'm not familiar with how XMPP networks actually work.
>
> | Who do I trust?
>
> All the XMPP servers in that specific XMPP network? Or is it just a
> specific one assigned that domain (by whom?)
>
>
> And I guess that a more practical question would be: is authentication
> by JID already in use anywhere for anything that is non-trivial?



It is my (perhaps flawed) understanding that XMPP servers authenticate  
between servers only, so this removes the problem from the domain of  
an Asterisk problem to solve.  There is no "peer-to-peer" mode for  
XMPP, so each server controls what they will accept and forward.

The Asterisk system will only accept inbound connections (or so I  
hope) from the XMPP server to which a JID is registered.  Someone  
should make sure this is the case, but that is what makes sense.  :-)   
So we're covered on the Asterisk side - now, how to make sure that a  
"sender" that is trying to relay messages through our XMPP server is  
who they say they are...

An XMPP server can use no authentication, weak authentication, or TLS  
authentication at the discretion of the sysadmin.  The most common  
method is "weak" authentication, which is called "dialback."  It uses  
DNS to establish a forward-path verification of an inbound message.   
I'll cut the example from the XEP (http://xmpp.org/extensions/xep-0220.html 
):

"A helpful analogy might be the following telephone scenario:
	• A representative from your electric utility company knocks on your  
front door and says he needs to enter your house.
	• Rather than letting him in, you ask for his employee ID number and  
politely close the door for a few moments.
	• You open the phone book, find the authoritative phone number for  
the utility company's headquarters, and call them on the phone.
	• After being transferred to the customer service department, you ask  
if a rep with that particular ID number is authorized to be visiting  
your house.
	• The company tells you that the rep is authorized, so you thank them  
and hang up.
	• You then reopen the front door and allow the rep to enter your house"

Of course, using TLS is far more secure, but many (most?) systems  
don't use TLS with root-signed certs, even if some use TLS with self- 
signed certs for encryption.

There is another anti-spoofing XEP (http://xmpp.org/extensions/attic/xep-0165-0.3.html 
) that seems to be relevant, but I don't know enough about it to say  
how much advantage it offers over dialback.


JT

---
John Todd                       email:jtodd at digium.com
Digium, Inc. | Asterisk Open Source Community Director
445 Jan Davis Drive NW -  Huntsville AL 35806  -   USA
direct: +1-256-428-6083         http://www.digium.com/