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

From: "Alexey Melnikov" <[email-masked]>
Date: Thu, 01 Sep 2016 07:50:21 -0700

Alexey Melnikov has entered the following ballot position for
draft-ietf-httpauth-extension-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-extension/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with Stephen that this document must include the registration
template as per Section 4.2.1 of BCP 90 (RFC 3864).

In Section 2.2:

    bare-token        = 1*(%x30-39 / %x41-5A / %x61-7A / "-" / "_")

Did you intent to allow leading "-" (and possibly "_") above?
As you are using "-<bare-token>.<domain-name>" for private extensions,
I think the ABNF is not right. I think you meant:

    lead-token-char   = (%x30-39 / %x41-5A / %x61-7A / "_")
    bare-token        = lead-token-char *(%x30-39 / %x41-5A / %x61-7A /
"-" / "_")

In Section 3, last paragraph:

   Support of this header is OPTIONAL; clients MAY also implement this
   extension only for some selected authentication schemes.  New
   authentication schemes can make support of the optional
   authentication mandatory by its specification, though.

I don't think this paragraph is needed, as this is granted, because
support for any
extension like specified in this document is optional. So I suggest
deleting it.

Section 3.1:

   I am still not convinced that Optional-WWW-Authenticate is needed,
   but the section provides a reasonable overview of the current
situation.

In Section 4:

   Support of this header is OPTIONAL, and clients MAY choose any subset
   of these parameters to be supported.  The set of supported parameters
   MAY also be authentication scheme-dependent.  However, some
   authentication schemes can require mandatory/recommended support for
   some or all of the features provided in this header.

As above, I don't think this paragraph is needed.

4.4.  No-auth parameter

   This parameter SHOULD NOT be used along with the
   location-when-unauthenticated parameter.

Why is this only a SHOULD NOT (or to rephrase it: what are possible
conditions for violating this)?

   If both were supplied,
   clients MAY choose which one is to be honored.

I would rather you pick one behaviour in order to improve
interoperability.

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?

   The log-out operation (e.g. erasing memories of user name,
   authentication credential and all related one-time credentials such
   as nonce or keys) SHOULD occur before processing a redirection.

4.6.  Logout-timeout parameter

   The parameter "logout-timeout", when contained in a successfully-
   authenticated response, means that any authentication credentials and
   state related to the current protection space are to be discarded if
   a time specified in this header (in seconds) has passed since from
   the time this header was received.  The value MUST be an integer.  As
   a special case, the value 0 means that the client is requested to
   immediately log-out from the current authentication space and revert
   to an unauthenticated status.

It sounds like this is not just a request, but the client will be logged
out. If this is correct,
then you should reword this, for example:

   As a special case, the value 0 means that the server is logging the
client
   out immediately from the current authentication space and that the
client
   is now returns to unauthenticated state.

---

From: 大岩寛 <[email-masked]>
Date: Sat, 3 Sep 2016 04:05:06 +0000

Thank you very much for your comments.

> I agree with Stephen that this document must include the registration template
> as per Section 4.2.1 of BCP 90 (RFC 3864).

Yes, I'll do it.

> As you are using "-<bare-token>.<domain-name>" for private extensions, I think
> the ABNF is not right. I think you meant:
> 

Thank you for notifying it.  We'll remove - and _ from the initial character.

> I don't think this paragraph is needed, as this is granted, because support
> for any extension like specified in this document is optional. So I suggest
> deleting it.

Of course, Experimental thing is always optional, as a starting point.
But if we have two or more OPTIONALs, we need to clarify whether these are
"one-by-one" or "all-or-nothing".
What we wanted to assure here is that
 - It's optional support may vary between schemes.
   For example, an implementation MAY choose to support it in Digest but not in Basic.
   Also, implementation MAY choose only to support "username" and not "logout-timeout".
   In this point, it's "one-by-one" OPTIONAL.

 - We have another "experimental" draft which normatively refers this draft and
   requires implementation of this extension.
   It's a kind of "all-or-nothing" (more precisely, "A implies B").
   It does not contradict with the "experimental status" of this draft.

These need a little more clarification than just saying "OPTIONAL" or "Experimental".
If you have some solution to resolve it nicely, it's really appreciated.

>    but the section provides a reasonable overview of the current situation.
> 
> 
> In Section 4:
> 
> Why is this only a SHOULD NOT (or to rephrase it: what are possible conditions
> for violating this)?
These are contradicting requests for the same scope and
using them together is meaningless.  So below,

> I would rather you pick one behaviour in order to improve interoperability.

we'll change these two clauses together to define precedence order between them.

> 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.

> It sounds like this is not just a request, but the client will be logged out.
> If this is correct, then you should reword this, for example:
> 
>    As a special case, the value 0 means that the server is logging the client
>    out immediately from the current authentication space and that the client
Thank you very much.  We'll fix in this direction.

-- 
Yutaka OIWA, Ph.D.       Leader, Cyber Physical Architecture Research Group
                                  Information Technology Research Institute
    National Institute of Advanced Industrial Science and Technology (AIST)
                      Mail addresses: <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 3 Sep 2016 10:55:30 +0100

Hi,

>   In this point, it's "one-by-one" OPTIONAL.

In this case I suggest that you either remove the first optional or rephrase this to say that there is no requirement to support this for all supported authentication schemes.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 3 Sep 2016 10:58:04 +0100

Hi,

> 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

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 3 Sep 2016 10:58:54 +0100

Hi,

On 3 Sep 2016, at 05:05, 大岩寛 <[email-masked]> wrote:

>>   is

Remove the "is" above.

>> now returns to unauthenticated state.

---

From: 大岩寛 <[email-masked]>
Date: Mon, 5 Sep 2016 08:24:07 +0000

Dear Alexey,

thank you for the suggestion.
"no requirement" phrase seems to be very good solution.
________________________________________
差出人: Alexey Melnikov <[email-masked]>
送信日時: 2016年9月3日 18:55:30
宛先: 大岩寛
CC: The IESG; [email-masked]; Yoav Nir; [email-masked]; [email-masked]
件名: Re: Alexey Melnikov's No Objection on draft-ietf-httpauth-extension-08: (with COMMENT)

Hi,

---

From: Yutaka OIWA <[email-masked]>
Date: Fri, 9 Sep 2016 18:44:08 +0900

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.)

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

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 9 Sep 2016 18:01:03 +0300

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

Best Regards,
Alexey

> On 9 Sep 2016, at 12:44, Yutaka OIWA <[email-masked]> wrote:
> 
> Dear Alexey,
>