Several people are complaining on baresip git that Kamailio is among those SIP servers that don't handle stale nonce properly, i.e., don't include stale=true flag in WWW-Authenticate header of 401 response.
I have tried to tell that Kamailio does what it has been configured to do, but the response is that "by default" Kamailio works incorrectly. "By default" I guess refers to the example Kamailio kamailio.cfg in etc dir.
How about adding stale nonce handling to the example config, for example, like in below?
-- Juha
*** kamailio.cfg 2019-06-13 17:17:17.182148989 +0300 --- /tmp/kamailio.cfg 2019-07-02 18:02:02.947183503 +0300 *************** *** 745,753 ****
if (is_method("REGISTER") || from_uri==myself) { # authenticate requests ! if (!auth_check("$fd", "subscriber", "1")) { ! auth_challenge("$fd", "0"); ! exit; } # user authenticated - remove auth header if(!is_method("REGISTER|PUBLISH")) --- 745,759 ----
if (is_method("REGISTER") || from_uri==myself) { # authenticate requests ! switch (auth_check("$fd", "subscriber", "1")) { ! case 1: ! break; ! case -4: ! auth_challenge("$fd", 17); ! exit; ! default: ! auth_challenge("$fd", "0"); ! exit; } # user authenticated - remove auth header if(!is_method("REGISTER|PUBLISH"))
Hello Juha,
sounds like a good idea to me, we should integrate it to the default cfg.
Just a small comment, I think this would be match the current behaviour more closely (only return stale=true, don't use qop=auth).
! case -4: ! auth_challenge("$fd", 16); ! exit;
Cheers,
Henning
Am 02.07.19 um 17:15 schrieb Juha Heinanen:
Several people are complaining on baresip git that Kamailio is among those SIP servers that don't handle stale nonce properly, i.e., don't include stale=true flag in WWW-Authenticate header of 401 response.
I have tried to tell that Kamailio does what it has been configured to do, but the response is that "by default" Kamailio works incorrectly. "By default" I guess refers to the example Kamailio kamailio.cfg in etc dir.
How about adding stale nonce handling to the example config, for example, like in below?
-- Juha
*** kamailio.cfg 2019-06-13 17:17:17.182148989 +0300 --- /tmp/kamailio.cfg 2019-07-02 18:02:02.947183503 +0300
*** 745,753 ****
if (is_method("REGISTER") || from_uri==myself) { # authenticate requests! if (!auth_check("$fd", "subscriber", "1")) { ! auth_challenge("$fd", "0"); ! exit; } # user authenticated - remove auth header if(!is_method("REGISTER|PUBLISH")) --- 745,759 ----
if (is_method("REGISTER") || from_uri==myself) { # authenticate requests! switch (auth_check("$fd", "subscriber", "1")) { ! case 1: ! break; ! case -4: ! auth_challenge("$fd", 17); ! exit; ! default: ! auth_challenge("$fd", "0"); ! exit; } # user authenticated - remove auth header if(!is_method("REGISTER|PUBLISH"))
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Henning Westerholt writes:
sounds like a good idea to me, we should integrate it to the default cfg.
Just a small comment, I think this would be match the current behaviour more closely (only return stale=true, don't use qop=auth).
! case -4: ! auth_challenge("$fd", 16); ! exit;
This change is fine. Perhaps someone who has capability to run the example config, could give the new version a try before commit?
Hello, I am not sure if this option is actually implemented according to the specs. iirc, stale=true should be set when the server checks the username and password and all is ok, but the nonce is expired. afaik, the check for nonce expiration is done before hiting the database to fetch the password and check the response. In UA side the stale=true would just make the app rebuild the response without prompting for password again, because the server said that with the expired nonce all was ok, from user/password point of view.
But if we hit the database for every expired nonce, then we expose the server to kind of a DoS processing.
Moreover, the latest recommendations in security is to disclose as less as possible what was not "correct", avoiding responses like "invalid user id" or "invalid password".
The lack of stale=true means that the UA should build again the authorization header from scratch with all the attributes.
I won't be against enabling this option if it would be for a "trusted" endpoint, but for servers exposed to the wild world, it may create some security concerns.
Therefore for the moment I would suggest to wait for more feedback from community, along with checking if the stale=true is implemented as per spec or is half brewed option.
Cheers, Daniel
On Tue, Jul 2, 2019 at 6:48 PM Henning Westerholt hw@skalatan.de wrote:
Hello Juha,
sounds like a good idea to me, we should integrate it to the default cfg.
Just a small comment, I think this would be match the current behaviour more closely (only return stale=true, don't use qop=auth).
! case -4: ! auth_challenge("$fd", 16); ! exit;
Cheers,
Henning
Am 02.07.19 um 17:15 schrieb Juha Heinanen:
Several people are complaining on baresip git that Kamailio is among those SIP servers that don't handle stale nonce properly, i.e., don't include stale=true flag in WWW-Authenticate header of 401 response.
I have tried to tell that Kamailio does what it has been configured to do, but the response is that "by default" Kamailio works incorrectly.
"By
default" I guess refers to the example Kamailio kamailio.cfg in etc dir.
How about adding stale nonce handling to the example config, for example, like in below?
-- Juha
*** kamailio.cfg 2019-06-13 17:17:17.182148989 +0300 --- /tmp/kamailio.cfg 2019-07-02 18:02:02.947183503 +0300
*** 745,753 ****
if (is_method("REGISTER") || from_uri==myself) { # authenticate requests! if (!auth_check("$fd", "subscriber", "1")) { ! auth_challenge("$fd", "0"); ! exit; } # user authenticated - remove auth header if(!is_method("REGISTER|PUBLISH")) --- 745,759 ----
if (is_method("REGISTER") || from_uri==myself) { # authenticate requests! switch (auth_check("$fd", "subscriber", "1")) { ! case 1: ! break; ! case -4: ! auth_challenge("$fd", 17); ! exit; ! default: ! auth_challenge("$fd", "0"); ! exit; } # user authenticated - remove auth header if(!is_method("REGISTER|PUBLISH"))
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://skalatan.de/services
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Daniel-Constantin Mierla writes:
I am not sure if this option is actually implemented according to the specs. iirc, stale=true should be set when the server checks the username and password and all is ok, but the nonce is expired. afaik, the check for nonce expiration is done before hiting the database to fetch the password and check the response.
Is there a function for doing the nonce check or is www_authorize doing it before making db query?
In UA side the stale=true would just make the app rebuild the response without prompting for password again, because the server said that with the expired nonce all was ok, from user/password point of view.
That is exactly the point of stale=true.
But if we hit the database for every expired nonce, then we expose the server to kind of a DoS processing.
It is possible to use, e.g., fail2ban, also in expired nonce case.
Moreover, the latest recommendations in security is to disclose as less as possible what was not "correct", avoiding responses like "invalid user id" or "invalid password".
I agree with that, but in case of expired nonce, the sender already has somehow figured out what the username is.
The lack of stale=true means that the UA should build again the authorization header from scratch with all the attributes.
And ask the user for password again, which is not a good idea.
I won't be against enabling this option if it would be for a "trusted" endpoint, but for servers exposed to the wild world, it may create some security concerns.
Therefore for the moment I would suggest to wait for more feedback from community, along with checking if the stale=true is implemented as per spec or is half brewed option.
The spec says:
"If stale is FALSE, or anything other than TRUE, or the stale directive is not present, the username and/or password are invalid and new values must be obtained."
As I already mentioned, not a good idea to keep asking password all the time.
-- Juha
Juha Heinanen writes:
Moreover, the latest recommendations in security is to disclose as less as possible what was not "correct", avoiding responses like "invalid user id" or "invalid password".
I agree with that, but in case of expired nonce, the sender already has somehow figured out what the username is.
I think that in order to be able send a request with stale nonce, the attacker must already have been able to capture the previous request/response. If so, there is not much to loose by including the flag.
-- Juha
Hello,
I did a quick check in the code, this is the path:
auth_check() -> digest_authenticate_hdr() -> auth_api.pre_auth() -> check for stale nonce etc..
DB calls are done later in the code path. So it looks that there is no possibility to do a DB DOS just with this path.
And as Juha mentioned, it is also not good from a security POV to keep sending the password hash again and again.
Cheers,
Henning
Am 02.07.19 um 19:04 schrieb Daniel-Constantin Mierla: Hello, I am not sure if this option is actually implemented according to the specs. iirc, stale=true should be set when the server checks the username and password and all is ok, but the nonce is expired. afaik, the check for nonce expiration is done before hiting the database to fetch the password and check the response. In UA side the stale=true would just make the app rebuild the response without prompting for password again, because the server said that with the expired nonce all was ok, from user/password point of view.
But if we hit the database for every expired nonce, then we expose the server to kind of a DoS processing.
Moreover, the latest recommendations in security is to disclose as less as possible what was not "correct", avoiding responses like "invalid user id" or "invalid password".
The lack of stale=true means that the UA should build again the authorization header from scratch with all the attributes.
I won't be against enabling this option if it would be for a "trusted" endpoint, but for servers exposed to the wild world, it may create some security concerns.
Therefore for the moment I would suggest to wait for more feedback from community, along with checking if the stale=true is implemented as per spec or is half brewed option.
Cheers, Daniel
On Tue, Jul 2, 2019 at 6:48 PM Henning Westerholt <hw@skalatan.demailto:hw@skalatan.de> wrote: Hello Juha,
sounds like a good idea to me, we should integrate it to the default cfg.
Just a small comment, I think this would be match the current behaviour more closely (only return stale=true, don't use qop=auth).
! case -4: ! auth_challenge("$fd", 16); ! exit;
Cheers,
Henning
Am 02.07.19 um 17:15 schrieb Juha Heinanen:
Several people are complaining on baresip git that Kamailio is among those SIP servers that don't handle stale nonce properly, i.e., don't include stale=true flag in WWW-Authenticate header of 401 response.
I have tried to tell that Kamailio does what it has been configured to do, but the response is that "by default" Kamailio works incorrectly. "By default" I guess refers to the example Kamailio kamailio.cfg in etc dir.
How about adding stale nonce handling to the example config, for example, like in below?
-- Juha
*** kamailio.cfg 2019-06-13 17:17:17.182148989 +0300 --- /tmp/kamailio.cfg 2019-07-02 18:02:02.947183503 +0300
*** 745,753 ****
if (is_method("REGISTER") || from_uri==myself) { # authenticate requests! if (!auth_check("$fd", "subscriber", "1")) { ! auth_challenge("$fd", "0"); ! exit; } # user authenticated - remove auth header if(!is_method("REGISTER|PUBLISH")) --- 745,759 ----
if (is_method("REGISTER") || from_uri==myself) { # authenticate requests! switch (auth_check("$fd", "subscriber", "1")) { ! case 1: ! break; ! case -4: ! auth_challenge("$fd", 17); ! exit; ! default: ! auth_challenge("$fd", "0"); ! exit; } # user authenticated - remove auth header if(!is_method("REGISTER|PUBLISH"))
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://skalatan.de/services
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org https://lists.kamailio.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 (SER) - Users Mailing List sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://skalatan.de/services
Hello,
Henning: it is what I said that I expect the db query is done later, so we actually do not assert the fact that the username and password used with the stalled nonce are correct, as per specs. To follow the specs, even when the nonce is expired, we have to fetch the password from database, compute the response and if it is correct, then add stale=true. Otherwise, not having valid username and password, the parameter must not be set, to force the UA to ask for new username and password.
But, doing an sql query in case of an expired nonce can expose the server to sort of useless (and quite time expensive) operations. Moreover, for an attacker will be easier to reuse an expired nonce and keep trying new passwords until getting stale=true, meaning that it has discovered the password.
With the above considerations, to make it specs compliant, the code has to be extended that even in the case of expired nonce, the auth_db (and the other auth* variants) has to go further to compute the response and if there was a match, then add stale=true. As it is right now, if someone sends an expired nonce with an incorrect password, the stale=true is added, even it shouldn't as per specs.
Therefore adding that flag now is not bringing benefits in my opinion and can be even more trouble maker.
Cheers, Daniel
On Tue, Jul 2, 2019 at 7:30 PM Henning Westerholt hw@skalatan.de wrote:
Hello,
I did a quick check in the code, this is the path:
auth_check() -> digest_authenticate_hdr() -> auth_api.pre_auth() -> check for stale nonce etc..
DB calls are done later in the code path. So it looks that there is no possibility to do a DB DOS just with this path.
And as Juha mentioned, it is also not good from a security POV to keep sending the password hash again and again.
Cheers,
Henning
Am 02.07.19 um 19:04 schrieb Daniel-Constantin Mierla:
Hello, I am not sure if this option is actually implemented according to the specs. iirc, stale=true should be set when the server checks the username and password and all is ok, but the nonce is expired. afaik, the check for nonce expiration is done before hiting the database to fetch the password and check the response. In UA side the stale=true would just make the app rebuild the response without prompting for password again, because the server said that with the expired nonce all was ok, from user/password point of view.
But if we hit the database for every expired nonce, then we expose the server to kind of a DoS processing.
Moreover, the latest recommendations in security is to disclose as less as possible what was not "correct", avoiding responses like "invalid user id" or "invalid password".
The lack of stale=true means that the UA should build again the authorization header from scratch with all the attributes.
I won't be against enabling this option if it would be for a "trusted" endpoint, but for servers exposed to the wild world, it may create some security concerns.
Therefore for the moment I would suggest to wait for more feedback from community, along with checking if the stale=true is implemented as per spec or is half brewed option.
Cheers, Daniel
On Tue, Jul 2, 2019 at 6:48 PM Henning Westerholt hw@skalatan.de wrote:
Hello Juha,
sounds like a good idea to me, we should integrate it to the default cfg.
Just a small comment, I think this would be match the current behaviour more closely (only return stale=true, don't use qop=auth).
! case -4: ! auth_challenge("$fd", 16); ! exit;
Cheers,
Henning
Am 02.07.19 um 17:15 schrieb Juha Heinanen:
Several people are complaining on baresip git that Kamailio is among those SIP servers that don't handle stale nonce properly, i.e., don't include stale=true flag in WWW-Authenticate header of 401 response.
I have tried to tell that Kamailio does what it has been configured to do, but the response is that "by default" Kamailio works incorrectly.
"By
default" I guess refers to the example Kamailio kamailio.cfg in etc dir.
How about adding stale nonce handling to the example config, for example, like in below?
-- Juha
*** kamailio.cfg 2019-06-13 17:17:17.182148989 +0300 --- /tmp/kamailio.cfg 2019-07-02 18:02:02.947183503 +0300
*** 745,753 ****
if (is_method("REGISTER") || from_uri==myself) { # authenticate requests! if (!auth_check("$fd", "subscriber", "1")) { ! auth_challenge("$fd", "0"); ! exit; } # user authenticated - remove auth header if(!is_method("REGISTER|PUBLISH")) --- 745,759 ----
if (is_method("REGISTER") || from_uri==myself) { # authenticate requests! switch (auth_check("$fd", "subscriber", "1")) { ! case 1: ! break; ! case -4: ! auth_challenge("$fd", 17); ! exit; ! default: ! auth_challenge("$fd", "0"); ! exit; } # user authenticated - remove auth header if(!is_method("REGISTER|PUBLISH"))
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://skalatan.de/services
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.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 (SER) - Users Mailing Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://skalatan.de/services
Henning: forgot about your remark: "And as Juha mentioned, it is also not good from a security POV to keep sending the password hash again and again."
If I haven't missed something, Juha said it is not good to ask the user again for introducing the password in the (soft)phone app. The hashed response (with nonce, realm, password) has to be sent always over the network, no matter the stale parameter value. So it is just the inconvenience of the person to type the password, it doesn't impact at all what is sent over the network.
Cheers, Daniel
On Tue, Jul 2, 2019 at 11:10 PM Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
Henning: it is what I said that I expect the db query is done later, so we actually do not assert the fact that the username and password used with the stalled nonce are correct, as per specs. To follow the specs, even when the nonce is expired, we have to fetch the password from database, compute the response and if it is correct, then add stale=true. Otherwise, not having valid username and password, the parameter must not be set, to force the UA to ask for new username and password.
But, doing an sql query in case of an expired nonce can expose the server to sort of useless (and quite time expensive) operations. Moreover, for an attacker will be easier to reuse an expired nonce and keep trying new passwords until getting stale=true, meaning that it has discovered the password.
With the above considerations, to make it specs compliant, the code has to be extended that even in the case of expired nonce, the auth_db (and the other auth* variants) has to go further to compute the response and if there was a match, then add stale=true. As it is right now, if someone sends an expired nonce with an incorrect password, the stale=true is added, even it shouldn't as per specs.
Therefore adding that flag now is not bringing benefits in my opinion and can be even more trouble maker.
Cheers, Daniel
On Tue, Jul 2, 2019 at 7:30 PM Henning Westerholt hw@skalatan.de wrote:
Hello,
I did a quick check in the code, this is the path:
auth_check() -> digest_authenticate_hdr() -> auth_api.pre_auth() -> check for stale nonce etc..
DB calls are done later in the code path. So it looks that there is no possibility to do a DB DOS just with this path.
And as Juha mentioned, it is also not good from a security POV to keep sending the password hash again and again.
Cheers,
Henning
Am 02.07.19 um 19:04 schrieb Daniel-Constantin Mierla:
Hello, I am not sure if this option is actually implemented according to the specs. iirc, stale=true should be set when the server checks the username and password and all is ok, but the nonce is expired. afaik, the check for nonce expiration is done before hiting the database to fetch the password and check the response. In UA side the stale=true would just make the app rebuild the response without prompting for password again, because the server said that with the expired nonce all was ok, from user/password point of view.
But if we hit the database for every expired nonce, then we expose the server to kind of a DoS processing.
Moreover, the latest recommendations in security is to disclose as less as possible what was not "correct", avoiding responses like "invalid user id" or "invalid password".
The lack of stale=true means that the UA should build again the authorization header from scratch with all the attributes.
I won't be against enabling this option if it would be for a "trusted" endpoint, but for servers exposed to the wild world, it may create some security concerns.
Therefore for the moment I would suggest to wait for more feedback from community, along with checking if the stale=true is implemented as per spec or is half brewed option.
Cheers, Daniel
On Tue, Jul 2, 2019 at 6:48 PM Henning Westerholt hw@skalatan.de wrote:
Hello Juha,
sounds like a good idea to me, we should integrate it to the default cfg.
Just a small comment, I think this would be match the current behaviour more closely (only return stale=true, don't use qop=auth).
! case -4: ! auth_challenge("$fd", 16); ! exit;
Cheers,
Henning
Am 02.07.19 um 17:15 schrieb Juha Heinanen:
Several people are complaining on baresip git that Kamailio is among those SIP servers that don't handle stale nonce properly, i.e., don't include stale=true flag in WWW-Authenticate header of 401 response.
I have tried to tell that Kamailio does what it has been configured to do, but the response is that "by default" Kamailio works incorrectly.
"By
default" I guess refers to the example Kamailio kamailio.cfg in etc
dir.
How about adding stale nonce handling to the example config, for example, like in below?
-- Juha
*** kamailio.cfg 2019-06-13 17:17:17.182148989 +0300 --- /tmp/kamailio.cfg 2019-07-02 18:02:02.947183503 +0300
*** 745,753 ****
if (is_method("REGISTER") || from_uri==myself) { # authenticate requests! if (!auth_check("$fd", "subscriber", "1")) { ! auth_challenge("$fd", "0"); ! exit; } # user authenticated - remove auth header if(!is_method("REGISTER|PUBLISH")) --- 745,759 ----
if (is_method("REGISTER") || from_uri==myself) { # authenticate requests! switch (auth_check("$fd", "subscriber", "1")) { ! case 1: ! break; ! case -4: ! auth_challenge("$fd", 17); ! exit; ! default: ! auth_challenge("$fd", "0"); ! exit; } # user authenticated - remove auth header if(!is_method("REGISTER|PUBLISH"))
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://skalatan.de/services
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.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 (SER) - Users Mailing Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://skalatan.de/services
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Daniel-Constantin Mierla writes:
If I haven't missed something, Juha said it is not good to ask the user again for introducing the password in the (soft)phone app. The hashed response (with nonce, realm, password) has to be sent always over the network, no matter the stale parameter value. So it is just the inconvenience of the person to type the password, it doesn't impact at all what is sent over the network.
I tried to say that if UA send REGISTER request that includes Authorization header and gets back 401 WWW-Authenticate header without stale=true, the UA MUST ask the user to enter authentication username/password again, even when there is nothing wrong with them.
In practice that is in many cases impossible, e.g., when the UA is in user's pocket. That is why it important that the server includes the flag in 401 response.
-- Juha
I do not have anything against being implemented as per specs, with an option (a new flag) to auth functions (likely it needs to be done in several modules that do digest-auth with various backends). I would also make sense to see what the specs say about an UA to reuse a nonce, if it something recommended or just some UAs do it for convenience. When the nonce is returned first time, unlikely that it will expire till the first usage, expiration happen when the UA uses the nonce from previous registration, that happened probably minutes ago. Is this something covered by specs?
Anyhow, setting this option in the default config file is something I don't consider really good from security point of view. Hitting the database can be a big performance impact. Adding additional rules to overcome the potential DoS exposure, such as fail2ban, of course are good, but it also does not belong to the default config file. There are many options that the auth modules have, including one-time-nonce, different auth qop, etc. I think all of these can be added to the advanced config, now located in misc/examples/pkg/kamailio-oob.cfg.
I prefer to keep kamailio.cfg as a complete-enough but still basic starting point to build the config file. It will be more negative feedback if the default config has poor performances and exposes to more security risks than someone reading the docs and enabling various auth options to tune it for specific needs.
Actually, so far nobody complained about lack of stale=true, I have seen some UAs that reused nonce between registrations and typically they don't ask for a new password if they reused the nonce, only when they got a fresh one and the auth failed... but could be specific implementation details, specs should be checked about the reuse of nonce to see what behaviour should be there.
Cheers, Daniel
On Wed, Jul 3, 2019 at 7:39 AM Juha Heinanen jh@tutpro.com wrote:
Daniel-Constantin Mierla writes:
If I haven't missed something, Juha said it is not good to ask the user again for introducing the password in the (soft)phone app. The hashed response (with nonce, realm, password) has to be sent always over the network, no matter the stale parameter value. So it is just the inconvenience of the person to type the password, it doesn't impact at
all
what is sent over the network.
I tried to say that if UA send REGISTER request that includes Authorization header and gets back 401 WWW-Authenticate header without stale=true, the UA MUST ask the user to enter authentication username/password again, even when there is nothing wrong with them.
In practice that is in many cases impossible, e.g., when the UA is in user's pocket. That is why it important that the server includes the flag in 401 response.
-- Juha
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Daniel-Constantin Mierla writes:
With the above considerations, to make it specs compliant, the code has to be extended that even in the case of expired nonce, the auth_db (and the other auth* variants) has to go further to compute the response and if there was a match, then add stale=true. As it is right now, if someone sends an expired nonce with an incorrect password, the stale=true is added, even it shouldn't as per specs.
I would consider that a serious bug that needs to be fixed. stale=true should be set only in case authentication would otherwise succeed, but nonce has expired.
After the fix, I don't see any reason why stale=true could not be set.
-- Juha
Hello,
I did some research, from RFC 2617:
stale A flag, indicating that the previous request from the client was rejected because the nonce value was stale. If stale is TRUE (case-insensitive), the client may wish to simply retry the request with a new encrypted response, without reprompting the user for a new username and password. The server should only set stale to TRUE if it receives a request for which the nonce is invalid but with a valid digest for that nonce (indicating that the client knows the correct username/password). If stale is FALSE, or anything other than TRUE, or the stale directive is not present, the username and/or password are invalid, and new values must be obtained.
It is a "SHOULD", not a "MUST". So it would be also ok to go with the current implementation.
That said, of course changing the auth module to make it more compliant to the spec would be a good idea. That could be also done with a parameter to switch between both modes (related to the discussed performance concerns).
About the other question in another part of this thread related to nonce re-use, I only found this old discussion:
https://lists.cs.columbia.edu/pipermail/sip-implementors/2003-October/005486...
This supports the point given above again:
"the server has the option of computing whether or not the credentials used to construct the response value with that nonce were good, and if so return 'stale=true' to indicate that a retry using the same credentials and the new nonce should succeed, but it is not required to do that check."
Cheers,
Henning
Am 03.07.19 um 07:30 schrieb Juha Heinanen:
Daniel-Constantin Mierla writes:
With the above considerations, to make it specs compliant, the code has to be extended that even in the case of expired nonce, the auth_db (and the other auth* variants) has to go further to compute the response and if there was a match, then add stale=true. As it is right now, if someone sends an expired nonce with an incorrect password, the stale=true is added, even it shouldn't as per specs.
I would consider that a serious bug that needs to be fixed. stale=true should be set only in case authentication would otherwise succeed, but nonce has expired.
After the fix, I don't see any reason why stale=true could not be set.
-- Juha
-- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://skalatan.de/services
-
Daniel-Constantin Mierla -
Henning Westerholt -
Juha Heinanen