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

["Richard Barnes" <[e-mail]>]

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