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

> ----------
> From: 	Dave Kristol[SMTP:dmk@bell-labs.com]
> Sent: 	Friday, March 27, 1998 6:45 AM
> To: 	Paul Leach
> Cc: 	http-wg@cuckoo.hpl.hp.com
> Subject: 	Re: comments on draft-ietf-http-authentication-01.txt
> 
> > >     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.
> 
Of course not. From your comment later on in your post, I inferred that you
thought this was more than just a clarification.

>   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... :-)
>  
> > >     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?
> 
For Basic, it's important. For Digest, it's not. That, and independent
authorship, are why the concept never showed up in the Digest section.

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

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.

> > 
> > > 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.
> 
> Okay.
>  
> > >       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".
> 
I meant to expand on that sentence, actually, but sent the reply before
doing so. The problem I have with the term "protection space" is that it
implies that anything outside the protection space is unprotected -- and
that's not true; it could be part of the protection space, the client just
doesn't know yet that his/her password is good in those other places.

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

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

Thanks for the close read. 

Larry -- do we edit and resubmit for another Last Call? Or can we fix and
submit for RFC?

Paul

Received on Friday, 27 March 1998 10:56:45 UTC