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 11:07:17 UTC