RE: Digest auth: what if client omits qop=?
Paul Leach (paulle@microsoft.com)
Wed, 8 Apr 1998 17:00:43 -0700
> -----Original Message-----
> From: Dave Kristol [mailto:dmk@research.bell-labs.com]
> Sent: Wednesday, April 08, 1998 3:05 PM
> To: http-wg@cuckoo.hpl.hp.com
> Subject: Digest auth: what if client omits qop=?
>
>
> 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
> them.
>
> 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.
No -- it will allow a response with no qop=auth or qop=auth-int only if that
meets its security policy.
>
> 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.
In which case, when the client eventually checks the Auth-info header's
"response=" directive, the check will fail.
>
> 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?
Either or both sides can insist on it. Obviously, if they allow a weaker
authentication menchanism, they can't guarantee the stronger security.
Paul