- From: Dave Kristol <dmk@research.bell-labs.com>
- Date: Mon, 23 Mar 1998 16:45:41 -0500 (EST)
- To: jg@w3.org, masinter@parc.xerox.com
- Cc: http-wg@cuckoo.hpl.hp.com
Here are some comments on draft-ietf-http-authentication-01.
Dave Kristol
======================
Substantive stuff:
General
(Formatting) On a number of pages (e.g., 5,7,9), the text runs
into the footer.
The spec. is incomplete in its description of whether auth-params
are case-sensitive. For example, "realm" and "stale" are mentioned
explicitly. I think it would be simpler to say the
attribute/parameter/directive (see below) names are
case-insensitive, but that the values may or may not be
case-sensitive.
What should a client do if it receives unrecognized attributes?
What should a server do if it receives unrecognized attributes?
1.2 Access Authentication Framework
credentials = basic-credentials | auth-scheme #auth-param
I think this should now read
credentials = basic-credentials | digest-credentials
| auth-scheme #auth-param
The term "protection space" gets used without a definition (here),
but the spec. describes how a client can reuse credentials for such
a protection space. I think we should say that the description of
any auth-scheme must describe the rules for deciding when two
objects are in the same protection space. In particular, a client
must be able to tell, so it knows whether or not to send credentials
unprompted.
Sect. 3.2.1, The WWW-Authenticate Response Header
[domain attribute]
If this keyword is omitted or empty, the client should assume that
the domain consists of all URIs on the responding server.
This behavior is different from Basic. If we want Digest to be
a more or less drop-in replacement, shouldn't the default
behavior mimic Basic?
Furthermore, this paragraph constitutes the equivalent of a
description of the Digest protection space, but it never calls
it such. It would be helpful to be more explicit. (There's
additional related information in section 3.3.)
Sect. 3.2.2, The Authorization Request Header
[cnonce attribute]
RFC 2069-compliant implementations might break upon receiving this
new, previously unknown attribute.
[nonce-count]
The grammar for nc-value says
nc-value = 8LHEX
but the examples all show four-character nc= values, as in this
section. The examples ought to be compliant. :-)
Also, why have such a restrictive syntax? Why not 1*LHEX?
[description of calculations]
If the "qop" value is "auth":
Shouldn't this read
If the "qop" value is "auth" or "auth-int":
Sect. 3.2.3, The Authentication-Info Header
What should a client do if the rspauth=response-digest information
is wrong?
Isn't there the risk that an intervening proxy could change the
status code?
... Authorization header for the request, A2 is
A2 = Status-Code ":" digest-uri-value
and if "qop=auth-int", then A2 is
A2 = Status-Code ":" digest-uri-value ":" H(entity-body)
Typographical nits, etc.:
Abstract
"This document also provides ..."
==== -> delete
"... other new elements have been added - for compatibility, ..."
change to
"... other new elements have been added. For compatibility, ..."
Sect. 1.1, Reliance on...
"It uses using the extended..."
===== -> delete
Sect. 2, Basic Authentication Scheme
The "basic" authentication ...
======= -> Basic
There are no optional [Basic] authentication parameters.
======= -> add
credentials = basic-credentials
^-- delete extra space
challenge = "Basic" realm
A proxy may respond with the same challenge using the
======== -> change to: an analogous
Proxy-Authenticate header field.
Sect. 3.1.1 Purpose
This document provides the specification for such a scheme, which
change to: "a different scheme that" <- ====================
does not send the password in cleartext. It is referred to as
"Digest Access Authentication".
Sect. 3.2.1, The WWW-Authenticate Response Header
digest-challenge = 1#( realm | [ domain ] | nonce |
[ opaque ] |[ stale ] | [ algorithm ] |
[ qop-options ] )
=== -> indent correctly
The meanings of the values of the parameters used above are as follows:
These thingies get referred to variously (and inconsistently) as
"parameters", "directives", and "attributes". It would be nice
if one term were chosen and used consistently.
[algorithm attribute]
... for the difference in usage, see the description .
^-- delete
Sect. 3.2.2, The Authorization Request Header
credentials = "Digest" digest-response
should be
digest-credentials = "Digest" digest-response
see below for the defintions for A1 and A2.
^-- See ========== -> definitions
This stuff should move after the description of A1:
where
passwd = < user's password >
This example needs to quote realm-value:
username="Mufasa", realm=myhost@testrealm.com
should be
username="Mufasa", realm="myhost@testrealm.com"
The description of white space in the digest is repetitive and
excessive (IMO). (And, I suspect, people will *still* get it
wrong, even with the belabored point.)
Sect. 3.2.3, The Authentication-Info Header
[message-qop attribute]
qop
=== -> change to: message-qop
Indicates the "quality of protection" options applied to the
^ -- delete
response by the server. The value "auth" indicates authentication;
header, except that if "qop=auth" or is not specified in the
^-- insert: qop
Authorization header for the request, A2 is
Sect. 3.3, Digest Operation
A client may remember the username, password and nonce values, so
that future requests within the specified <domain> may include
==================
change to: domain specified by the domain attribute
the Authorization header preemptively.
As with the basic scheme, proxies must be completely transparent
===== -> Basic
Sect. 3.6, Proxy-Authentication and Proxy-Authorization
... sections 10.30 and 10.31 of the HTTP/1.1 specification [2] and
===== =====
should be: 14.33 14.34
authentication, the proxy/server must issue the "HTTP/1.1 401
Unauthorized " response with a "Proxy-Authenticate" header.
^-- delete
Sect. 3.5, Example
... same as that for the WWW-Authenticate header as defined above in
section 2.1.
=== -> should be: 3.2.1
The client/proxy must then re-issue the request with a Proxy-
Authorization header, with attributes as specified for the Authorization
header in section TBD above.
=== -> should be: 3.2.2
Sect. 4.1, Authentication of Clients using Basic Authentication
The first three paragraphs are a bit repetitions. Here's a
revision:
Basic authentication is not a secure method of user
authentication. It essentially transmits the user's password as
cleartext across the physical network. Therefore it SHOULD NOT be
used (without enhancements) to protect sensitive or valuable
information. Digest authentication fixes this flaw.
Basic authentication does not protect the entity, which is
transmitted as cleartext across the physical network. Digest
authentication can reduce this vulnerability.
HTTP does not preclude additional authentication schemes and
encryption mechanisms from being employed to increase security, nor
does it preclude the addition of enhancements (such as schemes to
use one-time passwords) to the authentication schemes described
here.
Sect. 4.2, Authentication of Clients using Digest Authentication
authentication is both useful and appropriate (any service in
change to: ==== -> e. (Any
present use that uses Basic should be switched to Digest as soon
as practical).
== -> .)
Sect. 4.5, Replay Attacks
use of integrity protection most metadata in header fields is
^-- delete
Sect. 4.6, Weakness Created by Multiple Authentication Schemes
agent should choose to use the first challenge it understands and
^-- delete
only as good as that of the of the weakest of the authentication
====== -> delete
Sect. 4.8, Man in the Middle
The countermeasure against this attack is to for clients to be
=== -> delete
Sect. 4.10, Precomputed dictionary attacks
The countermeasure against this attack is to for clients to be
=== -> delete
Sect. 4.11, Batch brute force attacks
The countermeasure against this attack is to for clients to be
=== -> delete
Sect. 4.14, Summary
nonces or digests to eliminate the possibility of replay. Others may
add: be ---^
Sect. 7, Authors' Addresses
Scott D. Lawrence
Agranat Systems, Inc.
1345 Main St.
Waltham, MA 02154, USA
EMail: stewart@OpenMarket.com
====================== -> lawrence@agranat.com
Received on Monday, 23 March 1998 13:55:50 UTC