RE: Digest auth: what if client omits qop=?

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

Received on Wednesday, 8 April 1998 17:13:10 UTC