3 Jan
2012
3 Jan
'12
4:48 p.m.
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 ?
I might be wrong....thanks for the help so far.
Regards
On Tue, Jan 3, 2012 at 5:15 PM, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
Hello,
On 1/3/12 4:12 PM, Ali Jawad wrote:
--
Ali Jawad
Information Systems Manager
Splendor Telecom (www.splendor.net)
Beirut, Lebanon
Phone: +9611373725/ext 116
FAX: +9611375554
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
> <miconda(a)gmail.com> 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<ali.jawad(a)splendor.net>
>>> 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