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

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

Received on Friday, 27 March 1998 11:19:01 UTC