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

Alexey Melnikov <> Fri, 09 September 2016 15:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3890412B45E; Fri, 9 Sep 2016 08:06:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.719
X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=deIRULEk; dkim=pass (1024-bit key) header.b=RSCuQ/wT
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5yB1w7MFx8z3; Fri, 9 Sep 2016 08:06:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E55BF12B1E7; Fri, 9 Sep 2016 07:59:29 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 2B89E204CD; Fri, 9 Sep 2016 10:59:29 -0400 (EDT)
Received: from frontend1 ([]) by compute6.internal (MEProxy); Fri, 09 Sep 2016 10:59:29 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=WQeASl7se1RqFi6KZd/wbFTVpzs=; b=deIRUL Ekmx4t/tmEc9Tfg8zqD7pTVmzDm2Z+ryaFMM8+dnv/jWCZdeAQOhvsA3EuTVEa7Q kjivo2FS9KlEopsiN5D/UreUNVZnpDmfgS96dNYXAh4AugCVHbJQKRWkyAnHeh6O 4mARZGLyytMH1RUcqgLp22Xy3JrdBnLzOMuUA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=WQeASl7se1RqFi6 KZd/wbFTVpzs=; b=RSCuQ/wTDu9ytQsO/dAu02iCQT6wYEkNuDFUFgrdKdbf7pz hb5UJSRYEQhsa33g4nVLqlRkOszRj+mPT0hEIakI47JgFTwbsSSymiEmFZf/JfF2 e0Ekh4awfRURKku7P8piRb57v2mD1S80XX5hEp7qW2g6uyIS/y8DBC469awA=
X-Sasl-enc: 8//4uUbP3R/10P6b2J/k4QIWMyfWWfZ4jxemiDhbs2Pf 1473433167
Received: from [] (unknown []) by (Postfix) with ESMTPA id 41313F2D29; Fri, 9 Sep 2016 10:59:27 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Alexey Melnikov <>
X-Mailer: iPhone Mail (13G35)
In-Reply-To: <>
Date: Fri, 09 Sep 2016 18:01:03 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Yutaka OIWA <>
Archived-At: <>
Cc: "" <>, "" <>, The IESG <>, "" <>
Subject: Re: [http-auth] Alexey Melnikov's No Objection on draft-ietf-httpauth-extension-08: (with COMMENT)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: HTTP authentication methods <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 09 Sep 2016 15:06:29 -0000

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

Best Regards,

> On 9 Sep 2016, at 12:44, Yutaka OIWA <> 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, 大岩寛 <> 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             (国研)産業技術総合研究所 情報技術研究部門
>                                     サイバーフィジカルウェア研究グループ長
>                                      <>, <>
> OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]