Some comments on Digest Auth

So I have finished my analysis of digest auth and am recommending that IE
5.0 implement it as a password protection mechanism, nothing more. While I
like to think my recommendation carries some weight the reality is that it
does not assure implementation, now or ever.

The following spec issues were brought up:

1) In section 3.3 of
ftp://ietf.org/internet-drafts/draft-ietf-http-authentication-00.txt, 4th
paragraph, it says "The client will follow the redirection, and pass the
same Authorization header, including the <opaque> data which the second
server may require." This sounds like a typo. If the client were to pass the
same authentication header it used before the redirection then the
information, such as digest-uri, in the header would be incorrect. This
could be used as the basis for a replay attack.
2) The proxy-authenticate headers seem to all use 401s, shouldn't these be
407s?

3) Assuming using a new nonce for every request becomes a MUST it will be
impossible to use pipelining or concurrent requests. The performance
implications are chilling. As such we were thinking of an addition to the
standard which would be 100% backwards compatible but would help with
performance. The idea is to send a "next-nonce" header which includes a list
of nonces. The client MUST use the nonces in order, this is necessary to
make the server's job of tracking nonces tractable. Current clients would
ignore the header and just use the nonce provided in the authentication
response header. I am not privy to the black corridors of security so I
can't be sure this wouldn't weaken the algorithm but it seems to make the
mechanism no weaker than providing the next nonce in the authentication
response header.

4) We wish to apply the same preauthorization rules we now use for basic.
So, for example, a URI in the domain list would imply that all that URI's
children are part of the same domain. In the worst case we end up sending in
a bad response and get a new challenge. It doesn't seem to hurt and it
definitely could help.

5) We will not support the digest-required option on a digest-challenge. If
we receive such a challenge we will look for another authentication option
in the www-authenticate. Failing to find one, we will inform the user that
we can't authenticate. There are a number of reasons for this decision but
the primary one is performance. Because the body authentication information
must be placed at the beginning of a message, with the exception of chunked
transfers, we would be required to buffer an entire message before sending
it off. The performance ramifications when compared to the security
advantage provided by hashing the body was not seen as a sufficiently good
trade off to justify the cost.

I suspect that digest is the best hope for reasonable security in the next
twelve to eighteen months. However work should begin now on a new standard,
digest-ng. It should provide for message based authentication of arbitrary
headers as well both public key and single key encryption. Connection based
security mechanisms like TLS require smashing through firewalls and proxies.
A message based mechanism would be significantly preferable for these very
reasons.

			Just some thoughts,
				from someone working on a Saturday,
					Yaron

Received on Saturday, 17 January 1998 13:05:26 UTC