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

[Jan Janak]

On Tue, Nov 17, 2009 at 5:12 PM, Alex Hermann <alex at speakup.nl> wrote:
> Jan,
>
> On Tuesday 17 November 2009, you wrote:
>> On Tue, Nov 17, 2009 at 4:13 PM, Alex Hermann <alex at speakup.nl> wrote:
>> > 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 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 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;

Good point, thanks.

   -- Jan