Subject: [http-state] Missing specification in RFC 2617, cannot use a user name nor a password in encoding different from ISO-8859-1

From: Honza Bambas <[email-masked]>
Date: Mon, 03 May 2010 20:54:39 +0200

There has been observed that many server appliances allow setup of user 
names and passwords with characters that cannot be represented with 
ISO-8859-1.  Client implementations that have problems to communicate 
with such servers properly, obeying RFCs, because of missing 
specification of character encoding of a user name and a password in 
both 'basic' and 'digest' authentication scheme.  Specially building of 
the Authorization header and its username= directive value and building 
of A1 string.

As for the username= directive value: it is by definition a 
'quoted-string' that is unable to carry any information about its 
character encoding.  I have found any explicit information in RFC 2617 
about a required character encoding for it.  RFC 2047 encoding cannot be 
used because "an 'encoded-word' MUST NOT appear within a 
'quoted-string'" per RFC 2047 and on the other hand, per RFC 2616, 
"words of *TEXT (which 'quoted-string' consist of) MAY contain 
characters from character sets other than ISO-8859-1 only when encoded 
according to the rules of RFC 2047".  A dead end.

As for A1 value: it's not said anywhere in what byte representation the 
user name, password and realm should be read when establishing the A1 
octet array.  The same problem applies to basic authentication where a 
base64 string is built to carry the username:password pair, but it is 
not said anywhere in what character encoding or generally an encoding 
the source for base64 has to be.

For example of violation: Apache configuration utility program for 
configuring digest authentication database is taking the user name and 
the password directly as an argument from a terminal, in, often but not 
generally, UTF-8 encoding, pushing it to a hash function directly 
without any further translation.  The client side then should build A1 
string on it's side from UTF-8 encoded octet arrays.  The authentication 
mod seems to take the usename= directive value, used to create the A1 
string, "as is", in a byte representation sent by the client.  But, 
there is no way for the client to know, what encoding should be used 
when generating the headers.

My question is: should we disallow acceptance of a user name or password 
input in encoding different from ISO-8859-1 on the client side 
(independently on a server being setup for it, in any way) or should 
there be defined an extension to RFC 2617 allowing communication of the 
encoding between the client and the server?

For reference there are Mozilla platform bugs 
https://bugzilla.mozilla.org/show_bug.cgi?id=546330 and 
https://bugzilla.mozilla.org/show_bug.cgi?id=41489.

Sincerely,
Honza Bambas

---

From: Adam Barth <[email-masked]>
Date: Mon, 3 May 2010 14:12:11 -0700

Hi Honza,

Thanks for your message, but I think you might have meant to send it to
another mailing list.  Perhaps [email-masked]?  This working group is
about cookies, not about HTTP authentication.

Kind regards,
Adam

On Mon, May 3, 2010 at 11:54 AM, Honza Bambas <[email-masked]> wrote:

> ISO-8859-1.  Client implementations that have problems to communicate with
> such servers properly, obeying RFCs, because of missing specification of
> character encoding of a user name and a password in both 'basic' and
> 'digest' authentication scheme.  Specially building of the Authorization
> header and its username= directive value and building of A1 string.
>
> As for the username= directive value: it is by definition a 'quoted-string'
> that is unable to carry any information about its character encoding.  I
> have found any explicit information in RFC 2617 about a required character
> encoding for it.  RFC 2047 encoding cannot be used because "an
> 'encoded-word' MUST NOT appear within a 'quoted-string'" per RFC 2047 and on
> the other hand, per RFC 2616, "words of *TEXT (which 'quoted-string'
> consist of) MAY contain characters from character sets other than ISO-8859-1
> only when encoded according to the rules of RFC 2047".  A dead end.
>
> user name, password and realm should be read when establishing the A1 octet
> array.  The same problem applies to basic authentication where a base64
> string is built to carry the username:password pair, but it is not said
> anywhere in what character encoding or generally an encoding the source for
> base64 has to be.
>
> configuring digest authentication database is taking the user name and the
> password directly as an argument from a terminal, in, often but not
> generally, UTF-8 encoding, pushing it to a hash function directly without
> any further translation.  The client side then should build A1 string on
> it's side from UTF-8 encoded octet arrays.  The authentication mod seems to
> take the usename= directive value, used to create the A1 string, "as is", in
> a byte representation sent by the client.  But, there is no way for the
> client to know, what encoding should be used when generating the headers.
>
>
> (independently on a server being setup for it, in any way) or should there
> be defined an extension to RFC 2617 allowing communication of the encoding
> between the client and the server?
>
> _______________________________________________
> http-state mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-state
>
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 04 May 2010 08:57:45 +0200

On 03.05.2010 23:12, Adam Barth wrote:
> another mailing list.  Perhaps [email-masked]
> <mailto:[email-masked]>?  This working group is about cookies, not
> about HTTP authentication.
>
> Kind regards,
> Adam
> ...

The HTTPbis WG isn't revising the scheme definitions of RFC 2617 (at 
this point); but of course it's fine to discuss auth related issues on 
that mailing list.

This topic comes up every now and then (lately in Mozilla and Chromium 
bugs). As far as I understand, Basic authentication *could* be improved 
by adding a new auth-param, selecting a preferred encoding.

In theory, this could be deployed in a backwards-compatible way; old 
clients will (well, should) just ignore it, new clients can switch to a 
different encoding. What's needed is a spec, plus volunteers to 
implement this in at least one server framework and a few UAs.

Best regards, Julian