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