[OpenSER-Users] Authentication with LDAP databse

Daniel-Constantin Mierla miconda at gmail.com
Tue May 20 10:54:53 CEST 2008


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 at inrialpes.fr <mailto:sip%3Aalali at inrialpes.fr>}
> May 20 10:25:36 [3652] DBG:core:get_hdr_field: <To> [33]; 
> uri=[sip:alali at inrialpes.fr <mailto:sip%3Aalali at inrialpes.fr>]
> May 20 10:25:36 [3652] DBG:core:get_hdr_field: to body 
> ["alali"<sip:alali at inrialpes.fr <mailto:sip%3Aalali at 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 at inrialpes.fr <mailto:sip%3Aalali at inrialpes.fr>}
> May 20 10:25:39 [3652] DBG:core:get_hdr_field: <To> [33]; 
> uri=[sip:alali at inrialpes.fr <mailto:sip%3Aalali at inrialpes.fr>]
> May 20 10:25:39 [3652] DBG:core:get_hdr_field: to body 
> ["alali"<sip:alali at inrialpes.fr <mailto:sip%3Aalali at 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 at inrialpes.fr <mailto:sip%3Aalali at 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 at gmail.com <mailto:miconda at 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 at lists.openser.org <mailto:Users at lists.openser.org>
>         http://lists.openser.org/cgi-bin/mailman/listinfo/users
>          
>
>
>     -- 
>     http://www.asipto.com
>
>

-- 
http://www.asipto.com





More information about the sr-users mailing list