[asterisk-dev] asterisk sip authentication flawed?

[Damon Estep]

Ran this by users, 1 responder agreed, no work around. Seems like a bug,
but I wanted to get some more feedback before reporting anything.

 

Asterisk authenticates on invite using this methodology;

 

First, the name portion of the URI on the from header of the invite is
compared to the defined sip users, so if an invite comes from
user1 at abc.com asterisk looks for a sip user named 'user1'. If that sip
user is found the invite is expected to pass the configured
authentication for that user.

 

If there is no match the source IP/port of the invite is compared to
statically configured users (host=, port=, insecure=).


The resulting behavior is that there is a bug when a SIP invite
coincidentally originates 'from' a trusted IP address, but the user in
the URI matches a configured user in the target system. Asterisk rejects
the invite with a 407, proxy authentication required.

 

The correct behavior (I think) would be to evaluate possible matches to
statically defined users FIRST (port AND IP for security), then look at
the username if there is no match. If it were not for NAT you would not
parse the URI either, you would look for a complete match of the from
URI in the invite and the registered users 'FULL CONTACT' URIs.

 

Situations were SIP users are trusted by IP address alone are typically
peering situations, and in most conceivable implementations the number
of peering partners is far fewer than the number of registered UAs, but
the number of calls from an individual peering partner is likely to be
far greater than the number of calls from any singe UA. There would be a
resulting slight efficiency gain since the higher number of inbound
calls from a trusted peer would find a match earlier in the evaluation.
I realize this is arguable and subject to the situation at hand, but the
point is that it would eliminate a bug and NOT create any IN-efficiency.

 

Have I missed a simple concept? Is there a way to send a user/pass pair
in the invite that overrides Asterisk authentication methodology?

 

Right now it seems truly impossible to fully trust a user by IP, since
an invite can be formed in such a way that certain calls are rejected
with the SIP 407 message.

 

The ultimate question is whether this is a bug or a training issue.

 

Damon E

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20070104/bbfd10dc/attachment.htm