17 Nov
2009
17 Nov
'09
11:09 p.m.
On Tuesday 17 November 2009 18:02:03 Jan Janak wrote:
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.
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. 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