[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