[sr-dev] [Kamailio] Why is the nonce expiry checked so late?

[Jan Janak]

On Tue, Nov 17, 2009 at 5:35 PM, Alex Hermann <alex at speakup.nl> wrote:
> On Tuesday 17 November 2009, Jan Janak wrote:
>> On Tue, Nov 17, 2009 at 5:12 PM, Alex Hermann <alex at speakup.nl> wrote:
>> > Jan,
>> >
>> > On Tuesday 17 November 2009, you wrote:
>> >> On Tue, Nov 17, 2009 at 4:13 PM, Alex Hermann <alex at speakup.nl> wrote:
>> > The server can just as well generate a stale=true response immediately,
>> > independent of the credentials check. If later on a non-expired nonce
>> > arrives, it can do the credentials check and send a response without
>> > stale=true if necessary.
>>
>> How does the server know that the credentials are valid and it can
>> thus send back stale=true? Note that you can only use that parameter
>> if you verified that the username and password is valid (by verifying
>> the response string). Here is relevant text from RFC2617:
>>
>> 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.
>>
>> In other words, you can move the expired nonce check to the beginning
>> of the authentication process, but in that case you should make sure
>> that you never send back stale=true.
>
> The text says _should_, which in normal RFC terms means that the
> implementation may choose not to do it if it has a good reason to do so
> rfc2119:
> "
> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>   may exist valid reasons in particular circumstances to ignore a
>   particular item, but the full implications must be understood and
>   carefully weighed before choosing a different course.

Note that RFC2119 only applies to capitalized "SHOULD", it does not
apply to "should".

> I think that halving the DB load on auth attempts is a good/valid reason, and
> I don't see how this could go wrong:
>
> 1) If the nonce is stale, stale=true is returned, the client tries again
> without prompting the user. If then the server decides the digest was
> invalid, it returns a response without stale=true and the client will prompt
> the user.

Or the user agent may just as well give up, report an error or try
again later. You may end up having UAs that fail to authenticate from
time to time, which can be worse than more DB load on the server.

I think that if you want to perform the stale nonce check early then
disabling stale=true all together would be a safe bet.

The stale parameter is only useful for software based user agents that
can interact with the user and prompt for password, most HW phones
have the password preconfigured and there it does not matter if you
send stale=true or not.

  -- Jan