Re: 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?

If the response attribute is missing then authentication must fail.
After all, this is "core" attribute (the rest are just to help
understand how the "response" was calculated), akin to the encoded
user-pass for Basic.

If qop is removed, then the server will calculate the response attribute
differently than the client did, and authentication will fail too.

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

Yup.

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

No. RFC-2069 also has the "response" attribute. So if it's missing, the
server must assume a MIM removed it and disallow access.

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

Hmm, I suppose a MIM could remove the qop attribute from the challenge,
thereby forcing rfc-2069 behaviour. I'll leave this to the crypto
experts to discuss.


  Cheers,

  Ronald

Received on Wednesday, 8 April 1998 17:55:46 UTC