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

[Alex Hermann]

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.
"

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.

The server gets a little bit more traffic if there are a lot of clients 
configured with wrong credentials, otherwise, the traffic is the same but the 
DB load halves.


2) If the nonce is not stale: no changes to current behaviour.

-- 
Met vriendelijke groet,


Alex Hermann
SpeakUp BV
T: 088-SPEAKUP (088-7732587)
F: 088-7732588