W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 1998

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

From: Dave Kristol <dmk@bell-labs.com>
Date: Fri, 27 Mar 1998 09:45:19 -0500
Message-Id: <351BBB7F.15EB@bell-labs.com>
To: Paul Leach <paulle@microsoft.com>
Cc: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/5512
Paul Leach wrote:
> > [DMK]
> > 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.

I don't think it hurts to be explicit here.  Furthermore, since I got
beat up by Yaron about stating explicitly what agents should do with
unrecognized attributes (namely, ignore) in RFC 2109, I feel obliged to
return the favor.
> >     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...)

True enough.  But if you're right, why bother to define the notion of
"protection space" at all?

Since the spec. goes to the trouble of defining a protection space
(sect. 1.2), I think each type of authentication (including successors
to Basic and Digest) ought to state clearly what its protection space

> > 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.

> >       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.

Sure it is.  The protection space is the set of URIs for which a given
set of credentials applies.  Certainly when there's an explicit "domain"
attribute it defines the protection space.  A missing "domain" attribute
implicitly sets the protection space to be "the server".

> > 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.

Where does it say that? :-)  Unrecognized headers should be ignored, but
even RFC 2068 is not explicit about unrecognized attributes (the word
used there).  Seriously, in the interests of increasing the likelihood
of interoperating implementations, I think it helps to say what you

> > 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.

How does a client, which has already read a response, "not accept
[it]"?  I'm picking nits here, true.  Does it mean that a browser would
show the user an error saying that the received response was in error? 
Or does it just stop spinning its logo and leave on the screen what was
already there?

Suppose the client is a proxy.  What should it do vis-a-vis its client?

> >
> >     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.

Is it possible to say a proxy can't change its status code?  Suppose you
have browser B, caching proxy P, origin server S.  (I'm sure you'll tell
me if this example is way off base.)  B requests object X, which it does
not have in its local cache.  P has the object, but the object has
Cache-Control: must-revalidate.  P sends a *conditional* request to S. 
After S asks for credentials, which response P passes to B, B asks again
for the X  S responds with 302 and (is this right?  possible?) an
Authentication-Info header.  The A-I header would presumably contain a
digest of the "302", but the proxy would return a 200 and supply X to B,
along with A-I.  B would be unable to match the A-I header and the
response and would assume the response is bogus.

Dave Kristol
Received on Friday, 27 March 1998 06:47:07 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:04 UTC