A savvy colleague reminded me to add that there are, occasionally, valid
reasons to relax this authentication vs identity concordance policy.

The main one comes up in Class 4/trunking environments, such as the
kinds we deal with as our bread and butter. In this universe, a lot of
caller ID/calling party name information is signalled in INVITEs using
the From header, without necessarily the option of superseding that with
P-Asserted-Identity or Remote-Party-ID (obsolete draft but stubbornly in
use). Moreover, the calling party information sent can vary depending on
which endpoint is making the call, so it is not practical to make it
align with a single set of digest authentication credentials for the
trunk.

For example, a customer may wish to send an outbound caller ID of:

   From: <sip:+14045551212@sip.evaristesys.com>

along with a dozen other possible numbers.

And the From URI may be their only viable means of sending it, as a
matter of technical limitations or policy. But their authentication
credentials would be a username or an account ID or something like that,
so sending them a 407 Proxy Authorization Required challenge with the
expectation that their response have an $au that aligns with their $fU
is not realistic.

So, on some installations, it is either necessary or expedient not to
enforce this requirement and just hope for the best.

For this reason, almost all the Kamailio auth functions provide
flexibility to turn this more draconian enforcement or on off. For
example, the auth_check() function in auth_db has a 'flags' parameter:

https://kamailio.org/docs/modules/5.3.x/modules/auth_db.html#auth_db.f.auth_check

>From the above documentation, flag 1 is:

   "If it is 1, then the function will check to see if the
   authentication username matches either To or From header
   username. REGISTER requests: From and To must match the
   authentication user."

This flexibility is a nod to the reality that this policy is not always
appropriate or practical.

-- Alex

On Tue, Oct 29, 2019 at 01:18:27PM -0400, Alex Balashov wrote:

> Hi,
>
> When any SIP request arrives at the proxy, it asserts some kind of
> identity ("I am claiming to be sip:alex@sip.evaristesys.com").
>
> In most SIP requests, this is the From URI ($fu) identity, but in
> REGISTERs, it's the To URI ($tu), because according to the standard, the
> AoR (Address of Record) that the registration seeks to establish a
> binding for is situated in the To URI.
>
> This identity can be trusted at face value, but usually isn't; that's
> the reason for the RFC 2617-inspired digest challenge / authentication
> mechanism. The proxy sends a nonce (temporary encryption key of sorts)
> and expects a new request which has an additional header (e.g.
> "Authorization") whose value is encrypted with that nonce. This
> Authorization header has several parameters, one of which is an
> "authentication username" -- exposed in the Kamailio config as $au.
>
> The check you are asking about ensures alignment between the
> authentication username and the broader "identity" username, if you
> like. This is usually desirable, because otherwise, I could register
> with an AoR of "sip:lenz@sip.evaristesys.com" as long as I have some
> other, valid credentials on the system. In other words, I could use my
> username for 'alex' in order to establish a registration of
> "sip:lenz@sip.evaristesys.com". But if alignment betweeen $tU == $au is
> assured, then I can only use authentication credentials for 'alex' in
> order to register an identity of 'alex', and you can only use
> authentication credentials for 'lenz' to bind an identity of 'lenz'.
>
> Does that make sense?
>
> -- Alex
>
> On Tue, Oct 29, 2019 at 11:35:45AM -0400, PICCORO McKAY Lenz wrote:
>
> > i have this in asterisk integration how to, and i noted the "exit"
> > before the "if($au!=$tU)" .. i dont understan the conditional and the
> > exit there!
> >
> > please can someon xplain me that!?
> >
> > # authenticate the REGISTER requests (uncomment to enable auth)
> > #!ifdef WITH_ASTERISK
> >    if (!www_authorize("$td", "sipusers"))
> > #!else
> >    if (!www_authorize("$td", "subscriber"))
> > #!endif
> >    {
> >       www_challenge("$td", "0");
> >       exit;
> >    }
> >    if ($au!=$tU)
> >    {
> >    sl_send_reply("403","Forbidden auth ID");
> >    exit;
> >    }
> >
> > i investigate at the kamailio cgf documentation and there's no clear
> > topic related!
> >
> > http://www.kamailio.org/wiki/cookbooks/5.2.x/pseudovariables#tu_-_to_uri
> >
> > Lenz McKAY Gerardo (PICCORO)
> > http://qgqlochekone.blogspot.com
> >
> > _______________________________________________
> > Kamailio (SER) - Users Mailing List
> > sr-users@lists.kamailio.org
> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Alex Balashov | Principal | Evariste Systems LLC
>
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

--
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users