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.
- Is it all considered valid for Kamailio 4 and Asterisk 11? (maybe a disclaimer could be added at the top)
- 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?
I use Kamailio for register and Asterisk servers for processing call. Asterisk accept all calls from Kamailio and dont know nothing about users and their passwords. I think this is simplest way for integration and using best from both applications.
On Thu, Jun 6, 2013 at 12:05 PM, Daniel Pocock daniel@pocock.com.au 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.
- Is it all considered valid for Kamailio 4 and Asterisk 11? (maybe a
disclaimer could be added at the top)
- 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?
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 6/6/13 2:11 PM, Stoyan Mihaylov wrote:
I use Kamailio for register and Asterisk servers for processing call. Asterisk accept all calls from Kamailio and dont know nothing about users and their passwords. I think this is simplest way for integration and using best from both applications.
The way you mention is the approach I use in most of the cases. The respective tutorial tries to give hints on how to plug Kamailio in front of an existing Asterisk deployment without disturbing it that much.
Cheers, Daniel
On Thu, Jun 6, 2013 at 12:05 PM, Daniel Pocock <daniel@pocock.com.au mailto:daniel@pocock.com.au> 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. - Is it all considered valid for Kamailio 4 and Asterisk 11? (maybe a disclaimer could be added at the top) - 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? _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 6/6/13 2:11 PM, Stoyan Mihaylov wrote:
I use Kamailio for register and Asterisk servers for processing call. Asterisk accept all calls from Kamailio and dont know nothing about users and their passwords. I think this is simplest way for integration and using best from both applications.
The way you mention is the approach I use in most of the cases. The respective tutorial tries to give hints on how to plug Kamailio in front of an existing Asterisk deployment without disturbing it that much.
Cheers, Daniel
I understand, when we started - we used your tutorial :) , but later I
decided to avoid "double" job.
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.
- 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.
- 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.
Cheers, Daniel
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?
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.
- 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
- 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
- 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
Asterisk has severe issues - and have had for a long time, with selecting the sender's IP address if you have multiple IPs on the host.
- 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.
THe current SIP stacks implementation of TLS stinks and was written and committed by people with very little knowledge of SIP and TLS. As I had no power to block the commit, I marked it experimental in release 1.6.0 and no one has stepped forward with resources to fix it.
Both of these issues are quite embarrassing and a reason to use a proxy like Kamailio in front of Asterisk.
Hopefully it will get better with the new Asterisk SIP stack - but do remember that it will take quite some time from release until that stack is ready for large-scale production.
/O
----- Edvina SIP Masterclass in Malaga, Spain, July 2013 Learn more about Kamailio and SIP! http://edvina.net/blog/2013/01/sipmaster-malaga-2013/ Register now!
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@domain.
ha1 = MD5(username:realm:password) ha1b = MD5(username@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
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@domain.
ha1 = MD5(username:realm:password) ha1b = MD5(username@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@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@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)
On 6/11/13 10:10 AM, Daniel Pocock wrote:
On 10/06/13 09:32, Daniel-Constantin Mierla wrote:
[...]
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@domain.
ha1 = MD5(username:realm:password) ha1b = MD5(username@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@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@domain convention is used for a particular domain?
not sure it would be domain specific, but rather subscriber specific and even device -- eg., same user using a snom phone as well as lumicall.
You can update kamailio config file to use pv_auth_check(...) function where you give the password as parameter -- it is up to you from where you load it (e.g., using sqlops). Then based on format of the auth username, you load the appropriate value. But again, I'm afraid you would need both values stored anyhow, because same user can have many devices with different behaviour.
- in other cases, do people expect this for administrative reasons or
solely to support devices that are internally hard-wired to this behavior?
I guess it the past we met devices that had it hard-wired.
Cheers, Daniel
On 06.06.2013 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.
Just a comment: it does not give you any additional security to store the passwords in hashed form - as also the hashed password can be used to calculate a proper authentication response.
The only benefit to use the hashed form is if the same password is used in other systems too - then leaking the subscriber table does not compromise the other systems (for approximately 4 hours with todays MD5 hacking performance), but only the SIP system.
regards Klaus
On 10/06/13 13:05, Klaus Darilion wrote:
On 06.06.2013 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.
Just a comment: it does not give you any additional security to store the passwords in hashed form - as also the hashed password can be used to calculate a proper authentication response.
The only benefit to use the hashed form is if the same password is used in other systems too - then leaking the subscriber table does not compromise the other systems (for approximately 4 hours with todays MD5 hacking performance), but only the SIP system.
Agreed - that is one reason why I encourage use of TLS client certs:
http://www.resiprocate.org/ReproMutualTLSAuthenticationJitsi
I've had that working with both Jitsi and Polycom devices (they have built-in certs) - it would be interesting to see a sample config and the same howto for Kamailio, from what I can tell the TLS module does support the same functionality.
One day I'll get around to adding client cert support into Lumicall
-
Daniel Pocock -
Daniel-Constantin Mierla -
Klaus Darilion -
Olle E. Johansson -
Stoyan Mihaylov