- From: (unknown charset) Dave Kristol <dmk@research.bell-labs.com>
- Date: Thu, 20 Aug 1998 13:01:15 -0400 (EDT)
- To: (unknown charset) 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 UTC