Status of Digest Authentication

> My notes say that we are expecting a new draft of digest
> authentication from the authors, of which you are one.
> It was my impression that this new draft would include:
>  * 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.
> ...
> Did I just imagine that we were going to see a revised draft? If not
> from you, from whom?

eric sink and i resubmitted the original draft a few months
ago in response to numerous requests.  a little bit later
and after a round of digest-related messages, i volunteered
to work on a revised draft based upon the feedback received
and which would address the 4 points quoted above.  the
revised draft would mainly nail-down ambiguous/vague wording,
but would not add any new features (except for hash algorithm
selection) nor would it change the digest construction. 
however, the digest-related messages this week indicate that
there is still interest in exploring/improving/breaking digest 
authentication or at least discussing it.  while these discussions
are important, i'd like to restate our original goal:

it is my position that digest authentication is/can be a
'nice' replacement for basic authentication and nothing more.
it is still a password-based system and (on the server side)
suffers from all the same problems of any password system,
but it is 'good-enough' -- where 'good-enough' is defined as:
	better than nothing
	better than what's in telnet and ftp
	better than basic authentication
	not as good as kerberos
	not as good as any client-side private-key scheme.

To summarize: tamper-resistant, but not tamper-proof.

it has become fairly obvious that my current work/travel
schedule will not permit me to give the document much attention
nor to actively participate in the discussion on this mailing
list.  i would therefore like to ask one of the other authors
(or, perhaps, w3) to take over as principal author of the
digest authentication draft.

would someone like to volunteer ??


the suggested change in principal authorship should be read
as just that.  spyglass is committed to digest authentication
in its client and server products and will upgrade its
implementations as the draft/spec evolves.

Received on Thursday, 22 February 1996 07:59:14 UTC