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

["Roy T. Fielding" <[e-mail]>]

On Feb 18, 2015, at 11:46 AM, 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.  

Please see "http://tools.ietf.org/html/rfc2616#section-14.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."

The secure channel would be "such as authenticated TLS", not HTTPS;
it doesn't matter what scheme is used.  Also, the last sentence is
inappropriate and pointless.

Historically (and currently), Basic authentication has been necessary
for environments where the end authentication mechanism is controlled
by a downstream server that uses legacy accounts and passwords.  Hence,
the Web server (acting as a gateway to that service) needs the actual
credentials as plain text in order for the user to be authenticated.
However unfortunate that may be in practice, it is an administrative
decision and not a protocol one, and the risk of compromise is not
much greater than any other mechanism that involves a user typing a
secret key into a piece of software that they don't completely control
(like a browser dialog).

Encouraging admins to use better authentication mechanisms when possible
is fine, but that doesn't translate into a general SHOULD NOT use this one.

....Roy