RE: REAUTHENTICATION REQUIRED
Paul Leach (paulle@microsoft.com)
Tue, 25 Nov 1997 15:55:08 -0800
Some comments:
I think that you need to be more explicit about the meaning of "discard" --
the credentials should be zero'd out in memory, so that even if someone
comes and attaches a debugger to an idle browser, they won't be able to get
the credentials.
I think you need to explain why this is an issue for the standard, and not
just a browser implementation issue -- the security (against certain
threats) of the end-to-end distributed application depends on it being done.
You may want to point out that when discarding credentials, the browser may
also want to erase history, etc. -- I presume that one environment is serial
reuse of the browser by another user who may immediately sit down and start
to use it.
Paul
> ----------
> From: Scott Lawrence[SMTP:lawrence@agranat.com]
> Sent: Tuesday, November 25, 1997 10:51 AM
> To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> Subject: Re: REAUTHENTICATION REQUIRED
>
>
> >>>>> "RP" == Ross Patterson <Ross_Patterson@ns.reston.vmd.sterling.com>
> writes:
>
> RP> "Scott Lawrence" <lawrence@agranat.com> writes:
>
> >> As I wrote the proposal, 'discard' can't be combined with other uses
> >> of the Authentication-Info header, such as nextnonce; this may have
> >> been a mistake.
>
> RP> Just to be clear: You're proposing that a client receiving an
> RP> "Authentication-Info: Discard" header in a response should discard the
> RP> credentials it supplied on the Authorization header in the request,
> RP> correct? Given everything Fote has been saying about the domain of
> RP> credentials over URLs, not to mention realm values, it's entirely
> RP> possible for a browser to have a large cache of presumably-valid
> RP> credentials. I don't think you're asking to have them all discarded,
> or
> RP> even some subset of those associated with the origin server, correct?
>
> Yes, correct. My intent was that the credentials used for the
> request be discarded - regardless of what other protection spaces
> they may have also applied to. Credentials not used for the request
> are not affected.
>
> Example:
>
> get /foo ------------------>
> <----------------- 401 Unauthorized
> WWW-Authenticate: realm="bar"
> (prompt user)
> get /foo ------------------>
> Authorization: xxxxx
> <----------------- 200 Ok
> ...
> get /foo/bogus ------------------>
> Authorization: xxxxx
> <----------------- 200 Ok
> ...
> post /foo/bar ------------------>
> Authorization: xxxxx
> <----------------- 200 Ok
> Authentication-Info: discard
> (discard credentials use to build xxxxx)
>
> At this point, if the user enters the URL for /foo/bogus, the user
> agent may 'remember' that it needs to prompt for credentials in
> realm 'bar' or it may just send a request and (presumably) get a 401
> as usual. The fact that 'discard' came in response to a request for
> /foo/bar does not restrict the loss of credentials to that resource
> - the credentials go away and must not be reused.
>
> If people don't think that was clear, I invite improved wording.
>
> RP> One more point: Since Authentication-Info is defined by RFC 2069 as
> RP> being sent when authentication is successful, this discard response
> must
> RP> be sent with a 2xx or 3xx status code and without a WWW-Authenticate
> RP> header. In other words, an origin server is only allowed to request
> the
> RP> client to discard credentials at a time when they are acceptable to
> the
> RP> server.
>
> I had not made that specific, but I see no problem with it.
>
> RP> And I assume we'd want to support "Proxy-Authentication-Info: Discard"
> RP> as well.
>
> I will leave that to those who believe that they understand proxy
> authentication...
>
> RP> I have to say that this is all starting to sound like something we
> RP> aren't allowed to do while trying to move HTTP/1.1 from Proposed to
> RP> Draft Standard. As much as the lack of a procedure for invalidating a
> RP> client's credentials has hurt my company's products (quite a bit!)...
>
> It is clear that this capability, if it existed, would be a big help
> to application developers. I believe that a good case can be made
> that its absense decreases the security of many applications, and so
> I would argue that it is a bug in the protocol - bugs may be fixed
> at this stage. I also believe (as I said in the earlier note) that
> it does not present a backward compatibility problem (web
> applications using old browsers will be bug-for-bug compatible with
> the old protocol :-).
>
> RP> ... we
> RP> would nonetheless be opposed to any change that would prevent the
> rapid
> RP> advancement of HTTP/1.1 to Draft Standard.
>
> I could not agree more.
>
> --
> Scott Lawrence EmWeb Embedded Server
> <lawrence@agranat.com>
> Agranat Systems, Inc. Engineering
> http://www.agranat.com/
>