RE: comments on draft-ietf-http-authentication-01.txt

> ----------
> From: 	Dave Kristol[SMTP:dmk@research.bell-labs.com]
> Sent: 	Monday, March 23, 1998 1:45 PM
> To: 	jg@w3.org; masinter@parc.xerox.com
> Cc: 	http-wg@cuckoo.hpl.hp.com
> Subject: 	comments on draft-ietf-http-authentication-01.txt
> 
> 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?
> 
Ignore them. I thought that was the "HTTP way" and needn't be expliclty
stated.

>     What should a server do if it receives unrecognized attributes?
> 
Ditto.

> 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
> 
Fine with me.

>     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.
> 
Why does it need to tell? If it's wrong, by either sending incorrect ones or
not sending any, it'll get a 401 to tell it what to do. As far as I can see,
for Digest it's only an optimization. (For Basic, you don't want to send
your credentials to the wrong place...)

> 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?
> 
As you point out below, there are implementations. As I point out above, it
shouldn't matter. If I were writing a browser, I'd guess that I should reuse
the key obtained from a previous 401/WWW-Auth until I left the server --
that way, I minimize the extra roundtrips.

In any case, this behavior is backwards compatible with Basic.

Net-net: no compelling reason to change.

> 	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.)
> 
I'm not sure it is. 

> Sect. 3.2.2, The Authorization Request Header
>     [cnonce attribute]
>     RFC 2069-compliant implementations might break upon receiving this
>     new, previously unknown attribute.
> 
Then they would be broken. Unknown directives are supposed to be ignored.

>     [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. :-)
> 
Sure.

>     Also, why have such a restrictive syntax?  Why not 1*LHEX?
> 
It was 4LHEX, and I didn't think that 16 bit counter was enough, so I bumped
it to 32; 1*LHEX is OK by me.

>     [description of calculations]
>     If the "qop" value is "auth":
> 	Shouldn't this read
> 	    If the "qop" value is "auth" or "auth-int":
> 
Yes.

> Sect. 3.2.3, The Authentication-Info Header
>     What should a client do if the rspauth=response-digest information
>     is wrong?
> 
Not accept the response.
>        
>     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)
> 
Well, the status code isn't a header, but there's a general proscription
against needlessly changing headers in 13.5.2. Maybe the status line
contents should be explicitly added to that list.

> Typographical nits, etc.:
> 
As soon as can be done.

Paul

Received on Thursday, 26 March 1998 19:52:08 UTC