[asterisk-dev] asterisk sip authentication flawed?

[Olle E Johansson]

5 jan 2007 kl. 03.17 skrev Damon Estep:

>> Damon Estep wrote:
>>> 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.
>>
>> Well, I can think of a couple of comments... First, the way Asterisk
>> does SIP authentication right now is far too complex and out of the
>> 'spirit' of the RFCs anyway, so Olle is working on changing that.  
>> That
>> work won't appear until Asterisk 1.6, though.
>
> RFC consideration is always a good thing.
>>
>> Second, Asterisk 1.4 already supports a limited amount of 'domain
> based'
>> authentication, and this could be used to segregate the calls from
> your
>> trusted peers by having them direct the calls to a specific domain  
>> you
>> have setup for that purpose.
>
> What about a case where two asterisk servers connect to the same MySQL
> realtime SIP table? I can not see any way to route calls between  
> the to
> boxes with SIP in this case, since every UA (regardless of how  
> abstract
> the naming convention is) has a matching SIP user on both boxes so  
> every
> call between them is rejected with a 407. Any ideas?
Don't mix extensions with account names. They're two separate name
spaces and should be kept separate.

>>
>> Third, most people find it cumbersome and impractical to name SIP
> users
>> using any pattern that would appear as the From: username (which is
>> frequently the CNAM/CLID info), instead they use something completely
>> different as a user/peer naming scheme. While this is not ideal,  
>> it is
> a
>> way to avoid this issue.
>
> Well, we choose early on to use full 10 digit ANI for the sip username
> and the peer name (name and username both match 10 digit ANI) since 10
> digit TNs are globally unique. What is not clear is which "name"
> asterisk checks on invite for authentication, is it "name" or  
> "username"
> as defined in the realtime tables?. There are still times when the
> INVITE form a remote peer matches the 10 digit ANI, primarily during a
> TN port from one carrier to another when both the losing carrier  
> and the
> winning carrier have the TN programmed for a day or so.
>

Then you're mixing the namespaces, which is a bad idea.
This has been covered in many discussions.

/O