Re: [SR-Users] Authentication Feature Question

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