60 lines
2.5 KiB
Plaintext
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.
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|