[asterisk-dev] asterisk sip authentication flawed?

[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?
> 
> 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.