Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (with COMMENT)

[Bjoern Hoehrmann <[e-mail]>]

* Barry Leiba wrote:
>>> "MUST NOT" does not mean the Internet Police will come to take you away.
>>> "MUST NOT" means "this won't work".
>>
>> Ahem, no, that's not what "MUST NOT" means.
>
>It is, modulo rhetoric.  It's an interoperability requirement.  "You
>MUST NOT do <x>," means that if you do <x>, you will not interoperate
>-- something will break.  It seems to me that that's exactly the case
>here: If my username is "b:leiba", and a client sends "b:leiba:plugh",
>many servers will think the username is "b" and the password is
>"leiba:plugh".  That means that allowing ":" in the username breaks
>interoperability.  Whether or not it works sometimes, and whether or
>not implementations currently *do* this are irrelevant.  The point is
>that the right definition of the protocol is that you "MUST NOT have a
>colon character in the username."

So, a browser shows a user a prompt like

  Username: _______________
  Password: _______________

User enters Username $user and Password $pass and the browser sends

  Authorization: Basic base64(utf8_encode(concat($user, ':', $pass)))

And then the server interprets that as Username $u and Password $p.

A couple of scenarios:

  a) Browsers abort the process above if $user contains `:`

  b) Browsers abort the process above if $pass contains `:`

  c) `Authorization` headers does not conform to the draft if
     concat($user, ':', $pass) contains more than one colon

  d) $u != $user

  e) $p != $pass

As it is, the draft does not require a); b) would be non-compliant; c)
is false; d) and e) can happen without violating requirements of the
specification due to colons alone.

The text suggested by Pete Resnick restricts, in the model above, the
contents of `$user`, without clear implications for browsers or servers
or header field value validity. What is it actually that people want
here? Should browsers be required to check user input for colons? Is it
okay that the draft requires support for colons in passwords, but does
not require servers to interpret `b:leiba:plugh` as having a password of
`leiba:plugh`? Perhaps encoded `user:pass` strings in `Basic` headers
should be non-conforming if they contain more than one colon?
-- 
Björn Höhrmann · mailto:[e-mail] · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/