Proxies and Digest-MessageDigest

Here's a proposed fixed description of Digest-MessageDigest to account 
for proxies.

Bascially, the nonce, username, realm, and password used to digest entities
in the D-MD have to be those of the origin-server, even when talking to a proxy
(where different N, U, R, P might have been used in the 
Proxy-Authorization header
of the transaction.)

If it turns out that general and response headers really can't be 
digested, even
when proxy header mangling isn't an issue, then remove the 
<header-digest> part.
If even entity headers can't be digested, then remove the <entity-digest> part.
(But I'm still not convinced that they can't be, at least if 
authentication is desired.)
But <message-digest> needs these changes to account for proxies, and 
<message-digest>
needs <nonce> and <date>.

(I changed the grammar notation, in both this and the previous proxy 
fixes proposals,
to be parallel to what's in the HTTP spec, so that a simple syntactic 
transform will make
it the same.)

   When authorization succeeds, the Server may optionally provide the
   a Digest-MessageDigest header, whose format is as follows:

      <digest-messagedisgest> := Digest-MessageDigest:
              message="<message-digest>",
              entity="<entity-digest>",
              header="<header-digest>",
              nextnonce="<nextnonce>",
              entity-nonce="<nonce>",
              entity-date="<date>"

   The Digest-MessageDigest header indicates that the server
   wants to communicate some information regarding the
   successful authentication (such as a message digest or a
   new nonce to be used for the next transaction). The parameters
   of this header can occur in any order.

   <message-digest> is a keyed digest of the entity in the message.
   It is computed by origin-servers and checked by clients in the same way
   as in the Authorization header, with N being the <nonce> in this header,
   and the username, realm, and password (U, R, P) in A1 being those
   appropriate for the origin-server, and not those for any 
intermediate proxies.
   Proxies do not compute <message-digest>; they get its value by
   caching the <message-digest> in the Digest-MessageDigest header
   of the message containing this entity when it was originally received
   by the proxy. Similarly, they get the value of <nonce> by caching
   the <nonce> in the Digest-MessageDigest header of the message
   containing this entity when it was originally received by the proxy.

   The <message-digest> allows the receiver to verify that an entity-body
   in the message has not been changed en-route, and that it came from
   a sender that shares knowledge of a password with the receiver.
   It does not verify that the entity-body is associated with any 
particular URI.

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

   <entity-digest> is a keyed digest over the entity, including entity
   headers. It is computed by origin-servers and checked by clients as:

      <entity-digest> := H( H(A1) + ":" + <nonce> + ":" + H(A2) + ":" +
        h1 + h2 + ... + h(n) + ":" + H(<entity-body>) + ":" + <date>)

   where A1, N, A2 and <entity-body> are the same as in the algorithms
   given above for the Authorization header, <date> is the value of the
   date parameter (see below), and h1 to h(n) are the entity headers in
   the message, in the order sent by the originator (origin-server or client).
   Proxies do not compute <entity-digest>; they get its value by
   caching the <entity-digest> in the Digest-MessageDigest header
   of the message containing this entity when it was originally received
   by the proxy.

   Each h(i) is digested exactly as sent by the originator: with case and LWS
   preserved, and including the header name, the colon, and all text up to
   and including the trailing CRLF. Similarly to the <message-digest>, this
   allows the receiver to verify that the entity and its headers have not
   been changed en-route, and in addition, to verify that the entity-body
   is associated with a specified URI, and to verify the freshness of the
   entity-body. There is no need to send <message-digest> if
   <entity-digest> is sent.

   Using <entity-digest> a client can know the time that the origin server
   sent the response, thus preventing proxies from claiming responses
   are newer than they actually are.  In particular, an <entity-digest> in
   the response to a conditional GET should always contain a reasonably
   recent date.

   <header-digest> is a keyed digest over all the information in a
   message other than the header containing the <header-digest> itself.
   It is computed by servers (including proxies) and checked
   by clients as:

      <header-digest> := H( H(A1) + ":" + N + ":" + H(A2) + ":" +
         h1 + h2 + ... + h(n) + ":" + <entity-digest> + ":" + D)

   where A1, A2, and <entity-digest> are the same as
   above for <entity-digest>, except that A1 contains the
   username, password, and realm (U, R, P) appropriate for
   the server generating this response, which is not the origin-server
   in the case of a proxy. N is the value of <nonce> from the
   credentials in the Authorization or Proxy-Authorization header
   of the request to which the message containing this header is a
   response. D is the value of the Date header
   in the message containing this header if the response is directly
   from an origin-server, and <date> if the response is from a proxy.
   The h1 to hn are the general and response headers (other
   than the one containing the <header-digest>) in the message; they are
   included in the digest calculation in the same manner as the h(i) of
   the <entity-digest>.
   Similarly to the <message-digest>, this allows the client to verify
   that the message has not been changed en-route. The <entity-digest>
   verifies that the entity came from an sender that shares knowledge of
   a password with the receiver; <header-digest> verifies that the response
   came from a server that shares knowledge of a (usually different in the
   case of a proxy) password with the receiver.

   <nextnonce> is the nonce the server wishes the client to use for
   the next authentication response.  All fields are optional.  In
   particular the server may send the Digest-MessageDigest header
   with only the nextnonce=<nextnonce> field as a means of
   implementing one-time nonces.  If the nextnonce field is present
   the client is strongly encouraged to use it for the next
   WWW-Authenticate header.  Failure of the client to do so may
   result in a request to re-authenticate from the server with
   the "stale=TRUE."


   entity-date="<date>" gives the date/time that the entity was sent by 
the origin-server;
   proxies must include it when <entity-digest> get this value from the 
Date header in the
   orignal message containing the entity. The <date> is in HTTP-Date format
   as defined in the HTTP specification (section 3.3.1 of [HTTP]). It is
   required in responses when <entity-digest> is present.

   entity-nonce="<nonce>" gives the nonce N to use to calculate the 
<message-digest> or
   <entity-digest> and is required when either of those two parameters
   is present. Origin-servers generate new <nonce> values on demand; 
proxies get
   the <nonce> value from the Digest-MessageDigest header
   of the message in which the entity was originally received.
   The origin-server chooses a <nonce> to use in computing <message-digest> or
   <entity-digest> and includes it in the Digest-MessageDigest header.

----------
] From: John Franks  <john@math.nwu.edu>
] To: "Roy T. Fielding"  <fielding@avron.ICS.UCI.EDU>
] Cc: Paul Leach;  <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>;  
<hallam@w3.org>
] Subject: Digesting headers
] Date: Thursday, February 29, 1996 7:56AM
]
] On Thu, 29 Feb 1996, Roy T. Fielding wrote:
]
] > >    <header-digest> is a keyed digest over the entity headers (as 
defined by
] > >    HTTP -- e.g., as of HTTP/1.1, Content-Type and other Content-* 
headers,
] > >    Last-Modified, Expires, etc.) It is computed as
] >
] > That won't work.  HTTP header fields of the same name can be appended
] > together, and header fields of different names can be reordered, by
] > any HTTP recipient without changing the semantics of the message.
] > The only way to digest the header fields is to first encapsulate them
] > using something like WRAPPED or MOSS.
] >
] >
]
] Ok, digests of headers will have to wait for the WRAPPED method.
]
] What about the date header being part of the data digested for the
] message-digest.  Is it unsafe to assume that proxies will not mangle
] the origin-server Date: header?
]
]
] John Franks 	Dept of Math. Northwestern University
] 		john@math.nwu.edu
]
]

Received on Thursday, 29 February 1996 11:42:02 UTC