17 Nov
2009
17 Nov
'09
9:54 p.m.
On Tue, Nov 17, 2009 at 5:12 PM, Alex Hermann <alex(a)speakup.nl> wrote:
Good point, thanks.
-- Jan
Jan,
On Tuesday 17 November 2009, you wrote:
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.
On Tue, Nov 17, 2009 at 4:13 PM, Alex Hermann
<alex(a)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. Hello,
Why is the nonce expiry checked in post_auth instead of pre_auth? Now the
expiry is checked after the username/password is checked against the DB.
That seems a bit odd.
I moved the check to check_nonce (which is called from pre_auth) and it
seems to work fine. Did I miss something? Security issue?
There are two major reasons for this:
The server sends back stale=true in digest credentials if the nonce
has expired, but only if the credentials are otherwise valid (i.e. the
username and the password are correct). The parameter stale=true
indicates to the user agent that there is no need to ask the user for
username and password again, it can just generate a new authorization
header with ca> ched username and password and a new nonce string from
the server. The second
reason is that we need to accept credentials with old nonce
string for ACK and CANCEL requests. Those two requests cannot be
challenged (There is no reply for ACK and CANCEL must have the same
CSeq as the request being canceled), thus we cannot ask the user agent
to resubmit them again with a new nonce.
This reason is invalid because of the
following existing code in pre_auth:
if ((_m->REQ_METHOD == METHOD_ACK) || (_m->REQ_METHOD == METHOD_CANCEL))
return AUTHORIZED;