4/14/98 http-authentication-01 comments

The specification provides this suggestion:

3.2.1 The WWW-Authenticate Response Header

  The contents of the nonce are implementation dependent. The quality
  of the implementation depends on a good choice. A nonce might, for
  example, be constructed as the base 64 encoding of

      time-stamp H(time-stamp ":" ETag ":" private-key)
  where time-stamp is a server-generated time or other non-repeating
  value, ETag is the value of the HTTP ETag header associated with the
  requested entity, and private-key is data known only to the server.
  With a nonce of this form a server would recalculate the hash portion
  after receiving the client authentication header and reject the
  request if it did not match the nonce from that header or if the
  time-stamp value is not recent enough. In this way the server can
  limit the time of the nonce's validity. The inclusion of the ETag
  prevents a replay request for an updated version of the resource.
  (Note: including the IP address of the client in the nonce would
  appear to offer the server the ability to limit the reuse of the
  nonce to the same client that originally got it. However, that would
  break proxy farms, where requests from a single user often go through
  different proxies in the farm. Also, IP address spoofing is not that
  hard.)

I think this example for nonce is a poor one, for the following reasons:

1) The nonce would not be reusable for other entities, because it's
tied to a particular URI by Etag.

2) Etag may be difficult or impossible to calculate.  For example, in
my server implementation, access control is done based on the raw URL,
before a URL gets mapped to a file.  When I discover that
authentication has failed, my server hasn't done the URL -> file
mapping, and it would be difficult to calculate Etag when generating
WWW-Authenticate.

In other contexts, such as dynamically generated content, there may not
*be* an Etag.

Dave Kristol

Received on Tuesday, 14 April 1998 12:16:40 UTC