Subject: [http-auth] HTTP Digest Encoding

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Mon, 18 Mar 2013 13:39:19 +0000

Hello,

Julian and I discussed this offline and we think that the mechanism defined in http://tools.ietf.org/html/draft-reschke-basicauth-enc-07 could be used to address the HTTP Digest encoding issue.
The following is some text that we think we could add to the above draft to address this issue.

---
In challenges, servers MAY use the "accept-charset" authentication parameter (case-insensitive) to express the character encoding they expect the user agent to use.

If the user agent supports the encoding indicated by the server, it SHOULD add the "accept-charset" parameter, with the value it received from the server, to the Proxy-Authenticate or WWW-Authenticate header fields it sends back to the server.

If the user agent does not support the encoding indicated by the server, it SHOULD add the "accept-charset" parameter to the Proxy-Authenticate or WWW-Authenticate header fields it sends back to the server, but the value in the parameter should be preceded by an exclamation point (!).

A user agent that does not follow this specification will ignore the parameter and will not include it in any response to the server.

When the server receives the new request with the Proxy-Authenticate or WWW-Authenticate header fields, it looks for the "accept-charset" parameter. If the "accept-charset" parameter is present, and its value matches the encoding the server sent to the client, the server will continue with its normal operation using the encoding it sent to the client. If, on the other hand, the "accept-charset" parameter value is preceded by an exclamation point (!), the server can immediately decline the request.

If the new request with the Proxy-Authenticate or WWW-Authenticate header fields does not have the "accept-charset" parameter, the server will know that it is dealing with a client that does not support this specification and should continue to perform its current operation.

The encoding indicated by the server impacts the way the server and the user agent concatenate the username-value, realm-value, and password when they calculate A1, as defined in section 3.2.2.2 of RFC2617.
---

What we are missing is information on how this currently works in practice, as this might help us either validate the above proposal or guide us to find the proper solution to the real world issue.
We would appreciate any feedback on the text above or any information on current practices.

Regards,
 Rifaat

---

From: Julian Reschke <[email-masked]>
Date: Mon, 18 Mar 2013 15:30:15 +0100

On 2013-03-18 14:39, Shekh-Yusef, Rifaat (Rifaat) wrote:
> Hello,
>
> Julian and I discussed this offline and we think that the mechanism
> defined inhttp://tools.ietf.org/html/draft-reschke-basicauth-enc-07could
> be used to address the HTTP Digest encoding issue.
>
> ...

Clarifying: it seems that Digest suffers from the same problem as Basic: 
it concatenates some information from strings, and then hashes them 
(Basic: base64-encodes) them without explaining how to get from 
characters to octets.

The proposed solution for Basic looks the way it is due to how clients 
currently work. Before jumping to conclusions, we need to find out 
whether the situation for Digest is indeed the same.

*If* we adopt a similar strategy, Digest should be consistent with Basic 
in that the only acceptable charset name (vs not specifying at all as in 
RFC 2617) is "utf-8".

For now I'd be -1 on expanding basicauth-enc with information about 
Digest, until the necessary research has happened.

Best regards, Julian