[prev in list] [next in list] [prev in thread] [next in thread]
List: serusers
Subject: Re: [SR-Users] strange conditional "if ($au!=$tU)" with previous exit
From: Giovanni Maruzzelli <gmaruzz () gmail ! com>
Date: 2019-10-30 8:46:26
Message-ID: CALXCt0oTHdUztp3OoBJuRJNA1FEOuzm-FHgxiorem8O9RHZsgw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Gorgeous explanations!
On Tue, Oct 29, 2019 at 6:36 PM Alex Balashov <abalashov@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@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
>
--
Sincerely,
Giovanni Maruzzelli
OpenTelecom.IT
cell: +39 347 266 56 18
[Attachment #5 (text/html)]
<div dir="ltr"><div>Gorgeous explanations!</div><div><br></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 29, 2019 at 6:36 PM \
Alex Balashov <<a \
href="mailto:abalashov@evaristesys.com">abalashov@evaristesys.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">A savvy colleague \
reminded me to add that there are, occasionally, valid<br> reasons to relax this \
authentication vs identity concordance policy. <br> <br>
The main one comes up in Class 4/trunking environments, such as the<br>
kinds we deal with as our bread and butter. In this universe, a lot of<br>
caller ID/calling party name information is signalled in INVITEs using<br>
the From header, without necessarily the option of superseding that with<br>
P-Asserted-Identity or Remote-Party-ID (obsolete draft but stubbornly in<br>
use). Moreover, the calling party information sent can vary depending on<br>
which endpoint is making the call, so it is not practical to make it<br>
align with a single set of digest authentication credentials for the<br>
trunk.<br>
<br>
For example, a customer may wish to send an outbound caller ID of:<br>
<br>
From: <<a href="mailto:sip%3A%2B14045551212@sip.evaristesys.com" \
target="_blank">sip:+14045551212@sip.evaristesys.com</a>><br> <br>
along with a dozen other possible numbers.<br>
<br>
And the From URI may be their only viable means of sending it, as a<br>
matter of technical limitations or policy. But their authentication<br>
credentials would be a username or an account ID or something like that,<br>
so sending them a 407 Proxy Authorization Required challenge with the<br>
expectation that their response have an $au that aligns with their $fU<br>
is not realistic. <br>
<br>
So, on some installations, it is either necessary or expedient not to<br>
enforce this requirement and just hope for the best. <br>
<br>
For this reason, almost all the Kamailio auth functions provide<br>
flexibility to turn this more draconian enforcement or on off. For<br>
example, the auth_check() function in auth_db has a 'flags' parameter:<br>
<br>
<a href="https://kamailio.org/docs/modules/5.3.x/modules/auth_db.html#auth_db.f.auth_check" \
rel="noreferrer" target="_blank">https://kamailio.org/docs/modules/5.3.x/modules/auth_db.html#auth_db.f.auth_check</a><br>
<br>
From the above documentation, flag 1 is:<br>
<br>
"If it is 1, then the function will check to see if the <br>
authentication username matches either To or From header <br>
username. REGISTER requests: From and To must match the <br>
authentication user."<br>
<br>
This flexibility is a nod to the reality that this policy is not always<br>
appropriate or practical.<br>
<br>
-- Alex<br>
<br>
On Tue, Oct 29, 2019 at 01:18:27PM -0400, Alex Balashov wrote:<br>
<br>
> Hi,<br>
> <br>
> When any SIP request arrives at the proxy, it asserts some kind of<br>
> identity ("I am claiming to be <a \
href="mailto:sip%3Aalex@sip.evaristesys.com" \
target="_blank">sip:alex@sip.evaristesys.com</a>"). <br> > <br>
> In most SIP requests, this is the From URI ($fu) identity, but in<br>
> REGISTERs, it's the To URI ($tu), because according to the standard, the<br>
> AoR (Address of Record) that the registration seeks to establish a<br>
> binding for is situated in the To URI.<br>
> <br>
> This identity can be trusted at face value, but usually isn't; \
that's<br> > the reason for the RFC 2617-inspired digest challenge / \
authentication<br> > mechanism. The proxy sends a nonce (temporary encryption key \
of sorts)<br> > and expects a new request which has an additional header (e.g.<br>
> "Authorization") whose value is encrypted with that nonce. This<br>
> Authorization header has several parameters, one of which is an<br>
> "authentication username" -- exposed in the Kamailio config as \
$au.<br> > <br>
> The check you are asking about ensures alignment between the<br>
> authentication username and the broader "identity" username, if \
you<br> > like. This is usually desirable, because otherwise, I could register<br>
> with an AoR of "<a href="mailto:sip%3Alenz@sip.evaristesys.com" \
target="_blank">sip:lenz@sip.evaristesys.com</a>" as long as I have some<br> \
> other, valid credentials on the system. In other words, I could use my<br> > \
username for 'alex' in order to establish a registration of<br> > "<a \
href="mailto:sip%3Alenz@sip.evaristesys.com" \
target="_blank">sip:lenz@sip.evaristesys.com</a>". But if alignment betweeen $tU \
== $au is<br> > assured, then I can only use authentication credentials for \
'alex' in<br> > order to register an identity of 'alex', and you \
can only use<br> > authentication credentials for 'lenz' to bind an \
identity of 'lenz'.<br> > <br>
> Does that make sense?<br>
> <br>
> -- Alex<br>
> <br>
> On Tue, Oct 29, 2019 at 11:35:45AM -0400, PICCORO McKAY Lenz wrote:<br>
> <br>
> > i have this in asterisk integration how to, and i noted the \
"exit"<br> > > before the "if($au!=$tU)" .. i dont \
understan the conditional and the<br> > > exit there!<br>
> > <br>
> > please can someon xplain me that!?<br>
> > <br>
> > # authenticate the REGISTER requests (uncomment to enable auth)<br>
> > #!ifdef WITH_ASTERISK<br>
> > if (!www_authorize("$td", "sipusers"))<br>
> > #!else<br>
> > if (!www_authorize("$td", "subscriber"))<br>
> > #!endif<br>
> > {<br>
> > www_challenge("$td", "0");<br>
> > exit;<br>
> > }<br>
> > if ($au!=$tU)<br>
> > {<br>
> > sl_send_reply("403","Forbidden auth ID");<br>
> > exit;<br>
> > }<br>
> > <br>
> > i investigate at the kamailio cgf documentation and there's no \
clear<br> > > topic related!<br>
> > <br>
> > <a href="http://www.kamailio.org/wiki/cookbooks/5.2.x/pseudovariables#tu_-_to_uri" \
rel="noreferrer" target="_blank">http://www.kamailio.org/wiki/cookbooks/5.2.x/pseudovariables#tu_-_to_uri</a><br>
> > <br>
> > Lenz McKAY Gerardo (PICCORO)<br>
> > <a href="http://qgqlochekone.blogspot.com" rel="noreferrer" \
target="_blank">http://qgqlochekone.blogspot.com</a><br> > > <br>
> > _______________________________________________<br>
> > Kamailio (SER) - Users Mailing List<br>
> > <a href="mailto:sr-users@lists.kamailio.org" \
target="_blank">sr-users@lists.kamailio.org</a><br> > > <a \
href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" \
target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br> \
> <br> > -- <br>
> Alex Balashov | Principal | Evariste Systems LLC<br>
> <br>
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) <br>
> Web: <a href="http://www.evaristesys.com/" rel="noreferrer" \
target="_blank">http://www.evaristesys.com/</a>, <a href="http://www.csrpswitch.com/" \
rel="noreferrer" target="_blank">http://www.csrpswitch.com/</a><br> > <br>
> _______________________________________________<br>
> Kamailio (SER) - Users Mailing List<br>
> <a href="mailto:sr-users@lists.kamailio.org" \
target="_blank">sr-users@lists.kamailio.org</a><br> > <a \
href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" \
target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br> \
<br>
-- <br>
Alex Balashov | Principal | Evariste Systems LLC<br>
<br>
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) <br>
Web: <a href="http://www.evaristesys.com/" rel="noreferrer" \
target="_blank">http://www.evaristesys.com/</a>, <a href="http://www.csrpswitch.com/" \
rel="noreferrer" target="_blank">http://www.csrpswitch.com/</a><br> <br>
_______________________________________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org" \
target="_blank">sr-users@lists.kamailio.org</a><br> <a \
href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" \
target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br> \
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" \
class="gmail_signature">Sincerely,<br><br>Giovanni \
Maruzzelli<br>OpenTelecom.IT<br>cell: +39 347 266 56 18<br><br></div>
[Attachment #6 (text/plain)]
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic