Authentication-Info in Chunked Footer
Scott Lawrence (lawrence@agranat.com)
Mon, 03 Mar 1997 07:35:22 -0500
[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/