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

Alexey Melnikov <aamelnikov@fastmail.fm> Fri, 09 September 2016 15:06 UTC

Return-Path: <aamelnikov@fastmail.fm>
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3890412B45E; Fri, 9 Sep 2016 08:06:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.719
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=deIRULEk; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=RSCuQ/wT
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yB1w7MFx8z3; Fri, 9 Sep 2016 08:06:19 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E55BF12B1E7; Fri, 9 Sep 2016 07:59:29 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 2B89E204CD; Fri, 9 Sep 2016 10:59:29 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Fri, 09 Sep 2016 10:59:29 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; 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= messagingengine.com; 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 [192.168.0.191] (unknown [176.59.5.138]) by mail.messagingengine.com (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 <aamelnikov@fastmail.fm>
X-Mailer: iPhone Mail (13G35)
In-Reply-To: <b3cc240b-1576-1133-d0c9-92d137fa1d19@aist.go.jp>
Date: Fri, 9 Sep 2016 18:01:03 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <C1C9AF18-C071-478C-B87E-E2A97F8B8674@fastmail.fm>
References: <147274142144.10095.917266239677089935.idtracker@ietfa.amsl.com> <TY1PR01MB058849D777444188BE2474A7A0E40@TY1PR01MB0588.jpnprd01.prod.outlook.com> <5F80951C-DF6A-4BD9-8818-167BFC5BE1A7@fastmail.fm> <b3cc240b-1576-1133-d0c9-92d137fa1d19@aist.go.jp>
To: Yutaka OIWA <y.oiwa@aist.go.jp>
Archived-At: <https://mailarchive.ietf.org/arch/msg/http-auth/zBVt-dCJsB6zZLzC6EA52YKZZZI>
Cc: "http-auth@ietf.org" <http-auth@ietf.org>, "httpauth-chairs@ietf.org" <httpauth-chairs@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-httpauth-extension@ietf.org" <draft-ietf-httpauth-extension@ietf.org>
Subject: Re: [http-auth] Alexey Melnikov's No Objection on draft-ietf-httpauth-extension-08: (with COMMENT)
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: HTTP authentication methods <http-auth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-auth>, <mailto:http-auth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/http-auth/>
List-Post: <mailto:http-auth@ietf.org>
List-Help: <mailto:http-auth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-auth>, <mailto:http-auth-request@ietf.org?subject=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,
Alexey

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