[SR-Users] Authentication Feature Question
Daniel-Constantin Mierla
miconda at gmail.com
Tue Jan 3 17:08:04 CET 2012
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 at 192.168.0.191:20020;rinstance=4009190a4e109ac6;transport=udp>.
> To: "Test Ast"<sip:support1 at register.domain>.
> From: "Test Ast"<sip:support1 at 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
> <miconda at gmail.com> 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 at 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
>>> <miconda at gmail.com> 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
>>>>> <miconda at 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 at 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
>>>
>>>
>> --
>> 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
More information about the sr-users
mailing list