RE: REAUTHENTICATION REQUIRED

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

Received on Tuesday, 25 November 1997 16:39:50 UTC