[sr-dev] [Kamailio] Why is the nonce expiry checked so late?
alex at speakup.nl
Tue Nov 17 17:35:46 CET 2009
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:
> 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
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 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,
T: 088-SPEAKUP (088-7732587)
More information about the sr-dev