This is a secdir review of draft-ietf-httpauth-basicauth-update-06

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

Overview
========

This draft updates the HTTP Basic Authentication scheme with a charset
parameter, whose only allowed value is "UTF-8".

I believe the draft is almost ready, but there are some issues,
described below.


Security and Privacy Considerations
===================================

Should recommend strong password-hashing on the server side
-----------------------------------------------------------

The Security Considerations section acknowledges that passwords can be
stolen from servers, but does not encourage server operators to hash
stored passwords with a reasonable or strong algorithm.  This document
may not be the place to provide normative guidance on how to store
passwords to mitigate the exposure of a password table, but perhaps a
brief mention and an informative reference would be useful?  Many
systems (e.g. modern nginx and apache) use 1000 iterations of salted
MD5, but still support cleartext passwords, crypt(), and unsalted SHA-1,
which are all terrible.

 https://httpd.apache.org/docs/2.4/misc/password_encryptions.html
 http://nginx.org/en/docs/http/ngx_http_auth_basic_module.html#auth_basic_user_file

an informative reference might point to the Password Hashing
Competition, which documents sensible rationales for why you should use
strong password hashing, and how to know it when you see it:

  https://password-hashing.net

by comparison the digest draft has a lot more about how passwords should
be stored (even though Digest auth can offer only weaker protections for
the password store compared to Basic auth):

 https://tools.ietf.org/html/draft-ietf-httpauth-digest-13#section-5.2



Should recommend constant-time server-side comparisons
------------------------------------------------------

Servers that implement basic auth should not leak information about
the stored password via timing of rejections.  For example, a server
that stored cleartext passwords (which is a bad idea anyway) should
mechanically compare the entire string instead of bytewise comparisons.
The attack here is an attacker who guesses credentials a byte at a time,
by making 256 initial guesses and seeing which of them gets back a
rejection faster than the other (and iterates down the list).

This might be less of an issue for reasonable (non-cleartext) password
storage, but if we're not requiring strong password hashing, we should
at least require constant time comparisons.



Should recommend padding the Authorization: response
----------------------------------------------------

When used behind HTTPS as recommended, TLS hides the username and
password presented.  However, it does not hide the length of the
username and password if the other parameters of the HTTPS request are
known.

An active attacker who wants to learn the length of the victim's
username and password together for a particular basic auth realm could
force the user's browser to make HTTPS requests to a few different URLs
within the realm and see how large the packets are.

This could be mitigated by including whitespace padding in the client's
Authorization: header itself up to some multiple of a blocksize (perhaps
256B) to obscure the length.


UTF-8 security considerations by reference: is this OK?
------------------------------------------

The Security Considerations section includes the UTF-8 security
considerations section by reference, but doesn't call out any specific
issues for implementers to be aware of.  the NFC canonicalization draft
also has Security Considersations section, which is not included by
reference:

  https://tools.ietf.org/html/rfc5198#section-6


Interaction with proxies?
-------------------------

There is only a passing mention of Proxy-Authenticate: and
Proxy-Authorization: headers, so one assumes that both mechanisms should
support this new auth-param.  It's not clear to me whether there are any
additional security or privacy implications when this is addressed to
proxies compared to origin servers.

Section 2.2 ("reusing credentials") talks about the URI path (presumably
for "WWW-Authenticate", but then mixes "Proxy-Authenticate" into the
middle of that commentary.  It looks to me like "Proxy-Authenticate" is
not intended to be scoped by the URI path (there is no mention of "in
that space" in the sentence about Proxy-Authenticate in Section 2.2),
but this is kind of ambiguous.  Clarification would be good.


Path matching?
--------------

Nothing in the security considerations section talks about the threat
that motivates path matching for determination of which realm to use.
It might be useful to spell this out explicitly:

 * A user agent that sends the Authorization: header to URLs outside the
   authentication scope as described in Section 2.2 may leak the user's
   credentials

User Agent visibility and logout?
---------------------------------

Most RFCs don't talk at all about the human interface of the mentioned
tools.

But this draft refers briefly to interaction between the user and the
User Agent (see step 1 on
https://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-06#page-6).
However, it provides no other guidance.  There are several additional
guidelines that make basic authentication more acceptable from a privacy
and security point of view for a typical web browser User Agent:

 * user agents should indicate to the user when they are re-using the
   user's authentication credentials as described in section 2.2
   (indicating the realm, authentication scope, and user-id?)

 * user agents should not display the user's password anywhere by
   default

 * user agents should make it straightforward for users to clear their
   credentials for any <realm,authentication scope,user-id>.

https://tools.ietf.org/html/rfc7235#section-6.3 includes some of these
guidelines; perhaps this is another include-by-reference?



Other Considerations
====================

Deployment chicken-and-egg
--------------------------

The server has no way of knowing that the client is trying to obey the
charset header.  For the servers mentioned in that do user-agent
sniffing, it's not clear how those servers could ever know to stop
relying on the user-agent, since the clients have no way of signalling
their intent to use UTF-8 for the Authorization header.  If the servers
don't know when to start accepting UTF-8 from these clients, then the
clients also have no way of knowing when they should switch over
themselves.  This strikes me as a recipe for stalled adoption, since
"user agents in the latter group" (from section B.3) will never use
UTF-8, even if they know about it.

If we want to avoid the adoption stall, we might need more forceful
language to discourage user agents from trying to guess whether they are
in "the latter group"

User IDs with Colons
--------------------

The draft says "a user-id containing a colon character is invalid" --
why not say that "the user-id MUST NOT contain a colon character", as it
already does for control characters?


Nits
====

 * in B.3, "Authentication on these sites will stop to work" should be
   "Authentication on these sites will stop working"


Regards,

        --dkg