- From: John Franks <john@math.nwu.edu>
- Date: Mon, 22 Dec 1997 09:53:02 -0600 (CST)
- To: Dave Kristol <dmk@bell-labs.com>
- cc: Scott Lawrence <lawrence@agranat.com>, paulle@microsoft.com, ietf-http-wg@w3.org
On Mon, 22 Dec 1997, Dave Kristol wrote:
> John Franks wrote:
> >
> > To the Authentication-info header we add a "digested-headers"
> > field with the form
> >
> > dheaders="status_code:entity_length:date:L-M-date:expires"
> >
> > but we add the proviso that a server MAY omit any or all of the
> > dates. Here are the advantages I see:
> >
> > 1. Proxies may now muck with date headers, content length, or status
> > code as much as they wish with no ill effect on digest. This is the
> > most important plus since making sure all proxies don't change or even
> > canonicalize headers was looking hopeless.
> >
> > 2. This provides the security of digested status code and when
> > necessary the three dates. Clockless servers or reponses with no
> > expires or L-M-date are dealt with cleanly and insulated from
> > rogue proxies. Servers can decide (on a per response basis if they
> > wish) whether including the dates is worthwhile.
> >
> > Just to clean things up a little I would then change the definition
> > of entity-digest to
> >
> > -----------------------------------------------------------
> > entity-digest =
> > <"> KD (H(A1), unquoted nonce-value ":"
> > transaction-info ":" H(entity-body)) <">
> > ; format is <"> *LHEX <">
> >
> > transaction-info =
> > H(
> > Method ":"
> > digest-uri-value ":"
> > media-type ":" ; Content-Type, see section 3.7 of [2]
> > content-coding ":" ; Content-Encoding, see 3.5 of [2]
> > *DIGIT ":" ; HTTP response status code
> > *DIGIT ":" ; entity-length, see ??
> > date ":" ; contents of origin HTTP date header
> > last-modified ":" ; last modified date, see 10.25 of [2]
> > expires ; expiration date; see 10.19 of [2]
> > )
> >
> > date = rfc1123-date ; see section 3.3.1 of[2]
> > last-modified = rfc1123-date ; see section 3.3.1 of [2]
> > expires = rfc1123-date
> > -----------------------------------------------------------
> >
> > Then the last five parts of the pre-digested transaction-info is precisely
> > the content of dheaders.
>
> I like the stated idea, but I don't see it reflected in the
> specification fragment above. What am I missing? The date-related
> pieces are still embedded in transaction-info, which is part of
> entity-digest. So it hasn't been separated out, and is therefore
> subject to the vagaries of proxies.
The entity-digest is a hash of the things above. It occurs (optionally)
as a field in the Authorization request header and in the optional
Authentication-info response header. Nowhere else. Surely proxies
don't change either of those headers.
> OTOH, if it's made exclusively part
> of a separate attribute, dheaders, then there's the possibility of its
> being stripped by a MITM.
>
It would, of course, be illegal to have the digest field without the
corresponding dheaders field, so stripping just dheaders wouldn't
work. Preventing the stripping of both digest and dheaders is done by
the digest-required parameter in the request Authorization header.
Here is a quote from the specification:
"If the value of the digest-required parameter is "true", the
response to this request MUST either include the "digest" field
in its Authentication-Info header or the response should be an
error message indicating the server is unable or unwilling to
supply this field. In the latter case the requested entity MUST
not be returned as part of the response."
If we decide on dheaders then this would change to "MUST either
include the "digest" field and the "dheaders" field or..."
John Franks
john@math.nwu.edu
Received on Monday, 22 December 1997 10:53:42 UTC