Hi,
There are lots of parameters controlling the creation of nonce values on a server, and I'm curious if there is a way to kind of "sync" them between servers.
The use case would be to have a UA send for example its registration to Proxy1. Proxy1 would challenge it, UA will send the registration again, this time with credentials. Proxy1 would look up the user based on $au/$ar in the subscriber table, and if it's not found, will look up the responsible proxy from another table (with key being $au@$ar), forward it to Proxy2, which then would be able authenticate the user.
The reason for this is that the auth credentials are unique across all servers and reliably identify a user, whereas for example From could be something else (e.g. in case of an IP-PBX sending a CLI in the From-userpart).
Challenging the user on the second proxy again would theoretically be possible, but if the UA gets a 401 twice (once from Proxy1, once from Proxy2), it'll most likely pop up a password form for soft-clients, so I want to avoid that.
Any ideas how to accomplish that?
Andreas
Is the database shared? If so maybe when they authenticate add a secure token to the header that the second proxy can use for auth?
Just a suggestion not sure if its the answer your looking for or perhaps I didn't understand the scenario well enough. On Nov 19, 2012 7:53 AM, "Andreas Granig" agranig@sipwise.com wrote:
Hi,
There are lots of parameters controlling the creation of nonce values on a server, and I'm curious if there is a way to kind of "sync" them between servers.
The use case would be to have a UA send for example its registration to Proxy1. Proxy1 would challenge it, UA will send the registration again, this time with credentials. Proxy1 would look up the user based on $au/$ar in the subscriber table, and if it's not found, will look up the responsible proxy from another table (with key being $au@$ar), forward it to Proxy2, which then would be able authenticate the user.
The reason for this is that the auth credentials are unique across all servers and reliably identify a user, whereas for example From could be something else (e.g. in case of an IP-PBX sending a CLI in the From-userpart).
Challenging the user on the second proxy again would theoretically be possible, but if the UA gets a 401 twice (once from Proxy1, once from Proxy2), it'll most likely pop up a password form for soft-clients, so I want to avoid that.
Any ideas how to accomplish that?
Andreas
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
Hi David,
On 11/19/2012 02:54 PM, David J wrote:
Is the database shared? If so maybe when they authenticate add a secure token to the header that the second proxy can use for auth?
No, the DBs are explicitely NOT shared in this scenario.
Just a suggestion not sure if its the answer your looking for or perhaps I didn't understand the scenario well enough.
Let me try to put the scenario in different words:
If a request from a subscriber hits a server, and it doesn't contain an Authorization header, then the server would just challenge the request. This doesn't require any subscriber information on this server, so it shouldn't matter whether this subscriber exists on this server or not.
When the request comes in again, this time with an Authorization header, the server can use the username and realm of this header to check whether the subscriber is local or not. If it's local, it would just try to authenticate it as usual, and if it's not, it can look up the correct server using this auth username/realm and forward the request to the responsible server.
Now this second server would receive a request, which already contains an authorization header, but it won't be able to authenticate it if the nonce is not in sync between server1 and server2.
So this leads to the question whether it's possible to sync the nonces in a way that server1 challenges a request, and a different server would be able to authenticate the subsequent request holding the challenge-response.
Andreas
19 nov 2012 kl. 15:06 skrev Andreas Granig agranig@sipwise.com:
Hi David,
On 11/19/2012 02:54 PM, David J wrote:
Is the database shared? If so maybe when they authenticate add a secure token to the header that the second proxy can use for auth?
No, the DBs are explicitely NOT shared in this scenario.
Just a suggestion not sure if its the answer your looking for or perhaps I didn't understand the scenario well enough.
Let me try to put the scenario in different words:
If a request from a subscriber hits a server, and it doesn't contain an Authorization header, then the server would just challenge the request. This doesn't require any subscriber information on this server, so it shouldn't matter whether this subscriber exists on this server or not.
When the request comes in again, this time with an Authorization header, the server can use the username and realm of this header to check whether the subscriber is local or not. If it's local, it would just try to authenticate it as usual, and if it's not, it can look up the correct server using this auth username/realm and forward the request to the responsible server.
Now this second server would receive a request, which already contains an authorization header, but it won't be able to authenticate it if the nonce is not in sync between server1 and server2.
So this leads to the question whether it's possible to sync the nonces in a way that server1 challenges a request, and a different server would be able to authenticate the subsequent request holding the challenge-response.
If both servers have the same procedure to produce the nonce, the first server can issue the nonce and the second accept it, verify that it is a valid nonce in this cluster and do the authentication.
I believe that's why we have the secret in the auth module: http://kamailio.org/docs/modules/3.3.x/modules/auth.html#auth.secret
If we have two kamailios with the same auth secret, I think one can issue a challenge and the other one will first verify the nonce, then go ahead with authorization based on the other server's nonce.
Before you believe in any word of what I say, wait for confirmation by one of the core developers :-)
/O
Hi Andreas,
short question: Why don't you use a shared secret to create a nonce value?
http://kamailio.org/docs/modules/devel/modules/auth.html#auth.secret
Something like: # ----------------- Settings for Auth-DB --------------- modparam("auth", "secret", "sipwise-is-great")
If you set a common secret on all servers, all servers can validate the nonce-value (works at least with 1.5 and 3.2).
Carsten
2012/11/19 Andreas Granig agranig@sipwise.com:
Hi David,
On 11/19/2012 02:54 PM, David J wrote:
Is the database shared? If so maybe when they authenticate add a secure token to the header that the second proxy can use for auth?
No, the DBs are explicitely NOT shared in this scenario.
Just a suggestion not sure if its the answer your looking for or perhaps I didn't understand the scenario well enough.
Let me try to put the scenario in different words:
If a request from a subscriber hits a server, and it doesn't contain an Authorization header, then the server would just challenge the request. This doesn't require any subscriber information on this server, so it shouldn't matter whether this subscriber exists on this server or not.
When the request comes in again, this time with an Authorization header, the server can use the username and realm of this header to check whether the subscriber is local or not. If it's local, it would just try to authenticate it as usual, and if it's not, it can look up the correct server using this auth username/realm and forward the request to the responsible server.
Now this second server would receive a request, which already contains an authorization header, but it won't be able to authenticate it if the nonce is not in sync between server1 and server2.
So this leads to the question whether it's possible to sync the nonces in a way that server1 challenges a request, and a different server would be able to authenticate the subsequent request holding the challenge-response.
Andreas
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
Thanks Olle and Carsten,
On 11/19/2012 03:27 PM, Carsten Bock wrote:
short question: Why don't you use a shared secret to create a nonce value?
http://kamailio.org/docs/modules/devel/modules/auth.html#auth.secret
I've noticed this "secret" parameter, but the documentation is a bit brief on the exact meaning of it, thus my question on the list.
If this setting is really doing what we all think it is doing, then that'll be great! :)
I'll just try it out...
Andreas
I am using it with 3.2 in production for exactly that purpose - for years now. We did use it to synchronize the nonce in the Telefonica/O2 DSL project.
Kind regards, Carsten
2012/11/19 Andreas Granig agranig@sipwise.com:
Thanks Olle and Carsten,
On 11/19/2012 03:27 PM, Carsten Bock wrote:
short question: Why don't you use a shared secret to create a nonce value?
http://kamailio.org/docs/modules/devel/modules/auth.html#auth.secret
I've noticed this "secret" parameter, but the documentation is a bit brief on the exact meaning of it, thus my question on the list.
If this setting is really doing what we all think it is doing, then that'll be great! :)
I'll just try it out...
Andreas
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
Maybe we should merge the docs from 1.5, the docs are much better:
"Secret phrase used to calculate the nonce value.
The default is to use a random value generated from the random source in the core.
If you use multiple servers in your installation, and would like to authenticate on the second server against the nonce generated at the first one its necessary to explicitly set the secret to the same value on all servers. However, the use of a shared (and fixed) secret as nonce is insecure, much better is to stay with the default. Any clients should send the reply to the server that issued the request."
2012/11/19 Andreas Granig agranig@sipwise.com:
Thanks Olle and Carsten,
On 11/19/2012 03:27 PM, Carsten Bock wrote:
short question: Why don't you use a shared secret to create a nonce value?
http://kamailio.org/docs/modules/devel/modules/auth.html#auth.secret
I've noticed this "secret" parameter, but the documentation is a bit brief on the exact meaning of it, thus my question on the list.
If this setting is really doing what we all think it is doing, then that'll be great! :)
I'll just try it out...
Andreas
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
19 nov 2012 kl. 15:40 skrev Carsten Bock carsten@ng-voice.com:
Maybe we should merge the docs from 1.5, the docs are much better:
"Secret phrase used to calculate the nonce value.
The default is to use a random value generated from the random source in the core.
If you use multiple servers in your installation, and would like to authenticate on the second server against the nonce generated at the first one its necessary to explicitly set the secret to the same value on all servers. However, the use of a shared (and fixed) secret as nonce is insecure, much better is to stay with the default. Any clients should send the reply to the server that issued the request."
Done.
Having done that, I think we should rephrase that a bit. An authenticated request is not a reply...
/O
2012/11/19 Andreas Granig agranig@sipwise.com:
Thanks Olle and Carsten,
On 11/19/2012 03:27 PM, Carsten Bock wrote:
short question: Why don't you use a shared secret to create a nonce value?
http://kamailio.org/docs/modules/devel/modules/auth.html#auth.secret
I've noticed this "secret" parameter, but the documentation is a bit brief on the exact meaning of it, thus my question on the list.
If this setting is really doing what we all think it is doing, then that'll be great! :)
I'll just try it out...
Andreas
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
-- Carsten Bock CEO (Geschäftsführer)
ng-voice GmbH Schomburgstr. 80 D-22767 Hamburg / Germany
http://www.ng-voice.com mailto:carsten@ng-voice.com
Office +49 40 34927219 Fax +49 40 34927220
Sitz der Gesellschaft: Hamburg Registergericht: Amtsgericht Hamburg, HRB 120189 Geschäftsführer: Carsten Bock Ust-ID: DE279344284
Hier finden Sie unsere handelsrechtlichen Pflichtangaben: http://www.ng-voice.com/imprint/
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
-
Andreas Granig -
Carsten Bock -
David J -
Olle E. Johansson