[SR-Users] Auth for SUBSCRIBE and others

Henning Westerholt hw at kamailio.org
Wed Mar 20 20:31:39 CET 2019


Am Mittwoch, 20. März 2019, 20:21:40 CET schrieb Kevin Olbrich:
> > Am Mittwoch, 20. März 2019, 19:48:00 CET schrieb Kevin Olbrich:
> > > > Am Dienstag, 19. März 2019, 16:40:23 CET schrieb Kevin Olbrich:
> > > > > thank you! I will check that again.
> > > > 
> > > > Hi Kevin,
> > > > 
> > > > I don't understand your problem or question, sorry.
> > > > 
> > > > Is the Digest Authentication not working correctly? Or are you
> > > > confused
> > > > about the SIP message flow for your wanted Presence application?
> > > 
> > > Yes, I am confused :-)
> > 
> > Hi Kevin,
> > 
> > if the AUTH for the Kamailio is the problem, just add some logic to
> > exclude
> > this particular SIP message from Kamailio from the AUTH challenge. Not
> > sure
> > how the Publish looks like, if its targeted to itself maybe something like
> > 'is_method("PUBLISH" && uri == "myself"' would do the trick. Maybe just
> > output the message in the kamailio cfg or look to the SIP signalization.
> 
> Ok, I understand. Thought this might be just a wrong module setting.
> This is what I am using now:
> 
> if(is_method("PUBLISH") && from_uri==myself) {
>     # source IP allowed
>     return;
> }

Hello,

well - as always with security questions, it depends. :-)

You could certainly check for the source IP too, just use the PV.

Best regards,

Henning

 
> Is this a safe setting? Looks like I allow forged messages if they set
> the servers domain in FROM.
> Do I need to implement $si check?
> 
> > About the question why it was developed like this - I guess the modules
> > were created independently from each others over several years.
> > 
> > Best regards,
> > 
> > Henning
> > 
> > > I read the docs and I learned, that the PUA modules with
> > > pua_dialoginfo + dialog (dlg_manage) allow me to track the call state
> > > per endpoint.
> > > This works perfectly (BLF works!) when I remove "WITH_AUTH" but it
> > > does not when it is enabled.
> > > 
> > > I can see that Kamailio generates a PUBLISH message and sends it back
> > > to itself. (Why? Shouldn't it be doing this inside the application?).
> > > Without AUTH, Kamailio accepts the message and sends NOTIFY to the
> > > endpoints. I do unterstand, that this makes perfect sense for cases
> > > where I host another Kamailio just for the PUBLISH / SUBSCRIBE. (But I
> > > am not...)
> > > 
> > > Why is it necessary to generate a message that is sent to the own
> > > process? And how is this supposed to work with Kamailio that has AUTH
> > > enabled?
> > > Asterisk for example nerver generates PUBLISH, it just sends NOTIFY to
> > > endpoints (the state is handled internal).
> > > 
> > > I am running the 5.2 Kamailio config with the additions from the HowTo
> > > and it does not work for me - Kamailio is rejecting it's own message.
> > > 
> > > > > In the mean time, I tried to get this running:
> > > > > http://kb.asipto.com/kamailio:presence:k43-blf
> > > > > 
> > > > > In my setup, the local node is also the presence server (... or
> > > > > should
> > > > > be).
> > > > > BLF is working perfectly fine if I disable AUTH (PUBLISH to local ->
> > > > > NOTIFY to phones).
> > > > > 
> > > > > If I enable AUTH, I can see "PUBLISH" sent to the node itself,
> > > > > getting
> > > > > denied by a 407 "Proxy Authentication Required".
> > > > > 
> > > > > Do I realy need a SIP message flowing to myself to "PUBLISH" the
> > > > > change detected by dlg_manage() + presence_dialoginfo +
> > > > > pua_dialoginfo?
> > > > > The behavior seems to be correct for external presence management
> > > > > where I do IP based auth.
> > > > > For my understanding, Kamailio could handle that internal without
> > > > > building a SIP message(?).
> > > > > 
> > > > > This is what I set up as params (pbx.example.com -> DOMAIN,
> > > > > 123.123.123.123 Public IP of node):
> > > > > =======================>%=======================
> > > > > #!ifdef WITH_PRESENCE
> > > > > # ----- presence params -----
> > > > > modparam("presence", "db_url", DBURL)
> > > > > modparam("presence", "server_address","sip:123.123.123.123:5060")
> > > > > modparam("presence", "send_fast_notify", 0)
> > > > > modparam("presence", "db_update_period", 20)
> > > > > modparam("presence", "subs_db_mode", 2)
> > > > > modparam("presence", "fetch_rows", 1000)
> > > > > 
> > > > > # ----- presence_xml params -----
> > > > > modparam("presence_xml", "db_url", DBURL)
> > > > > modparam("presence_xml", "force_active", 1)
> > > > > 
> > > > > # ----- presence_dialoginfo params -----
> > > > > modparam("presence_dialoginfo", "force_single_dialog", 0)
> > > > > 
> > > > > # -- dialog params --
> > > > > modparam("dialog", "db_url", DBURL)
> > > > > modparam("dialog", "db_mode", 1)
> > > > > modparam("dialog", "dlg_match_mode", 1)
> > > > > modparam("dialog", "enable_stats", 1)
> > > > > modparam("dialog", "dlg_flag", FLT_DLG)
> > > > > 
> > > > > # -- pua parameters --
> > > > > modparam("pua", "db_url", DBURL)
> > > > > modparam("pua", "db_mode", 2)
> > > > > modparam("pua", "update_period", 60)
> > > > > modparam("pua", "dlginfo_increase_version", 0)
> > > > > modparam("pua", "reginfo_increase_version", 0)
> > > > > modparam("pua", "check_remote_contact", 1)
> > > > > modparam("pua", "fetch_rows", 1000)
> > > > > 
> > > > > # ----- pua_dialoginfo params -----
> > > > > modparam("pua_dialoginfo", "include_callid", 1)
> > > > > modparam("pua_dialoginfo", "send_publish_flag", FLT_DLGINFO)
> > > > > modparam("pua_dialoginfo", "caller_confirmed", 0)
> > > > > modparam("pua_dialoginfo", "include_tags", 1)
> > > > > modparam("pua_dialoginfo", "override_lifetime", 124)
> > > > > 
> > > > > # CUSTOM
> > > > > modparam("pua_usrloc", "default_domain", "pbx.example.com")
> > > > > modparam("pua_reginfo", "server_address",
> > > > > "sip:123.123.123.123:5060")
> > > > > modparam("pua_reginfo", "default_domain", "pbx.example.com")
> > > > > #!endif
> > > > > =======================>%=======================
> > > > > 
> > > > > Kind regards
> > > > > Kevin
> > > > > 
> > > > > Am Mo., 18. März 2019 um 22:55 Uhr schrieb Henning Westerholt
> > > > 
> > > > <hw at kamailio.org>:
> > > > > > Am Montag, 18. März 2019, 19:42:30 CET schrieb Kevin Olbrich:
> > > > > > > I rolled back the change and Kamailio still sends the challenge.
> > > > > > > Seems
> > > > > > > I took the wrong transaction during debug...
> > > > > > > 
> > > > > > > Am Mo., 18. März 2019 um 19:16 Uhr schrieb Kevin Olbrich
> > 
> > <ko at sv01.de>:
> > > > > > > > Hi!
> > > > > > > > 
> > > > > > > > I am implementing forwarding of SUBSCRIBE (BLF) to an Asterisk
> > > > > > > > behind
> > > > > > > > Kamailio. This works but Kamailio is not requesting for Auth.
> > > > > > > > 
> > > > > > > > I then added SUBSCRIBE to:
> > > > > > > > https://github.com/kamailio/kamailio/blob/master/etc/kamailio.
> > > > > > > > cfg#
> > > > > > > > L746
> > > > > > > > 
> > > > > > > > And it now challenges the client correctly.
> > > > > > > > 
> > > > > > > > Why does this line only show REGISTER?
> > > > > > > > Shouldn't it request a challenge for all messages?
> > > > > > > > And why does it work with INVITES ootb?
> > > > > > 
> > > > > > Hi Kevin,
> > > > > > 
> > > > > > have a look to e.g. this page:
> > > > > > 
> > > > > > https://andrewjprokop.wordpress.com/2015/01/27/understanding-sip-a
> > > > > > uthe
> > > > > > ntic
> > > > > > ation/
> > > > > > 
> > > > > > "That means that messages like INVITE and BYE will receive 407
> > > > > > responses
> > > > > > and REGISTER and SUBSCRIBE will receive 401 responses."
> > > > > > 
> > > > > > For this reasons they are two *challenge functions in the auth
> > > > > > module
> > > > > > available.

-- 
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://skalatan.de/services




More information about the sr-users mailing list