Re: comments on draft-ietf-http-authentication-01.txt
Dave Kristol (dmk@bell-labs.com)
Fri, 27 Mar 1998 14:15:54 -0500
Paul Leach wrote:
> > [DMK]
> > 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.
> >
> Unlike the Borg, we don't have a collective mind, and hence no collective
> guilt... :-)
I was returning the favor to another spec. writer, not to another MS
person.
> [...]
> > 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
> > is.
> >
> If we have a chance to make editorial changes, then OK. But I am wieghing
> everything against the standard of "does this mean that it is good enough to
> pass Last Call or not"? If it can pass Last Call and editorial changes can
> still be made, I'm happy to make the changes you suggest.
Sounds like it's editorial -- a clarification -- to me.
>
> Even then, I think I'd call it the "assumed protection space" -- i.e. is
> what the client believes is protected by that set of credentials, until it
> discovers otherwise by either gettin a 401 on a URL it thought was in that
> sapce, or being prompted for credentials in the same realm for a URL that it
> thought wasn't in that space. Naming suggestions welcomed.
You could just take the Humpty Dumpty approach: "protection space"
means what it's defined to mean. Changing the term now may be hard.
> [...]
> > > > 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?
> >
> That's what I'd do. But we aren't supposed to prescribe UI behavior...
Maybe not in detail, but I suspect you would like the browser to inform
the user. That doesn't seem like a onerous prescription.
> >
> > 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?
> >
> Proxies do not posses enough info to check reponses. By design -- if they
> could know it, that would mean that the protocol is insecure.
Yeah, okay, I got confused.
>
> > > >
> > > > 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.
> >
> No, I think this is right on target (except it's 304 Not Modified, not 302).
Oops.
> I think this is an important case to make work, for efficiency reasons. If I
> were implementing an origin server, what I'd do, regardless of what the spec
> says, is to calculate the response-digest assuming the proxy will turn the
> status code into 200. It violates the letter of the law but not the spirit.
> The question that I can't figure out off the top of my head is: how well
> would that work?
Couldn't a client, or proxy, make a Range request? In that case the
response could be 206. Does sending the status code in response-auth
really add that much value?
Dave Kristol