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

Yutaka OIWA <y.oiwa@aist.go.jp> Fri, 09 September 2016 09:46 UTC

Return-Path: <y.oiwa@aist.go.jp>
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 7319F12B415; Fri, 9 Sep 2016 02:46:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aist.go.jp
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 BQPOzQU_UEz5; Fri, 9 Sep 2016 02:46:33 -0700 (PDT)
Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0042.outbound.protection.outlook.com [104.47.92.42]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8643512B3E3; Fri, 9 Sep 2016 02:44:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=t0YNzkbnkadBwnPWkH8fYixPVPq66qp6fXk2HTmIwJ8=; b=IQqQqf7Asvz9ova5/24/oGLDTtW9F6QS9Ag/g6iVQlg0PeXBVE5RMUVcUP1+A4m9L7s3GlqwaXnwGwbx0Bmr3Xu4wSHj2ekoRMbsxz62ADUqJ6QINP7wI1GB+ELM/D06HPS1sdi5Cxg2O12fko4HkFn2+jAJOIv7JHP2w7M6wew=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=y.oiwa@aist.go.jp;
Received: from [150.29.149.156] (150.29.149.156) by OSXPR01MB0581.jpnprd01.prod.outlook.com (10.167.146.143) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.609.9; Fri, 9 Sep 2016 09:44:12 +0000
To: Alexey Melnikov <aamelnikov@fastmail.fm>
References: <147274142144.10095.917266239677089935.idtracker@ietfa.amsl.com> <TY1PR01MB058849D777444188BE2474A7A0E40@TY1PR01MB0588.jpnprd01.prod.outlook.com> <5F80951C-DF6A-4BD9-8818-167BFC5BE1A7@fastmail.fm>
From: Yutaka OIWA <y.oiwa@aist.go.jp>
Message-ID: <b3cc240b-1576-1133-d0c9-92d137fa1d19@aist.go.jp>
Date: Fri, 09 Sep 2016 18:44:08 +0900
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <5F80951C-DF6A-4BD9-8818-167BFC5BE1A7@fastmail.fm>
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [150.29.149.156]
X-ClientProxiedBy: TY1PR01CA0053.jpnprd01.prod.outlook.com (10.167.153.141) To OSXPR01MB0581.jpnprd01.prod.outlook.com (10.167.146.143)
X-MS-Office365-Filtering-Correlation-Id: 1aec07ba-cf26-43d8-91ea-08d3d895dadd
X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0581; 2:aGJyH5y2ml+Bmwl2lELpYjiiTnosFuKU5fKJaZINVkHVNyDINfZw09iWDl/m1bNi2sR0Dkya6WtbgJz45JcmPW/FALw1KZC2+PZr33BgvLov11AzKV1rKDgHEjCzA8XmDTxMwdgpIh3uWzsv4pc3XqCkho0nG9XIUUcK/miibO+UGB9fO4quBw1rlo3Ty9pH; 3:qYMZk0kNxKDGwRG5Tei964PoG3s4MLONbG/bXykOTuc7Pq+PqtOFxaf+HOCQSSu15if/xJQulqO09l2IPYqOCASBHXxIOAbwcr9vhWC3IIDzFQNQdxRMda5cAeGlisQL; 25:we2wbcgrXUyD+LNlJL+0OySEaCjvJDor6i+nXzmVsh7PLMD0atlijl8eMwIXP09KH/YRq7b1XuArzI9+3fuASUWLKsTAAAZexUnQ65Y4d/C2zHdcG8NwWLGvebb/H4JuDMPzeB2K08H7zjj1Z7+eeO76RP8SSRc5ujJBUUDe485heDch9WVEvS3XKeCYWlM2tK+m/Xv7Wb7LfJqf65rwiDYh+z/xGtIYqsz7R0bU8uOslOwVBE3yXTPxU8M9R6kPD06nJ0eClt4m44jylq5fpYbP+beb+E2DsfJ09pdaJgex0VmuzGC7Kfdqq7Fc3O0ZVl08iIL88aiIgmBcs91QvOm809CO+/K5vQREvJlyeSt1VL3zDGyU1mtILiz9UrD4tG2N4eL88TMb4GX07y34wlXLQPzheNeIhGxhCCUmMrc=
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OSXPR01MB0581;
X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0581; 31:tvlLyQ6e/9aSsb8nnXc84FuQmvnlzdXnOR0GwwJcraxoq3Xl9DeZW08HBL19HXQ9iKAOO98Fe/iEXPYMJpIMvW7KdrxP3dQ5n/oeGMV4TIK1yNE3VJmzpJp82fSp/oNH4lUaaawXmYY3EwzuFYJ+zJaaWVieV9ynzsqVj9kANm+WQ2gLhFxUV3ifkeVnTVwTeQ++zaOWrGvdRtlUJXf4N7fQMCULhTUGP07gP+FsMHY=; 20:4Jc7y9SOUGCbuboBcXvoiC+8/fEctuLf8ajxwf2X7yBf83kRgyKUIhDq/+GAFl+wtZzj79cL4udOazaJlUCG+Pf5hbEmToTV52nmteMHYifm8+xmdy65Uhx+mVw4oWj3n6gokpZCX74HUk15kchUrU4mJ4TIg63NTjAFMW4d0Z6O+92Vb4/XLU0VlTnho+iTFZvoegNfb9VsTcyGeAX8YsHYl9yvt3Egi2WcF8a3BWPJ4YUPEiqam/w5i/Vp/uwvoVsJTd5Yt7EmKbWbF62zYJFl/P/uhlVcd1C39/HEEvjFMT41ZFmd5gWVkuGUok6N57gy9tyjV64wFKV28ZTiknqRPwd/9mDvop4jTgFy+8q4Cc/T08rsSK0sFRx2C4xb+28gPuuNGinc683PTzRqryQ8RirvO/xtbfBdMPuGZnwHaG3G6A/6/V5huJChfT9P9o73g9jjudLDh2fhY6TZLw1tJAoA4AR6UYVd/brO1lyuQiY9GMVaAQWOTj6vW1/O5/kMLMSBu8lmiq4apM0b5Rq1LRvnTajFGm0uE87xwqxym1Gr1RxJuG5M8V+aoBawiPzBNcjSGit5czOsgAbiyqfsDoe6bxFwV6U+G8FQ5t4=
X-Microsoft-Antispam-PRVS: <OSXPR01MB0581D65021ED1BD3FFCC57F5A0FA0@OSXPR01MB0581.jpnprd01.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(192374486261705);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:OSXPR01MB0581; BCL:0; PCL:0; RULEID:; SRVR:OSXPR01MB0581;
X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0581; 4:HIwtCm4bwiIut+7b6bmELrLUGoGxD7kqO6hr7blduH7DoNUJy0ouoMjTQkeG4ovFFcxdNcTMPfwpkHXv6fcHOLVK5sTkWS6WdVA4DIHHktcl6NzSzrzSTcB8+xFt3PfxrbohIr9KShwEUA6HXGplFXXkznHSokfBDXs1Fa8bshGzQaa343xUc89XNs51CLAukGZleMaPSdzJOzZXhLp+oJHSAOEig+w6i5HFgjIC1itNi9j789v5aSbjM7+becQ7av6nIU3MQaTyUHzUahEp3iYuRcepN4zDTAmzUeKvRivLf17l1Cm5NsZ3OW0cHseFH1tb8BG65laQ66rfi/bs/0v5On7d9SOwEkaj6ujzG2uI0TAf+HeDIvJidXl6NrUM0r5S9D6iKg1Sus86yy3QoREUc4Udk6PykIirl3WTESiiLtAdsbr+ngSrqtsLGVDlGwut4K68n+/k2chku7aH0Q==
X-Forefront-PRVS: 00603B7EEF
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6049001)(6009001)(7916002)(24454002)(199003)(189002)(2870700001)(2950100001)(8676002)(68736007)(7736002)(7846002)(42186005)(3846002)(8666005)(66066001)(47776003)(19580405001)(50986999)(65956001)(65806001)(86362001)(230783001)(81156014)(31696002)(19580395003)(305945005)(33646002)(31686004)(81166006)(110136002)(586003)(97736004)(76176999)(6116002)(4001350100001)(65826007)(189998001)(5660300001)(106356001)(92566002)(54356999)(105586002)(77096005)(36756003)(64126003)(50466002)(83506001)(4326007)(2906002)(23736002)(101416001)(74482002)(120846001)(7099028)(7059030)(3940600001); DIR:OUT; SFP:1101; SCL:1; SRVR:OSXPR01MB0581; H:[150.29.149.156]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Received-SPF: None (protection.outlook.com: aist.go.jp does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: 1;OSXPR01MB0581;23:QXzX5KriTpLcOBRk+todZ6o8w/F6kY67m6e4KNyeIB2g3Q/ZBosLyaI+zbCoxMRBMJS0eeAR2jF6b9NXFoiSpV0WxSkTy4Z7nVC3j1cwJO5SMpRUDiWo1+o+F7FyKHarczx386neIUVOrCjBfUZ2hc7SrIhVGp0RzAkmbZGM66l4OZJifv3qMTUS5+iXjJK4vpLJDGsUQmLaGw7EAFlEe4h+d28QZAdCPZBQrocydkeQGGXHalvCljxeuTWI63+CeAwc7TdHL5s9/lLUpKTSZ/9zrM3ndVWzxoasPIpAwuPq4NCMmNvGGyfPxb3cEvd0gS2kFxr90IIfVdcXqrbPdKJWm3rS8QBN8wihB9f0kJZhaqHnXkH+2BarX4/sGqB26vTB8V45PIX4bU+3+DsmRX6WgzodVx+RxIDuTfEPuc8m4ZIRgak4W1N+nVqHk5g5ba+98czXQFXHHbhOlLWnqHnYc3EwTvXeXaT9qV5DCqXZZjZIdTF25bmricAoLudPgtVMAv9fK7cqukFtdB0daYVvLPdxvt6jvR/jAhFoghkUggSuzsk0cR88RZAioZv1e5xHgt9jyNz63rlZ5nrrlvYQG20AGx4yEVUVHkwRzQOGnQfRUfYvEVv6dw7Hz0qtCWoS5tQS3V5unmaa2YYrFkkI88eWByRClh+5Kq0v7EUjOKflMUXx+xk10aJJN6sRy5SQpiRcOw7u/QzqQ6zicVEY7coSWpxOg1D+AJ58oI21OvWLv/FNPbO4KYGU9cGHjLHVtkrARC8qm4zJeZm+iuZ2ZHBYgsSu5eBL7xqNYVDjAOB7OFTz+FNCzYklT6yc4j1qScUbdC6vAV+TboySZqpr4n1nXdSK8T5fBi9BfOJwpzNMl82FuCbSoxqHDzS/wiOJZYG/wRIuz2ZNWHFJleQ9RPs23TpC8aJIeWGxce5vYimxmipyScdD1m5HyRZ/y5jdbHu/6JvNLxIttfi4KrskMf3AJwloDt/QYTqb1MCkTt1dHk1Z/CTexe4LuNEm+QlRtqz79chru/2tVKf2VTTVM8eNF+xOlXWJEUOoxB/nqwAGLHHvK4W4Q4ma1jagAUC9T0S6WuTIhdzu3L78+X/rDkn0vxf248I+fhbwOU2l/5cdj6GJzWn47B+QTGaxN5Z54h/GHTbjqT25HPP7PtAb4deEzvEWDildQ+uTnThYOlsYO6Tf06U2Vntst3jZDfPBLfwNN7QT8rmUvDQIsZLoogmpidGk6gI0aRpwzEHXRmvzfZolXJGnuoMEmCzZgjBS7ywJ03mnZRo8yS3aK9Lt5EUAA9Uy+ZI2egh6f1yrFJiKX9SOUr84+/0/6nOeFAaDorVP5IoM3I3mYQ3jIV3tVK1+okCke3FK2IX8latfT3W4sFl7rpdF0GVt//QP4SR4tj8VoDh+y1YFg5x3xw==
X-Microsoft-Exchange-Diagnostics: 1; OSXPR01MB0581; 6:fiQMxQPskaA9MZpRxBkutfxEFhboGonB6rECrF0kfH2tKioi6aeK175uP0Yhv51/+0ERqIAt32UaR3/Bk6zTJ8rBWjpGo70jQtn63vnoTuitYlm9THaL4j7Eske3IDDoSJa8A9eUrmcX95b86NiqpevnX3/dislPu9RoZ44OazEPGZHJr0bI8yohaeN15wIlUlnjuJMxOH9BmyKCMhAQn3+k3FyaD9fsVw+QHpE1cdSIHMAtQANUg9Z42UhzTQLZvGpdb8qh6d6m+UOD4i5v3ZoUtoGu/OHq0OsCej9zjs7jJxzPn23+f0HJMY8XBJU/MEWzYnyR+PAWjgCHr+srbQ==; 5:raunLiNymbbgJPkcUk+Vmo+enYjH/Kqr4p2TVlxdtsLdu/XPvjg9HJCBXk984Q/zn+4HKZNtCU79AqJcDaAOLfpjjECxFtqVWoHzyj428K3J2yA+D1HbJfY0RT7bDzmo/XyWNJ2FOblmXJRrLys5mg==; 24:1YdJwZuvuDtPFO3IKBWB5RQMlHf3p1Fi69O/RmCNSc+D6A1WayccnahDOtMq8ck67bw15yHAu2KhUlapmtUORdDWnck4tQdQcjS0L3qrsZw=; 7:uJFErqsFvr04TSjpeNYmEUyEJHLtvi2iaOIEseuH9LBKTvY7/sj3rkMwobpKDpJoHZrC7g+odrW3OadOCllqU8PitLtR2l++hQKz6ddwI70wX2Tuyhqk10TFeYpkCYpNWw8smdBISwMc+5A/xe6Uq6cZFhG8FvIqhxrZIUs7kdW5mpDXbpOl+tA3NOsVRZfmqd2BekOCORNiDySVitHER+vUjZQYb9yzcYZIBhc9YGPJm/UupxHpmPZfQprN8mEa
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: aist.go.jp
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Sep 2016 09:44:12.1781 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSXPR01MB0581
Archived-At: <https://mailarchive.ietf.org/arch/msg/http-auth/OZjiWWcObuEGq5cmN-DcirbfLas>
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 09:46:35 -0000

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>, <yutaka@oiwa.jp>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]