[SR-Users] Authentication Feature Question

Ali Jawad ali.jawad at splendor.net
Tue Jan 3 22:08:43 CET 2012 

Hi
In Xlite/eyebeam I put in the username and one of my 3 kamailio
servers respectively as the sip registrar, I.e. register1.domain.com,
register2.domain.com and register3.domain.com, that is why I was
saying that hashing will create different hashes based on the register
domain.  With reference to my first related post, one kamailio server
is for softphones, one for sip devices and one for mobile phones with
SIP software. Each server has a slightly different NAT and Call
routing structure.
This is why I wanted to eliminate the domain factor from the hashing
procedure, I am sure it chooses the right value from the DB  value
because it is the same value shown in the log of kamailio against
which a comparison is being done and because it works if I put
register.domain.com in the domain column rehash the HA! value of the
db.

>>>>> values at 0xb7b78dac
>>>>>>  5(18649) DEBUG:<core>      [db_val.c:117]: converting STRING
>>>>>> [6f966cd9c628f14cdc20172f96a4d065]  <====##### This is the value in the DB based on domain.com
>>>>>>  5(18649) DEBUG: auth [api.c:210]: check_response: Our result =
>>>>>> '6f95e6235edca0b7765042ef119fd83b' <====##### This value appears to be the value generated register.domain.com
>>>>>>  5(18649) DEBUG: auth [api.c:220]: check_response: Authorization

How can I enable the SQL query log ?

On Tue, Jan 3, 2012 at 8:12 PM, Daniel-Constantin Mierla
<miconda at gmail.com> wrote:
> Hello,
>
> why are you using register.domain.com as domain for registration? Isn't
> domain.com the right one?
>
> Can you enable the sql query log for mysql server and double check if the
> right value (column) is selected from the database table?
>
> Cheers,
> Daniel
>
>
> On 1/3/12 5:13 PM, Ali Jawad wrote:
>>
>> Hi
>> Please see the below, thanks !
>>
>> interface: eth1 (xx.xx.xx.0/255.255.255.0)
>> match: support1
>>
>> U +6.698682 yy.yy.yy.146:18832 ->  xx.xx.xx.51:5060
>> REGISTER sip:register.domain.com SIP/2.0.
>> Via: SIP/2.0/UDP
>>
>> 192.168.0.191:18832;branch=z9hG4bK-d8754z-05164a466600837d-1---d8754z-;rport.
>> Max-Forwards: 70.
>>
>> Contact:<sip:support1 at 192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp>.
>> To: "Test Ast"<sip:support1 at register.domain.com>.
>> From: "Test Ast"<sip:support1 at register.domain.com>;tag=f710b930.
>> Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY..
>> 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.
>> .
>>
>>
>> U +0.005245 xx.xx.xx.51:5060 ->  yy.yy.yy.146:18832
>> SIP/2.0 401 Unauthorized.
>> Via: SIP/2.0/UDP
>>
>> 192.168.0.191:18832;branch=z9hG4bK-d8754z-05164a466600837d-1---d8754z-;rport=18832;received=yy.yy.yy.146.
>> To: "Test
>> Ast"<sip:support1 at register.domain.com>;tag=e597ca73bdb255490f0cefa03b2fda82.3053.
>> From: "Test Ast"<sip:support1 at register.domain.com>;tag=f710b930.
>> Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY..
>> CSeq: 1 REGISTER.
>> WWW-Authenticate: Digest realm="domain.com",
>> nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl".
>> Server: kamailio (3.2.1 (i386/linux)).
>> Content-Length: 0.
>> .
>>
>>
>> U +0.428042 yy.yy.yy.146:18832 ->  xx.xx.xx.51:5060
>> REGISTER sip:register.domain.com SIP/2.0.
>> Via: SIP/2.0/UDP
>>
>> 192.168.0.191:18832;branch=z9hG4bK-d8754z-fc633b21627dca6d-1---d8754z-;rport.
>> Max-Forwards: 70.
>>
>> Contact:<sip:support1 at 192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp>.
>> To: "Test Ast"<sip:support1 at register.domain.com>.
>> From: "Test Ast"<sip:support1 at register.domain.com>;tag=f710b930.
>> Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY..
>> CSeq: 2 REGISTER.
>> Expires: 3600.
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
>> SUBSCRIBE, INFO.
>> User-Agent: eyeBeam release 1102q stamp 51814.
>> Authorization: Digest
>>
>> username="support1",realm="domain.com",nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl",uri="sip:register.domain.com",response="6122245b77e2df0b90179304464341e7",algorithm=MD5.
>> Content-Length: 0.
>> .
>>
>>
>> U +0.005146 xx.xx.xx.51:5060 ->  yy.yy.yy.146:18832
>> SIP/2.0 401 Unauthorized.
>> Via: SIP/2.0/UDP
>>
>> 192.168.0.191:18832;branch=z9hG4bK-d8754z-fc633b21627dca6d-1---d8754z-;rport=18832;received=yy.yy.yy.146.
>> To: "Test
>> Ast"<sip:support1 at register.domain.com>;tag=e597ca73bdb255490f0cefa03b2fda82.fce3.
>> From: "Test Ast"<sip:support1 at register.domain.com>;tag=f710b930.
>> Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY..
>> CSeq: 2 REGISTER.
>> WWW-Authenticate: Digest realm="domain.com",
>> nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl".
>> Server: kamailio (3.2.1 (i386/linux)).
>> Content-Length: 0.
>> .
>>
>> [root at kam-rtp-100-51 mysql]# mail alijawad1 at gmail.com<  output.txt
>> [root at kam-rtp-100-51 mysql]#  ngrep -W byline -T support1  -q -d eth1
>> interface: eth1 (xx.xx.xx.0/255.255.255.0)
>> match: support1
>>
>>
>>
>>
>> U +5.321505 yy.yy.yy.146:63610 ->  xx.xx.xx.51:5060
>> REGISTER sip:register.domain.com SIP/2.0.
>> Via: SIP/2.0/UDP
>>
>> 192.168.0.191:63610;branch=z9hG4bK-d8754z-fb28723daa3f772d-1---d8754z-;rport.
>> Max-Forwards: 70.
>>
>> Contact:<sip:support1 at 192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp>.
>> To: "Test Ast"<sip:support1 at register.domain.com>.
>> From: "Test Ast"<sip:support1 at register.domain.com>;tag=ba705453.
>> Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI..
>> 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.
>> .
>>
>>
>> U +0.004782 xx.xx.xx.51:5060 ->  yy.yy.yy.146:63610
>> SIP/2.0 401 Unauthorized.
>> Via: SIP/2.0/UDP
>>
>> 192.168.0.191:63610;branch=z9hG4bK-d8754z-fb28723daa3f772d-1---d8754z-;rport=63610;received=yy.yy.yy.146.
>> To: "Test
>> Ast"<sip:support1 at register.domain.com>;tag=e597ca73bdb255490f0cefa03b2fda82.6b98.
>> From: "Test Ast"<sip:support1 at register.domain.com>;tag=ba705453.
>> Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI..
>> CSeq: 1 REGISTER.
>> WWW-Authenticate: Digest realm="domain.com",
>> nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk".
>> Server: kamailio (3.2.1 (i386/linux)).
>> Content-Length: 0.
>> .
>>
>>
>> U +0.400706 yy.yy.yy.146:63610 ->  xx.xx.xx.51:5060
>> REGISTER sip:register.domain.com SIP/2.0.
>> Via: SIP/2.0/UDP
>>
>> 192.168.0.191:63610;branch=z9hG4bK-d8754z-81517d296225234f-1---d8754z-;rport.
>> Max-Forwards: 70.
>>
>> Contact:<sip:support1 at 192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp>.
>> To: "Test Ast"<sip:support1 at register.domain.com>.
>> From: "Test Ast"<sip:support1 at register.domain.com>;tag=ba705453.
>> Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI..
>> CSeq: 2 REGISTER.
>> Expires: 3600.
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
>> SUBSCRIBE, INFO.
>> User-Agent: eyeBeam release 1102q stamp 51814.
>> Authorization: Digest
>>
>> username="support1",realm="domain.com",nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk",uri="sip:register.domain.com",response="4bfd80b0b836c20b748ee19a1c886284",algorithm=MD5.
>> Content-Length: 0.
>> .
>>
>>
>> U +0.005302 xx.xx.xx.51:5060 ->  yy.yy.yy.146:63610
>> SIP/2.0 401 Unauthorized.
>> Via: SIP/2.0/UDP
>>
>> 192.168.0.191:63610;branch=z9hG4bK-d8754z-81517d296225234f-1---d8754z-;rport=63610;received=yy.yy.yy.146.
>> To: "Test
>> Ast"<sip:support1 at register.domain.com>;tag=e597ca73bdb255490f0cefa03b2fda82.2f76.
>> From: "Test Ast"<sip:support1 at register.domain.com>;tag=ba705453.
>> Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI..
>> CSeq: 2 REGISTER.
>> WWW-Authenticate: Digest realm="domain.com",
>> nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk".
>> Server: kamailio (3.2.1 (i386/linux)).
>> Content-Length: 0.
>> .
>>
>> On Tue, Jan 3, 2012 at 6:08 PM, Daniel-Constantin Mierla
>> <miconda at gmail.com>  wrote:
>>>
>>> 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
>>>
>>
>>
>
> --
> Daniel-Constantin Mierla -- http://www.asipto.com
> http://linkedin.com/in/miconda -- http://twitter.com/miconda
>



-- 
Ali Jawad
Information Systems Manager
Splendor Telecom (www.splendor.net)
Beirut, Lebanon
Phone: +9611373725/ext 116
FAX: +9611375554

More information about the sr-users mailing list