Re: Nonce count, digest authentication.

Thanks for the information about using a bit mask Scott.

I just wonder what kind of size you set on the bit mask. As far as I
understand, the bigger the bit mask, the greater risk you run of
having a reply attack slip through your protection mechanism.

I run a few tests using various browsers and the only browser
implementing preemptive authorization seems to be Opera. Worst of all
seems to be Mozilla, which can have huge gaps in the nonce counter. I
had one request with nc=00000017 and the next with nc=0000003c.

/Wilfred

----- Original Message ----- 
From: "Scott Lawrence" <scott-http@skrb.org>
To: "Wilfred Nilsen" <wilfred.nilsen@cox.net>
Cc: <ietf-http-wg@w3.org>
Sent: Wednesday, July 02, 2003 4:25 AM
Subject: Re: Nonce count, digest authentication.


>
> "Wilfred Nilsen" <wilfred.nilsen@cox.net> writes:
>
> > I have some problems with implementing Digest Authentication for a
> > small web-server.  I do not know how many browsers support Digest
> > Authentication.  It seems like Mozilla and IE is supporting some
of
> > the features, although they do not seem to implement preemptive
> > authorization.
>
> They both implement it, though the IE implementation still does not
> include the query string in the hash as a part of the URL, so it
will
> fail for any request with a query string unless you make allowances
> for that.
>
> > The way I do it is to store the local 'nonce counter' in a session
> > object and increment the value every time I get a request.  I keep
3
> > {nonce, nc} pairs.  This is to prevent 'nonce' mismatch if the
client
> > implements preemptive authorization and the client pipelines the
> > requests.  I simply search for the correct {nonce, nc} pair by
> > comparing the local nonce with the client nonce.  I then increment
the
> > 'nc' value for the {nonce, nc} pair that matches the client nonce.
>
> > The problem is that the client sometimes skips a 'nc' value.  For
> > example, the server and client nonce count matches say to the
value
> > 00000016, but then the next value from the client is 00000018?
>
> That's valid behaviour in the client; there is no requirement that
> they be used in strict order - only that each value be used only
> once.  This is because if you have multiple connections to the
server
> open and/or if you are going through proxies, you can't ensure what
> the order of delivery to the origin server will be.
>
> I suggest recording which nc values you have seen for any given
nonce,
> and not allow reuse (I used a bit mask), but do not try to enforce
> ordering.
>
> -- 
> Scott Lawrence
>   http://skrb.org/scott/
>   [ <lawrence@world.std.com> is deprecated ]
>
>

Received on Thursday, 3 July 2003 17:06:46 UTC