<div dir="ltr"><div>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?<br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>Cheers,</div><div>Daniel<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 3, 2019 at 7:39 AM Juha Heinanen <<a href="mailto:jh@tutpro.com">jh@tutpro.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Daniel-Constantin Mierla writes:<br>
<br>
> If I haven't missed something, Juha said it is not good to ask the user<br>
> again for introducing the password in the (soft)phone app. The hashed<br>
> response (with nonce, realm, password) has to be sent always over the<br>
> network, no matter the stale parameter value. So it is just the<br>
> inconvenience of the person to type the password, it doesn't impact at all<br>
> what is sent over the network.<br>
<br>
I tried to say that if UA send REGISTER request that includes<br>
Authorization header and gets back 401 WWW-Authenticate header without<br>
stale=true, the UA MUST ask the user to enter authentication<br>
username/password again, even when there is nothing wrong with them.<br>
<br>
In practice that is in many cases impossible, e.g., when the UA is<br>
in user's pocket.  That is why it important that the server includes the<br>
flag in 401 response.<br>
<br>
-- Juha<br>
<br>
<br>
_______________________________________________<br>
Kamailio (SER) - Users Mailing List<br>
<a href="mailto:sr-users@lists.kamailio.org" target="_blank">sr-users@lists.kamailio.org</a><br>
<a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Daniel-Constantin Mierla - <a href="http://www.asipto.com" target="_blank">http://www.asipto.com</a></div><div><a href="http://twitter.com/#!/miconda" target="_blank">http://twitter.com/#!/miconda</a> - <a href="http://www.linkedin.com/in/miconda" target="_blank">http://www.linkedin.com/in/miconda</a></div></div></div></div></div>