Re: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-basicauth-update-06: (with DISCUSS and COMMENT)

[Julian Reschke <[e-mail]>]

On 2015-02-18 20:47, Richard Barnes wrote:
> Richard Barnes has entered the following ballot position for
> draft-ietf-httpauth-basicauth-update-06: Discuss
>
> 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 http://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:
> http://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Section 2.2 seems like a significant departure from RFC 2617, which says
> nothing about the scope of authentication.

It's only a rephrasing of 
<http://greenbytes.de/tech/webdav/rfc2617.html#rfc.section.2.p.8>.

> (1) Did the WG discuss the compatibility impact of this change?  Although
> clients might send the Authorization header preemptively, they should
> still be prepared to get a 401 response back.
>
> (2) Did the WG discuss the possibilities for leakage of credentials due
> to this change?  It's not hard to imagine scenarios where, say,
> "http://example.com/~user1" and "http://example.com/~user2" are
> controlled by different entities, and leakage between them would be
> harmful.
>
> (3) At the very least, there needs to be (a) a mention of this change in
> Appendix A, and (b) a discussion of leakage through unsolicited
> Authorization headers in the Security Considerations.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> The current text on the use of TLS is an OK start, but I would prefer if
> it were refactored so that the recommendation against Basic were general
> to HTTP and HTTPS.
>
> "Because Basic authentication involves the cleartext transmission of
> passwords it SHOULD NOT be used except over a secure channel such as
> HTTPS [RFC2818]. Likewise, due to the risk of compromise, Basic
> authentication SHOULD NOT be used to protect sensitive or valuable
> information."
>
>


-- 
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782