6 Jun
2013
6 Jun
'13
12:05 p.m.
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?
6 Jun
6 Jun
3:11 p.m.
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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
5:39 p.m.
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(a)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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
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 *
5:56 p.m.
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.
5:35 p.m.
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
--
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 *
7 Jun
7 Jun
12:33 p.m.
On 06/06/13 16:35, Daniel-Constantin Mierla wrote:
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
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
Hello,
On 6/6/13 11:05 AM, Daniel Pocock wrote:
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.
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. 
12:42 p.m.
- 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!
10 Jun
10 Jun
10:32 a.m.
Hello,
On 6/7/13 11:33 AM, Daniel Pocock wrote:
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.
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 *
On 06/06/13 16:35, Daniel-Constantin Mierla wrote:
Yes, same realm along same username and password results in same hash.
Hello,
On 6/6/13 11:05 AM, Daniel Pocock wrote:
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 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. 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.
- 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.
11 Jun
11 Jun
11:10 a.m.
On 10/06/13 09:32, Daniel-Constantin Mierla wrote:
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)
Hello,
On 6/7/13 11:33 AM, Daniel Pocock wrote:
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(a)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?
On 06/06/13 16:35, Daniel-Constantin Mierla
wrote:
Yes, same realm along same username and password results in same hash.
Hello,
On 6/6/13 11:05 AM, Daniel Pocock wrote:
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 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. 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. - 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.
11:22 a.m.
On 6/11/13 10:10 AM, Daniel Pocock wrote:
On 10/06/13 09:32, Daniel-Constantin Mierla wrote:
:-)
[...]
Oddly enough, I almost forgot to mention Lumicall is using the ha1b column. 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.
In Lumicall, it is explicitly configured in the phone settings:
authentication username = +41xxxxx(a)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
--
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 *
10 Jun
10 Jun
2:05 p.m.
On 06.06.2013 16:35, Daniel-Constantin Mierla wrote:
Hello,
On 6/6/13 11:05 AM, Daniel Pocock wrote:
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
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.
11 Jun
11 Jun
11:12 a.m.
On 10/06/13 13:05, Klaus Darilion wrote:
On 06.06.2013 16:35, Daniel-Constantin Mierla wrote:
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
Hello,
On 6/6/13 11:05 AM, Daniel Pocock wrote:
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.
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.
4182
days inactive
4187
days old
11 comments
5 participants
participants (5)
-
Daniel Pocock -
Daniel-Constantin Mierla -
Klaus Darilion -
Olle E. Johansson -
Stoyan Mihaylov