Re: [SR-Users] Authentication Feature Question

Hello, I need the entire flow for registration, including the 401 reply and the following REGISTER request. Cheers, Daniel On 1/3/12 5:02 PM, Ali Jawad wrote: > Hi > Please see the ngrep below, please note that if I use in the db > register.domain.com and generate a hash against it for HA1 it > works,but then the user cant logon to register2.domain.com > > > U +10.630576 xx.yy.yy.yy:20020 -> xx.xx.xx.xx:5060 > REGISTER sip:register.domain SIP/2.0. > Via: SIP/2.0/UDP > > > 192.168.0.191:20020;branch=z9hG4bK-d8754z-af65a442980c375f-1---d8754z-;rport. > Max-Forwards: 70. > > > Contact:<sip:support1@192.168.0.191:20020;rinstance=4009190a4e109ac6;transport=udp>. > To: "Test Ast"<sip:support1@register.domain>. > From: "Test Ast"<sip:support1@register.domain>;tag=976bb004. > Call-ID: MDFmZDU2ZTI2YjJjMGNlMGFmOTIzMWFmZGQ1ZTNjMDE.. > CSeq: 1 REGISTER. > Expires: 3600. > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, > SUBSCRIBE, INFO. > User-Agent: eyeBeam release 1102q stamp 51814. > Content-Length: 0. > > On Tue, Jan 3, 2012 at 5:58 PM, Daniel-Constantin Mierla > &lt;miconda(a)gmail.com&gt; wrote: >> Hello, >> >> >> On 1/3/12 4:48 PM, Ali Jawad wrote: >>> Hi Daniel >>> >>> Please see >>> >>> 5(18649) DEBUG:<core> [db_res.c:184]: allocate 8 bytes for rows >>> at >>> 0xb7b78d74 >>> 5(18649) DEBUG:<core> [db_row.c:119]: allocate 20 bytes for row >>> values at 0xb7b78dac >>> 5(18649) DEBUG:<core> [db_val.c:117]: converting STRING >>> [6f966cd9c628f14cdc20172f96a4d065] >>> 5(18649) DEBUG: auth [api.c:210]: check_response: Our result = >>> '6f95e6235edca0b7765042ef119fd83b' >>> 5(18649) DEBUG: auth [api.c:220]: check_response: Authorization >>> failed >>> 5(18649) DEBUG:<core> [db_res.c:81]: freeing 1 columns >>> 5(18649) DEBUG:<core> [db_res.c:85]: freeing RES_NAMES[0] at >>> 0xb7b78d3c >>> 5(18649) DEBUG:<core> [db_res.c:94]: freeing result names at >>> 0xb7b78bfc >>> 5(18649) DEBUG:<core> [db_res.c:99]: freeing result types at >>> 0xb7b78c64 >>> 5(18649) DEBUG:<core> [db_res.c:54]: freeing 1 rows >>> 5(18649) DEBUG:<core> [db_row.c:97]: freeing row values at >>> 0xb7b78dac >>> 5(18649) DEBUG:<core> [db_res.c:62]: freeing rows at 0xb7b78d74 >>> 5(18649) DEBUG:<core> [db_res.c:136]: freeing result set at >>> 0xb7b78bb0 >>> 5(18649) DEBUG: auth [challenge.c:102]: build_challenge_hf: >>> realm='nymgo.com' >>> 5(18649) DEBUG: auth [challenge.c:244]: auth: 'WWW-Authenticate: >>> Digest realm="domain.com", nonce="TwMcuk8DG47SLxatlNdZfyfR8p3OiyAE" >>> ' >>> >>> I rebuilt the hashes against domain.com and then tried to connect to >>> sip1.domain.com and sip2.domain.com and sip3.domain.com with all of >>> the having >>> >>> >>> # ----- auth_db params ----- >>> #!ifdef WITH_AUTH >>> modparam("auth_db", "db_url", DBURL) >>> modparam("auth_db", "calculate_ha1", 0 ) >>> modparam("auth_db", "password_column", "ha1") >>> modparam("auth_db", "load_credentials", "") >>> modparam("auth_db", "use_domain", MULTIDOMAIN) >>> >>> And in the routing process : >>> >>> if (!www_authorize("domain.com", "subscriber")) >>> { >>> >>> www_challenge("domain.com", "0"); >>> exit; >>> } >>> >>> >>> +++++++++++++ >>> >>> My point is that the hashes are caculated from user:doman:pwd which >>> are extracted from the SIP packet and in this case the domains are >>> sip1,sip2,sip3 while the hashes stored in the database are generated >>> against domain.com >>> >>> If " ha1 is actually hash over 'user:realm:pwd' " shouldn't I have to >>> set the domain/realm in the config file ? >> >> the first parameter in www_authorize and www_challenge functions is the >> realm and it is used to build the digest response. >> >> Is your phone putting user@domain in authorization header? Can you >> paste >> here the ngrep of registration? >> >> Cheers, >> Daniel >> >> >>> I might be wrong....thanks for the help so far. >>> >>> Regards >>> >>> On Tue, Jan 3, 2012 at 5:15 PM, Daniel-Constantin Mierla >>> &lt;miconda(a)gmail.com&gt; wrote: >>>> Hello, >>>> >>>> >>>> On 1/3/12 4:12 PM, Ali Jawad wrote: >>>>> Hi Daniel >>>>> This certainly makes sense, I will try it in a few mins, but what I >>>>> observed at Debug Level 3 is that Hash is calculated before >>>>> www_authenticate is executed and it shows HA comparison failed, if I >>>>> do use domain.com instead of $fd and use $domain.com in db domain >>>>> field and build HA1 filed based on that, wont Kamailio still try to >>>>> build the HA1 hash which it will compare form user:domain:pwd where >>>>> domain is fed in to the hash function from the header of the SIP >>>>> packet ? >>>> >>>> the ha1 is actually hash over 'user:realm:pwd' -- it is just common >>>> practice >>>> to use the domain as realm, since realm should be a unique token to >>>> identify >>>> the service, but it can be any random string. realm is given as >>>> parameter >>>> to auth functions in kamailio.cfg >>>> >>>> Cheers, >>>> Daniel >>>> >>>> >>>>> Regards >>>>> >>>>> On Tue, Jan 3, 2012 at 5:07 PM, Daniel-Constantin Mierla >>>>> &lt;miconda(a)gmail.com&gt; wrote: >>>>>> Hello, >>>>>> >>>>>> you can simply use 'domain.com' as realm parameter to >>>>>> authentication >>>>>> function instead of $fd. Also build ha1 and ha1b with domain.com >>>>>> and >>>>>> then >>>>>> you are safe no matter which sip server is used. >>>>>> >>>>>> Of course you can build the realm by striping first token before >>>>>> '.' >>>>>> in >>>>>> $fd >>>>>> and pass it to authentication functions, but not sure if makes >>>>>> sense >>>>>> since >>>>>> it should be always domain.com >>>>>> >>>>>> Cheers, >>>>>> Daniel >>>>>> >>>>>> >>>>>> On 1/3/12 3:15 PM, Ali Jawad wrote: >>>>>>> Hi >>>>>>> After some research it seems to me that the only way to achieve >>>>>>> this >>>>>>> is to "try" and change how hashing is done in the source code, a >>>>>>> little bit too ambitious for me, and it means I will have loads of >>>>>>> problems each time an upgrade is released. >>>>>>> >>>>>>> Or >>>>>>> >>>>>>> Use pseudovariables to fix the value of the $fd value to something >>>>>>> constant, while this worked for values like $var(y) I was not able >>>>>>> to >>>>>>> assign/strip $fd to remove the subdomain part. >>>>>>> >>>>>>> Any input please ? >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> On Tue, Jan 3, 2012 at 2:06 PM, Ali Jawad&lt;ali.jawad(a)splendor.net&gt; >>>>>>> wrote: >>>>>>>> Hi >>>>>>>> I do have 3 Kamailio servers, one for mobile phone registrations, >>>>>>>> one >>>>>>>> for softphone registrations and one for SIP device registrations. >>>>>>>> Each >>>>>>>> of those devices connects to it's perspective kamailio server >>>>>>>> >>>>>>>> sip1.domain.com >>>>>>>> sip2.domain.com >>>>>>>> sip3.domain.com >>>>>>>> >>>>>>>> All 3 Kamailio servers share the same database, and users can use >>>>>>>> their kamailio user/pwd on any of the devices, now I want to use >>>>>>>> encrypted passwords and remove clear text passwords from the >>>>>>>> database. >>>>>>>> I did test with one server and all is fine,however if a user want >>>>>>>> to >>>>>>>> register from the second kamailio server it does not work, >>>>>>>> basically >>>>>>>> because the db domain entry from which the hash is created is >>>>>>>> sip1.domain.com and stored in the db, while the user connects >>>>>>>> from >>>>>>>> to >>>>>>>> sip2.domain.com this eventually generates a different hash. >>>>>>>> >>>>>>>> Is there anyway to overcome this ? Can I exclude Domain from Hash >>>>>>>> generation ? Any other option that allows me to do the above ? >>>>>>>> >>>>>>>> Thanks >>>>>>> >>>>>>> >>>>>> -- >>>>>> Daniel-Constantin Mierla -- http://www.asipto.com >>>>>> http://linkedin.com/in/miconda -- http://twitter.com/miconda >>>>>> >>>>> -- >>>>> Daniel-Constantin Mierla -- http://www.asipto.com >>>>> http://linkedin.com/in/miconda -- http://twitter.com/miconda >>> >>> >> -- >> Daniel-Constantin Mierla -- http://www.asipto.com >> http://linkedin.com/in/miconda -- http://twitter.com/miconda >> -- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda