[asterisk-dev] asterisk sip authentication flawed?

[Johansson Olle E]

4 jan 2007 kl. 20.00 skrev 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.
>
>
As Kevin said, this is in general a bad concept. But don't forget  
that regardless of the matching, we do have authentication
always.

The problem is that if I have an account named "olle" and someone  
called "olle" calls me from another domain, he can't call
me. The general advice, which you can find in many places in the  
archives, is not to use any account name that resembles
a mail address user part - like "olle" or "olle.johansson". One  
suggestion was to basically use the ethernet mac address
as account name.

And yes, I am going to change this so that we base authentication on  
the authentication ID, not the From: ID. THere's
an experimental patch in svn trunk for this, but I do believe we need  
a more general solution.

/O