HTTP Authentication Extensions for Interactive Clients
RFC 8053

Note: This ballot was opened for revision 08 and is now closed.

(Ben Campbell) Yes

(Stephen Farrell) Yes

Comment (2016-09-01 for -08)
No email
send info
I think experiments to improve web authentication are a good
thing (tm:-) so am happy to see this experiment proceed.

- Figure 1: Maybe clarify that "credentials" here is not the
same as in RFC 7235?

- Figure 3: this is a mixture of an example ("Basic") and ABNF
("1#challenge") which is odd. I'd say just make it an example
and fix the figure caption accordingly.

- section 7: I thought that registrations of new HTTP headers
needed some more information, e.g. in which messages they can
be sent and with which status codes? BCP90 does seem to call
for that - why aren't those details here?

(Kathleen Moriarty) Yes

(Jari Arkko) No Objection

Comment (2016-09-01 for -08)
No email
send info
Comments from the Gen-ART reviewer Matt Miller should be taken into account, see below. I considered making a Discuss about the reference to Authentication-Info RFC but I trust that you guys will make the correct modifications. Thanks!

----

* There is at least a couple of mentions of the
"Authentication-Info" header, but no reference to RFC 7615 in which
it is defined.  I think an informational reference is warranted
here.

* Just reading sections 4.5. "Location-when-logout parameter" and
4.6. "Logout-timeout parameter", it is unclear how these are meant
to interact to inform a client the user's authentication session.
Frankly, I think the text in section 4.5 is too vague about how
a client can detect termination of a user's authenticated session,
and could use more of a hint on how "logout-timeout" is involved
to accomplish it. At the least, I think both sections 4.5. and
4.6. need pointers to section 5. to help readers get a
sense of how to apply them.

* In section 4.7. "Username parameter", I think there should be
an explicit pointer to the Security Considerations to warn about
potential issues this parameter presents.  I also recommend
separating that portion of the Security Considerations about
"username" into its own subsection to make such a callout
better.

* Since this document is acknowledging that cookies are used for
authentication, and

Nits/editorial comments:

* In section 2.1. "Terms for describing authentication protocol
flow", the word "distinguishable" should instead be "distinguished"
in the phrase "it can't be distinguishable from a non-authenticated
response."

* In section 3. "Optional Authentication", the word "be" is missing
in "Optional-WWW-Authenticate header MUST NOT sent on 401
responses".

* In section 3.1. "Note on Optional-WWW-Authenticate and use of
WWW-Authenticate header with non-401 status", the word "is" should
be replaced with "are" in the phrase "clients which is unaware of
this extension will ignore the header".

* Also in section 3.1., the word "authentications" should be
"authentication" in the phrase "secondary fallback method of
authentications".

* Also in section 3.1., the word "ignores" should be "ignore" in
the phrase "just ignores the WWW-Authenticate headers".

* Also in section 3.1., all instances of the word "implementer"
should be replaced with "implementers" in the phrase "the authors
propose implementer of the standard HTTP/1.1 specification
(especially implementer of this extension)".

* In section 4. "Authentication-Control header", the word "an"
should be "a" in the phrase "and MUST be sent in an plain".

* In section 4.1. "Non-ASCII extended header parameters", the
interoperability note as a number of grammatical challenges.
I believe the following addresses the grammar issues while
retaining its meaning:

   """
   Interoperability note: [RFC7235], Section 2.2, defines the "realm"
   authentication parameter which cannot be replaced by the "realm*"
   extend parameter.  It means that the use of non-ASCII values for an
   authentication realm is not the defined behavior in HTTP.
   Unfortunately, some people currently use a non-ASCII realm parameter
   in reality, but even its encoding scheme is not well-defined.
   Given this background, this document does not specify how to handle
   a non-ASCII "realm" parameter in the extended header fields.  If
   needed, the authors propose to use a non-extended "realm" parameter
   form, with a wish for maximum interoperability.
   """

* In section 4.2. "Auth-style parameter", the word "preferences"
should be replaced with "preference" in the phrase "server's
preferences for user interface behavior".

* In section .4.4. "No-auth parameter", the word "authentications"
should be replaced with "authentication" in the phrase "content is
desired before authentications".

* In section 4.6. "Logout-timeout parameter", the word "from" should
be removed in the phrase "has passed since from the time this header
was received".

* In section 5.3. "When to use Cookies", the first sentence has some
grammatical challenges, which I believe the following text addresses:

   """
   In current Web sites using form-based authentication, Cookies
   [RFC6265] are used for managing both authorization and
   application sessions.
   """

* In section 5.4. "Parallel deployment with Form/Cookie
authentications", the META tag example should be "<META
http-equiv="refresh" ...>" instead of ">META http-equiv="refresh"
...<".

* In section 7. "IANA Considerations", the word "documents" should
be "document" in the phrase "a publicly-accessible documents".

Deborah Brungard No Objection

(Benoît Claise) No Objection

Comment (2016-09-01 for -08)
No email
send info
As mentioned by Rick Casarez in his OPS DIR review:

Section 3, paragraph 3:
Some sentence cleanup is required so that this remains clear. I believe I understand what is being said as far as implementation goes but some cleanup would make this paragraph more concise.

(Spencer Dawkins) No Objection

(Joel Jaeggli) No Objection

Comment (2016-09-01 for -08)
No email
send info
Rick Casarez <rick.casarez@gmail.com> provided the opsdir review

Suresh Krishnan No Objection

Mirja Kühlewind No Objection

Comment (2016-09-01 for -08)
No email
send info
1) The following disclarer is a little odd:

"The terms "encouraged" and "advised" are used for suggestions that do
   not constitute "SHOULD"-level requirements.  People MAY freely choose
   not to include the suggested items.  However, complying with those
   suggestions would be a best practice; it will improve the security,
   interoperability, and/or operational performance."

Both terms are only used once. I would recommend to remove the text above and simply use MAY later in the doc (or not use MAY and leave the later text as it is just without the disclaimer).

2) I agree that the section on username should point to the secturity section to give a clear warning. However, I also don't really understand why username is needed. If there is a good use case for it, maybe it's worth to explain this as another example.

(Terry Manderson) No Objection

Alexey Melnikov No Objection

Comment (2016-09-01 for -08)
No email
send info
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.

Alvaro Retana No Objection