Re: Where we stand on Digest Authentication

The Area Directors have asked that we make sure that Digest
Authentication has gotten a thorough review from the "right"
community.  I've taken this to mean those who have some claim to being
experts in security issues.

Previously, I managed to get Allan Schiffman to give the previous
draft of Digest Authentication a review. It was his and Rescorla's
review that led to the improvements we asked for:

>  * 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.

The problem you're having is in coming to agreement on the appropriate
wording for point 2 ("describe in detail construction of nonces").

By most accounts, Digest Authentication is likely succeptable to a
variety of concerted attacks. However, it offers a simple efficient
way of getting better security than Basic Authentication, at least
from the point of view of not revealing passwords to packet-sniffing
or logging TCP bridges, etc.

Given the limited security that Digest Authentication offers, adding
additional requirements on implementations seems to be unreasonable.

I believe it will be necessary to obtain additional explicit opinions
on the final draft of Digest Authentication before it will be
accepted. I base this belief on an interchange last week with the area

My summary of the status was:

I said that:
>The basic feedback from the working group on digest authentication is:
>it's not perfect, but it's better than basic, and we have two
>independent interoperable implementations. 

And the concern was:

> My concern is basically that I'm not sure the WG is the locus of the right
> expertise to be able to decide on this (if you were to run quiz on the
> number of people who actually understood the issue, how many would you have
> pass?) and that I hate to see the same work done twice.

to which we were allowed to proceed based on the following assurance:

> I asked WTS to review digest authentication, and got Allan Schiffman
> to spend 3-4 hours reviewing Digest Authentication and, with Rescorla,
> to propose some changes that they thought would improve it. In the
> cases where the changes weren't accepted, the "security
> considerations" section of the draft will show the limitations of
> Digest Authentication. I believe that actually at this point the
> proposal *has* recieved sufficient review.

That is, Digest Authentication will not be accepted as standards track
if there are not interoperable implementations, or if the draft has
only been reviewed by two people who understand the issues.

If we push out a draft that is no longer compatible with current
interoperable implementations or requires additional review because
the mechanisms have changed beyond those changes suggested or accepted
by the reviewers, we'll reset the clock. I don't think that would be
consistent with the motivation for engaging in Digest Authentication
work here (rather than to WTS.)

My advice is to leave "nonce incrementing" out on tactical grounds.

Received on Tuesday, 27 February 1996 08:59:22 UTC