[SR-Users] Kamailio/Asterisk combination + hashed passwords?

[Daniel-Constantin Mierla]

Hello,

On 6/7/13 11:33 AM, Daniel Pocock wrote:
> On 06/06/13 16:35, Daniel-Constantin Mierla wrote:
>> Hello,
>>
>> On 6/6/13 11:05 AM, Daniel Pocock wrote:
>>> I was just looking over:
>>>
>>> http://kb.asipto.com/asterisk:realtime:kamailio-3.3.x-asterisk-10.7.0-astdb
>>>
>>>
>>> A couple of things I noticed:
>>>
>>> - Kamailio is using a column sippasswd which is not hashed.  Asterisk
>>> doesn't use that column at all.  Is there any reason this can't be done
>>> with the H(A1) and H(A1b) columns?  The INSERT example shows a
>>> non-encrypted password.
>> you can store hashed value there. In Kamailio is just a matter of
>> config parameter/function parameter to say the loaded value is either
>> plain text or ha1.
> Great - are there any interoperability issues with the realm name when
> using hashes?  I presume that as long as the same challenge realm name
> is configured in Asterisk and Kamailio and when making the hashes it is
> all OK?
Yes, same realm along same username and password results in same hash.

> I also posted a query on the asterisk-users list about support for ha1b
> - would you know if that is something that still comes up in practice?
> It is in the Kamailio schema, but I have not encountered a device
> behaving that way in practice.

There are few devices, not remembering any at this moment that use user 
value in authentication header as being username at domain.

ha1 = MD5(username:realm:password)
ha1b = MD5(username at domain:realm:password)

I hope I remembered correctly the order, by you get the idea.

>>> - Is it all considered valid for Kamailio 4 and Asterisk 11?  (maybe a
>>> disclaimer could be added at the top)
>> There is another one for K4.0 and A11:
>>
>> -
>> http://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb
>>
>> Not many changes and apparently there are newer updates in asterisk
>> database structure on latest RC of 11.3.x.
>>
> Great - Google searches for "Asterisk Kamailio" or even "Asterisk 11
> Kamailio 4" still return the old page, so maybe it is still useful to
> link the pages

I will add that next time I get a chance.

>>> - The Asterisk columns `md5secret' and `secret' are left empty so that
>>> Asterisk won't challenge.  I believe there are other ways of doing this:
>>> for example, telling Kamailio to be the registrar and forcing Asterisk
>>> to use outbound proxy mode.  I managed to make this work against repro -
>>> Asterisk no longer receives any REGISTER messages, but all INVITEs go
>>> through Asterisk, so the double-challenge problem only arises for
>>> INVITEs.  Maybe Asterisk can be told that Kamailio's source IP:port is
>>> `trusted' and doesn't need to be challenged - is anybody aware of such
>>> an option in Asterisk?
>> There are various ways of doing it, this particular one tried to be at
>> least intrusive as possible in asterisk, not to require changing a
>> deployed asterisk configuration.
>>
>> For a new deployment, other approach is more recommended, using
>> kamailio as outbound proxy.
>
> As you can imagine, I've played with a few variations of this against repro
>
> I've noticed that it isn't so straightforward, here are some issues
> (Asterisk faults, not proxy issues):
>
> - Asterisk doesn't automatically use it's bind IP:port for outgoing
> connections to the proxy - so proxy ACLs are tricky to set up if the
> Asterisk host has multiple IPs
>
> - if Asterisk tries to connect to a TLS proxy, and the proxy has
> optional client cert verification enabled, Asterisk tries to send it's
> cert.  There seems to be no way to disable Asterisk sending a cert in
> this scenario, but the proxy doesn't like the way the client cert is
> submitted and so it seems impossible to connect to such a proxy.
>
> This was observed with Asterisk 11.4
I haven't played with Asterisk over tls, I used kamailio to bridge tls 
to udp and then send to asterisk.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013
   * http://asipto.com/u/katu *