domain attribute in digest auth

I have some points concerning draft-ietf-http-authentication-03.

1) Section 3.2.1:

    domain
      A quoted, space-separated list of URIs, as specified in RFC XURI [7],
      that define the protection space.  If a URI is an abs_path, it is
      relative to the canonical root URL (see section 1.2 above) of the
      server being accessed. An absoluteURI in this list may refer to a
      different server than the one being accessed. The client can use this
      list to determine the set of URIs for which the same authentication
      information may be sent: any URI that has a URI in this list as a
      prefix (after both have been made absolute) may be assumed to be in
      the same protection space. If this directive is omitted or its value
      is empty, the client should assume that the protection space consists
->    of all URIs on the responding server. This directive is not
->    meaningful in Proxy-Authenticate headers, for which the protection
->    space is always the entire proxy; if present it should be ignored.

   I disagree with the last part. The domain directive could be used
   usefully to share auth info between various proxies. So, while the
   abs_path part of the URI is indeed not meaningful, I claim the host:port
   part is. Therefore I suggest changing the last three lines to:

      of all URIs on the responding server.

      Since on proxies the protection space is always the entire proxy,
      the abs_path part of the URIs is not meaningful in
      Proxy-Authenticate headers and SHOULD be ignored.

   (I think that should be normative SHOULD?)


2) Same text:

    domain
      A quoted, space-separated list of URIs, as specified in RFC XURI [7],
      that define the protection space.  If a URI is an abs_path, it is
      relative to the canonical root URL (see section 1.2 above) of the
      server being accessed. An absoluteURI in this list may refer to a
      different server than the one being accessed. The client can use this
      list to determine the set of URIs for which the same authentication
      information may be sent: any URI that has a URI in this list as a
      prefix (after both have been made absolute) may be assumed to be in
->    the same protection space. If this directive is omitted or its value
->    is empty, the client should assume that the protection space consists
->    of all URIs on the responding server. This directive is not
      meaningful in Proxy-Authenticate headers, for which the protection
      space is always the entire proxy; if present it should be ignored.

   Current practise for Basic auth and Cookies is that all URIs with the
   same prefix as the requested URI are in the same protection space. I
   think this is more intuitive and more closely follows the way sites are
   set up, and therefore should be adopted here too. If somebody wants to
   say that the whole server is in the same space they can always use
   domain="/". So, borrowing from the wording in the cookie spec I propose
   changing the marked lines to read:

      the same protection space. If this directive is omitted or its value
      is empty it defaults to the request URI up to and including the
      right-most /. This directive is not

   Merging the above two changes would result in:

    domain
      A quoted, space-separated list of URIs, as specified in RFC XURI [7],
      that define the protection space.  If a URI is an abs_path, it is
      relative to the canonical root URL (see section 1.2 above) of the
      server being accessed. An absoluteURI in this list may refer to a
      different server than the one being accessed. The client can use this
      list to determine the set of URIs for which the same authentication
      information may be sent: any URI that has a URI in this list as a
      prefix (after both have been made absolute) may be assumed to be in
      the same protection space. If this directive is omitted or its value
      is empty it defaults to the request URI up to and including the
      right-most /.

      Since on proxies the protection space is always the entire proxy,
      the abs_path part of the URIs is not meaningful in
      Proxy-Authenticate headers and SHOULD be ignored.


3) While a careful reading of the spec does imply the following, it might
   not hurt to add something like it (marked by new>) to the description
   of the nonce-count in section 3.2.2:

    nonce-count
      This MUST be specified if a qop directive is sent (see above), and
      MUST NOT be specified if the server did not send a qop directive in
      the WWW-Authenticate header field.  The nc-value is the hexadecimal
      count of the number of requests (including the current request) that
      the client has sent with the nonce value in this request.  For
      example, in the first request sent in response to a given nonce
      value, the client sends "nc=00000001".  The purpose of this directive
      is to allow the server to detect request replays by maintaining its
      own copy of this count - if the same nc-value is seen twice, then the
      request is a replay.   See the description below of the construction
      of the request-digest value.

new>  Servers which check the nonce-count must be sure to increment their
new>  own copy of the count each time an Authorization header is received
new>  from the client, irrespective of the final outcome of the request
new>  (e.g. even if the request-URI doesn't require authentication, 
new>  requires different authentication, or doesn't exist).



  Cheers,

  Ronald

Received on Monday, 28 September 1998 13:18:45 UTC