[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