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

[Richard Barnes <[e-mail]>]

On Wed, Feb 18, 2015 at 2:52 PM, Julian Reschke <
[e-mail]> wrote:

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


Ah, thank you.  The change in wording stymied my efforts to find the
comparable text.

It still seems like it would be good to mention this leakage risk in the
security considerations.  But I've moved this to a COMMENT.


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