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

[Daniel Pocock]

On 10/06/13 09:32, Daniel-Constantin Mierla wrote:
> 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.


Oddly enough, I almost forgot to mention Lumicall is using the ha1b column.

In Lumicall, it is explicitly configured in the phone settings:
   authentication username = +41xxxxx at sip5060.net

and it sends that whole value to the SIP proxy in the auth header

To be clear, this was an administrative decision and not a
device-specific issue.

- instead of having a ha1b column (which is a hassle for sharing the
database with Asterisk or other systems that don't know ha1b), maybe it
is also useful to have an auth_user column or to have a flag in the
domains table to indicate that the user at domain convention is used for a
particular domain?

- in other cases, do people expect this for administrative reasons or
solely to support devices that are internally hard-wired to this behavior?

>
>> - 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.

I first hit this issue with Asterisk 1.8 I think - ever since then, I've
been doing the same workaround with transport=tcp (I found some UDP
packets would be too big)