New draft for Digest Authentication

The authors of the Digest Authentication draft have been asked for
a revision of that draft incorporating the following changes.

  * Adding an algorithm parameter.
  * Describe in detail construction of nonces.
       Here there are a number of tricks already in use which ensure that
       a nonce is only valid for requests comming from a single TCP/IP
       address.
  * Fix dependence on 'extension mechanism'.       
  * Enhance 'security considerations' section to explain limitations.


I have produced a new version which I hope meets these needs.
My intent was to make these changes and as little other change
as possible.

One minor change is that the nonce is now defined to be a string
opaque to the client rather than an "integer" opaque to the client.

There is also now an optional Digest header parameter "algorithm" to
allow specification of another digesting algorithm (as requested).
The default algorithm is MD5.  

I have greatly expanded the description of nonce construction.  Nonce
construction remains implementation dependent, but some of the issues
involved are discussed and some possible recommended implementations
are provided.

I have added a section 3. on Security Considerations.  It is largely
a comparison with Basic Authentication.

This draft is currently available at

	http://hopf.math.nwu.edu/~john/new_rfc.txt

I would welcome comments on it -- especially constructive ones.

In light of the recent discussion in this group I want to make some
additional comments.  I have not added "nonce icrementing" to the
draft and I personally am not in favor of such a change.  Here are my
reasons:

1) Nonce incrementing, does not in any way strengthen the security of
digest authentication over the use of one-time nonces. One-time nonces
are consistent with, and suggested in, the current and past
specifications.  The only advantage of nonce incrementing would be a
small efficiency improvement.

2) Nonce incrementing breaks current implementations.  Making it
optional to maintain backwards compatibility would make it useless for
security as any attacker would simply use the old version of the
protocol.

3) HTTP is, in general, a "stateless" protocol.  Incorporating nonce
incrementing makes it "stateful."  Many people will strongly oppose
this change.  If you want to debate whether statelessness is a
desirable design goal for HTTP, or whether the maintaining of state
can be done efficiently for nonce incrementing I hope you will find
another forum.  I am simply reporting a historical fact that many
people want to keep HTTP a stateless protocol.  I am aware that one-time
nonces (advocated above) and many CGI applications require maintaining
state.  The difference is that these are implementation decisions, not
part of the protocol and, in particular, the protocol does not
*require* the server to keep state information across connections.

John Franks
john@math.nwu.edu

Received on Friday, 23 February 1996 09:40:28 UTC