Re: [http-auth] Alexey Melnikov's No Objection on draft-ietf-httpauth-extension-08: (with COMMENT)

[Alexey Melnikov <[e-mail]>]

Dear Yutaka,
Thank you for the explanation. This is much clearer now.

Best Regards,
Alexey

> On 9 Sep 2016, at 12:44, Yutaka OIWA <[e-mail]> wrote:
> 
> Dear Alexey,
> 
> A short answer seems to be "the client (not the server)
> will terminate the session",
> but please let me clarify the "session" first.
> 
> As a background:
> In HTTP authentication (please think of the behavior of Basic),
> general implementation of web browsers are that once the
> authentication is successful, the client will "re-authenticate"
> with the same credential (user/pass) to the same realm
> of the same host automatically, "forever"
> (until the browser itself is terminated.)
> In this sense, the duration of HTTP authentication "session"
> is defined by the clients ("as long as they want to
> send the credentials"), not by the servers in any way.
> Servers can't distinguish whether an authentication request
> is "re-authentication" in the above sense, also servers
> does not have a clear way of making client stop
> "re-authenticating" (*Note 1).
> 
> Given this:
> The extension parameter "logout-timeout=0" allow servers
> to request clients terminating the current session.
> It "asks" client to stop sending the current credential
> automatically to the server.
> It's up to client implementation to behave nicely, then.
> 
> Security consideration:
> 
> When it's important "for servers" to reject any
> actions for the timed-out sessions, it must be implemented as an
> "_authorization_ session" expiration using Cookies.
> When the cookie is considered "expired" by the server,
> it can reject any authorized request by itself, and it can treat any requests
> as if it were unauthenticated, regardless of the result of HTTP authentication.
> However, the client will continue thinking current "authentication session"
> as valid, and thus it will continue to send the authentication credentials.
> 
> In this case, "logout-timeout=0" is useful to let the client
> terminate the "authentication session",
> letting it know the credential is no longer useful.
> Without doing this, if the server requests the client
> to make a new "session" by sending 401, the client will send
> the "old credential" automatically without asking users,
> resulting in a kind of unwanted "auto log-in by the previous user".
> 
> In many cases, the purpose of timed/user-initiated session expiration
> is to just protect "users" from impersonation caused by an unattended terminal.
> In that case, we can trust the behavior of client software and
> we can use "logout-timeout=<n>" quite simply.
> (If the user uses malicious software, it's up to the user.)
> 
> 
> 
> 
> Next on "location-when-logout":
> 
> Some clients, even currently, have a ability to terminate
> the session by themselves (e.g. in Firefox,
> "Clear recent history" - "active logins").
> We call it "user-initiated log-out".
> However, unlike a "sign out" link in Cookie-authorized sites,
> doing it will not generate any visible responses,
> and contents for authenticated users
> will be still displayed on user's screen after that.
> 
> Then, "location-when-logout" can be useful to show the
> "you're logging out" page and clearing the
> authenticated contents away from the user's screen,
> so that users can understand what is happening.
> It's like a non-existing "when-logout" hook updating
> the current location (document.href in Javascript).
> It can be useful for both
> - user-initiated log-out from browser-user interface, and
> - timed log-out by "logout-timeout=<n>".
> 
> Do these make sense?
> 
> 
> 
> (*Note 1) One undocumented way of doing this is to make
> client's authentication trial "fail once" in some way.
> However, in usual case, a log-in dialog is shown to the user
> as a result of failed authentication trial.
> Doing this without showing the log-in dialog to the user is quite tricky.
> (A few tricky ways:
> - use an XMLHTTP request with user/pass parameters for
>   Basic authentication, carrying a "dummy" user to fail.
> - By some way, carefully detect the time of "new authentication",
>   and generate 401 response for a valid credential "only once".
>   The dialog will shown for the "new authentication",
>   and if the user types in a valid user/pass,
>   it will (must) be accepted after that.
> I'm aware of the instances for both, but both are really dirty tricks.)
> 
>> On 09/03/16 18:58, Alexey Melnikov wrote:
>> Hi,
>> 
>> On 3 Sep 2016, at 05:05, 大岩寛 <[e-mail]> wrote:
>> 
>>>> In 4.5:
>>>> 
>>>>  When the user requests termination of an authentication period, and
>>>>  if the client currently displays a page supplied by a response with
>>>>  this parameter, the client will be redirected to the specified
>>>>  location by a new GET request (as if it received a 303 response).
>>>> 
>>>> Is this value advisory? Should the client go to this page automatically or would
>>>> the server redirect it? If the latter, why does this need to be told to the
>>>> client?
>>> 
>>> We'll clarify it.  It's client's role to go to that page. 
>>> In client-initiated logging-out, the server cannot initiate redirect
>>> unless the client takes some action first.
>> 
>> Ok. So just to double check: the server will expire the session at the specified time, but the client needs to go to the specified web page once the session is expired?
>> 
>> Thank you,
>> Alexey
> 
> -- 
> 大岩 寛   Yutaka OIWA             (国研)産業技術総合研究所 情報技術研究部門
>                                     サイバーフィジカルウェア研究グループ長
>                                      <[e-mail]>, <[e-mail]>
> OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]