On Tuesday 17 November 2009, Jan Janak wrote: > On Tue, Nov 17, 2009 at 5:12 PM, Alex Hermann <[email protected]> wrote: > > Jan, > > > > On Tuesday 17 November 2009, you wrote: > >> On Tue, Nov 17, 2009 at 4:13 PM, Alex Hermann <[email protected]> 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 _______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
