W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1998

Digest auth: what if client omits qop=?

From: Dave Kristol <dmk@research.bell-labs.com>
Date: Wed, 8 Apr 1998 18:04:41 -0400 (EDT)
Message-Id: <199804082204.SAA24636@aleatory.research.bell-labs.com>
To: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/30
I'm just starting to think about implementing the qop= part of
Digest authentication in draft-ietf-http-authentication-01.

It would appear that a client that understands Digest could
willfully or accidentally omit the qop= and response=
attribute/values, which would bypass the checks based on them.
Or, presumably, an intermediate malicious agent could delete

What are the consequences?

1) If the server sends qop="auth" www-Authenticate for its own benefit,
it still has to accept a response with no qop="auth" in Authorization,
to allow for older Digest implementations.

2) A client can send qop="auth" in Authorization only if it got
qop="auth" in WWW-Authenticate.  By sending a cnonce, the client could
gain some assurance that its request arrived unchanged at the server.
But if the qop/response/cnonce attributes got deleted by an agent in
the middle, the server wouldn't know it and would just assume it was
dealing with an older client.

So what, exactly, is the threat that qop="auth" guards against?  This
feature only has value if both the client and server understand and use
qop="auth".  But the "security" of qop="auth" seems no greater than
what's achieved without it.  The same logic would seem to apply to
qop="auth-int", too.

I assume I'm missing something.  What?

Dave Kristol
Received on Wednesday, 8 April 1998 15:08:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:30 UTC