windows-xp/Source/XPSP1/NT/inetcore/digest/notes.txt

Digest authentication:


1) Digest clients can be subdivided into serial clients and parallel clients.
We know how serial clients work. Parallel clients are two or more serial clients 
operating concurrently, sharing authentication data (specifically nonces). We 
postulate no a priori specific behavior for the parallel client nonce cache.

2) Parallel clients exist. Servers will receive multiple concurrent requests 
from single clients.

3) Given that parallel clients exist, what are possible modes of server behaviors 
regarding the generation and acceptance of nonces? There are several base cases and 
several degenerate cases

    a) Base case : A server generates a single nonce and always accepts it.
    b) Base case : A server generates unique nonces which are accepted only once 
       and timeout.

    c) Degenerate case: A server generates a single nonce and only accepts it once.
    d) Degenerate case: A server generates varying nonces but accepts only one of them.



Normal server behavior is assumed to be a composition of a) and b).

Are there any other server nonce behaviors possible? Specifically, can the 
server specify any kind of ordering on the nonces that are received? No. The 
reason for this is that the underlying transport is asynchronous. The
server cannot require that one nonce is received before or after another nonce, 
since it cannot guarantee any kind of ordering of requests from the client or 
client responses. Because the server cannot guarantee ordering, neither can the 
client, so it makes no sense for the client to enforce ordering in what nonces are 
used with requests.

4) Given the above, the distinction between nonces and nextnonces is confusing, and 
actually meaningless. A nonce results from a 401, a nextnonce results from a 200. Each of 
them specifies what should be used on the next request. Should they be treated differently? 
If so, how? Suppose a client makes two requests which result in two challenges. The response 
to the first challenge goes through and results in a nextnonce. Should this nextnonce override 
the nonce about to be used in the response to the challenge of the second request? If so, this 
would imply an ordering on the client side, which we know doesn't make sense.

5) Given this, the spec stating that clients SHOULD use the nextnonce value on the subsequent 
request is meaningless. What's the next request? What if another nextnonce value comes in before 
another request goes out? What if the nextnonce comes in 'late' ? This is a meaningless stipulation.