[OpenSER-Users] Authentication with LDAP databse

Ahmed Huraimel huraimel at gmail.com
Tue May 20 10:44:14 CEST 2008


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])
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>
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 <sip%3Aalali at inrialpes.fr>}
May 20 10:25:36 [3652] DBG:core:get_hdr_field: <To> [33]; uri=[
sip:alali at inrialpes.fr <sip%3Aalali at inrialpes.fr>]
May 20 10:25:36 [3652] DBG:core:get_hdr_field: to body ["alali"<
sip:alali at inrialpes.fr <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] == [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] == [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", 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,
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>
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 <sip%3Aalali at inrialpes.fr>}
May 20 10:25:39 [3652] DBG:core:get_hdr_field: <To> [33]; uri=[
sip:alali at inrialpes.fr <sip%3Aalali at inrialpes.fr>]
May 20 10:25:39 [3652] DBG:core:get_hdr_field: to body ["alali"<
sip:alali at inrialpes.fr <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] == [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] == [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 <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", 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>
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
>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>
>>
>
> --
> http://www.asipto.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kamailio.org/pipermail/users/attachments/20080520/8083366e/attachment.htm 


More information about the Users mailing list