W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

I-D on RFC 2069 issue: digest request

From: Scott Lawrence <lawrence@agranat.com>
Date: Tue, 22 Jul 1997 16:00:53 -0400
Message-Id: <199707222000.QAA18820@devnix.agranat.com>
To: HTTP Working Group List <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>

  A New Internet-Draft is available from the on-line Internet-Drafts
  directories.

         Title     : HTTP/1.1 Message Digest Attribute Request
         Author(s) : S. Lawrence
         Filename  : draft-lawrence-digest-request-00.txt
         Pages     : 3
         Date      : 07/14/1997

  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.

  ================

  Since as I understand it, the plan is to issue a new document for
  HTTP Authentication which would supersede RFC 2069, I would like to
  get this considered as an improvement to Digest Access
  Authentication as a part of that.  This is a problem with
  interoperability found as a result of implementation experience, and
  as such, I believe, proper for consideration at this point in the
  process.

  Since it isn't very long, I've attached it below.

--
Scott Lawrence           EmWeb Embedded Server       <lawrence@agranat.com>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/


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.
Received on Tuesday, 22 July 1997 13:07:31 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:49 EDT