INTERNET-DRAFT Scott Lawrence draft-lawrence-digest-request-00.txt Agranat Systems, Inc. Expires: December 1997 July 14, 1997 HTTP/1.1 Message Digest Attribute Request Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 1. Abstract This memo describes a security weakness in the current Proposed Standard for HTTP Digest Access Authentication, and proposes a change to that scheme to correct the deficiency. The problem is that there is no mechanism for either party to indicate a requirement that messages be sent with an authentication digest. draft-lawrence-digest-request-00.txt Page 2/4 2. The Problem The Digest Authentication scheme specifies a mechanism (the 'digest' attribute of the Authentication-Info and Authorization header fields) by which a digest of the message body and selected headers may be transmitted. This provides a valuable means of protecting the message body from modification or replay attacks based on modifying either the message body or the protected headers, while preserving the authentication headers. The mechanism is only valuable, however, if the message recipient can require that the digest attribute is present, but at present the authentication scheme does not provide a means to indicate that the digest is required. There are two difficulties created by this lack, an interoperability problem and a security problem: - The interoperability problem is that if one party (either client or server) wishes to require a digest for a particular HTTP request or response, the other party cannot be told of the requirement. This leaves us with the situation that in order for such a requirement to work that all messages using the Digest Authentication scheme would need to use the message digest, even those for which it would not be required. Because computing the digest is relatively expensive, this is undesirable. - The security problem is that an attacker can remove the attribute, preserving the remainder of the authentication information, and modify the parts of the message the digest was meant to protect. For example, a server implementation might provide for a resource attribute to require that Digest Authentication be used and a message digest supplied in order to submit a form. This would be used to ensure that forms could be defined for which the flimsy protections of Basic authentication are not appropriate. The requirement that the Digest Authentication scheme be used can be communicated to the client by sending a WWW-Authenticate header with 'digest' as the only acceptable scheme, but no mechanism is provided to require the message digest. draft-lawrence-digest-request-00.txt Page 3/4 3. Solution Attributes should be added to the WWW-Authenticate and Authorization headers to indicate that a message digest is required on the subsequent message. The section numbers below refer to [RFC 2069]. Note that this draft does not propose that support for Digest Access Authentication become a requirement for HTTP/1.1 conformance. It does add a requirement to the definition of the scheme if it is supported at all. ================================================================ in section 2.1.1: WWW-Authenticate = "WWW-Authenticate" ":" "Digest" digest-challenge digest-challenge = 1#( realm | [ domain ] | nonce | [ opaque ] |[ stale ] | [ algorithm ] | [ digest-required ] ) ... digest-required = "digest-required" ... digest-required A flag, indicating that any request for the resource to which this response applies must include the 'digest' attribute in its Authorization header. ================================================================ in section 2.1.2: Authorization = "Authorization" ":" "Digest" digest-response digest-response = 1#( username | realm | nonce | digest-uri | response | [ digest ] | [ algorithm ] | opaque | digest-required ) ... digest-required = "digest-required" ... digest-required A flag, indicating that the response to this request must include the 'digest' attribute in its Authentication-Info header. ================================================================ in section 3.3, paragraph 4: The discussion of attacks based on removing the "digest" field of the Authentication-Info header can be removed; the remainder is still correct. draft-lawrence-digest-request-00.txt Page 4/4 4. Security Considerations This entire draft is about security considerations. 5. Author's Addresses Scott Lawrence Agranat Systems, Inc. 1345 Main St. Waltham, MA 02154 Phone: +1-617-893-7868 Fax: +1-617-893-5740 Email: lawrence@agranat.com 6. References [RFC 2068] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T. Berners-Lee. "Hypertext Transfer Protocol -- HTTP/1.1." RFC 2068, U.C. Irvine, DEC, MIT/LCS, January 1997. [RFC 2069] J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen, E. Sink, and L. Stewart. "An Extension to HTTP : Digest Access Authentication" RFC 2069, Northwestern University, CERN, Spyglass Inc., Microsoft Corp., Netscape Communications Corp., Spyglass Inc., Open Market Inc., January 1997.