Authentication-Info in Chunked Footer

  [My apologies if you receive this twice - mail problem]

  In response to the recent call for issues, I would like to raise one
  point that was discussed briefly earlier on the list
  <http://www.ics.uci.edu/pub/ietf/http/hypermail/1996q4/0449.html>.

  There is a small but important and (I believe) easily corrected
  conflict between the HTTP 1.1 chunked encoding mechanism and the
  Digest Authentication Scheme (rfc2069).  This request comes from our
  implementation experience at Agranat Systems in adding support for
  2068 (we already support Digest Authentication).

  In the discussion of chunked transfer encoding (section 3.6), 2068
  specifies that:

2068> ...The purpose of the
2068> footer is to provide an efficient way to supply information about an
2068> entity that is generated dynamically; applications MUST NOT send
2068> header fields in the footer which are not explicitly defined as being
2068> appropriate for the footer, such as Content-MD5 or future extensions
2068> to HTTP for digital signatures or other facilities.

  The restriction on what entity headers are appropriate for the
  footer creates a problem for the use of the Authentication-Info
  header specified by 2069.  The Authentication-Info header (rfc2069,
  section 2.1.3) may include a message digest for the response.  The
  purpose of this digest is described as:

2069> The optional digest allows the client to verify that the body of the
2069> response has not been changed en-route.

  Because the response digest is calculated using the shared secret
  known to client and server, and using the nonce provided by the
  server, the client gains a measure of confidence that the response
  is authentic and unmodified (it is not my intent to start a
  discussion here of the relative strengths of different
  authentication schemes).

  RFC 2069 also includes the comment that:

2069> The server would probably only send this when it has the
2069> document and can compute it.  The server would probably not
2069> bother generating this header for CGI output.

  If the Authentication-Info header were to be allowed in the footer
  of a chunk-encoded response, this limitation on the response
  authentication would be removed because the server could calculate
  the digest value for a dynamic response as it is created, and then
  transmit it in the footer.

  I propose that the restriction in RFC 2068 section 3.6:

2068> ; applications MUST NOT send header fields in the footer which
2068> are not explicitly defined as being appropriate for the footer,
2068> such as Content-MD5 or future extensions to HTTP for digital
2068> signatures or other facilities.

  be removed.  In addition, I'd like to point out that it is in
  conflict with the rule (stated in sections 4.5, 5.3, and 6.2):

2068> Unrecognized header fields are treated as entity-header fields.

  Since the footer of a chunked response is defined as
  '*entity-header', then without the explicit restriction it would be
  legal to include any extension header.

  If completely removing the restriction would present a problem, it
  would serve our purposes to just explicitly add the
  Authentication-Info header as defined by RFC 2069 to the list of
  headers permitted in the footer (though that would still leave the
  matter of the conflict above).

  At Agranat Systems, we build a portable server for embedded systems;
  in these systems it is not possible to buffer an entire response in
  order to calculate the digest, but authentication can be very
  important.  While the digest authentication scheme has weaknesses,
  it is substantially better than basic, and is much cheaper to
  implement (in both system and financial terms) than the stronger
  SSL/TLS or SHTTP mechanisms.  This proposed change would, I believe,
  improve both HTTP 1.1 and the Digest Authentication standards.

--
Scott Lawrence             Principal Engineer        <lawrence@agranat.com>
Agranat Systems, Inc.                               http://www.agranat.com/

Received on Monday, 3 March 1997 04:48:26 UTC