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

From: "Richard Barnes" <[email-masked]>
Date: Wed, 18 Feb 2015 11:46:56 -0800

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.  

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

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 18 Feb 2015 17:08:50 -0800

> http://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/

Please see "http://tools.ietf.org/html/rfc2616#section-14.8"

> Authorization headers in the Security Considerations.

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

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 18 Feb 2015 17:08:50 -0800

....Roy

---

From: Yoav Nir <[email-masked]>
Date: Thu, 19 Feb 2015 08:27:40 +0200

> On Feb 19, 2015, at 3:08 AM, Roy T. Fielding <[email-masked]> wrote:
> 

I think it can be argued that this is a better arrangement then placing a database of passwords or password equivalents directly on a web-connected server.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Thu, 19 Feb 2015 08:27:40 +0200

Yoav