asterisk users - Jan 2007 - asterisk sip peer/user matching methodsforauthentication backwards?

I have considered opening a bug report on this, but wanted to get some
feedback and make sure I am not missing something in the way of a simple
work around. What is the scenario in which this impacts your
implementation?

 

Ours is the desire to use the same realtime SIP database for many
asterisk servers, and route the call based on a "home server" value in
the realtime database. The problem is that a call routed form one server
to another will not complete because the originating server is not
trusted as it should be by IP address, rather the SIP UA that initiated
the call is expected to authenticate on the destination server, which is
ridiculous.

 

All methods of allowing un-authenticated SIP peering (host=, insecure=)
are broken as soon as the caller name portion of the "from" header URI
is present on the called parties server.

 

I can not think of why it would break something different to reverse the
evaluation order.

 

 

________________________________

From: asterisk-users-bounces@lists.digium.com
[mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Doug
Meredith
Sent: Thursday, January 04, 2007 10:23 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: RE: [asterisk-users] asterisk sip peer/user matching
methodsforauthentication backwards?

 

Hi,

 

I too have found this matching to be frustrating.  I would like it to
behave as you describe.

 

Doug

-- 

Doug Meredith

506-854-7997 ext. 801

________________________________

From: asterisk-users-bounces@lists.digium.com
[mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Damon
Estep
Sent: Thursday, January 04, 2007 1:50 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: [asterisk-users] asterisk sip peer/user matching methods
forauthentication backwards?

 

Take an example where there is two sip users defined in sip.conf as
follows;

 

[peer1]

Host=192.168.1.1

...

 

[peer2]

Host=dynamic

Secret=password

...

 

[Peer3]

Config not relevant

...

 

The intention is to accept calls from peer1 without authentication (ip
address authentication only), but require authentication from peer2

 

If by chance a SIP invite comes "From" peer2@192.168.1.1 (where the
name
peer2 on the calling server coincidentally matches a defined sip user on
the called asterisk server)  "To" peer3@asterisk_hostname, Asterisk
will
attempt to authenticate the caller "peer2" rather than accepting the
call based on the fact that it came from a trusted Ip address defined
for peer1. Since peer1 is trusted it is not sending credentials and will
have its invite rejected with a 407 "proxy authentication required"
when
it fails to authenticate as "peer2".

 

This logic seems backwards to me, the IP address should be matched
first, and if there is no statically defined user with that IP address
the username should be matched next. This would insure that all calls
from the trusted IP address are accepted regardless of whether there is
coincidently a SIP user with a matching name defined on the target
asterisk server.

 

So rather than looking for a match in this order;

 

1.	name portion of "From" URI in the invite ("host" in the
URI
host@domain.com).
2.	ip address statically assigne for a user

 

it should look in this order;

 

1.	statically defined sip user ip addresses
2.	name portion of the "From" URI

 

Can anyone shed any light on this, or suggest a workaround so 407's are
not sent if the invite "from" header happens to have the same name
portion of the URI as a defined sip user on the target asterisk server ?

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20070104/6935b7c1/attachment-0001.htm

Anyone found a solution to this problem?

Remi

Damon Estep wrote:
>
> I have considered opening a bug report on this, but wanted to get some 
> feedback and make sure I am not missing something in the way of a 
> simple work around. What is the scenario in which this impacts your 
> implementation?
>
> Ours is the desire to use the same realtime SIP database for many 
> asterisk servers, and route the call based on a ?home server? value in 
> the realtime database. The problem is that a call routed form one 
> server to another will not complete because the originating server is 
> not trusted as it should be by IP address, rather the SIP UA that 
> initiated the call is expected to authenticate on the destination 
> server, which is ridiculous.
>
> All methods of allowing un-authenticated SIP peering (host=, 
> insecure=) are broken as soon as the caller name portion of the ?from? 
> header URI is present on the called parties server.
>
> I can not think of why it would break something different to reverse 
> the evaluation order.
>
> ------------------------------------------------------------------------
>
> *From:* asterisk-users-bounces@lists.digium.com 
> [mailto:asterisk-users-bounces@lists.digium.com] *On Behalf Of *Doug 
> Meredith
> *Sent:* Thursday, January 04, 2007 10:23 AM
> *To:* Asterisk Users Mailing List - Non-Commercial Discussion
> *Subject:* RE: [asterisk-users] asterisk sip peer/user matching 
> methodsforauthentication backwards?
>
> Hi,
>
> I too have found this matching to be frustrating. I would like it to 
> behave as you describe.
>
> Doug
>
> -- 
>
> Doug Meredith
>
> 506-854-7997 ext. 801
>
> ------------------------------------------------------------------------
>
> *From:* asterisk-users-bounces@lists.digium.com 
> [mailto:asterisk-users-bounces@lists.digium.com] *On Behalf Of *Damon 
> Estep
> *Sent:* Thursday, January 04, 2007 1:50 AM
> *To:* Asterisk Users Mailing List - Non-Commercial Discussion
> *Subject:* [asterisk-users] asterisk sip peer/user matching methods 
> forauthentication backwards?
>
> Take an example where there is two sip users defined in sip.conf as 
> follows;
>
> [peer1]
>
> Host=192.168.1.1
>
> ?
>
> [peer2]
>
> Host=dynamic
>
> Secret=password
>
> ?
>
> [Peer3]
>
> Config not relevant
>
> ?
>
> The intention is to accept calls from peer1 without authentication (ip 
> address authentication only), but require authentication from peer2
>
> If by chance a SIP invite comes ?From? peer2@192.168.1.1 
> <mailto:peer2@192.168.1.1> (where the name peer2 on the calling
server
> coincidentally matches a defined sip user on the called asterisk 
> server) ?To? peer3@asterisk_hostname, Asterisk will attempt to 
> authenticate the caller ?peer2? rather than accepting the call based 
> on the fact that it came from a trusted Ip address defined for peer1. 
> Since peer1 is trusted it is not sending credentials and will have its 
> invite rejected with a 407 ?proxy authentication required? when it 
> fails to authenticate as ?peer2?.
>
> This logic seems backwards to me, the IP address should be matched 
> first, and if there is no statically defined user with that IP address 
> the username should be matched next. This would insure that all calls 
> from the trusted IP address are accepted regardless of whether there 
> is coincidently a SIP user with a matching name defined on the target 
> asterisk server.
>
> So rather than looking for a match in this order;
>
>    1. name portion of ?From? URI in the invite (?host? in the URI
>       host@domain.com <mailto:host@domain.com>).
>    2. ip address statically assigne for a user
>
> it should look in this order;
>
>    1. statically defined sip user ip addresses
>    2. name portion of the ?From? URI
>
> Can anyone shed any light on this, or suggest a workaround so 407?s 
> are not sent if the invite ?from? header happens to have the same name 
> portion of the URI as a defined sip user on the target asterisk server ?
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>