W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1998

(Nit) Comments on draft-ietf-http-authentication-02.txt

From: Dave Kristol <dmk@research.bell-labs.com>
Date: Thu, 20 Aug 1998 13:01:15 -0400 (EDT)
Message-Id: <199808201701.NAA17132@aleatory.research.bell-labs.com>
To: http-wg@hplb.hpl.hp.com
I have some comments about the latest draft of HTTP Authentication:
Basic and Digest Access Authentication.  This message contains just
editorial comments.  Some of the problems seem to arise from the MS
Word to .txt conversion.  Some further messages will (individually)
address substantive stuff.

Dave Kristol
-----------------

1) Authors:
    J. Hostetler, Spyglass, Inc.
should be AbiSource, Inc.

2) Sect. 2.

    If a client wishes to send the same userid and password to a proxy, it
    would use the Proxy-Authorization header field. See section 4 for
    security considerations associated with Basic authentication.

To my brain, this reads funny, particularly in context, where "the
same" seems to refer to the preceding paragraph.  I suggest new wording:

    When it sends a request to a proxy, a client may reuse a userid and
    password in the Proxy-Authorization header field without receiving
    another challenge from the proxy server. See section 4 for security
    considerations associated with Basic authentication.

3) Sect. 3.1.1
                                                        This document
    provides the specification for such a scheme, which does not send the
    password in cleartext.

Reword to:
                                                        This document
    provides the specification for a scheme that does not send the
    password in cleartext.

4) Sect. 3.1.2
    value. A valid response contains a checksum (by default the MD5
    					    insert ',' ----^

5) Sect. 3.2.1 (under "domain")
  to canonical root URL (see section 1.2 above) of the server being
    ^-- add "the"

6) Sect. 3.2.1 (under "algorithm")

  and a checksum. If this is not present it is assumed to be "MD5". If
  the algorithm is not understood, the challenge should be ignored (and
  a different one used, if there is more than one). In this document
  the string obtained by applying the digest algorithm to the data

I think "In this document" should begin a new paragraph.

6) Sect. 3.2.1 (under "algorithm")
  intended to allow efficient 3rd party authentication servers;
  for the difference in usage, see the description .

						  ^
There's an extra space here; was there a reference?

6) Sect. 3.2.1 (under "qop-options")
  this choice. Unrecognized options MUST be ignored.
  			    ------- -> change to qop-options

7) Sect. 3.2.3
    nonce value to be used for a limited time to permit request
    pipelining. Use of

This (indented) paragraph just trails off....

7) Sect. 3.2.3 (just before 3.3)
     The Authentication-Info header is allowed in the trailer of an
    ^-- extra space at beginning of sentence.

8) Sect. 4.1
    essentially cleartext transmission of the user’s password over the
			    non-ASCII character --^

9) Sect. 4.2
    directive values (see section 0) are  protected.  Most header
    			  --------- -> bad reference?


    authentication is both useful and appropriate (any service in
    present use that uses Basic should be switched to Digest as soon
    as practical).
Change to
    authentication is both useful and appropriate.  (Any service in
    present use that uses Basic should be switched to Digest as soon
    as practical.)

10) Sect. 4.3
    The Digest scheme uses a server-specified nonce to seed the generation
    of the response-digest value (as specified in section 0).  As shown in
    						  --------- -> missing ref.
    the example in 0, the server is free to construct the nonce such that it
                   - -> missing ref.

11) Sect. 4.4 (last sentence)
    limited by the servers choice of nonce.
    		   ------- -> server's

12) Sect. 4.5
    on the use of  the integrity protection of qop=auth-int, an
    		  ^-- extra space

13) Sect. 4.7
    This attack can be mitigated by checking the password against a
    dictionary when a user tries to change it and disallowing passwords that
    are in the dictionary.

I think this wording is unclear; it doesn't say who does the checking
and what "it" is.  Suggestion:

    A server can mitigate the risk of this attack.  When a user asks
    the server to change a password, the server can disallow passwords
    that are in the dictionary.

14) Sect. 4.9
    The countermeasure against this attack is to for clients to be
    					      -- -> delete

15) Sect. 4.11
    very quickly – reports exist of searching all passwords with six or
    		 ^-- non-ASCII character
Received on Thursday, 20 August 1998 10:04:21 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:20 EDT