Re: [SR-Users] Authentication Feature Question

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@192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp>. To: "Test Ast"<sip:support1@register.domain.com>. From: "Test Ast"<sip:support1@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@register.domain.com>;tag=e597ca73bdb255490f0cefa03b2fda82.3053. From: "Test Ast"<sip:support1@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@192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp>. To: "Test Ast"<sip:support1@register.domain.com>. From: "Test Ast"<sip:support1@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@register.domain.com>;tag=e597ca73bdb255490f0cefa03b2fda82.fce3. From: "Test Ast"<sip:support1@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@kam-rtp-100-51 mysql]# mail alijawad1(a)gmail.com&lt;    output.txt [root@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@192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp>. To: "Test Ast"<sip:support1@register.domain.com>. From: "Test Ast"<sip:support1@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@register.domain.com>;tag=e597ca73bdb255490f0cefa03b2fda82.6b98. From: "Test Ast"<sip:support1@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@192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp>. To: "Test Ast"<sip:support1@register.domain.com>. From: "Test Ast"<sip:support1@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@register.domain.com>;tag=e597ca73bdb255490f0cefa03b2fda82.2f76. From: "Test Ast"<sip:support1@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 &lt;miconda(a)gmail.com&gt;    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@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 >