Windows-Server-2003/inetcore/digest/notes.txt

60 lines
2.5 KiB
Plaintext

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.