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

Alex Hermann alex at speakup.nl
Tue Nov 17 18:39:17 CET 2009

On Tuesday 17 November 2009 18:02:03 Jan Janak wrote:
> > 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.
A nonce will(/should) only be reused by an UAC when it was accepted in an 
earlier request. So the credentials are highly likely to be correct.

An initial request has no credentials, so no stale=true is returned.

The only scenario of failure I can think of is this: the UAC reuses a nonce, 
it receives a stale=true response and concludes(*) the credentials are 
correct, so it resubmits with the new nonce. On the UAS however, the 
credentials are changed since the previous authenticated request so the 
resubmitted credentials with valid nonce are rejected without stale=true. 
Because of the earlier conclusion (*) the UAC doesn't ask the user for new 
credentials and stops. IMHO the UAC should only conclude the credentials are 
correct when it receives a non-failure code for the request.

I think this sequence of events is seldom and the behaviour of the UAC is so 
weird that I'm willing to take that risk.

I'll try to cook a patch that makes the nonce check before credentials check 
configurable and submit it properly.

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

If an UAC sends valid credentials with an expired nonce and the UAS send back 
a 407 without stale=true, the UAC should give up or ask the user. Both of 
which are unwanted.

Alex Hermann

More information about the sr-dev mailing list