Subject: Re: [Gen-art] Telechat Review of draft-ietf-httpauth-extension-08

From: Jari Arkko <[email-masked]>
Date: Thu, 1 Sep 2016 12:35:25 +0300

Matt: Many thanks for your detailed review. Much appreciated.

Authors, can you take these notes into account?

Jari

On 01 Sep 2016, at 05:15, Matt Miller <[email-masked]> wrote:

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

---

From: 大岩寛 <[email-masked]>
Date: Sat, 3 Sep 2016 03:27:57 +0000

Dear Matt and Jari,

Thank you for giving and forwarding us useful comments.

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

Thank you for notifying it.  We did it on another draft but not on this.

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

We'll think about some improvements here, along with other people's comments on this.

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

It's a good idea. We'll do.

> > * Since this document is acknowledging that cookies are used for

Could you give me continuation, if possible?

> > Nits/editorial comments:

We'll incorporates these comments. Thank you.

-- 
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: Matt Miller <[email-masked]>
Date: Wed, 7 Sep 2016 09:02:01 -0600

Hello Oiwasan,

Thank you for your response, and look forward to reading the next revision.

As for that uncompleted thought; my apologies, it should not have been
included!  When I had started that thought, I had not yet finished all
of section 5.  I think, for an experiment, the interaction of
webform/cookie authentication with this extension is covered as well as
can be done until the experiment is performed.

Thanks ,

- m&m

Matt Miller
Cisco Systems, Inc.