Re: [SR-Users] Authentication Feature Question

Daniel-Constantin Mierla Tue, 03 Jan 2012 13:27:04 -0800

Hello,

On 1/3/12 10:08 PM, Ali Jawad wrote:

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.

but your service domain is 'domain.com', specific server addresses(domains) per UA type should be set as outbound proxy on the UA devices.

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.

When auth_db module is configured to take the hashed value from database(calculate_ha1 parameter is 0), there is no more computation of it inkamailio -- it is just fetched from database and used -- so it does notmatter anymore the domains in the sip message.

Check to see if the xlite does not have a realm field that has to be setproperly.

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 ?


I don't know by hart, googling should help you.

Cheers,
Daniel


On Tue, Jan 3, 2012 at 8:12 PM, Daniel-Constantin Mierla
<mico...@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@192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp>.
To: "Test Ast"<sip:suppo...@register.domain.com>.
From: "Test Ast"<sip:suppo...@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:suppo...@register.domain.com>;tag=e597ca73bdb255490f0cefa03b2fda82.3053.
From: "Test Ast"<sip:suppo...@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:suppo...@register.domain.com>.
From: "Test Ast"<sip:suppo...@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:suppo...@register.domain.com>;tag=e597ca73bdb255490f0cefa03b2fda82.fce3.
From: "Test Ast"<sip:suppo...@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 alijaw...@gmail.com<    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:suppo...@register.domain.com>.
From: "Test Ast"<sip:suppo...@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:suppo...@register.domain.com>;tag=e597ca73bdb255490f0cefa03b2fda82.6b98.
From: "Test Ast"<sip:suppo...@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:suppo...@register.domain.com>.
From: "Test Ast"<sip:suppo...@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:suppo...@register.domain.com>;tag=e597ca73bdb255490f0cefa03b2fda82.2f76.
From: "Test Ast"<sip:suppo...@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
<mico...@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@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
<mico...@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@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
<mico...@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
<mico...@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.ja...@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


--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda


_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Authentication Feature Question

Reply via email to