Last Call Review of draft-ietf-httpauth-basicauth-update-05

Request Review of draft-ietf-httpauth-basicauth-update
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-02-17
Requested 2015-02-12
Other Reviews Genart Last Call review of -05 by Meral Shirazipour (diff)
Opsdir Last Call review of -05 by Jürgen Schönwälder (diff)
Review State Completed
Reviewer Daniel Gillmor
Review review-ietf-httpauth-basicauth-update-05-secdir-lc-gillmor-2015-03-02
Posted at
Reviewed rev. 05 (document currently at 07)
Review result Has Issues
Draft last updated 2015-03-02
Review completed: 2015-03-02


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.


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.

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:

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):

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

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

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

User Agent visibility and logout?

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

But this draft refers briefly to interaction between the user and the
User Agent (see step 1 on

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

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

 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?


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






 PGP signature