Gorgeous explanations!
On Tue, Oct 29, 2019 at 6:36 PM Alex Balashov <[email protected]> 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:[email protected]> > > 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:[email protected]"). > > > > 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:[email protected]" 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:[email protected]". 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 > > > [email protected] > > > 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 > > [email protected] > > 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 > [email protected] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > -- Sincerely, Giovanni Maruzzelli OpenTelecom.IT cell: +39 347 266 56 18
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
