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

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

From: Paul Leach <paulle@microsoft.com>
Date: Fri, 27 Mar 1998 11:33:28 -0800
Message-Id: <5CEA8663F24DD111A96100805FFE6587031E3C8E@red-msg-51.dns.microsoft.com>
To: Paul Leach <paulle@microsoft.com>, 'Dave Kristol' <dmk@bell-labs.com>, 'Jeffrey Mogul' <mogul@pa.dec.com>
Cc: http-wg@cuckoo.hpl.hp.com


> ----------
> From: 	Dave Kristol[SMTP:dmk@bell-labs.com]
> Sent: 	Friday, March 27, 1998 11:15 AM
> To: 	Paul Leach
> Cc: 	http-wg@cuckoo.hpl.hp.com
> Subject: 	Re: comments on draft-ietf-http-authentication-01.txt
> 
> > 
> > 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.
> 
OK. I'll just clarify what "proection space" means -- the space that the
client may assume the same credentials are valid, until the server indicates
otherwise.

> > [...]
> 
> > > > > 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.
> 
Yup. I'll put in something like: If the response-digest does not check, then
the user agent MUST NOT process it in the same way as if it were correct,
and MUST indicate a security failure in an appropriate way.

> > 
> > > > >
> > > > >     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.
> 
If the proxy passes the range request toward the origin server, just adding
the conditional, then the origin server would know to use 206 in the
response digest. If the proxy converts an ordinary request in a range
request, then that would be a problem. Given that the proxy can't return
anything from cache for a request with Authorization headers unless it has
re-validated, I don't know that it would have occaision to do range
requests... I don't know off the top of my head -- Jeff?

>   Does sending the status code in response-auth
> really add that much value?
> 
It's hard to say. How much damage/confusion could the attacker cause by
changing the status code? For example, it could change a 200 OK into a 304
Not Modified, causing the client to think it's local copy was up to date --
that could cause large financial losses.

The idea in communications seciurity is just to make sure everything is
authenticate, so you don't have to be very clever and think of the worst an
infinitely smart, infinitely malicious attacker can do.

Paul
Received on Friday, 27 March 1998 11:36:32 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:14 EDT