[SR-Users] strange conditional "if ($au!=$tU)" with previous exit

Wed Oct 30 09:46:26 CET 2019

Gorgeous explanations!

On Tue, Oct 29, 2019 at 6:36 PM Alex Balashov <abalashov at evaristesys.com>
wrote:

> 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 at 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 at 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 at 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 at 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 at 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 at 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 at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>

-- 
Sincerely,

Giovanni Maruzzelli
OpenTelecom.IT
cell: +39 347 266 56 18
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20191030/95584ad2/attachment.html>