20 May
2008
20 May
'08
11:54 a.m.
Hello,
if the ldap server returns the HA1 password with some prefix, then you
need to strip it. Can you paste here a sample HA1 (send mail to me only
if you want to keep it private) as you get it from the ldap server?
Cheers,
Daniel
On 05/20/08 11:44, Ahmed Huraimel wrote:
Hello,
below is the log you request
======================================
May 20 10:23:05 [3652] DBG:ldap:ldap_connect: [inria]: LDAP bind
successful (ldap_host [ldap://ldapmaster.inrialpes.fr
<http://ldapmaster.inrialpes.fr>])
May 20 10:25:36 [3652] DBG:core:parse_msg: SIP Request:
May 20 10:25:36 [3652] DBG:core:parse_msg: method: <REGISTER>
May 20 10:25:36 [3652] DBG:core:parse_msg: uri: <sip:inrialpes.fr
<http://inrialpes.fr>>
May 20 10:25:36 [3652] DBG:core:parse_msg: version: <SIP/2.0>
May 20 10:25:36 [3652] DBG:core:parse_headers: flags=2
May 20 10:25:36 [3652] DBG:core:parse_via_param: found param type 232,
<branch> = <z9hG4bK-d87543-1154d43f445f6e1a-3--d87543->; state=6
May 20 10:25:36 [3652] DBG:core:parse_via_param: found param type 235,
<rport> = <n/a>; state=17
May 20 10:25:36 [3652] DBG:core:parse_via: end of header reached, state=5
May 20 10:25:36 [3652] DBG:core:parse_headers: via found, flags=2
May 20 10:25:36 [3652] DBG:core:parse_headers: this is the first via
May 20 10:25:36 [3652] DBG:core:receive_msg: After parse_msg...
May 20 10:25:36 [3652] DBG:core:receive_msg: preparing to run routing
scripts...
May 20 10:25:36 [3652] DBG:core:parse_headers: flags=100
May 20 10:25:36 [3652] DBG:maxfwd:is_maxfwd_present: value = 70
May 20 10:25:36 [3652] DBG:core:parse_headers: flags=8
May 20 10:25:36 [3652] DBG:core:parse_to: end of header reached, state=10
May 20 10:25:36 [3652] DBG:core:parse_to: display={"alali"},
ruri={sip:alali@inrialpes.fr <mailto:sip%3Aalali@inrialpes.fr>}
May 20 10:25:36 [3652] DBG:core:get_hdr_field: <To> [33];
uri=[sip:alali@inrialpes.fr <mailto:sip%3Aalali@inrialpes.fr>]
May 20 10:25:36 [3652] DBG:core:get_hdr_field: to body
["alali"<sip:alali@inrialpes.fr <mailto:sip%3Aalali@inrialpes.fr>>
]
May 20 10:25:36 [3652] DBG:uri:has_totag: no totag
May 20 10:25:36 [3652] DBG:core:parse_headers: flags=78
May 20 10:25:36 [3652] DBG:core:get_hdr_field: cseq <CSeq>: <1>
<REGISTER>
May 20 10:25:36 [3652] DBG:tm:t_lookup_request: start searching:
hash=34958, isACK=0
May 20 10:25:36 [3652] DBG:tm:matching_3261: RFC3261 transaction
matching failed
May 20 10:25:36 [3652] DBG:tm:t_lookup_request: no transaction found
May 20 10:25:36 [3652] DBG:core:grep_sock_info: checking if host==us:
12==14 && [inrialpes.fr <http://inrialpes.fr>] == [194.199.18.159
<http://194.199.18.159>]
May 20 10:25:36 [3652] DBG:core:grep_sock_info: checking if port 5060
matches port 5060
May 20 10:25:36 [3652] DBG:core:grep_sock_info: checking if host==us:
12==14 && [inrialpes.fr <http://inrialpes.fr>] == [194.199.18.159
<http://194.199.18.159>]
May 20 10:25:36 [3652] DBG:core:grep_sock_info: checking if port 5060
matches port 5060
May 20 10:25:36 [3652] DBG:core:parse_headers: flags=ffffffffffffffff
May 20 10:25:36 [3652] DBG:core:get_hdr_field: content_length=0
May 20 10:25:36 [3652] DBG:core:get_hdr_field: found end of header
May 20 10:25:36 [3652] DBG:auth:build_auth_hf: 'WWW-Authenticate:
Digest realm="inrialpes.fr <http://inrialpes.fr>",
nonce="48328c2cfe3d852ecb1ff2f1fc7e378022046d34"
'
May 20 10:25:36 [3652] DBG:core:parse_headers: flags=ffffffffffffffff
May 20 10:25:36 [3652] DBG:core:check_via_address: params
194.199.18.152 <http://194.199.18.152>, 194.199.18.152
<http://194.199.18.152>, 0
May 20 10:25:36 [3652] DBG:core:destroy_avp_list: destroying list (nil)
May 20 10:25:36 [3652] DBG:core:receive_msg: cleaning up
May 20 10:25:39 [3652] DBG:core:parse_msg: SIP Request:
May 20 10:25:39 [3652] DBG:core:parse_msg: method: <REGISTER>
May 20 10:25:39 [3652] DBG:core:parse_msg: uri: <sip:inrialpes.fr
<http://inrialpes.fr>>
May 20 10:25:39 [3652] DBG:core:parse_msg: version: <SIP/2.0>
May 20 10:25:39 [3652] DBG:core:parse_headers: flags=2
May 20 10:25:39 [3652] DBG:core:parse_via_param: found param type 232,
<branch> = <z9hG4bK-d87543-4b05271d9943dd31-3--d87543->; state=6
May 20 10:25:39 [3652] DBG:core:parse_via_param: found param type 235,
<rport> = <n/a>; state=17
May 20 10:25:39 [3652] DBG:core:parse_via: end of header reached, state=5
May 20 10:25:39 [3652] DBG:core:parse_headers: via found, flags=2
May 20 10:25:39 [3652] DBG:core:parse_headers: this is the first via
May 20 10:25:39 [3652] DBG:core:receive_msg: After parse_msg...
May 20 10:25:39 [3652] DBG:core:receive_msg: preparing to run routing
scripts...
May 20 10:25:39 [3652] DBG:core:parse_headers: flags=100
May 20 10:25:39 [3652] DBG:maxfwd:is_maxfwd_present: value = 70
May 20 10:25:39 [3652] DBG:core:parse_headers: flags=8
May 20 10:25:39 [3652] DBG:core:parse_to: end of header reached, state=10
May 20 10:25:39 [3652] DBG:core:parse_to: display={"alali"},
ruri={sip:alali@inrialpes.fr <mailto:sip%3Aalali@inrialpes.fr>}
May 20 10:25:39 [3652] DBG:core:get_hdr_field: <To> [33];
uri=[sip:alali@inrialpes.fr <mailto:sip%3Aalali@inrialpes.fr>]
May 20 10:25:39 [3652] DBG:core:get_hdr_field: to body
["alali"<sip:alali@inrialpes.fr <mailto:sip%3Aalali@inrialpes.fr>>
]
May 20 10:25:39 [3652] DBG:uri:has_totag: no totag
May 20 10:25:39 [3652] DBG:core:parse_headers: flags=78
May 20 10:25:39 [3652] DBG:core:get_hdr_field: cseq <CSeq>: <2>
<REGISTER>
May 20 10:25:39 [3652] DBG:tm:t_lookup_request: start searching:
hash=34955, isACK=0
May 20 10:25:39 [3652] DBG:tm:matching_3261: RFC3261 transaction
matching failed
May 20 10:25:39 [3652] DBG:tm:t_lookup_request: no transaction found
May 20 10:25:39 [3652] DBG:core:grep_sock_info: checking if host==us:
12==14 && [inrialpes.fr <http://inrialpes.fr>] == [194.199.18.159
<http://194.199.18.159>]
May 20 10:25:39 [3652] DBG:core:grep_sock_info: checking if port 5060
matches port 5060
May 20 10:25:39 [3652] DBG:core:grep_sock_info: checking if host==us:
12==14 && [inrialpes.fr <http://inrialpes.fr>] == [194.199.18.159
<http://194.199.18.159>]
May 20 10:25:39 [3652] DBG:core:grep_sock_info: checking if port 5060
matches port 5060
May 20 10:25:39 [3652] DBG:core:parse_headers: flags=ffffffffffffffff
May 20 10:25:39 [3652] DBG:core:get_hdr_field: content_length=0
May 20 10:25:39 [3652] DBG:core:get_hdr_field: found end of header
May 20 10:25:39 [3652] DBG:core:parse_to_param: tag=e66a6272
May 20 10:25:39 [3652] DBG:core:parse_to: end of header reached, state=29
May 20 10:25:39 [3652] DBG:core:parse_to: display={"alali"},
ruri={sip:alali@inrialpes.fr <mailto:sip%3Aalali@inrialpes.fr>}
May 20 10:25:39 [3652] DBG:ldap:ldap_url_search: LDAP URL parsed into
session_name [inria], base [ou=People,dc=inrialpes,dc=fr], scope [1],
filter [(uid=alali)]
May 20 10:25:39 [3652] DBG:ldap:lds_search: [inria]: performing LDAP
search: dn [ou=People,dc=inrialpes,dc=fr], scope [1], filter
[(uid=alali)], client_timeout [5000000] usecs
May 20 10:25:39 [3652] DBG:ldap:ldap_params_search: [inria]: [1] LDAP
entries found
May 20 10:25:39 [3652] DBG:auth:check_nonce: comparing
[48328c2cfe3d852ecb1ff2f1fc7e378022046d34] and
[48328c2cfe3d852ecb1ff2f1fc7e378022046d34]
May 20 10:25:39 [3652] DBG:auth:check_response: our result =
'f2703eead969f071b5cbf724876b555c'
May 20 10:25:39 [3652] DBG:auth:check_response: authorization failed
May 20 10:25:39 [3652] DBG:auth:build_auth_hf: 'WWW-Authenticate:
Digest realm="inrialpes.fr <http://inrialpes.fr>",
nonce="48328c2f395ff6d2cf662b281063ff20ac03b62f"
================================================
you can clearly see that the response generated by the server will not
match the one received from UAC. i sniffed the network packets to see
what is going on and i found that the LDAP server return the password
in this formate ( {MD5} blablabla ). do not you think that the server
took it all as password (including {MD5} string)?
regards,
Ahmed ALALI
On Mon, May 19, 2008 at 9:26 PM, Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
Hello,
I had a quick look at the code and the module should work with HA1
in the PV and calculate_ha1=0. Can you set the debug =5 and send
the log to me for such case (the 3 in your list). It will help to
troubleshoot quickly.
Cheers,
Daniel
On 05/19/08 15:05, Ahmed Huraimel wrote:
Hello,
i am successfully integrated an openLDAP server with my
openSER SIP proxy server. however i am facing a security
problem. let me explain it briefly.
**** Successful Registration with password save as clear in
openLDAP DB ****
* # Configration #
- user name was stored in clear in openSER database
- modparam("auth", "calculate_ha1", 1) which means the
server
will assume that the "password_spec" pseudo-variable contains
plaintext passwords and it will calculate HA1 strings on the fly.
# Senario #
- after the UAC receives Authentication request he will build
the response = MD5(username + MD5(passowrd) + realm + nonce)
- then the server will build the challenge by searching the
the user in the database and retrieving the password in clear
then hash the password with MD5 build the challenge such that
challenge=MD5(username + MD5(passowrd) + realm + nonce) . .
- by comparing the the response the with the challenge the
user will be authenticated.
- *it works *
**** Successful Registration with password save as MD5 in
openLDAP DB ****
* # Configration #
- user name was stored in MD5 in openSER database
- modparam("auth", "calculate_ha1", 0) which means the
server
assumes the pseudo-variable contains the HA1 strings directly
and will not calculate them.
# Senario #
- after the UAC receives Authentication request he will build
the response = MD5(username + MD5(password) + realm + nonce)
- then the server will build the challenge by searching the
the user in the database and retrieving the password in MD5
then challenge such that challenge=MD5(username +
MD5(password) + realm + nonce) .
- by comparing the the response the with the challenge the
user will be authenticated.
- *401 unauthorized !!!!
***** CONCLUSION ****
*there for possible scenarios:
1- password clear + calculate_ha1= 0 ==> 401 unauthorized !!!!
2- password clear + calculate_ha1= 1 ==> Authorized
3- password MD5 + calculate_ha1= 0 ==> 401 unauthorized !!!!
4- password MD5 + calculate_ha1= 1 ==> 401 unauthorized !!!!
*
*-----------------------------------------------------------------------------------------
*
asuumptions:
*1- the password might be not hashed. if so then why
modparam("auth", "calculate_ha1", ) used? does it mean that
the password might be received hashed or not?
_2- in scenario(2) the sip server hash the password by setting
calculate_ha1= 1. if the password is already hashed in the
database then scenario(3) should work unless there is a
conflict with the hash. is this might be related to hash type
or size?_ or something else that i do not know!!!
*question*:
1- why scenario(3) does not work? where might be the problem?
2- what to do if i want to change the hash algorithm used? for
example i need to SSH1 instead of MD5 because nowadays MD5 is
proved to be weak algorithm
regards,
Ahmed ALALI
------------------------------------------------------------------------
_______________________________________________
Users mailing list
Users(a)lists.openser.org <mailto:Users@lists.openser.org>
http://lists.openser.org/cgi-bin/mailman/listinfo/users
--
http://www.asipto.com
--
http://www.asipto.com