Re: I-D on RFC 2069 issue: digest request

Some comments on the draft below:

1.  It is factually inaccurate to say that this proposed change
addresses either an interoperability problem or a security problem.
The change may have virtues (like saving bandwidth) but it has no
effect on security.  This has been re-iterated here many times, but I
will do it once more: Under the current draft, if the recipient
requires the message body be accompanied by a digest, it must reject
any message without the digest and send an appropriate error message.
Some bandwidth has been wasted in sending a message that was rejected,
but security has not been comprimised.

2. Nevertheless, the suggested change is probably a good one, as it
does does simplify the issue of sender/receiver negotiation on whether
a digest is required.  Rejecting a message is not a very efficient method
of negotiation.  

3. Any change along the lines proposed should make clear (as the ID
below does not) that for a client or server to be compliant with
the specification it is not necessary to be capable of providing
digests for message bodies.

John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu



On Tue, 22 Jul 1997, Scott Lawrence wrote:

> 
>   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 Thursday, 24 July 1997 08:23:53 UTC